A reliable workflow
The other Foundations pages are principles. This one is the routine that puts them to work. It’s the same five steps whether you’re in a terminal agent, an editor, or a chat window, and it’s boring on purpose: boring is what makes results repeatable instead of lucky.
The loop
Section titled “The loop”- Explore. Before any change, have the tool understand the ground. “Read these files and explain how X works.” You’re checking it sees reality before it acts, and filling its context window with the right things.
- Plan. Ask for the approach before the code. “How would you do this? List the steps.” A plan is cheap to read and cheap to correct; a wrong implementation is not. Approve or fix the plan first.
- Do. Let it execute the agreed plan, ideally one focused change at a time, not the whole feature in one shot.
- Verify. Run the check. Tests, build, the output. See Verification. No proof, not done.
- Commit. Capture the working change before you start the next one. A clean commit is your undo button when the next step goes sideways.
The reason to separate plan from do is that correcting direction is almost free while it’s still words, and expensive once it’s code you have to read and unpick.
Common failure patterns
Section titled “Common failure patterns”Nearly every bad session is one of these. The fix is usually a step you skipped.
| What goes wrong | The fix |
|---|---|
| It jumps straight to code and gets the wrong end of the stick | Make it explore and explain first |
| It tries to do too much at once and tangles everything | Scope to one change, then the next |
| Answers get worse the longer you go | Context bloat: clear or compact and re-state the task |
| It says “done” but it isn’t | Verify: demand the test output, not the claim |
| It quietly drifts from what you wanted | Plan first and approve the plan before any code |
When to break the rules
Section titled “When to break the rules”The loop is a default, not a law. As you build intuition you’ll skip steps on purpose, and that’s the goal, not a cheat.
- A tiny, reversible change (rename a variable, fix a typo) doesn’t need a formal plan.
- A throwaway script you’ll read in full doesn’t need a test harness.
- A quick factual question doesn’t need an explore phase.
The skill is knowing which step is safe to skip this time. The tell: how expensive is it if the tool is wrong? Cheap and reversible: move fast. Costly or hard to undo: run the full loop, every step. You earn the right to break the rules by knowing what each one was protecting you from.
Where you’ll see this
Section titled “Where you’ll see this”The full loop shows up, in the tool’s own commands and modes, here: