Bootstrap a Chief of Staff

Use this skill when the user wants to set up an AI Chief of Staff for a software project - a persistent reasoning layer that watches a repository's specifications, decisions, issues, tests, and meetings, and reconciles them, without becoming the project's…

This skill is Labor as Code™ for one chapter of Zero-Bureaucracy Product and Project Management: "Setting It Up Takes an Afternoon and Five Commands." Read that chapter for the reasoning behind every step below — the worked example there (a product called Referral Bridge) is the specific case this skill generalizes. This skill only executes the method; it does not carry the argument for why the method works. It also does not decide anything the chapter leaves to a human: which repository to watch, what the Chief of Staff may see, and whether a given ambiguity gets resolved are always the user's calls, not this skill's.

Before running

Confirm with the user, in plain conversation, before creating anything:

1. Which repository the Chief of Staff will watch (call it the product repo). It should already have, or be about to get, its own specification, decision records, and issue tracker. A Chief of Staff with no product repo to point at has nothing to be canonical about — do not proceed without a real answer here.
2. Where the Chief of Staff's own repository should live. Default: a sibling directory next to the product repo (<product-repo>-chief-of-staff/), matching the book's own Referral Bridge example. If the user wants it somewhere else (a portfolio Chief of Staff watching several repos, say), follow their answer instead of this default.
3. What the Chief of Staff is explicitly not allowed to see — a private ticket system, private email, anything the user wants kept out. State it in the constitution; do not guess it.

Steps

1. Create the empty repository:

   mkdir <product-repo>-chief-of-staff && cd <product-repo>-chief-of-staff
   git init
   specify init --here
   

2. Run /constitution, filling in this template with the real product repo's name and the user's answer to "what can't it see":

   /constitution
   
   <PRODUCT_REPO> already has its own specification, decision records,
   and issue tracker. This Spec Kit instance does not specify
   <PRODUCT_REPO>. It specifies the Chief of Staff that watches
   <PRODUCT_REPO>.
   
   The Chief of Staff's jobs are memory, classification, reconciliation,
   questioning, drafting, and escalation. It remembers, reconciles,
   audits, drafts, questions, and escalates. It never decides, accepts,
   or rejects on a human's behalf, and it is not a project manager or a
   product manager: it does not choose what <PRODUCT_REPO> should build
   or how the team should be organized.
   
   Every claim the Chief of Staff makes about <PRODUCT_REPO> must trace
   to a source outside this repository. This repository is canonical
   only for the Chief of Staff's own doctrine, audit rules, escalation
   rules, and current state. It is never a second copy of anything that
   is already canonical somewhere else.
   

3. Run /specify, listing the product repo's actual coverage — real paths or a real issue-tracker URL, not placeholders left unfilled:

   /specify
   
   Specify a Chief of Staff for <PRODUCT_REPO> with this coverage:
   
   - Product specification: <path> (read-only; the Chief of Staff
     never edits it)
   - Decision records: <path>
   - Issues: <issue tracker URL or location>
   - Tests and acceptance evidence: <path>
   - Meeting summaries: <path>
   
   State explicitly what this Chief of Staff cannot see: <the user's
   answer from step 3 above>.
   
   Specify six triggers: after a meeting, before substantial
   engineering work, on a pull request, daily, weekly, and when
   customer evidence arrives. For each, specify what it does and what
   it is not authorized to do on its own.
   

4. Run /plan and /tasks the same way any other Spec Kit feature would: /plan turns the specification into a concrete approach (which files, which trigger wires to which prompt); /tasks breaks that into small, sequenced units.

5. Run /implement. Confirm the result contains exactly: constitution.md, doctrine.md, audit-rules.md, escalation-rules.md, sources.md, current-state.md, and a bzo/ directory holding generated views and a small presentation layer — nothing else. If /implement produced anything that reads like new product intent (a requirement, a decision, a specification of its own) rather than a pointer to something already canonical in the product repo, stop and fix it before continuing.

The sources.md check — do not skip this

Every row in the generated sources.md MUST be one of:

• A path or URL pointing at something already canonical in the product repo (its specification, its decision records, its issue tracker, its tests, its meeting summaries).
• One of the four names canonical to the Chief of Staff's own repository, as the book's own sources.md lists them: doctrine.md, audit-rules.md, escalation-rules.md, or current-state.md. Views under bzo/ are generated from these sources, so they never appear in sources.md as a source.

If a row is neither of those, it is a duplicate in the making — the exact failure mode the book calls out: a Chief of Staff that quietly becomes a second, competing home for the product's own intent. Fix sources.md before telling the user the Chief of Staff is ready, not after.

After bootstrap: this skill's job is done

Wire the six triggers to the prompts in Zero-Bureaucracy Product and Project Management's Appendix A (Prompt Library) — a daily exception audit, a weekly review, a meeting-classification pass, and the rest. Operating a Chief of Staff day to day is that appendix's subject, and the subject of "The Playbook Has to Fit in Human Memory" in "Setting It Up Takes an Afternoon and Five Commands," not this skill's. This skill's only job is getting from an empty harness to a correctly scoped Chief of Staff without it turning into an unaccountable project manager along the way.