Menu
Craft a clear /goal condition for Claude Code's autonomous mode from a rough task description.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
Use before any creative/build work — adding features, building components, new functionality, or changing behavior. Turns a brief or vague idea into an approved design doc through one-question-at-a-time dialogue. Does NOT write code until the design is approved. Output is the design doc; the next step is owned by the caller.
Convene an independent cross-model judge — a model of a different family (e.g. Codex/GPT, Gemini, or a Cursor agent pinned to a non-Claude model), whichever CLI is installed — to cross-examine an artifact (a decision, a diff, a document, or a research answer) and adjudicate its findings disbelieve-it-back. This is the cross-model *mechanism*; the caller brings the artifact and its own in-family review. Use via `vet` (code), `research-council` (research), `plan` (a design decision), or directly when you want a second opinion from a model that doesn't share your blind spots. It reviews; it never edits.
Create new skills, modify and improve existing skills, and measure skill performance. Use when users want to create a skill from scratch, edit, or optimize an existing skill, run evals to test a skill, benchmark skill performance with variance analysis, or optimize a skill's description for better triggering accuracy.
Reference for writing and editing skills well — the vocabulary and principles that make a skill predictable.
Build and sharpen a project's domain model. Use when the user wants to pin down domain terminology or a ubiquitous language, record an architectural decision, or when another skill needs to maintain the domain model.
Execute an approved implementation spec by delegating the coding to a cheaper/faster headless agent CLI (cursor-agent, codex, or a cheaper claude) while the main agent plans, verifies, and owns the merge. Use when you have a clear, self-contained task or plan and want another agent to write the code instead of doing it inline — for cross-family diversity, parallelism, or cost on large/repetitive work — e.g. 'have cursor do this', 'delegate this to cursor-agent', 'let codex implement this', 'let the cheap model write it', or any time the implementation is well-specified and mechanical enough to hand off. Also invoke explicitly as /delegate-coding. Does NOT write the plan; pair it with `plan` / `writing-plans` upstream.
| name | goal-crafter |
| description | Craft a clear /goal condition for Claude Code's autonomous mode from a rough task description. |
| disable-model-invocation | true |
Turn a rough task into a /goal condition — a done-check that a small fast model
evaluates from conversation output after each turn.
After each turn an evaluator model reads the conversation and decides yes/no on the
condition. It cannot run commands or read files — it only judges what Claude has
already printed. So the condition must name things Claude will surface: test output it
ran and showed, a git status it printed, a grep result it displayed.
Write checks as "Claude has shown X", not "X is true" — the evaluator can only verify what appeared in the transcript.
If the task is ambiguous, ask one question and stop. A goal built on the wrong interpretation drives autonomous mode toward the wrong outcome — that's worse than pausing. Ambiguity triggers: subjective verbs without a measurable end state (clean up, improve, refactor, modernize, fix), missing scope boundary, unknown verification command. Output exactly one clarifying question and nothing else. If the task is concrete, skip this step.
Write the condition. A goal has three parts, folded into one or two sentences:
npm test and the output shows all passing", "Claude prints git diff --stat showing
only the intended files"). Use only commands you know exist in the project; if you don't
know the test command, askDon't add implementation guidance, skill references, or approach suggestions — the executing agent owns all of that.
Print the goal. Nothing else — no preamble, no explanation.
Short. The official example: all tests in test/auth pass and the lint step is clean.
A more constrained one: config/ is split into config/parser.py and config/schema.py, Claude runs pytest -q and shows all passing, and git diff --stat shows changes only in config/.
Tight means: if removing a clause wouldn't change the evaluator's yes/no decision, cut it. Max 4,000 characters, but most goals are under 200.