The compound engineering loop — five discrete stages that systematically reduce rework by front-loading clarity and back-loading lessons. Each stage can be run independently or in sequence.
Git Root Detection
Before running any command, detect the git root:
git rev-parse --show-toplevel
Commands
| Command | Description |
|---|---|
brainstorm |
Clarify scope through dialogue, surface key decisions and open questions |
plan |
Research codebase, write concrete implementation plan |
work |
Execute the plan, track progress in task backend |
review |
Evaluate output, identify lessons, decide accept/rework |
compound |
Document lessons, update rules/templates/docs |
spec <topic> |
Create outcome spec (overview, decisions, steps, edge cases) |
audit |
Review current branch for blindspots; fix now / needs spec / create issues |
$ARGUMENTS Routing
| $ARGUMENTS | Action |
|---|---|
help |
→ commands/help.md |
brainstorm |
→ commands/brainstorm.md |
plan |
→ commands/plan.md |
work |
→ commands/work.md |
review |
→ commands/review.md |
compound |
→ commands/compound.md |
spec |
→ commands/spec.md |
audit |
→ commands/audit.md |
| (empty) | → commands/help.md |
Stage Task Naming
Each stage creates or updates a task in the configured backend (if tasks != none). Tasks follow the naming convention (no stage numbers):
YYYY-MM-DD, <Stage>
e.g. 2026-02-28, Brainstorm, 2026-02-28, Plan, 2026-02-28, Compound — <topic>
Tasks are created under the relevant workstream epic if one exists.
Frustration Detection
If the user shows signs of repeated fixes, confusion, or rework — proactively suggest running work compound even mid-stream. The value of compound is in capturing lessons before they fade.
Design Note
80% of the compound loop's value comes from plan and review. work is execution. Do not skip plan — scope creep and rework almost always trace back to an unclear plan.