Agent Iteration Loop

Agent-led implementation should move through isolation, implementation, validation, live verification, review, CI triage, shipping, and follow-up rather than stopping at code generation. Source: skills/productivity/agent-iteration-loop/SKILL.md

The methodology for agent-led implementation and testing: take work from implementation through validation, live verification, review, CI triage, shipping, and follow-up, instead of just writing code and stopping. Codified as the agent-iteration-loop personal skill (skills/productivity/agent-iteration-loop/SKILL.md).

The loop

isolate -> understand -> implement -> validate -> verify live -> review -> triage CI -> ship -> follow up.

1. Isolate in a git worktree per task; reuse running servers (check the terminals folder first) rather than spawning duplicates.
2. Understand by reading the code and mapping blast radius; explore breadth with parallel explore subagents. If the blast radius grows faster than expected, pause for a status report or split the work instead of silently expanding the diff.
3. Implement the minimal correct change; reuse before adding; match style.
4. Validate on a cheap-first gradient: typecheck -> lint(changed) -> format -> targeted tests -> build. Add invariant tests. Verify empirically.
5. Verify live: start/reuse the dev server, check the UI in a real browser (browser-harness / agent-browser / Playwright per tool-hierarchy), screenshot it, then tear down what you spawned (process hygiene).
6. Review with code-reviewer / style-reviewer / gstack-review and the relevant doctors; resolve Bugbot/Greptile findings, classifying each as actionable-mine, stale, pre-existing, or owner-decision. For explicitly large orchestration, use planner/worker/verifier fan-out: planners decompose, workers edit, verifiers run the checks, and failures feed the next worker rather than the same agent declaring victory.
7. Triage CI honestly: separate failures you caused from pre-existing or systemic ones (warning caps, broken seeds, drift checks); fix yours, report the rest, do not absorb repo-health into a feature PR.
8. Ship small (< 500 LOC, one concern), conventional commits, a PR body that documents what and why and the decisions made; never push without approval; never change prod/growth/ad surfaces unasked.
9. Follow up: document hardening per PR, resolve every open question, flag owner decisions, propose wiki updates.

Why it matters

The bottleneck in LLM-assisted development is understanding and verification, not code generation. This loop forces the agent to prove its work against reality (tests, a live server, a real browser, CI) and to be honest about what is and is not green, instead of declaring done after the diff compiles. It pairs with Agent Ethos (minimal, suspicious, empirical) and Staying in the Loop with Agents (keeping the human in control).

Hard rules

• Never push without explicit approval; never modify prod DB/infra; never silently change marketing-conversion / ad surfaces (flag as owner decisions).
• Report systemic CI failures as systemic; do not claim a feature PR turns them green or pad it with unrelated repo fixes.
• ASCII only, no em dashes, in code, comments, and commits.

Concept Position

---

Timeline

• 2026-07-01 | Concepts category refresh added this page to the Agent harness and runtime primitives family, linked it to Concept System Map, and kept it standalone because it owns this reusable mental model: Agent-led implementation should move through isolation, implementation, validation, live verification, review, CI triage, shipping, and fol... Source: User request, 2026-07-01