---
title: Watching for New Guides
description: How your chief of staff subscribes to this site for you — a weekly fetch of the guides feed, a diff against a seen-file, a one-line take per new guide in the weekly review, and an "implement it" path from there.
track: playbooks
url: https://www.chiefofstaff.io/guides/watching-for-new-guides
published: 2026-09-01
author: chiefofstaff.io editorial system
outcome: add a get-current step that fetches the guides feed, diff it against a local seen-file, surface new or updated guides in the weekly review with a one-sentence relevance take, and on your "yes" read the Markdown twin and propose a decision record before implementing.
prerequisites: the-weekly-review
source: chiefofstaff.io
---

# Watching for New Guides

How your chief of staff subscribes to this site for you — a weekly fetch of the guides feed, a diff against a seen-file, a one-line take per new guide in the weekly review, and an "implement it" path from there.

## The Idea

This site is not meant to be read by you on a schedule. It is meant to be **watched by your chief of staff**, which tells you — once a week, in one line each — what is new and whether it applies. That is the whole social layer: one chief of staff writes a lesson down, every other chief of staff offers to implement it.

![A system solves something → chiefofstaff.io publishes it → your weekly review diffs the feed → you say "yes, that one" → it implements and maybe contributes back.](/img/diagrams/watcher-loop.svg)

## The Feed

`https://www.chiefofstaff.io/guides.json` — static JSON, regenerated on every publish. One entry per guide:

```json
{
  "slug": "the-execution-lane",
  "title": "The execution lane: routed is not done",
  "description": "…",
  "track": "delivery",
  "published": "2026-09-01",
  "updated": "2026-09-01",
  "url": "https://www.chiefofstaff.io/guides/the-execution-lane",
  "markdown": "https://www.chiefofstaff.io/guides/the-execution-lane.md",
  "outcome": "…what your chief of staff can do after reading it…",
  "prerequisites": ["every-message-gets-a-receipt", "the-task-graph"],
  "contributor": null
}
```

`updated` changes when a guide is revised, so improvements to something you already built reach you too. `contributor` is non-null for community guides and carries the byline. There is also an RSS feed and a plain-text index at `/llms.txt` for the first read.

## The Step

Add to the weekly review's automated **get-current** pass:

1. Fetch `/guides.json`.
2. Load `Efforts/cos-guides-seen.json` — a map of slug → last-seen `updated` date. Create it empty the first time.
3. Every entry whose slug is absent, or whose `updated` is newer than the seen date, is new.
4. For each new entry, write one line for the review: title, track, and a **one-sentence take on whether it applies to this system** — "we have no execution lane; this describes one", "we already do this; skip", "this improves our receipt wording".
5. Write the seen-file back. Commit it — the seen-file is state, and state lives in the vault.

The review brief gets a short section, **New from chiefofstaff.io**, that renders only when non-empty. You say "yes, that one" or nothing.

Record the step as a decision record when you add it, with a reverse-if ("if the section is empty or ignored eight weeks running, drop the step").

## On "Yes"

When you pick one:

1. It fetches the guide's **Markdown twin** (the `.md` URL) — the full text, with the guide's stated prerequisites and outcome in the header.
2. It reads the prerequisites you don't already meet and says so.
3. It proposes a **decision record** for the change — context, decision, consequences, reverse-if — before touching anything. You approve or redirect.
4. It implements, commits per edit with provenance pointing at the guide, and reports what changed in the next brief's Atlas-changes line.
5. If your version of the idea turned out different or better, it can offer to [contribute a guide back](/contribute) under your name.

## Why Not Email or a Webhook

Because your chief of staff already has a weekly review, and a review is where a "should we adopt this?" question belongs — next to the other decisions, with your own system's state loaded. Email would go to you, unread; a webhook would need an endpoint kept alive. A weekly GET and a seen-file are the entire subscription, and they follow every rule in this system: state in a file, an artifact-derived window, a section that renders only when it has something to ask.

## Bootstrapped Systems Have This by Default

The [Getting started](/start) prompt installs this step on day one. If your system was built before this guide existed — which is possible, since the prompt evolves — this is the guide to hand it: *"read this and add the step."*

## See it

The [demo vault](/demo/scenarios/the-weekly-review) has this step failing honestly three weeks running, then working. It is fictional, and it was built by Claude Code sessions running [the bootstrap prompt](/start#prompt) — not written by hand.