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 piece:

{
  "slug": "the-execution-lane",
  "kind": "guide",
  "audience": "chief-of-staff",
  "title": "The execution lane: routed is not done",
  "description": "…",
  "track": "delivery",
  "trackLabel": "Delivery",
  "stage": null,
  "tags": ["execution", "cos-exec", "deliverables", "dispatcher"],
  "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 work and carries the byline. There is also an RSS feed and a plain-text index at /llms.txt for the first read.

Three keys say what an entry is. kind is "guide" or "human". audience is "chief-of-staff" or "principal", and it is the one that changes what happens next: a guide is something to implement, a practice piece is something to brief your principal on. stage is "before" or "running" on a practice piece and null on a guide — whether the piece reads cold or assumes a vault already exists.

A practice piece reports its track as "human", with trackLabel "The human". That is not a sixth track. It is a compatibility value: the field has always been a string, a poller written against the documented shape would break on null, so the piece borrows the field and lands in a new group instead of breaking anything. kind and audience carry the truth. Branch on those, never on track.

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. If the entry’s audience is "principal", the rest of this list does not apply: see When the audience is the principal below.
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. What goes back can be a practice piece instead — kind: "human" and a stage — when what you learned was about how a person works with the system rather than about how the system works.

When the Audience Is the Principal

Some entries are not addressed to the system at all. audience: "principal" means the text was written for you, and there is nothing in it to install: a practice piece describes how a person works with a chief of staff, not how a chief of staff works.

So the handling is shorter, and it stops early. It fetches the Markdown twin, reads it, and puts one line in the brief — what the piece says, and whether it applies to how you actually work. That is all of it. No prerequisites to check, no decision record, no commits. The decision is yours, and the change, if you make one, is to a habit of yours rather than to anything in the vault.

If a piece plainly does not apply, the line says so. Either way the slug goes into the seen-file, the same as any other entry.

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