Watching for New Guides

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.

The Feed

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

{
  "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 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 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 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 — not written by hand.

#feed · #subscribe · #weekly-review · #meta