Structure bounded dev cycles with plan-build-review phases

AI-Loop organizes development into a bounded Spec, Build, and Review cycle. It helps define a feature, implement the agreed requirements, compare the result against the specification, and correct identified gaps within an explicit iteration budget. The loop ends when every requirement passes the declared verification, a stop condition is reached, or a decision needs human input. Scope, evidence, and approval boundaries are established before implementation begins.

The Spec phase asks one focused question at a time to establish the goal, must-have requirements, constraints, and definition of done. It does not start building while those decisions are unresolved. The resulting specification is saved as a feature-named Markdown file in the specs directory and includes the objective, exact requirements, edge cases, checkable completion criteria, maximum build-review iterations, verification commands or manual checks, and approval gates.

The Build phase reads that document and implements exactly what it describes. It records which requirements were covered so the review can compare work with the same contract. Additional features, unrelated refactoring, and invented requirements are outside the loop's scope. Review then checks each requirement individually, naming gaps, bugs, or missing pieces by the exact specification item they fail.

Use this skill for a new or substantially modified feature, component, or module with clear boundaries and a reasonable verification path. It fits a complete development pass when success criteria are concrete and no unresolved product or safety decisions prevent execution. Large systems should be broken into smaller independent loops rather than handled as one oversized specification.

It is less suited to open-ended architectural refactoring or work with insufficient context. Conflicting requirements, tests that cannot run, unavailable credentials or systems, or exhausted iteration limits are reasons to stop and report the exact remaining issue. The review is the agent's assessment against its generated specification; critical systems still warrant manual review. This workflow does not replace human approval for sensitive, destructive, production, compliance, or externally visible changes.

Inputs are the desired feature, language and behavior constraints, edge-case decisions, success criteria, verification environment, and a small iteration budget. The specification becomes the durable reference for both implementation and review. Outputs include the specification file, scoped code changes, a requirement coverage list, and the evidence and findings from verification.

A statistics-helper specification might require mean, median, and mode, return null for empty arrays, and ignore non-numbers. Review detects that mode failed the non-number requirement, sends that specific fix back to Build, and verifies it again. This illustrates repairing an identified requirement gap rather than repeatedly trying the same unsuccessful change without new evidence.

A failed check returns to Build only while the budget remains and the fix stays within the agreed specification. Changes to the specification, broad architectural pivots, risky operations, or uncaptured product decisions require human input. Completion requires all specified items and their declared checks to pass.

Testing generated code should use a safe, sandboxed environment. Arbitrary shell commands require safety validation, and code or specifications must not contain hardcoded secrets. Production deployment, data migrations, payments, credential changes, destructive commands, and external writes belong behind the defined approval gates.