goal-loop

Goal Loop

A procedure document for accomplishing a goal using worker / verifier / evaluator until the agreed Scope and success criteria are met. The current agent that invoked this skill becomes the orchestrator and is responsible for criteria, the ledger, evidence reconciliation, and deciding the next move.

When to Use

User's goal-loop / ゴールまで回す / 必ずやり遂げる / loop until done / until it actually works I requested.
The deliverable needs to be completed end-to-end, and a loop of verification, retries, and evaluation is required rather than a one-off fix.
Work that is medium-scale or larger, or irreversible or multi-step, where it is worth separating worker generation from evaluator judgment.

Do Not Use For

A one-file, obvious, low-risk fix. A normal agent executes it directly.
An ordinary consultation, planning only, code review only, or fact-checking only.
Design review of a skill / prompt / instruction / agent itself. Out of scope for this skill.

Execution Contract

Freeze scope, AC, verifier, out-of-scope, must NOT, autonomy, and persistence before execution.
Keep a compact ledger: AC status, evidence, attempts, gaps, and next action.
Delegate broad research, mutation, and primary verification when workers are available; workers return evidence only.
Before parallel durable dispatch, checkpoint each partition identity, expected evidence, and wait deadline. After cancellation, retry, or a missing parent completion, reconcile durable evidence first and rerun only unresolved partitions.
Judge by external signals first. Never PASS from self-evaluation, supporting checks alone, skipped tests, TODOs, or weakened criteria.
On failure, update the ledger from the failed signal, change approach, and avoid repeating attempts.
Use Small-Bet-First for broad, irreversible, dependency, schema, deployment, or user-facing changes.
Stop or replan on stall, oscillation, diminishing returns, budget exhaustion, or genuine external blockers.

Phase 1: Scope + Criteria Freeze

Use criteria-agreement.md.

Freeze goal, scope terminus, AC with verify:, primary verifier, out-of-scope, must NOT, autonomy, and persistence.
If the finish line is ambiguous, ask one structured question before execution.
Do not use build/control-plane success as the primary verifier when the real outcome is deploy / runtime / UI / app behavior.

Phase 2: Plan Minimal Subgoals

Use steering-and-final-gates.md and ledger-templates.md.

Pick the lightest effort level that still protects the goal; downgrade trivial work.
Split into verifiable subgoals and record status. Parallelize read-only work, or independently partitioned mutations with durable identity, idempotency, expected evidence, and conflict-free ownership.

Phase 3: Delegate Workers

Use loop-control.md.

Start broad or risky changes with a pilot; never expand a failed pilot.
Give workers only the subgoal, AC, boundaries, must NOT, relevant attempt lessons, and expected evidence.
Treat parent tool receipt, UI state, and turn_end as delivery evidence, not completion authority; use terminal child state plus verified durable artifacts.
If no subagent tool exists, record degraded mode; only downgraded small work may run in main context.

Phase 4: External Verification

Run the frozen verify: steps and capture exit codes, logs, screenshots, readbacks, or capability gaps.
If the primary verifier is unavailable, record exact manual verification steps and required evidence; do not complete from weaker checks.

Phase 5: Evaluate

Use evaluation-rubric.md.

Reconcile evidence against each AC. Use a separate evaluator for non-small or non-read-only work.
PASS only when every must AC passes and confidence is above threshold.

Phase 6: Loop Control