{"id":50951478,"url":"https://github.com/a/claude-booping","last_synced_at":"2026-06-18T02:02:53.026Z","repository":{"id":354132244,"uuid":"1216947856","full_name":"A/claude-booping","owner":"A","description":"Self-learning scrum workflow for Claude Code","archived":false,"fork":false,"pushed_at":"2026-06-14T05:38:21.000Z","size":3552,"stargazers_count":8,"open_issues_count":0,"forks_count":1,"subscribers_count":0,"default_branch":"master","last_synced_at":"2026-06-14T07:20:49.855Z","etag":null,"topics":["agentic-workflow","claude-code","claude-skills","vibe-coding"],"latest_commit_sha":null,"homepage":"https://a.github.io/claude-booping/","language":"Jinja","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/A.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null,"notice":null,"maintainers":null,"copyright":null,"agents":null,"dco":null,"cla":null}},"created_at":"2026-04-21T11:48:14.000Z","updated_at":"2026-06-14T05:36:59.000Z","dependencies_parsed_at":null,"dependency_job_id":null,"html_url":"https://github.com/A/claude-booping","commit_stats":null,"previous_names":["a/claude-booping"],"tags_count":3,"template":false,"template_full_name":null,"purl":"pkg:github/A/claude-booping","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/A%2Fclaude-booping","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/A%2Fclaude-booping/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/A%2Fclaude-booping/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/A%2Fclaude-booping/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/A","download_url":"https://codeload.github.com/A/claude-booping/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/A%2Fclaude-booping/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":34472826,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-05-26T15:22:16.424Z","status":"online","status_checked_at":"2026-06-18T02:00:06.871Z","response_time":128,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["agentic-workflow","claude-code","claude-skills","vibe-coding"],"created_at":"2026-06-18T02:02:50.457Z","updated_at":"2026-06-18T02:02:53.012Z","avatar_url":"https://github.com/A.png","language":"Jinja","funding_links":[],"categories":[],"sub_categories":[],"readme":"# booping\n\nA 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.\n\n![Vault open in Obsidian](docs/images/vault-in-obsidian.webp)\n\n*Each project's vault is a plain Obsidian-friendly folder of markdown files.*\n\n## Obsidian-ready by design\n\nThe 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.\n\n## Disclaimer\n\nbooping 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.\n\nIt'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.\n\nThe 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.\n\n## Dependencies\n\nRequired: `uv` and `git`. Optional: `GEMINI_API_KEY` environment variable for `/groom` cross-validation against Gemini.\n\n```bash\n# macOS\nbrew install uv git\n\n# Linux (Debian/Ubuntu)\nsudo apt install -y git\ncurl -LsSf https://astral.sh/uv/install.sh | sh\n```\n\n## Installation\n\nInside Claude Code, register the marketplace once, then install the plugin:\n\n```\n/plugin marketplace add A/claude-booping\n/plugin install booping@booping\n```\n\nUpdate later via `/plugin update booping` (or from the `/plugin` UI).\n\nAfter installing, `cd` into the target repo and run `/install`. That single step scaffolds `~/Claude/{project}/` (with `plans/`, `retrospectives/`, `lessons/`, `notes/`, `_booping/`).\n\n## Quick start\n\nFor a hand-holding walkthrough and per-command reference, see the [docs site](https://A.github.io/claude-booping/).\n\nThe full loop is five commands. Run them in order:\n\n```bash\n# Inside the target repo, once:\n/install\n\n# Spec a feature, bug, or refactor — free-text description.\n# The more detailed your brief, the sharper the resulting plan:\n/groom Add per-tenant rate limiting to the public API\n\n# Execute the next ready plan (auto-claims from the queue):\n/develop\n# …or target a specific one (path relative to ~/Claude/{project}/):\n/develop plans/20260426-per-tenant-rate-limiting.md\n\n# Retrospect on what shipped:\n/retro plans/20260426-per-tenant-rate-limiting.md\n\n# Fold the retro's findings into durable rules:\n/learn retrospectives/20260426-per-tenant-rate-limiting.md\n```\n\nThe skills will list candidates if you forget the exact filename.\n\n## Workflow\n\nA 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.\n\nThe status vocabulary below is the canonical set in `src/config.yaml` `plan.statuses`:\n\n```text\n/groom    backlog → in-spec → awaiting-plan-review → ready-for-dev\n          (loopback: awaiting-plan-review → in-spec)\n          (parking: in-spec → backlog)\n          (cancellation: backlog/in-spec/awaiting-plan-review → cancelled)\n\n/develop  ready-for-dev → in-progress → awaiting-retro\n          (failure: in-progress → fail)\n\n/retro    awaiting-retro → awaiting-learning\n          (skip: awaiting-retro → done)\n\n/learn    awaiting-learning → done\n\nTerminal states: cancelled · done · fail\n```\n\n## Statuses\n\nA plan carries one of the following statuses in its frontmatter. Terminal states are marked.\n\n- **`backlog`** — Parked plan. Split-sibling stubs and user-filed ideas not yet in grooming.\n- **`in-spec`** — `/groom` is actively researching, designing, and drafting.\n- **`awaiting-plan-review`** — Draft complete; `/groom` is presenting and awaiting explicit user approval, change request, or cancellation.\n- **`ready-for-dev`** — Approved. Queued for `/develop` to claim.\n- **`in-progress`** — `/develop` has claimed the plan and is executing milestones.\n- **`awaiting-retro`** — All milestones done; waiting for `/retro` to write the retrospective.\n- **`awaiting-learning`** — Retro written; waiting for `/learn` to absorb lessons.\n- **`done`** *(terminal)* — `/learn` has absorbed all lessons.\n- **`cancelled`** *(terminal)* — User shelved the plan.\n- **`fail`** *(terminal)* — `/develop` hit an unrecoverable blocker.\n\n`src/config.yaml` `plan.statuses` is the canonical contract for the full transition table — including triggers (`when`), gates, artifacts, and `on_exit` mutations. Read it there if you need the exact rules; this README only narrates them.\n\n## Sprints \u0026 SPs\n\nIn booping, a **plan is a sprint** — the unit `/groom` produces and `/develop` executes end-to-end. Story Points (SP) measure the sprint's **complexity and review burden**, not effort or time. A 20-SP sprint might take a couple of hours on one project, a full session on another, and a full day on a third; what matters is that SPs give you a feel for the size and review weight of the sprint, independent of how fast the underlying work happens.\n\nThe 1–5 scale (`src/config.yaml` `sprint.scale`):\n\n- **1 SP** — Simple text/config change, no risk.\n- **2 SP** — Simple task, predictable, no risk.\n- **3 SP** — Medium task, minor risks but predictable overall.\n- **4 SP** — Complex task, medium risk, may need small research but clear enough.\n- **5 SP** — Research task — developer needs to clarify and decompose further before proceeding.\n\nIn practice, sprints over **35 SP** (`sprint.default_threshold_sp`) get hard to keep reviewable, so `/groom` ends up suggesting a split into sibling sprints above that mark. It's a soft cap, **not a velocity** — booping has no fixed cadence and no per-week capacity. Tasks at 5 SP must be re-decomposed; tasks at 1 SP should be grouped into a single agent briefing.\n\n## Extensibility\n\nWide-domain skills stay stack-agnostic. Project-specific concerns live entirely in your vault:\n\n- **`~/Claude/{project}/_booping/skill_\u003cname\u003e.md`** — per-skill extension. Loaded automatically into the skill's context at invocation. Use it to teach `/groom` your codebase's conventions or `/develop` your test runner.\n- **`~/Claude/{project}/_booping/agent_\u003cname\u003e.md`** — per-agent extension. Injected into the matching agent's body at load time so worker agents inherit project rules without separate reads.\n- **`~/Claude/{project}/plan_templates/*.md`** — project-local plan templates. Discovered alongside the core templates (`backend`, `frontend`, `claude-skill`, `cli`); can override a core one by sharing its `name` or add entirely new ones.\n- **`~/Claude/{project}/review_templates/*.md`** — project-local code-review templates. Loaded by `/code-review` alongside the core templates (`coding-architecture`, `python`, `security`); the skill picks the matching subset by inspecting the repo's manifests and reading each template's `description` frontmatter.\n- **`~/Claude/{project}/lessons/`** — accumulated rules from `/learn`. Read by skills' Preflight on every invocation.\n\n## Learning\n\n`/retro` and `/learn` are the loop that makes booping worth more than the sum of its sprints.\n\n`/retro` reads the plan, scans the session logs and git diff for what actually shipped, and writes a retrospective at `~/Claude/{project}/retrospectives/YYYYMMDD-{kebab-title}.md` — what worked, what didn't, divergences from spec, the business goal outcome.\n\n`/learn` then reviews the retrospective with the user, picks the durable findings, and writes them into two surfaces: project-wide lessons (`~/Claude/{project}/lessons/{N}_{title}.md`) and extra instructions for the matching skill or agent (`~/Claude/{project}/_booping/skill_\u003cname\u003e.md`, `_booping/agent_\u003cname\u003e.md`). Lessons are loaded by future `/groom` and `/develop` invocations; extension files travel with the matching skill or agent at load time. The user confirms each finding before it lands.\n\n## What booping doesn't do\n\nbooping is a feedback loop, not an autopilot. Three things stay your job:\n\n- **Plan review is still on you.** `/groom` produces a draft and waits at `awaiting-plan-review` for a reason — sharpen it, push back, ask for splits. As lessons accumulate, plans drift toward your style and constraints, but only if you fed the loop honest reviews. Shit in, shit out.\n- **Code review is still on you.** `/develop` ships milestones; you own the quality bar. `/code-review` is a helper that runs stack-aware passes against the in-progress diff and surfaces findings — but reading those findings, deciding what's off, and bringing the feedback into `/retro` so `/learn` can turn it into rules is still your job.\n- **Learning isn't automatic.** `/retro` and `/learn` are scaffolding for a feedback loop, not a substitute for one. You still need to sit with the retrospective, confirm which findings are durable, and let `/learn` write them down. Skip that step and the loop stalls.\n\nInvest in the loop and it compounds. Treat it as a magic box and you'll get magic-box results.\n\n## License\n\nMIT — see [LICENSE](LICENSE).\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fa%2Fclaude-booping","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fa%2Fclaude-booping","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fa%2Fclaude-booping/lists"}