decaf-claude

Run parallel code review agents and consolidate findings into a unified report

Capture a follow-up idea or task as a work-item draft without interrupting current work. Use to quickly jot down something you think of mid-task so it gets tracked. Works with nibs, GitHub, Azure DevOps, or a Markdown fallback.

Take an under-specified work item and make it actionable — resolve its open questions through a short interview grounded in the code, and give it acceptance criteria. Use on a captured draft, or any item too vague to start on.

Reconcile what was built against what was planned, record decisions and deviations, close the item (a single phase or a whole plan), and file follow-ups for deferred work. Use after finishing a phase or plan to keep planned and actual from drifting apart.

Orchestrate execution of MULTIPLE nibs in one run. Selects a queue, understands the nibs collectively (including how they fit together), then chooses the best execution mechanism per cluster — single series agent, parallel fan-out, scripted workflow, or agent team — and dispatches with ONE approval gate. Use when the user wants to work several nibs together (in parallel or series) rather than one at a time. Complements /decaf-build:auto-dev and /decaf-build:auto-tdd (which handle a single nib).

Direct development with automated review. Plans implementation, executes via subagent, then auto-reviews. Use for work that isn't test-driven (UI, config, styling, infrastructure, scaffolding).

TDD-first development with automated review. Runs a TDD session (plan → red-green-refactor) then auto-review on the result. Use when building features test-first with quality gates.

Automated review-fix-recheck loop. Runs code review, triages findings, fixes autonomously via subagent, and re-reviews if substantial changes were made. Iterates until code stabilizes.

Autonomously drive a whole plan to completion — loop SELECT → BREAKDOWN → EXECUTE → VERIFY → RECONCILE → LEARN → REPLAN → MERGE, one phase at a time, WITHOUT stopping at phase boundaries. Use when you have a phased plan (work items in a tracker) and want it built end-to-end unattended. Stops only when the plan is complete (or it genuinely cannot proceed).

Stress-test a decision you're about to make by arguing against it — decompose it into claims/assumptions/constraints, verify each, steel-man the strongest case for the opposite, and return a STAND/REVISE/ESCALATE verdict. Use before committing to architectural choices, technology selection, or tradeoffs.

Audit a codebase for places where documentation, specs, comments, config, names, or versions disagree with the actual code, then resolve each (update docs, flag code, or accept). Use for documentation/spec audits, after major changes, or before a release.

Investigate why something is broken and identify the root cause through competing hypotheses and evidence — diagnoses only, never proposes fixes. Use before attempting a fix, when the cause isn't obvious.

Explore a codebase for structural and testability improvements — deepening shallow modules, untangling tight coupling — and write up recommendations (RFCs), not code changes. Use when you want to find architecture-level improvements rather than fix specific lines of code.

Interview the user one decision at a time to stress-test a plan or design until it holds up. Use when you want to pressure-test an idea, find the weak points in a plan, or be grilled on a design before committing to it.

Walk through architecture-review proposals one at a time, designing the interface and writing an RFC for each. Use after architecture-review to turn its candidates into concrete RFCs.

Run code coverage analysis and review gaps for severity and test suggestions

Analyze code for structural improvement opportunities and produce a prioritized refactoring plan

Walk through code review findings one at a time and decide a resolution for each — fix, skip, dismiss, or defer. Use "auto" for autonomous resolution with TDD.

Walk through coverage review gaps one at a time and decide a resolution for each — write tests, skip, dismiss, or defer. Use "auto" for autonomous test-writing.

Walk through refactoring plan opportunities one at a time and decide a resolution for each — apply, apply incrementally, skip, dismiss, or defer. Use "auto" for autonomous application.

Break one phase of a plan into concrete, buildable features, each with a done-checklist. Use when you're about to start a phase and need it decomposed into work items with acceptance criteria.

Turn a spec into an ordered, phased build plan and create the work-item nibs for it. Use when you have a spec (PRD) and need to break it into vertical-slice phases (tracer bullets) ready to implement.

Interview the user and explore the code to write a spec (PRD) — what to build and why. Use when starting a new feature and you need to capture the problem, solution, and requirements before planning how to build it.

Generate several radically different designs for a decision — from a single method up to a whole architecture — then compare them and write up the one you choose (the "design it twice" habit). Use when a design choice is open and you want real alternatives before committing.

Dig into an unfamiliar problem or technology from several angles and write up what you find. Use before drafting a spec, when the domain, tools, or trade-offs aren't well understood yet.

Test-driven development with red-green-refactor loop. Use when user wants to build features or fix bugs using TDD, mentions "red-green-refactor", wants integration tests, or asks for test-first development.

Walk through unresolved PR review feedback and decide a resolution for each thread — fix, reply, decline with evidence, or escalate. Works with Azure DevOps and GitHub. Use "auto" for autonomous resolution; replies are drafted and approved before posting.

Open the erinra memory dashboard in the browser

Search erinra for stored memories

Manually load erinra session context — use when the automatic startup hook didn't trigger the call

Store a memory in erinra for future reference