Key idea
One change per branch, one step per commit. Small steps keep every diff short enough to read, and make every mistake cheap to undo: you throw away one step, not an afternoon.
Start on a branch
A branch is a separate line of work. Main keeps running while you experiment, and if the whole idea fails you delete the branch.
git switch main
git pull
git switch -c feat/mark-done
Ask for a plan before any edit
Give the agent the brief and ask it to plan, not build:
Read docs/briefs/mark-done.md. Plan only: list the files you'll change,
in what order, and why. Don't edit anything yet.
Some agents have a read-only planning mode; in any agent, asking in words works. Read the plan against the brief. Does it touch files the brief didn't mention? Add a dependency? Change an existing endpoint? Pushing back now costs one message. After the edit, it costs a review and a revert.
Build it in steps
Split the plan into steps you can check one at a time, each with its own tests. For the brief in the last lesson, that's three steps on one branch; the PATCH endpoint's tests cover 200, 404 and 403:
One branch, one commit per step
mainfeat/mark-donegit restore .Commit Pull request
After each step, before you ask for the next:
npm test
git diff
git add -A
git commit -m "feat: store can mark a task done"
Run the tests yourself, even if the agent says it did. Read the diff (next module). Then commit, so this step is a point you can come back to.
When a step goes wrong
If the agent's change is wrong, don't stack a fix on top of it. Throw the step away and try again with a clearer instruction:
git restore .
That discards every uncommitted change, back to your last commit. New files the agent created stay until you delete them; git status lists them.
A good rule: after two rounds of "that's still not right" on one step, stop. Either the step is too big, or the brief is missing something the agent needs. Fix that, not the code.
Finish with a pull request
Push the branch and open a pull request into main:
git push -u origin feat/mark-done
GitHub prints a link to open it. Paste the brief into the description. Even working alone, a pull request gives you one page with every change, a place for checks to run, and a single button to undo it later.
Check yourself