Back to Details

goal-prompt-crafter

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Goal Prompt Crafter

Goal Prompt Crafter

曖昧な要望を「自律実行エージェントまたは評価器が達成判定できる、測定可能な完了条件文」へ 練り上げる。汎用コアは完了条件設計。
/goal
系コマンドを持つ環境 (Claude Code など) では その入力文として、持たない環境では自律ループの停止条件・Definition of Done・レビュー基準として、 同じ条件文をそのまま流用できる。対象例: Claude Code、Codex CLI、Stop hook、外部オーケストレータ。
Refine vague requests into measurable completion condition statements that autonomous execution agents or evaluators can use to determine achievement. The universal core is completion condition design. The same condition statement can be reused as input for environments with 
/goal
commands (such as Claude Code), or as stop conditions, Definitions of Done, or review criteria for autonomous loops in environments without such commands. Target examples: Claude Code, Codex CLI, Stop hook, external orchestrators.

When to Use

When to Use

  • ユーザーが 
    /goal
    ・done criteria・Definition of Done・stop condition を作りたいとき
  • 「達成するまで自律的に回してほしい」タスクを安全に定義したいとき
  • タスク記述を、テスト・lint・build・ファイル生成・issue 消化などの二値判定できる 完了条件に落としたいとき
  • 自律ループ (loop / cron / Stop hook / 外部オーケストレータ) の停止条件を設計するとき
  • When users want to create 
    /goal
    commands, done criteria, Definitions of Done, or stop conditions
  • When users want to safely define tasks that should run autonomously until completion
  • When users want to convert task descriptions into binary-verifiable completion conditions (such as passing tests, zero lint errors, successful builds, file generation, or issue resolution)
  • When designing stop conditions for autonomous loops (loop/cron/Stop hook/external orchestrator)

Not for

Not for

  • 1ターンで終わる単発タスク (条件文を作るまでもない)
  • 要件仕様そのものの精緻化 (それは prompt-optimizer 等の要件系スキルの領分)
  • One-off tasks that finish in a single turn (no need to create condition statements)
  • Refining requirements specifications themselves (this falls under requirement-focused skills like prompt-optimizer)

Target Adapters (出力先の3類型)

Target Adapters (3 Types of Output Destinations)

同じ完了条件文を、達成を判定する主体に応じて出し分ける。既定は最も保守的な output-only evaluator を想定して条件文を組む (それが通れば他の2類型にも通る)。
The same completion condition statement can be adapted based on the entity responsible for determining achievement. By default, condition statements are constructed assuming the most conservative output-only evaluator (if it works for this type, it will work for the other two).

1. Output-only evaluator — 評価器がエージェント出力しか見ない

1. Output-only evaluator — Evaluator only observes agent output

Claude Code の 
/goal
が代表例。評価器 (既定 Haiku 相当の軽量モデル) は エージェントの出力テキストのみを観測し、自分で shell を叩かない。
  • /goal <条件文>
    で設定。条件達成まで各ターン終了後に判定し、未達なら次ターンを自動開始する (Claude Code の /goal 対応版が前提。挙動は導入時に実機で確認する)
  • 条件文は最大 4000 字。
    /goal
    単体で状態表示、
    /goal clear
    で解除、再指定で置換
  • 検証結果は出力に現れなければ判定できない。「テストが通る」を条件にするなら、 エージェントに検証コマンドを実際に実行させ、コマンド・exit code・要約を出力させる文言を 条件文に必ず含める
  • 参照: https://code.claude.com/docs/en/goal.md
Claude Code's 
/goal
is a representative example. The evaluator (a lightweight model equivalent to Haiku by default) only observes the agent's output text and does not execute shell commands itself.
  • Set with 
    /goal <condition statement>
    . After each turn, it checks if the condition is met; if not, it automatically starts the next turn (assuming a Claude Code version that supports 
    /goal
    . Verify behavior with the actual implementation during setup)
  • Condition statements have a maximum length of 4000 characters. Use 
    /goal
    alone to display status, 
    /goal clear
    to remove the goal, and re-specify to replace it
  • Verification results must appear in the output to be judged. If setting a condition like "tests pass", the condition statement must explicitly require the agent to execute the verification command and output the command, exit code, and summary
  • Reference: https://code.claude.com/docs/en/goal.md

2. Tool-capable evaluator / orchestrator — shell・CI・workspace を直接検査できる

2. Tool-capable evaluator / orchestrator — Can directly inspect shell/CI/workspace

外部オーケストレータや、検証器自身がコマンドを実行できる自律ループ。 検証コマンドの実行結果そのものを判定対象にしてよい (出力への転記を義務付けなくてよい)。 
/goal
系コマンドを持つ環境ではその入力文として、持たない環境では自律ループの 停止条件・Definition of Done・レビュー基準としてそのまま流用する。
External orchestrators or autonomous loops where the evaluator itself can execute commands. The actual execution results of verification commands can be used for judgment (no requirement to transcribe them to output). The statement can be reused as input for environments with 
/goal
commands, or as stop conditions, Definitions of Done, or review criteria for autonomous loops in environments without such commands.

3. Human-reviewed loop — 人間が達成を確認する

3. Human-reviewed loop — Humans confirm achievement

条件文はレビュー基準として使う。人間が観測できるなら output-only 制約は緩めてよいが、 「二値判定できる測定可能性」は必ず保つ。
Condition statements are used as review criteria. If humans can observe the results, output-only constraints can be relaxed, but binary-verifiability must always be maintained.

Workflow

Workflow

Step 1: 入力判定 (5点チェック)

Step 1: Input Validation (5-Point Check)

ユーザーの要望を以下でチェックし、欠けている項目だけを Step 2 で聞く。 全部そろっていれば Step 3 へ直行してよい。
  1. 単一の測定可能ゴールか — 「テストが通る」「lint がゼロ」など二値判定できるか。 複数ゴールの混在は分割するか、and で明示的に束ねる
  2. 検証方法が具体か — どのコマンドの exit code / 出力を見れば達成と言えるか
  3. スコープ制約があるか — 触ってはいけないファイル・変えてはいけない挙動
  4. 停止上限があるか — ターン数・時間の上限 (暴走保険)
  5. 評価器から観測可能か — 既定の output-only evaluator を想定し、出力に現れない条件 (人間の承認、外部システムの状態) を含んでいないか。tool-capable / human-reviewed の adapter (Target Adapters 参照) と分かっている場合のみ、この制約を緩めてよい
Check the user's request against the following points, and only ask for missing items in Step 2. If all items are complete, proceed directly to Step 3.
  1. Is it a single measurable goal? — Can it be binary-verified, such as "tests pass" or "zero lint errors"? If multiple goals are mixed, split them or explicitly combine with "and"
  2. Is the verification method specific? — Which command's exit code/output indicates achievement?
  3. Are there scope constraints? — Files that cannot be modified, behaviors that cannot be changed
  4. Is there a stop limit? — Maximum number of turns or time limit (to prevent infinite loops)
  5. Is it observable by the evaluator? — Assuming the default output-only evaluator, does it include conditions that don't appear in output (e.g., human approval, external system status)? This constraint can only be relaxed if using a tool-capable/human-reviewed adapter (see Target Adapters)

Step 2: 不足分のヒアリング

Step 2: Gathering Missing Information

不足している軸だけを質問する。全部そろっているのに聞き直さない。
  • 質問 UI があるエージェント (Claude Code の AskUserQuestion 等) ではそれを使う。 無い環境ではプレーンテキストの質問にフォールバックする
  • ユーザーが不在・応答不能な文脈 (自律実行中の再帰利用など) では、 欠落軸を保守的な仮定で埋め、仮定として条件文と一緒に明示する
聞く軸と定番の選択肢:
軸質問例定番の答え
検証方法何を実行すれば達成と分かるかテストコマンド exit 0 / lint 0件 / build 成功 / 特定ファイルの存在
スコープ制約変えてはいけないものは他のテストを書き換えない / 公開 API 不変 / 特定 dir 不可侵
停止上限何ターン・何分で打ち切るか
or stop after 20 turns
相当
部分達成全件必須か、一部除外を許すかflaky test の除外リスト / 既知失敗の skip 許容
Only ask about missing dimensions. Don't re-ask if all items are complete.
  • Use the question UI if available (e.g., Claude Code's AskUserQuestion). Fall back to plain text questions in environments without it
  • In contexts where the user is absent/unresponsive (e.g., recursive use during autonomous execution), fill in missing dimensions with conservative assumptions and explicitly state these assumptions alongside the condition statement
Dimensions to ask and common options:
DimensionExample QuestionCommon Answers
Verification MethodWhat needs to be executed to confirm achievement?Test command exits with 0 / 0 lint errors / Successful build / Existence of specific file
Scope ConstraintsWhat should not be modified?Do not rewrite existing tests / Public API unchanged / Specific directory immutable
Stop LimitAfter how many turns/minutes should it stop?Equivalent to 
or stop after 20 turns
Partial AchievementAre all items required, or can some be excluded?Exclude flaky tests / Allow skipping known failures

Step 3: 成果物の組み立て (完了条件 + 実行ブリーフ)

Step 3: Assemble Deliverables (Completion Condition + Execution Brief)

成果物は2部構成にする。完了条件文は評価器が観測する測定可能な条件、 実行ブリーフは自律ループに渡す作業指示 (サブエージェント委譲方針を含む)。
Deliverables consist of two parts. The completion condition statement is the measurable condition observed by the evaluator, and the execution brief is the work instruction passed to the autonomous loop (including sub-agent delegation guidelines).

3-1: 完了条件文 (
/goal
に渡す部分)

3-1: Completion Condition Statement (Part passed to 
/goal
)

[検証可能ゴール: <検証コマンド> を実行して <期待する結果> になる]
[不変制約: ただし <触ってはいけないもの> は変更しない]
[上限: 達成できなければ <N> ターンで停止する]
  • output-only evaluator (既定) 向けには、検証コマンドをエージェント自身に実行・出力させる 文言にする (評価器が出力から判定できるように)。tool-capable な adapter では 実行結果そのものを判定できるので、この転記は必須ではない
  • 4000 字制限内に収める。長大な背景説明は条件文に入れず、実行ブリーフへ回す
  • サブエージェント委譲は「作業のやり方」なので条件文には入れない (評価器が観測するのは達成状態であって、手段ではない)
[Verifiable Goal: Execute <verification command> to achieve <expected result>]
[Invariant Constraint: Do not modify <items that cannot be touched>]
[Upper Limit: Stop after <N> turns if not achieved]
  • For output-only evaluators (default), phrase the verification command to require the agent to execute and output it (so the evaluator can judge from the output). For tool-capable adapters, this transcription is not required since the evaluator can directly judge execution results
  • Keep it within the 4000-character limit. Move lengthy background explanations to the execution brief instead of including them in the condition statement
  • Sub-agent delegation is a "method of work" and should not be included in the condition statement (the evaluator observes achievement status, not the means used)

3-2: 実行ブリーフ (自律ループに渡す作業プロンプト)

3-2: Execution Brief (Work prompt passed to autonomous loop)

自律的な複数ターン実行は、素朴に回すとメインコンテキストが調査・検証の出力で 埋まり、ループ後半で息切れする。ブリーフにはサブエージェント委譲方針を必ず含める:
undefined
When running autonomous multi-turn tasks naively, the main context fills up with investigation and verification output, leading to performance degradation in later loops. The brief must include sub-agent delegation guidelines:
undefined

タスク

Task

<何をするか (背景・設計指示はここに置く。条件文には入れない)>
<What to do (place background and design instructions here; do not include in condition statement)>

サブエージェント委譲方針 (必須スロット)

Sub-agent Delegation Guidelines (Required Section)

  • 広い調査・grep・複数ファイル読みは調査系サブエージェントに委譲し、結論だけ受け取る (メインコンテキストにファイルダンプを溜めない)
  • 独立した並行作業は複数サブエージェントに fan-out する
  • テスト実行・レビューなどの検証もサブエージェントに投げ、要約だけ受ける
  • メインループは「委譲先の結論を統合して次の一手を決める」役に徹する
  • Delegate broad research, grep operations, and multi-file reading to research sub-agents, and only receive conclusions (do not accumulate file dumps in the main context)
  • Fan out independent parallel work to multiple sub-agents
  • Delegate verification tasks like test execution and reviews to sub-agents, and only receive summaries
  • The main loop focuses solely on "integrating delegated conclusions to decide the next step"

スコープ制約

Scope Constraints

<触ってはいけないもの・変えてはいけない挙動>

- 委譲方針は削除・省略しない (欠けると素朴なシングルコンテキスト実行に退行する)
- 委譲先の呼称は対象に合わせる (subagent / task tool / worker agent / parallel agent /
  reviewer agent 等)
- これら委譲機能が対象エージェントに無い場合のみ、その旨を明記した上で「長いファイル
  ダンプを避け、調査結果を短い要約に圧縮してからメインで次に進む」方針に差し替える
<Items that cannot be modified, behaviors that cannot be changed>

- Do not delete or omit delegation guidelines (without them, execution regresses to naive single-context operation)
- Adjust the terminology for delegate targets to match the environment (subagent/task tool/worker agent/parallel agent/reviewer agent, etc.)
- Only if the target agent lacks delegation functionality, explicitly state this and replace the guidelines with: "Avoid long file dumps; compress research results into short summaries before proceeding in the main loop"

Step 4: セルフチェック (アンチパターン照合)

Step 4: Self-Check (Anti-pattern Matching)

生成した条件文を以下と照合し、該当したら Step 3 に戻って修正する:
  • 曖昧語: "improve" / "clean up" / "きれいにする" — 二値判定できない
  • 複数ゴールの暗黙混在: 「テストを直してドキュメントも整える」— and で束ねるか分割
  • 観測不能条件: 「レビューが承認されたら」「デプロイが安定したら」— 評価器はエージェント出力しか見えない
  • 検証コマンド欠落: 「テストが通る」とだけ書き、実行を義務付けていない
  • 自己言及の抜け穴: 「達成したと報告する」— 報告だけで達成扱いになる条件は不可
  • 上限なし: 達成不能なゴールで無限ループする保険がない
Compare the generated condition statement against the following; if any apply, return to Step 3 to revise:
  • Ambiguous terms: "improve" / "clean up" — Cannot be binary-verified
  • Implicit multiple goals: "Fix tests and organize documentation" — Combine with "and" or split into separate goals
  • Unobservable conditions: "When review is approved" / "When deployment stabilizes" — Evaluator can only see agent output
  • Missing verification command: Only writing "tests pass" without requiring execution
  • Self-referential loophole: "Report when achieved" — Conditions that count achievement solely based on reports are invalid
  • No upper limit: No safeguard against infinite loops for unachievable goals

Step 5: 出力 (md ファイル保存 + メッセージ提示)

Step 5: Output (Save as MD File + Message Prompt)

成果物はファイルシステムに書き込める環境では必ず md ファイルとして保存する (メッセージ出力だけで終わらせない)。条件文とブリーフは長くなりがちで、後から 
/goal
に 貼り直したり別セッションで再利用したりするため、揮発するメッセージだけでは足りない。 配布先の開発エージェント (Claude Code / Codex CLI 等) はいずれも file-capable なので、保存を既定とする。書き込めない環境でのみ、同じ 
# 完了条件
/ 
# 実行ブリーフ
/ 
# 仮定
の構造をメッセージ内に出力し、ユーザーが自分で保存できる形にする。
  1. md ファイルに保存 (書き込める環境では必須):
    • 保存先はユーザー指定パス。未指定なら作業ディレクトリの 
      goal-<slug>.md
      (slug はゴールから生成)。scratchpad が使える環境ではそちらでもよい
    • ファイル構成: 
      # 完了条件
      (Step 3-1 の条件文) → 
      # 実行ブリーフ
      (Step 3-2) → Step 2 で置いた仮定があれば 
      # 仮定
    • 保存後、ファイルパスをユーザーに報告する
  2. メッセージでも提示:
    • Claude Code: 
      /goal <条件文>
      をコピペ可能なコードブロックで示す。 slash command はユーザーが打つものなので、スキル側で実行しない。 実行ブリーフは初回プロンプトとして貼るか、保存した md を参照させる旨を添える
    • その他のエージェント: 条件文を「完了条件 (Definition of Done)」として返し、 自律ループの停止判定・タスク定義・レビュー基準への流用先を一言添える
    • Step 2 で仮定を置いた場合は、仮定の一覧を条件文の直後にも明示する
In environments where writing to the file system is possible, always save deliverables as an MD file (do not stop at just message output). Condition statements and briefs tend to be long, and volatile messages alone are insufficient for later reuse like pasting into 
/goal
or using in other sessions. Since target development agents (Claude Code/Codex CLI, etc.) are all file-capable, saving as a file is the default. Only in environments where writing is not possible, output the same structure (
# Completion Condition
/ 
# Execution Brief
/ 
# Assumptions
) in a message, formatted so the user can save it themselves.
  1. Save as MD file (required in writable environments):
    • Save to the user-specified path. If no path is specified, use 
      goal-<slug>.md
      in the working directory (slug generated from the goal). Can also use scratchpad if available
    • File structure: 
      # Completion Condition
      (Step 3-1 statement) → 
      # Execution Brief
      (Step 3-2) → 
      # Assumptions
      if any were made in Step 2
    • After saving, report the file path to the user
  2. Also present in message:
    • Claude Code: Show 
      /goal <condition statement>
      in a copy-pasteable code block. Do not execute the slash command on behalf of the user, as this is the user's responsibility. Attach the execution brief as the initial prompt or note that it can be referenced from the saved MD file
    • Other agents: Return the condition statement as "Completion Condition (Definition of Done)", along with a note on its use as stop criteria for autonomous loops, task definition, or review standards
    • If assumptions were made in Step 2, explicitly list them immediately after the condition statement

良い例 / 悪い例

Good / Bad Examples

以下の「良い/悪い」は 
/goal
に渡す完了条件文の対比。実際の成果物は これに実行ブリーフ (サブエージェント委譲方針を含む) を足して md 保存する。
The following "good/bad" examples compare completion condition statements passed to 
/goal
. Actual deliverables include the execution brief (with sub-agent delegation guidelines) and are saved as MD files.

完全な成果物の見本 (保存する md)

Sample Complete Deliverable (MD File to Save)

markdown
undefined
markdown
undefined

完了条件

Completion Condition

uv run pytest tests/unit を実行して全件 pass し、uv run ruff check src/ が 0 件になる。 ただし tests/ 配下の既存テストは修正しない。達成できなければ 15 ターンで停止。
Execute 
uv run pytest tests/unit
and ensure all tests pass, and 
uv run ruff check src/
returns 0 errors. Do not modify existing tests under 
tests/
. Stop after 15 turns if not achieved.

実行ブリーフ

Execution Brief

タスク

Task

失敗している unit テストを修正する。実装バグが原因ならプロダクションコードを直す。
Fix failing unit tests. If caused by implementation bugs, correct the production code.

サブエージェント委譲方針

Sub-agent Delegation Guidelines

  • 失敗原因の調査 (該当モジュールの grep・関連ファイル読み) は調査系サブエージェントに委譲し、 結論だけ受け取る
  • 修正後の検証 (pytest / ruff 実行) はテスト実行系サブエージェントに投げ、要約を受ける
  • メインループは委譲結果を統合して次の修正対象を決める役に徹する
  • Delegate investigation of failure causes (grep relevant modules, read related files) to research sub-agents and only receive conclusions
  • Delegate post-fix verification (pytest/ruff execution) to test execution sub-agents and receive summaries
  • The main loop focuses solely on integrating delegation results to determine the next fix target

スコープ制約

Scope Constraints

  • tests/ 配下の既存テストは書き換えない
  • 公開 import パスを変えない
undefined
  • Do not rewrite existing tests under 
    tests/
  • Do not change public import paths
undefined

テスト修復系

Test Fix Scenario

undefined
undefined

良い

Good

/goal uv run pytest tests/unit を実行して全件 pass し、uv run ruff check src/ が 0 件になる。ただし tests/ 配下の既存テストは修正しない。達成できなければ 15 ターンで停止。
/goal Execute 
uv run pytest tests/unit
and ensure all tests pass, and 
uv run ruff check src/
returns 0 errors. Do not modify existing tests under 
tests/
. Stop after 15 turns if not achieved.

悪い

Bad

/goal テスト周りをいい感じに直す # 測定不可・検証コマンドなし・上限なし
undefined
/goal Fix the tests nicely # Unmeasurable, no verification command, no upper limit
undefined

リファクタ系

Refactoring Scenario

undefined
undefined

良い

Good

/goal src/big_module.py を 3 つ以上のモジュールに分割し、各ファイルが 300 行以下に なり、uv run pytest が分割前と同じ pass 数を維持する。公開 import パスは変えない。 20 ターンで停止。
/goal Split 
src/big_module.py
into 3 or more modules, ensure each file has ≤300 lines, and 
uv run pytest
maintains the same number of passes as before splitting. Do not change public import paths. Stop after 20 turns.

悪い

Bad

/goal コードをきれいに分割する # 「きれい」は判定不能
undefined
/goal Cleanly split the code # "Cleanly" is unjudgeable
undefined

backlog 消化系

Backlog Resolution Scenario

undefined
undefined

良い

Good

/goal gh issue list --label quick-fix --state open の件数が 0 になる。各 issue は 修正 commit を作り issue 番号を commit message に含める。main には push しない。 30 ターンまたは全 issue 着手済みで停止。
/goal Ensure the number of open issues labeled "quick-fix" (from 
gh issue list --label quick-fix --state open
) is 0. For each issue, create a fix commit that includes the issue number in the commit message. Do not push to main. Stop after 30 turns or when all issues have been addressed.

悪い

Bad

/goal issue を全部片付ける # 「片付ける」の定義がない・安全制約なし
undefined
/goal Fix all issues # No definition of "fix", no safety constraints
undefined

制約・注意

Constraints & Notes

  • /goal
    の仕様 (バージョン・字数上限・評価モデル) は Claude Code 側の変更で変わりうる。 挙動が説明と食い違う場合は公式ドキュメント (Target Adapters の URL) を優先する。 4000 字・output-only といった制約は output-only evaluator adapter 固有のもので、 tool-capable / human-reviewed の adapter には当てはまらない
  • 条件文は達成判定のためのもの。作業手順・背景・設計指示・サブエージェント委譲方針は 実行ブリーフ側に置き、条件文に混ぜない
  • 成果物 (完了条件 + 実行ブリーフ) は書き込める環境では必ず md 保存し、パスを報告する。 書き込めない環境ではメッセージ内に同じ構造で出力する
  • 破壊的操作 (push / deploy / 削除) を含むゴールでは、不変制約に安全境界 (「main に push しない」等) を必ず入れる
  • /goal
    specifications (version, character limit, evaluation model) may change due to updates to Claude Code. If behavior differs from this description, prioritize the official documentation (URL in Target Adapters). Constraints like the 4000-character limit and output-only requirements are specific to the output-only evaluator adapter and do not apply to tool-capable/human-reviewed adapters
  • Condition statements are for achievement judgment only. Work procedures, background, design instructions, and sub-agent delegation guidelines belong in the execution brief and should not be mixed into the condition statement
  • In writable environments, always save deliverables (completion condition + execution brief) as an MD file and report the path. In non-writable environments, output the same structure in a message
  • For goals involving destructive operations (push/deploy/delete), always include safety boundaries in the invariant constraints (e.g., "Do not push to main")