goal-driven-execution

goal-driven-execution is a skill for Claude Code, Codex from orlando-japan/claude-code-setting. It costs 33 tokens per session (570 once invoked), scanned A, original, MIT.

A work method that defines a concrete success check before coding and repeats it until it passes.

In plain words
What is it for?
Use it for coding tasks with a verifiable outcome, such as passing tests, a correct redirect, a specific API response, or an expected Git history.
Why use it?
It prevents declaring a task finished because code merely compiles or looks plausible when the requested behaviour has not been tested directly.

Skill for Claude CodeCodex

Written for no agent in particular: nothing here depends on one.

Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

agentmods
npx agentmods add skills/orlando-japan/claude-code-setting/goal-driven-execution
Any agent
npx skills add orlando-japan/claude-code-setting --skill goal-driven-execution
Clone the repo
git clone --depth 1 https://github.com/orlando-japan/claude-code-setting

Made for: Claude Code, Codex.

Wrote this? Show the measurements

A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.

agentmods badge for goal-driven-execution

README.md
[![agentmods](https://agentmods.dev/badge/skills/orlando-japan/claude-code-setting/goal-driven-execution.svg)](https://agentmods.dev/skills/orlando-japan/claude-code-setting/goal-driven-execution)
Your own site
<a href="https://agentmods.dev/skills/orlando-japan/claude-code-setting/goal-driven-execution"><img src="https://agentmods.dev/badge/skills/orlando-japan/claude-code-setting/goal-driven-execution.svg" alt="Measured on agentmods" height="20"></a>
Per session 33 Skills are progressive disclosure: only the name and description are preloaded; the body loads when the skill is used.
When invoked 570 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 1 finding. Scan, not verified.
Origin original No closer match found in the catalogue.
Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

ModelPer sessionOnce invoked
Fable 5.1 $0.00033 $0.00570
Opus 5 $0.00016 $0.00285
Sonnet 5 $0.00007 $0.00114
Haiku 4.5 $0.00003 $0.00057

Measured 5d ago against content hash 7ae2fe9c24fd, method: parsed. Prices are Anthropic first-party input rates as of 2026-09-06, from the pricing page.

Security

Grade A, and why

goal-driven-execution scanned grade A with 1 finding against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 5d ago.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Makes network callslowCapability

Not a fault in itself. Listed so you know the mod talks to something, and to what.

- "…when `curl -X POST /api/user` with a missing name returns 400 with `{error: 'name required'}`."
templates/extra/skills/goal-driven-execution/SKILL.md · 60 lines

How it starts

The opening of the file, as written. The whole thing — 60 lines — stays where its author put it; the contents beside it link to each section on GitHub.

Goal-driven execution

Most "done" declarations are premature because the definition of done was vague. This skill forces a concrete check up front.

Protocol

Step 1 — Write the verification before the code.

Phrase it as: "I will know this is done when <command> produces <output>."

Examples:

  • "…when pnpm test path/to/user.test.ts exits 0 and shows 'handles empty input' passing."
  • "…when visiting http://localhost:3000/settings as a logged-out user redirects to /login with ?return_to=/settings."
  • "…when curl -X POST /api/user with a missing name returns 400 with {error: 'name required'}."
  • "…when git log --oneline -5 shows 5 commits all tagged with [auth-v2]."

If you can't state a verification, the task isn't clear enough — ask the user before coding.

Step 2 — Code.

Step 3 — Run the exact verification you wrote.

Not a proxy, not "the type checker is happy," not "it compiled." The literal command from step 1.

Step 4 — If it fails, iterate. Diagnose the gap, fix, re-run. Don't declare done with "it should work now."

Step 5 — If it passes, state it explicitly with the command and its output in the message back to the user. This gives the user evidence, not a claim.

For UI work

The verification must include actually opening a browser and exercising the feature:

  • Golden path: the main user flow, click-through.
  • At least one edge case: empty state, error state, or boundary input.

If you can't run a browser in the current environment, say so explicitly. Claiming success on unverified UI is the worst outcome.

For bug fixes

  1. Verification = the reproduction command fails before the fix and passes after.
  2. No reproduction = no fix, it's a guess.
  3. Reproduce first, fix second, confirm third.

Anti-patterns

  • "Tests should pass now." Run them.
  • "Based on my analysis it works." Evidence over analysis.
  • Type check as verification. Type check is necessary, not sufficient.
  • Declaring done when you hit the first green. Run the full verification list, not just the one test you touched.

Read the full file on GitHub · 60 lines

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

  1. 5d ago First seen · 60 lines · 33 tokens per session scan A 7ae2fe9c24fd

Subscribe to this mod's changes

goal-driven-execution is a skill published in the GitHub repository orlando-japan/claude-code-setting (2 stars, last pushed 3mo ago), licensed MIT. It adds 33 tokens to every session and 570 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 1 finding (makes network calls). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.

Related

Other skills, from other repositories

Effective Memory

The essential habits for an AI agent with memory — session bookends, learning triggers, verification, safety, and the operational discipline that turns raw recall into compounding intelligence. Pinned, always-injected.

plur-ai/plur · 44 tokens

finishing-a-development-branch

Use when implementation is complete, all tests pass, and you need to decide how to integrate the work.

obra/superpowers · 27 tokens

image-to-code

Elite website image-to-code skill for Codex. For visually important web tasks, it must first generate the design image(s) itself, deeply analyze them, then implement the website to match them as closely as possible. In Codex, it must prefer large, readable, section-specific images instead of tiny compressed boards…

Leonxlnx/taste-skill · 116 tokens

react-grab

Use when the user wants a hands-free loop where grabbing UI elements in the browser with React Grab feeds tasks to the agent automatically, with no copy-paste or manual handoff. Triggers: "watch react grab", "monitor my grabs", "auto-process react grab", "watch my clipboard for grabs". Not for a one-off paste of a…

aidenybai/react-grab · 86 tokens

output-standards

Use this skill when defining or enforcing output formatting standards for agent responses in WrongStack. Triggers: user says "next steps format", "output standard", "response format", "final message format", "standardize next steps".

WrongStack/WrongStack · 52 tokens

lc-curate-context

Decide which files a task actually needs, record that as a reusable llm-context rule, verify it against the codebase - including the files your selection references but leaves out - and pack it for your own context, a chat, or a sub-agent you dispatch. Load when choosing what code to put in front of a model, packing…

cyberchitta/llm-context.py · 90 tokens