booping

booping

A self-learning, project-scoped sprint workflow for Claude Code. booping turns a feature idea into a durable, on-disk loop — groom → develop → retro → learn — that effectively utilizes sub-agents to avoid context rot and cross-validates each plan against Gemini before development begins. Every artifact (plans, retros, lessons, sprint snapshots) lives under ~/Claude/{project}/, one folder per codebase, so weeks-long programs stay legible long after the session ends.

Each project's vault is a plain Obsidian-friendly folder of markdown files.

Obsidian-ready by design

The vault at ~/Claude/{project}/ is markdown-only with YAML frontmatter that Obsidian renders natively as Properties. One vault per project, side-by-side with whatever else you keep in ~/Claude/. No proprietary database, no lock-in — just files you can grep, version, and edit by hand.

Disclaimer

booping is aimed at experienced developers and tech leads — people comfortable making architectural calls, decomposing work, and reviewing code critically. The skills assume you can tell a sharp plan from a vague one and a sound diff from a sloppy one.

It's built for iterative, agile-style development: maintenance, incremental features, or growing a project sprint by sprint. It is not a waterfall tool — don't hand it a whole-project spec and expect a finished product. One plan is one sprint; the loop compounds across many.

The framework is in beta. Per-project configuration is now live: place a ~/Claude/{project}/config.yaml file in your vault and it deep-merges over the plugin's src/config.yaml at render time — the lifecycle, sprint scale, and agent wiring are the natural targets for per-project tuning. The /code-review skill is now available as a side-route for stack-aware review of in-progress diffs against the active plan.

Dependencies

Required: uv and git. Optional: GEMINI_API_KEY environment variable for /groom cross-validation against Gemini.

# macOS
brew install uv git

# Linux (Debian/Ubuntu)
sudo apt install -y git
curl -LsSf https://astral.sh/uv/install.sh | sh

Installation

Inside Claude Code, register the marketplace once, then install the plugin:

/plugin marketplace add A/claude-booping
/plugin install booping@booping

Update later via /plugin update booping (or from the /plugin UI).

After installing, cd into the target repo and run /install. That single step scaffolds ~/Claude/{project}/ (with plans/, retrospectives/, lessons/, notes/, _booping/).

Quick start

For a hand-holding walkthrough and per-command reference, see the docs site.

The full loop is five commands. Run them in order:

# Inside the target repo, once:
/install

# Spec a feature, bug, or refactor — free-text description.
# The more detailed your brief, the sharper the resulting plan:
/groom Add per-tenant rate limiting to the public API

# Execute the next ready plan (auto-claims from the queue):
/develop
# …or target a specific one (path relative to ~/Claude/{project}/):
/develop plans/20260426-per-tenant-rate-limiting.md

# Retrospect on what shipped:
/retro plans/20260426-per-tenant-rate-limiting.md

# Fold the retro's findings into durable rules:
/learn retrospectives/20260426-per-tenant-rate-limiting.md

The skills will list candidates if you forget the exact filename.

Workflow

A plan moves through a small set of statuses. /groom shapes the spec and waits for explicit user approval before handing off; /develop claims the next ready plan and executes milestone by milestone; /retro compares what shipped to the original spec; /learn distils the retrospective into rules that bind the next sprint.

The status vocabulary below is the canonical set in src/config.yaml plan.statuses:

/groom    backlog → in-spec → awaiting-plan-review → ready-for-dev
          (loopback: awaiting-plan-review → in-spec)
          (parking: in-spec → backlog)
          (cancellation: backlog/in-spec/awaiting-plan-review → cancelled)

/develop  ready-for-dev → in-progress → awaiting-retro
          (failure: in-progress → fail)

/retro    awaiting-retro → awaiting-learning
          (skip: awaiting-retro → done)

/learn    awaiting-learning → done

Terminal states: cancelled · done · fail

Statuses

A plan carries one of the following statuses in its frontmatter. Terminal states are marked.