Playbook Repo as Control-Loop Distribution
petrova intermediate 5 min read
ELI5
Petrova-hq is a recipe book, not a kitchen. It hands a fresh repo three pieces of paper — a workspace map, a phase schedule, and a delegation grammar — and that is enough for an agent session to know what to do next without anyone explaining the project from scratch.
Technical Deep Dive
What petrova-hq emits versus what consumers own
flowchart LR subgraph PH[petrova-hq — thin centre] P[core/prompts/00..04] T[core/templates/*.tmpl] M[META-RULES.md] R[registry.yaml] V[spec/verbs + cli/] end subgraph CR[consumer repo — project truth] C[CLAUDE.md] MS[MILESTONES.md] AX[AGENTS.xml] NS[docs/north-star/] DD[docs/decisions/] end P -->|paste 00-bootstrap| C P --> MS P --> AX T --> C T --> MS T --> AX M -->|copied verbatim| CR V -->|emits PRs into| CR R -.governs.-> CRThe control plane is deliberately thin (docs/decisions/2026-04-29-petrova-control-plane.md):
- Centralised: methodology (META-RULES, prompt set, template skeletons), the verb specifications that define what agent fleets may do, the
registry.yamlof governed repos, and the read-only cross-repo aggregator. - Not centralised: north-star intent, decision docs, milestones — these stay in the consumer repo so MR-7 (append-only, dated, in-repo) and MR-12 (CLAUDE.md is a projection, not a source) hold.
Why no build, no tests, no entrypoint
CLAUDE.md in the petrova-hq root says it explicitly: “Nothing here gets executed against a stack.” Edits in petrova-hq mutate the control loop that downstream repos run, not any product surface. That makes correctness about whether the prompt still stops at its checkpoints and whether the template still places its <<PLACEHOLDER>> tokens, not whether a server boots.
The bootstrap path
The user-facing entrypoint is 00-bootstrap.md. A human pastes it into a fresh Claude Code session opened on a consumer repo with detailed spec docs already present. The prompt:
- Reads ground truth (Phase 1 —
docs/spec/,README, scaffold). - Asks Q1–Q7 calibration questions.
- Generates
CLAUDE.md,MILESTONES.md,AGENTS.xml, plus thedocs/scaffold from the templates. - Self-audits against MR-1…MR-12.
After bootstrap, four further prompts (01-phase-open, 02-phase-close, 03-verification-round, 04-drift-check) drive the loop for the rest of the project’s life.
Distribution mechanism
Templates use <<PLACEHOLDER>> tokens; the bootstrap agent fills them from Phase 1 reads + Phase 2 answers. The two core/ subtrees are git submodules so methodology changes propagate to all consumers via a single submodule pointer bump.
Key Terms
- Control loop — the closed cycle of
phase open → implementer → auditor → reviewer → phase close → next phasethat the playbook’s prompts plus AGENTS.xml drive. - Thin centre — the architectural commitment that petrova-hq holds methodology only, never project intent.
- Consumer repo — any repo that has been registered in
registry.yamland adopts the three control-loop documents.
Q&A
Q: Why does petrova-hq deliberately ship no application code? A: Because the artefact it ships is a control loop, not a runtime. Adding a build target would invite drift toward “petrova as a framework” instead of “petrova as a methodology you instantiate per repo”.
Q: Which three documents does the playbook generate inside a consumer repo?
A: CLAUDE.md (workspace projection), MILESTONES.md (phase schedule with acceptance gates), and AGENTS.xml (delegation grammar with <spawns_on> triggers and <handoff_to> chains).
Q: What lives centralised vs what stays in each consumer repo?
A: Centralised: META-RULES, prompts, templates, verb specs, registry.yaml. Per-consumer: docs/north-star/, docs/decisions/, MILESTONES.md, the project’s own invariants I-N.
Examples
A new repo traceo-cat is added to the petrova line. The operator (1) opens a registry-update PR via petrova-onboard, (2) merges it so the slug becomes valid for the verb surface, (3) opens a Claude Code session in the consumer repo and pastes 00-bootstrap.md. After the bootstrap session, the consumer has its own CLAUDE.md, MILESTONES.md, AGENTS.xml, and docs/ scaffold — none of which lives back in petrova-hq.
neighbors on the map
- Prompt Artefact Directory Layout scaffolding a new prompt under prompts/
- Rocky Superproject Topology onboarding a new submodule into rocky-hq
- Graph Topology Snapshot authoring a new graph.json