Read time: 10 minutes. You know Claude Code. Your repo has the plugin installed and /sdlc:setup done.
You start from an accepted spec.md, not a ticket. Claude plans in plan mode with you, you accept the plan,
Claude implements with a feedback loop (build, test, lint after each step), keeps the plan honest, checks its
own work with a fresh-eyes verifier, and opens the pull request. Hooks stop it touching protected paths,
secrets, or tests during a fix. Review runs automatically in CI; you shepherd the PR to green; a code owner
approves. Your job moves from typing to steering and reviewing, and you can run several streams at once.
/sdlc:status where is everything, what is waiting on me
/sdlc:plan <change-id> plan mode → plan.md (accepted by you)
/sdlc:build implement the accepted plan → PR
/sdlc:verify run build/test/lint with the configured commands, paste the proof
/sdlc:verify --fix "<bug>" failing test first, tests locked, then the fix
/sdlc:verify --ui <mock> implement → screenshot → compare → adjust
/sdlc:babysit <PR> sweep comments and failing checks until green
/sdlc:plan 2026-06-02-claims-status-self-service. Claude enters plan mode (it cannot edit files),
reads spec.md, intent.md, CLAUDE.md and the code, and interviews you: files to change, reuse, order,
which tests prove which acceptance criterion. It drafts plan.md and then must answer: what could break,
which step is riskiest, what options it rejected. Push back until an engineer who never saw the
conversation could implement from the plan alone. Accept. The plan is committed; .sdlc/current records
the active change. risk: high plans also need a tech lead’s approval; Claude will say so and stop./sdlc:build. Claude follows “Order of work”, runs the configured checks after each step, fixes
code (never tests), and appends any departure to plan.md in the same commit. Commits carry
SDLC-Change: <id>. At the end it runs the verifier subagent, then opens a PR whose description contains
Change: sdlc/changes/<id>, the proof output, and departures./sdlc:babysit <PR> addresses comments and failing checks, pushes, replies, and stops
when only the code owner’s approval remains. It will not approve or merge.Blocked: 'src/gen/ClaimsClient.ts' is protected (src/gen/**). Generated code. Change the generator or schema
instead. Route to approval: platform team. ...
Every block says why and how to get approval. Follow the route; do not work around the hook.
/sdlc:verify --fix "status panel shows yesterday's date": Claude reproduces the bug as a failing test, confirms
it fails for the expected reason, commits the test alone, writes .sdlc/fix-lock, and only then fixes. While the
lock exists the test-guard hook blocks any edit to test files. If the test itself is wrong, Claude tells you;
you remove the lock deliberately and the reason goes in the plan.
The plan marks tasks that touch different files. Run each in its own worktree: claude --worktree task-a, then
/sdlc:build --task 1 inside it. Start with two or three sessions; add more only while your review keeps up.
Tasks that share files stay in one session.
If code changed under an active change and plan.md was not updated, the Stop hook asks you to either add the
departure or state “plan.md: unchanged, implementation matches the plan”. That keeps review honest.
Accept the plan. Decide when a departure is right. Remove a fix lock. Judge a review comment as wrong.
Approve or merge your own PR, deploy to production, or edit tests to make checks pass. Hooks and settings prevent the first and last; the release manager owns the middle.
CLAUDE.md (“Things Claude gets wrong”).