| name | ai-loop |
| description | Runs a bounded Spec-Build-Review cycle with an iteration budget, recorded verification commands, and human approval gates. Use when an isolated feature needs a full build from scratch or a heavy modification with checkable requirements. Not for open-ended architecture refactors, /goal contracts, or work whose tests depend on missing credentials. |
| version | 1.0.1 |
| category | workflow |
| risk | safe |
| source | community |
| date_added | 2026-06-27 |
| tags | ["agent-workflow","specification","implementation","review","verification","feedback-loop"] |
| tools | ["claude","cursor","codex","gemini"] |
AI-Loop Skill
Overview
The ai-loop skill structures a bounded development cycle for agentic workflows. It divides work into three explicit phases — Spec, Build, Review — and loops between Build and Review until every requirement passes verification, a stop condition is reached, or human approval is needed.
Before invoking the loop, the agent must define and record:
- Iteration budget: maximum number of Build→Review cycles (default: 3).
- Verification evidence: the exact commands or manual checks that count as proof.
- Approval gates: any action requiring explicit human sign-off (destructive commands, production changes, external service writes, credential changes, broad architectural pivots).
When to Use
- A feature needs to be built from scratch or heavily modified, and the agent should own the full lifecycle (specification, implementation, verification) inside one bounded workflow.
- The work targets an isolated component, module, or feature with well-defined scope and constraints.
- The user asks for a complete development pass and there are clear success criteria, a reasonable verification path, and no unresolved safety or product decisions.
Do not use for open-ended architectural refactoring, security-sensitive changes, or work where verification depends on unavailable credentials or systems — stop instead.
Prerequisites
- A working directory where
specs/ can be created (PowerShell: New-Item -ItemType Directory -Path specs -Force).
- Verification commands that can actually run in the current environment (tests, linters, type-checkers, build scripts).
- Sufficient user context available during the Spec phase to pin down requirements.
Procedure
0. Pre-Loop Setup
- Confirm the feature name with the user. Use a kebab-case
<feature-name> for file paths.
- Create the specs directory if it does not exist:
New-Item -ItemType Directory -Path specs -Force
- Agree on and record the iteration budget, verification commands, and approval gates before any design discussion.
Phase 1: Spec (Planning)
- Interview the user about the feature. Ask one focused question at a time until the goal, must-have requirements, constraints, and definition of done are clear.
