--- name: bootstrap-chief-of-staff description: 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 product or project manager. Triggers on requests like "set up a chief of staff for this project," "bootstrap a CoS for my repo," or "I want an AI that watches this project the way Zero-Bureaucracy describes." --- # Bootstrap a Chief of Staff 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 (`-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 -chief-of-staff && cd -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 already has its own specification, decision records, and issue tracker. This Spec Kit instance does not specify . It specifies the Chief of Staff that watches . 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 should build or how the team should be organized. Every claim the Chief of Staff makes about 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 with this coverage: - Product specification: (read-only; the Chief of Staff never edits it) - Decision records: - Issues: - Tests and acceptance evidence: - Meeting summaries: State explicitly what this Chief of Staff cannot see: . 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.