loop-engineering

Loop Engineering

<skill_contract> A repeatable task with inspectable state, finite budgets, permissions, and an independent verifier. A validated Trigger -> Execute -> Verify -> State contract plus resumable run receipts. The declared metric or stop condition is supported by fresh validator and verifier evidence. <non_goals>Dependency-graph orchestration, unbounded autonomy, or self-certified completion.</non_goals>

Build loops only when repeated execution creates evidence. Every loop needs admission, a validated contract, durable state, independent evaluation, bounded retries, stop/recovery rules, and a final receipt.

Usage Template

Provide: objective, trigger, scope/non-goals, inputs, state/artifact paths, metric, verifier, permissions, budgets, stop condition, recovery, and write-back. See references/ci-repair-loop-example.md for a worked contract.

Workflow

Select one mode:

• Goal: run until a defined end state or cap.
• Loop: poll/iterate while eligible work exists.
• Automation: start from an external schedule/event; the trigger is not execution evidence.
• AutoResearch: vary experiments against an objective metric in a sandbox.

Admit only if work is repeatable, outputs are inspectable, a verifier exists, failures are recoverable, and autonomy is worth the orchestration/review cost. Otherwise use a one-shot workflow.

Use graph-engineering instead when explicit data dependencies, independent branches, typed joins, or node-local recovery create measurable value. A Graph node may use this Loop contract for local repetition; Graph width does not replace finite Loop depth.

<unknowns_gate>

Classify unknowns as known, probeable, testable, or blocked. Missing objective, verifier, permission boundary, budget, or recovery is NEEDS_INPUT; do not infer these controls from intent. Unknown implementation details may be resolved inside the loop only when the probe is bounded and reversible.