The rules for getting a task from to-do to committed. See
PLANNING_GUIDE.mdfor how to create the plan and tracker.
These rules do not depend on who does the work. They hold when the user
writes the code by hand, when Claude writes it on request, and when the
automated loop in TASK_LOOP.md runs it. That loop is a machine built on these
rules — it mechanizes them and adds a way to delegate one action (the commit).
It is not an alternative set of rules, and this document does not describe it.
- By hand — the user writes the code. Nothing here constrains that; the rules describe what makes a task finished, not who types.
- On request — Claude implements, presents, the user reviews and commits.
- Through the loop — where a project has
.review/, this is the default path for task work, with or without the skill name being typed. SeeTASK_LOOP.md.
Default means default: any change can be made outside the loop on request, without a reason. "Just make this change", "skip the review", "I'll write it myself" are complete instructions — follow them and do not re-propose the loop. What is not optional is honesty about what actually ran; never present a partial run as a completed one.
A project that sets up .review/ without adding the routing block to its
CLAUDE.md gets the worst case: a loop that exists and is never invoked.
/maintain --init installs it.
Tasks are executed one at a time. Never batch multiple tasks into a single work unit.
The shape of every task:
- Pick the next task — the next unblocked
💡 to-do - Do the work — implement, test, verify exit criteria
- Stop and present — show what changed, mark the task
✅ done - The user reviews — and decides whether the task is actually finished
- The change is committed — after that decision, never before it
- Repeat — the next task starts only once this one is settled
Steps 4 and 5 are the only ones the loop changes, and only in mechanism: there, the user reviews the finished task rather than the raw diff, and the commit happens through the landing contract instead of by hand. Who decides — step 4 — never moves.
Do not start T-002 until T-001 is reviewed and committed. Even if tasks seem small or related, each one goes through the full cycle. No exceptions.
Never run a git command that changes anything. Not add, commit,
reset, checkout, switch, restore, stash, rm, mv, branch,
merge, rebase, push, pull, tag, or clean. Read-only only:
status, diff, log, show, blame.
This includes tidying up. A messy git status after moving files is the
user's to read, not yours to clean. Staging is part of how the user reviews
work: git add on their behalf empties git diff and destroys the review
they were about to do.
Do not hand over the command either. git add … or git commit -m …
pasted into a reply is blind: the user cannot see from it what would be staged
or what would land, and a stray keystroke runs it. It also assumes they commit
from a terminal.
Say what changed instead — which files, and what is in each — and stop there. They commit in their own tool, where staging is visible before it happens. Print a git command only when they ask for one.
The loop commits — that is the point of the maintainer role. It does so through
exactly one script, land.sh, which the user enabled deliberately and can
revoke with one line in .review/land.conf. That script
refuses unless eight conditions hold, stages and commits only the task's
declared files, and has no code path for push, amend, force, or branch switching
(TASK_LOOP.md § Landing).
Everything about that exception is what makes it different from an agent running
git commit: it is delegated in advance, narrow in what it can do, revocable,
and auditable in the commit trailers. Nothing generalizes from it. In a chat
session, and everywhere outside the loop, git stays read-only — including "just
staging" and "just tidying up".
By hand or on request, the user reviews the diff and commits. Through the loop, the maintainer commits and the user reviews the finished task — what changed, what the review found, what was rejected and why.
The unit of review differs; the authority does not. The user, never the agent, decides that a task is genuinely done and that work may continue. The maintainer may only stop asking for a category of task when the user has said so — nothing measures its way out of asking (MAINTAINER_TRAINING.md).
- Frame the report in the user's request, never in the pipeline's steps.
- Never invent step numbers (
0a,1b), and never use a word from your own documents unexpanded:Layer 0,gate,round,threshold,landing,advance,hunt. The user has not read them. - Prerequisites are one blocker line, not a plan. Never renumber the user's work behind your own setup.
- Rank by what blocks the product, and state the ranking. A list with no named worst item is not a report. No tests outranks any individual defect: untested code cannot be shown fixed, so every other repair is unverifiable.
- Never name a group with a word that is not the thing. "Debt", "junk", "misc", "structure", "other" name your filing system, not the reader's problem — name the consequence instead.
- Give the verdict, not just the inventory. For every item say whether you think it should be fixed, and why. Handing over an unranked list is refusing the judgment the user asked for.
- A diagram may show the process, never its output. The loop is worth drawing; a list of findings is not — that goes to the triage tool (skills/review.md).
- A second telling never carries less than the first. Point back at the original rather than restate it shorter — a recap missing what the reader needed to act is worse than no recap.
- The reader must be able to act on what you wrote without asking you anything. Nothing is left out to make it shorter — if it will not fit, say where the whole thing is instead of shortening it.
- Before sending, check: reading only this, can the user say what changed in their product and what you think they should do first?
After presenting a completed task, wait for the user to confirm the work is accepted before picking up the next one.
A task is done when all its exit criteria are met and its behavior is covered by tests. If a criterion can't be verified, flag it — don't skip it silently.
- Small, reviewed increments catch mistakes early
- Each commit is a clean, reviewable unit of work
- The user stays in control of what enters the repository
- Rolling back a single task is trivial