메뉴
Help the user craft one or more well-specified `/goal` objectives for goal mode. Use when the user asks for help writing, refining, or improving goals, goal-mode objectives, completion contracts, autonomous run objectives, proof, boundaries, or stop rules.
기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.
설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
직접 명령은 검토 Prompt를 거치지 않습니다. 실행하기 전에 소스를 확인하세요.
npx skills add https://github.com/autohandai/code-cli --skill goal-writer명령은 한 줄로 유지됩니다. 복사하기 전에 가로로 스크롤해 전체 내용을 확인하세요.
로컬 사본을 원하시나요? SkillsMP에서 현재 제공할 수 있는 파일을 다운로드하세요.
SOC 직업 분류 기준
SKILL.md 표시 중
| name | goal-writer |
| description | Help the user craft one or more well-specified `/goal` objectives for goal mode. Use when the user asks for help writing, refining, or improving goals, goal-mode objectives, completion contracts, autonomous run objectives, proof, boundaries, or stop rules. |
Help the user turn a rough intention into one or more /goal objectives that
goal mode can pursue across many turns without supervision. A goal is not a task
description; it is a completion contract. It says what must become true, how
that truth is proven, where the work may and may not reach, and when to stop and
report.
Drafting and starting are separate steps. Settle the wording first. Only once
the user has approved the exact objective should you call create_goal. When
the user approves more than one objective, call create_goal for each approved
goal in the intended order; the first starts and the rest are queued.
When a decision has concrete options, use the host's user-question tool if it is available. Do not write a prose menu and ask the user to answer in free text.
Examples of choices that should use the tool:
If no user-question tool is available, fall back to a short plain-text question with clearly labeled options and wait. Open-ended questions are fine in prose.
create_goal.Strong goals define proof, not effort.
Include as many of these as the task warrants:
Queue-shaped goals work best: failing tests, open issues, error traces, files to migrate, rows to process. Lean on existing verification: tests, CI, typechecks, lint, evals, browser checks, or zero-match searches.
create_goal only after approval. Include a token
budget only if one was agreed.<What must become true.>
Done when <command/search/state that proves it>.
Scope: only <files/area>; do not <off-limits action>.
Loop: <how to iterate, such as rerun the check after each change>.
If <blocking condition>, stop and report instead of forcing a pass.
Use only the lines that help. A small task can be a single clear sentence.
Weak: Find all bugs in this codebase.
Strong: Fix every test in test/auth that currently fails, rerun npm test until it exits 0, change no file outside test/ or src/auth, and report anything you cannot fix with its location and why.
Weak: Optimize the project.
Strong: Migrate the payment module to the new API, make npm test -- payment exit 0, keep the diff limited to payment-related files, and stop and ask before touching shared infrastructure.
Weak: Make it faster.
Strong: Make renderFrame at least 3x faster measured by the bench/render benchmark; if you cannot reach 3x after several attempts, report the best result and why.
| Mistake | Better |
|---|---|
| Starting or suggesting a goal the user did not ask for | Only draft a goal once the user asks |
| Drafting in the wrong language | Match the user's language |
| Running before the user sees the exact text | Show the full draft and get agreement |
| Burying a discrete choice in prose | Use the user-question tool when available |
| Specifying effort | Specify proof |
| Setting a budget unprompted | Suggest a budget only when useful |
| No blocked path | Add an explicit stop-and-report rule |
| No way to verify completion | Anchor to tests, search, metric, file, or inspectable check |