Use when working on beads from a specific epic, or when asked to "do a bead from
Claim and complete ONE bead from a specified epic, then stop.
/execute-epic <epic-id> - The epic to pull the next bead from (e.g., bd-qz97)
Before claiming, understand the landscape:
bd prime # full workflow state
bd ready # what's available
jj log --limit 20 # recent work
Filter to the epic:
bd show <epic-id> # understand the epic
bd list --parent=<epic-id> # beads in this epic
Before writing new types, traits, errors, or tests, read the relevant doc in docs/philosophy/:
type_design.md - typestate, parse-don't-validateerror_design.md - error context, propagationtrait_design.md - trait boundaries, coherencetest_design.md - test structure, property-based testingBefore writing code, read the essay in docs/philosophy/scatter.md .
Pick the next bead from the epic. Justify:
Then proceed immediately to execution.
bd show <bead-id> # understand it fully
bd claim <bead-id> # own it
jj is not git. No staging area - working copy IS the commit.
The loop (runs MANY times per bead):
jj new
# edit ONE thing (add a fn, write a test, fix a bug)
jj describe "<bead-id>: what you did"
# repeat
Heuristics:
jj split.Every commit message includes the bead ID. 3-15 commits per bead is normal. 1 commit = batched too much.
If there are uncommitted changes when you start:
jj describe them with what they actually areRun proactively and often - not just at verification:
cargo check
cargo clippy -- -D warnings
cargo test
Run tests after writing them. Don't wait until the end.
Verify:
Acceptance criteria met - re-read the bead, check each item
Philosophy compliance:
Tests pass:
If verification uncovers issues, use the same jj rhythm. jj new -> fix -> jj describe -> repeat.
Then close:
bd close <bead-id>
When you encounter ANY of these, file a P2 bead immediately:
bd create "Brief description" --priority=2 --type=task
Don't fix it now unless blocking. File it, keep going.
After the bead is closed:
bd ready