Vault

Every booping project gets its own vault, scaffolded by /install. By default it lives at ~/Claude/{project}/; you can instead keep it inside the repo (a local vault) by setting the .booping marker's vault_path: key. 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, a one-line summary, 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. The owning skill moves a plan by running a booping transition command, which performs the status change and every mechanical mutation it entails in one step.

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.

/install always seeds _booping/agent_booping-developer.md, and seeds the two skill files only when the project carries local signal the repo CLAUDE.md does not already own — otherwise it skips them:

_booping/agent_booping-developer.md — stack + conventions for the developer agent (always seeded).
_booping/skill_groom.md — a project-local groom override the repo CLAUDE.md doesn't carry (e.g. a sizing override); seeded only when such signal exists.
_booping/skill_develop.md — project-local dev signal the repo CLAUDE.md lacks (e.g. env / service notes); seeded only when such signal exists.

/learn keeps whatever is seeded current as the project accumulates lessons; the seeds are just a starting point.

`_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.

It is a snapshot, not a live view: nothing auto-refreshes it on a plan write today, so it can drift between /chat orients as other skills transition plans. Treat the plan files as the source of truth and re-run /chat (or bin/booping render-sprints) when you need a current picture. An auto-refresh hook is planned but not yet wired.

`.booping`

The marker that ties a repo to its vault. Unlike everything else on this page, .booping lives in the attached repo's working tree (its root), not inside the vault. It is written by /install and carries the project_name: {project} key — how every skill resolves which vault to operate on. It may also carry an optional vault_path: key: when present, the vault resolves to that path (relative paths against the repo root, absolute paths and ~ honoured) instead of ~/Claude/{project}/ — this is how a repo-local vault is wired. Commit .booping with the repo so the binding travels with the checkout.

`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.