The six-phase loop

By the end you can run one feature through research, plan, execute and ship, and you know which gates are yours.

TL;DR

• Six phases: research, plan, execute, review, verify, ship. Each one produces an artifact you can read, and each one ends at a gate.
• The plan is the gate where a human matters most. A few minutes reading it saves an afternoon of unwinding execute.
• Ship is a normal pull request with the evidence attached. There is no AI lane.

What is the six-phase loop?¶

Every phase produces an artifact and ends at a gate.

The six phases are research, plan, execute, review, verify, ship. Each phase is a skill - a packaged set of instructions the agent loads when the phase is active - with a clear input, a clear output and a clear hand-off to the next phase. Superpowers is one implementation; GitHub Spec Kit, BMAD frameworks and team-built skill collections share the same loop.

The loop stands on a well-defined expected outcome. The agent can build almost anything you describe, but it cannot know which thing you meant. Research surfaces what is undecided, you settle it, the plan turns it into checks, and verify measures the result against it. Skip that and "done" is whatever the agent decided.

The feature

Here is one feature, followed through every phase. It is small: add a priority field to the Wire record in a regulated banking service.

Priority is one of low / normal / high / urgent and defaults to normal. The urgent flag triggers a separate compliance-review queue.

Research

Research produces a note, not code - and its open questions are yours to settle.

I asked the agent to read the codebase and write a research note. It named four files I would not have found in an hour of grepping:

• the Wire record itself
• the migration directory
• the compliance-review-queue service
• the audit-log emitter

It also raised an open question: should priority be an enum or free text? The regulator's spec uses free text in some documents and an enum in others. I picked enum. That was not a detail - it defined the target every later phase was checked against.

A research note is two to four pages and covers:

• the files that will be touched
• the conventions those files follow
• the existing tests that cover the area
• related concepts elsewhere in the codebase
• open questions where a human has to decide

Teams skip research most often, because it produces no code. In my experience it is the highest-leverage phase: a bad note guarantees a bad plan, and a good one grounds the plan in the real code instead of the agent's first guess.

If the task sits outside your own domain, run a blind spot pass first: ask the agent to help you find your unknown unknowns, and tell it plainly what you do not know. It calibrates to the expertise it infers from your vocabulary, so false fluency hides its assumptions.

Commit the note with the change. Six months later, when someone asks why the code is shaped this way, the answer is in the repository.

Plan

The plan is the gate where you matter most.

The agent turned the note into a six-task plan:

1. Add the database column with a default.
2. Update the Wire record class.
3. Update the wire-builder service.
4. Update the API contract.
5. Update the compliance-routing logic to read the new field.
6. Update the audit-log emitter.

Each task touched one file or one pair of files. Task five depended on task four's contract change; the order was right and the agent had flagged the dependency. Approved.

A plan you can approve has three properties:

• Every task names the file, the change and the check that proves it worked. Each is sized to two to five minutes - small enough that a failure is recoverable.
• It names the tests to add or update. A plan without tests is incomplete and goes back.
• It states what "done" means for the whole change, not only per task. That is the outcome verify will check.

Then you read it. Push back on tasks that are vague, too large or wrongly ordered. Add what it missed, remove what is out of scope. Only then does execute start.

The review takes a few minutes. It saves an afternoon when the plan was wrong and you would have found out during execute, where it is much harder to unwind.

Execute

One subagent per task, one writer per file.

Six subagents ran in parallel, one per task, each constrained to its file. They returned in under three minutes. Five tasks had passing tests on the first run.

The sixth, the audit-log emitter, also had a passing test - but the test was wrong. It asserted the old log format. Green, and wrong. Chapter 5 picks up how that got caught.

Each subagent works in its own isolated context: it reads only what it needs, makes its change, runs the plan's check and reports back. Task one's confused reasoning cannot pollute task four.

Isolation is not a silver bullet. The rules that keep it working:

• Split only when the tasks are independent by file or by module. Six subagents each editing one file is safe. Six editing the same feature across overlapping files is a recipe for expensive conflicts, which eat the speed you went parallel for.
• Fewer is usually faster. Three well-scoped subagents finish faster than eight overlapping ones.
• Read the orchestrator's hand-offs with skepticism. It still holds a summary of every task, and an imprecise summary of task one can lead task four to contradict it. I have watched six subagents produce mutually inconsistent edits for exactly this reason.
• Keep an implementation-notes file. Every deviation from the plan and why, every edge case the plan never mentioned, every decision a subagent made that the plan left open. Recorded when it happens, not compressed into a hand-off later.

When a task fails, the orchestrator retries, routes around it, or stops and asks you. Most failures are recoverable on a second attempt. A blocking failure means the plan needs revision, and the loop goes back to plan.

Review and verify

Review checks the diff against the spec; verify checks the behavior against the outcome.

On the wire, review caught the audit-log test and a migration with no down direction, and verify ran the full suite plus a smoke test against staging. Chapter 5 owns both phases: how to read an agent diff, and why a green suite the agent wrote is evidence, not proof.

Ship

Ship is a normal pull request. There is no AI lane.

The agent commits with a structured message, pushes the branch and opens a pull request whose description says what changed, why, how it was verified, what risks remain and who is tagged to review.

On the wire, the PR carried the research note, the plan, the per-task reports, both reviews and the test evidence. A senior reviewer spent eleven minutes on it and asked one question: should the urgent flag be observable in the metrics dashboard? I had not thought about it. Approved, merged.

That PR is exactly the artifact the team already knows how to review. The agent does not replace your shipping process; it feeds it better-formulated work.

What it costs in time

On a healthy workflow, the human gates are the rate limiter, not the agent.

On a small feature the full loop takes twenty to thirty minutes of wall clock; on a medium one, an hour; on a large one, a few hours - work that would have taken days without the agent. The agent runs for maybe a third to half of that. The rest is you reading the note, reviewing the plan and approving the diff.

The wire feature took ninety minutes from "let's add a priority field" to merged code. The difference is the regulated context: a 3,400-test suite, a staging smoke test and a contract diff for the regulator. Small in scope is not small in ceremony.

If a small feature takes three hours, your gates are over-engineered or run as slow back-and-forth instead of a focused pass. The agent will not save you from your own meeting culture.

When to run less of it

Skip a phase only if you can name what already does its job.

Chapter 3's test tells you when the loop pays at all; inside the loop the same accounting applies.

One team I watched ran for most of a year on what looked like half the loop: research was a comment thread, the plan was three bullets in the PR. It worked because the functions had moved into the team's walls - a small senior team that built the codebase, a strict CI suite and a serious PR culture. The six phases are functions that have to happen somewhere. If you cannot say where, the phase stays.

When it breaks

• The gates are requests, not walls. Skill instructions ask for "tests in the plan"; strict enforcement needs a project-specific PreToolUse hook (Chapter 2).
• Parallel subagents on overlapping files produce inconsistent edits. Re-scope by file or module, or run the tasks in sequence.
• Long sessions drift. The agent re-answers settled questions and forgets constraints. That is context contamination, and Chapter 6 covers the fix.

Do this Monday

• [ ] Pick one task that passes Chapter 3's test and ask the agent for a research note before any code.
• [ ] Settle every open question in the note, in writing.
• [ ] Read the plan: every task names a file, a change and a check; tests are listed; there is a "done when" line. Push back once before approving.
• [ ] Execute with one subagent per file and an implementation-notes file.
• [ ] Ship it as a normal PR with the note and plan attached.
• [ ] Time each phase. Note which ate the most wall clock and which produced the most value. They are often not the same.

Go deeper

• Template: Appendix B.3, the six-phase loop checklist.
• Deep dive: Appendix D, Chapter 4 - when splitting into subagents pays, forking workers vs isolating reviewers, and the vendor autonomy and scope prompt blocks.
• Sources: Appendix C.