메뉴
Craft a clear /goal condition for Claude Code's autonomous mode from a rough task description.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
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.