Skill: Goal-Driven Execution

Don't tell it what to do — give it success criteria and watch it go. But bounded: max 5 tries, hard cap, always.

Purpose

Transform an imperative task ("fix the bug", "add validation") into a runnable success criterion, then loop attempt -> verify until green or the cap is hit. This trades open-ended agent looping (which drifts and rationalizes "close enough") for a bounded, falsifiable contract.

This is an original implementation inspired by Andrej Karpathy's LLM-coding-pitfalls observations (via multica-ai/andrej-karpathy-skills) — not a copy of that work.

Step 1 — Lock success criteria BEFORE building

Every criterion must be a runnable, observable check — a command, a test, a curl, a browser behavior. Not "works", not "faster", not "should be fine now".

If the task can't be made verifiable, stop and ask — don't start looping on a vague goal. A criterion you can't run is not a criterion.

Step 2 — State the try plan

Before the first attempt, write the numbered plan the user will see if this escalates:

1. [action] — verify: [exact command/check]
2. [action] — verify: [exact command/check]
3. ...

Keep it short. The plan can change try-to-try (see Step 3) but it must exist before try #1.

Step 3 — The loop

Each cycle: attempt -> run verification -> on fail, diagnose first.

On failure:

1. State the delta between expected and actual output — exactly, not "it didn't work".
2. Form a new hypothesis for why.
3. Only then change something.

Never re-run an unchanged fix hoping for a different result — that is not a new try, it's the same try with a wasted cycle.

The 5-try hard cap (non-negotiable)

A "try" = one attempt at making the criteria pass, ended by actually running the verification.

On the 5th failed try: STOP. Do not attempt a 6th. Switch to the debug-loop-breaker protocol (also in this collection) and report:

• A table: try # / hypothesis / what changed / result
• Current best hypothesis
• What information or decision is needed from the user to continue

Honesty rule

Never declare success unless the verification actually ran and passed in this session. A partial pass is not done — say plainly which criteria are still red.

Model delegation note

When a stronger orchestrator model delegates a build to a cheaper builder model, the orchestrator locks the success criteria up front and judges the verification output; the builder model executes the tries against those locked criteria. The builder does not get to renegotiate criteria on its own — see the Gotcha below on stating renegotiations explicitly.

Gotchas

• Vacuous criteria prove nothing. A check that passes even before the change (a test that asserts nothing, a grep that matches pre-existing text) is not a criterion. When feasible, confirm the check FAILS before implementing.
• A failed verification counts as a full try even if the change was one line. Cheap edits don't earn extra attempts.
• Don't silently weaken criteria mid-loop to make them pass. Renegotiating criteria is allowed but must be stated explicitly — e.g. "relaxing criterion 2 because [reason]".
• "5 tries" is per-goal, not per-session. If the goal is re-scoped into a genuinely different goal, the counter resets — but say so out loud when it happens.