One shape, whichever command runs
Every command that changes files in your project follows the same journey. The implementation command is the clearest example, so that is the one told here, but the gates below are shared: a review, a cleanup and a repair all pass through them.
Knowing the shape is worth the five minutes. It tells you where you will be asked something, where the run can stop, and what you are looking at in the final report.
1. Nothing is written before the scope is agreed
Your assistant restates what it understood, names the files and flows it expects to touch, asks whatever is genuinely missing, and waits. Vague requests come back as questions rather than as guesses.
The one case where you are not asked again is a request a command's own gate has already proved complete — it read your request against the code and found nothing missing. Asking after that confirms nothing and only delays work you already described in full.
If you arrive carrying a prompt written earlier by the planning command, it is recognised by the line at its head naming the command that wrote it, and the run starts from what that prompt already settled instead of asking you again.
2. The deliverables are written down as a list
Before any code is touched, the work becomes a numbered checklist: what must exist when this is finished, and in which states. That list is what the run is measured against later, so it is worth reading while it is still cheap to correct.
At the same point your assistant says what will prove the change — the screen it will open, the command it will run, the migration it will execute — and what else it needs from you before it can get there.
3. Your uncommitted work is fenced off
The state of your working tree is recorded before the first change, so the files the task owns stay separate from whatever you already had in progress. Nothing outside that set is staged, reverted, stashed or reset. Work you had going stays exactly as you left it.
4. The change is implemented
Edits stay inside the agreed scope. Untouched code is not reordered, restyled or tidied on the way past: if something outside the scope looks wrong, it is reported to you rather than changed.
Before changing existing code, /develop looks at who put it there. It reads the history of exactly the lines it is about to change, and when a commit changed those lines to what they are now on purpose, and the edit would undo that decision, it stops and asks you instead of quietly reversing it — naming the commit and what it decided. Adding a case beside existing code, or extending it, is not undoing anything and goes ahead. Inside /next, where nothing is asked mid-run, the same question is written into the plan as an open question carrying the commit, the work that depends on the answer waits for it, and the rest is built.
If the work needs data — a user, a role, a record that puts a screen into the state being built — your assistant checks the environment first, and in a confirmed local environment it creates what it needs and signs in itself instead of asking you to. What it created is its own to change. What was already there is not: an existing record is never deleted, and one the task had to change is put back before the run ends.
5. It is validated, not assumed
Validation is where most of the time goes, and it has three parts.
Every file goes through the analyzer. Each file the task wrote is sent with its path and its full contents, every error that comes back is fixed, and it is sent again until it comes back clean. If the connection to the server is down, you are told that plainly and an internal reviewer stands in — reported as a different thing, never as an analyzer pass, because the two are not the same. See Analyse a file and Read a finding.
What proves the change is actually run. A migration that exists but was never run leaves the change unproved. So do a missing dependency, an unbuilt asset and a development server nobody started. Recovering that environment is part of the job, not a reason to stop: the run installs, migrates, builds and starts what it needs, and only a genuine blocker ends it early.
Anything a person can see is opened and looked at. Not a screenshot, not the page returning without an error — your real browser, on the screens the change touches. Elements are checked for being fully visible and unobstructed; a modal is checked for opening above the page, scrolling inside itself, and leaving nothing behind when it closes. Each one comes back as a pass or a fail naming the screen and the element.
That browser pass runs against every state the changed code tells apart, not only the one your database happens to be in — an empty list as well as a full one, an account with a subscription as well as one without. A state that cannot be created is reported as uncovered rather than quietly counted as passed. And because validation itself writes records, the browser pass runs once more after the last write, before the commit.
6. The checklist is walked point by point
Each deliverable from step 2 is marked done or not done against concrete evidence: the file, the run, the screen opened, the migration executed. A point with no evidence is not done. Nothing half-finished is reported as finished.
A blocked point does not unmake the others. The points that stand on evidence stay done, the blocked one is named with its reason, and the code already written for it ships with the rest rather than being thrown away.
7. One commit, and no push
What was proved becomes a single focused commit, staging only the files the task owns, with a message in English even when you worked in another language. Nothing is pushed, no branch is created, no earlier commit is rewritten. The commit hash is in the report.
The commit is skipped when no validation could run at all, when Git is unavailable, or when your other changes make safe staging ambiguous. In that case you get the blocker and the file list instead.
8. The report tells you what is still owed
The final report names what was built, what was run to prove it, how the browser pass came out, the commit that was created, and anything left open.
The documentation is already written by then: the run that builds a change writes what that change owes — the developer documentation, and the feature item and guide when a user would notice it — in the same run, so it describes what was actually built rather than what somebody remembered a week later. What the last line still names as owed is the changelog entry, written by /finish standing on the main branch — it is dated by the moment the work reaches users, not by the day it was written.
Next
- What each command does — picking the right one to start with.
- The agents behind a command — who does each part of this journey.