Vault

Every booping project gets its own vault at ~/Claude/{project}/, scaffolded by /install. The vault is plain markdown with YAML frontmatter — open the directory in Obsidian for graph view and backlinks across plans, retros, and lessons.

This page is the reference for every file and directory inside the vault. For the lifecycle that ties them together, start at Quick start.

plans/

Sprint plans live here as {YYYYMMDD}-{kebab-title}.md. Each plan carries a YAML frontmatter (status, type, story points, business goal, etc.) and a body of milestones with tasks. Authored by /groom, executed by /develop.

A plan walks the status table from backlog / in-spec through awaiting-plan-review, ready-for-dev, in-progress, awaiting-retro, awaiting-learning, to done. Status transitions are manual frontmatter edits performed by the owning skill — no CLI mutates them.

Sibling stubs created by a /groom-driven split point at the primary plan via split_from: plans/... in their frontmatter.

retrospectives/

Retrospectives written by /retro, one per shipped plan. Same {YYYYMMDD}-{kebab-title}.md filename shape as the plan they cover, so files line up alphabetically.

A retro records what actually shipped vs. the original spec, divergences, and the tensions you flagged during /develop. It is the input to /learn.

lessons/

Durable, project-wide rules accumulated over many sprints. Files are named {N}_{title}.md where N is a monotonic counter so the directory stays ordered chronologically.

Authored by /learn from confirmed retro findings. Loaded by every skill's Preflight on every invocation, so lessons accumulate into the active context for /groom and /develop automatically.

notes/

Free-form user notes — plan-review comments, code-review threads, ideas for next sprints, anything else. Skills and agents do not read this directory. It is purely a scratchpad for you, kept in the same vault for convenience and Obsidian graph visibility.

_booping/skill_<name>.md

Per-skill extension file. Loaded automatically into the matching skill's context at invocation time, so the project's local conventions reach /groom, /develop, etc. without you having to restate them. Authored and updated by /learn — do not hand-edit unless you know what /learn would have written.

_booping/agent_<full-agent-name>.md

Per-agent extension file. Injected into the matching worker agent's body at agent load time, so subagents inherit project rules without separate reads. The filename uses the agent's full name (which starts with booping-) — e.g. _booping/agent_booping-developer.md, _booping/agent_booping-researcher.md. Authored and updated by /learn.

plan_templates/

Project-local plan templates. Each file has frontmatter (name, description) plus two top-level sections (# Plan Body, # Quality Checklist). Discovered by /groom alongside the core templates that ship with the plugin; can override a core template by sharing its name, or add entirely new template flavours suited to the project.

review_templates/

Project-local code-review templates. Loaded by /code-review alongside the core templates; the skill picks the matching subset by inspecting the repo's manifests and reading each template's description frontmatter. Use this directory to add review checklists specific to your stack or domain.

sprints.md

A snapshot of every plan in the vault, grouped by status — the at-a-glance view of where the project sits.

Regenerated by the CLI; never hand-edit. It is rendered by bin/booping render-sprints (template src/templates/sprints.md.j2) from the live plan files. /chat refreshes it on orient. Any manual edit will be overwritten on the next refresh.

config.yaml

Optional per-project override for the plugin's src/config.yaml. Deep-merges over the plugin defaults at render time (no rebuild step): dict keys merge, list keys replace wholesale. The natural targets for per-project tuning are the lifecycle, sprint scale, and agent wiring.

See Project config for the full key tour and override mechanics.