2. Implementing Phase (~ 5–45 minutes)
In a new conversation, use the guided-coding-implement skill, including a reference to the plan file.
/guided-coding-implement @path/to/plan.md
The agent verifies that the plan is frozen, goes off and works, typically for 5 to 45 minutes depending on the task. I let it run in auto-continue mode without supervising. In enterprise environments, make sure that you run in a secure VM or Docker container to prevent rogue agents from hurting your host, see Security: Be Vigilant.
The plan stays frozen
The plan is a committed decision record by the time the agent sees it. The agent implements against it; it does not maintain it.
The one exception is the acceptance criteria. As each criterion is genuinely satisfied - implemented and verified by the relevant feedback loop - it gets ticked from - [ ] to - [x]. Nothing else about the plan changes. Criteria are never reworded to match what was built, and unmet criteria stay unchecked so you can see them during review.
This works best when it is written down where the agent will read it. A short section in your root AGENTS.md is enough:
## When you implement a plan
Plans in `ai-plans/` are frozen once their Planning Phase ends. The only edit you may make
to a plan is flipping an acceptance criterion from `- [ ]` to `- [x]`.
- Check a criterion only after the implementation exists and the relevant feedback loops verify it.
- Leave unmet criteria unchecked, and never change the wording of a criterion.
- When the implementation materially departs from an explicit decision in the plan, write a Plan
Deviations document instead of editing the frozen plan.
If the agent concludes mid-implementation that the plan is wrong, that is a signal worth having - but the response is to stop and go back to the Planning Phase, not to silently implement something else. See The Plan Record.
Feedback loops
The key to a successful Implementing Phase is having good feedback loops in place:
- Compilers / transpilers catch invalid syntax
- Static code analysis tools catch potential issues in the codebase
- Automated tests validate functional correctness
- Linters enforce code style
- Automated benchmarks verify performance
- Security tools like trivy detect vulnerabilities
These feedback loops let the agent work longer autonomously. When the agent writes code, runs the tests, sees failures, and fixes them - all without your intervention - that's the power of this setup. Modern models execute tests by themselves; you don't have to instruct them to do so. You just need an acceptance criterion that says automated tests should be written.
I once asked an agent to optimize memory allocations in a hot path in Light.PortableResults. It wrote a benchmark, implemented a stack-allocated optimization for cases with fewer than 10 errors, ran the benchmark, and reported: 25% faster runtime and 80% less memory allocated. When I then asked it to eliminate one last remaining heap allocation, it tried, ran the benchmarks again, and saw that performance actually got worse. It rolled back its own changes.
I document every feedback loop by its exact command in the root AGENTS.md, with a note about what it verifies. Agents are good at running commands they've been told about and bad at guessing them.
/guided-coding-setup builds this section for you: it discovers commands from your build files, scripts, and CI configuration and lists only those that are immediately executable in the repository. It warns you when it finds none, because guided-coding-write-plan refuses to write a plan without a listed feedback loop. Re-run it when your tooling changes.
A missing feedback loop is itself plan material. If a change needs a benchmark or a test harness that doesn't exist yet, the plan should say so explicitly rather than assuming the agent will improvise one.