SuperAPI AI Directory
Partner中文AI newsFavorites
Skillsgoal-prompt-crafter

goal-prompt-crafter

Agents & models

View repository

Updated 10-15 21:33

About this skill

Goal Prompt Crafter

Refine a vague request into a "measurable completion-condition statement that an autonomous execution agent or evaluator can use to judge achievement." The general-purpose core iscompletion-condition design。/goal In environments that have this family of commands (such as Claude Code), it can be used directly as the input text; in environments that do not, the same condition statement can be reused as-is as the stop condition, Definition of Done, or review criteria for an autonomous loop. Target examples: Claude Code, Codex CLI, Stop hook, external orchestrators.

When to Use

  • the user /goal- When you want to create done criteria, a Definition of Done, or a stop condition
  • When you want to safely define a task as "keep running autonomously until it is achieved"
  • When you want to reduce a task description to completion conditions that can be judged in binary terms, such as tests, lint, build, file generation, or issue resolution
  • When designing the stop condition for an autonomous loop (loop / cron / Stop hook / external orchestrator)

Not for

  • One-shot tasks that finish in a single turn (no need to create a condition statement)
  • Refinement of the requirements specification itself (that is the domain of requirements-related skills such as prompt-optimizer)

Target Adapters (the 3 output destination types)

Output the same completion-condition statement differently depending on the entity that judges achievement.By default, compose the condition statement assuming the most conservative output-only evaluator (if it passes there, it will also pass for the other 2 types).

1. Output-only evaluator — the evaluator sees only the agent's output

Claude Code の /goal is a representative example. The evaluator (by default a lightweight model equivalent to Haiku) observes only the agent'soutput textand does not run shell itself.

  • /goal <条件文> Configure with this. Judge after each turn ends until the condition is achieved, and if not achieved, automatically start the next turn (assuming the /goal-compatible version of Claude Code. Verify the behavior on the actual machine when introducing it)
  • The condition statement ismaximum 4000 characters。/goal displays the status by itself,/goal clear clears it, and re-specifying replaces it
  • Verification results cannot be judged unless they appear in the output. If you make "the tests pass" the condition, always include wording in the condition statement that makes the agent actually run 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 — can directly inspect shell, CI, and workspace

An external orchestrator, or an autonomous loop in which the verifier itself can execute commands. The execution results of verification commandsitselfmay be used as the judgment target (there is no need to require transcription into the output). /goal In environments that have this family of commands, use it directly as the input text; in environments that do not, reuse it as-is as the stop condition, Definition of Done, or review criteria for an autonomous loop.

In an external state monitoring loop such as PR maintenance, define the completion condition not as a natural-language impression but as state predicates observable with tools. Example: gh pr checks succeeds,isDraft == false, The expected bot review artifact exists, there are 0 blocking comments, and the head SHA matches the last confirmed value. In environments like Codex that do not assume /goal primitives, treat this set of predicates as the stop condition of the inline polling loop.

3. Human-reviewed loop — a human confirms achievement

Use conditional statements as review criteria. If a human can observe it, the output-only constraint may be relaxed, but always preserve "measurability that allows binary judgment."

Workflow

Step 1: Input assessment (5-point check)

Check the user's request against the following, and ask only about the missing items in Step 2. If everything is present, you may go directly to Step 3.

  1. Is it a single measurable goal? — Can it be judged binary, such as "tests pass" or "zero lint errors"? If multiple goals are mixed, split them or explicitly combine them with and
  2. Is the verification method concrete? — Which command's exit code / output should be checked to say it is achieved?
  3. Are there scope constraints? — Files that must not be touched, behavior that must not be changed
  4. Is there a stop upper bound? — Upper bounds on turns / time (runaway insurance)
  5. Is it observable from the evaluator? — Assuming the default output-only evaluator, does it include conditions that do not appear in the output (human approval, external system state)? Only when it is known to be a tool-capable / human-reviewed adapter (see Target Adapters) may this constraint be relaxed

Step 2: Hearing the missing parts

Ask about the missing axesonly. If everything is present, do not ask again.

  • For agents with a question UI (such as Claude Code's AskUserQuestion), use it. In environments without one, fall back to plain-text questions
  • In contexts where the user is absent or unresponsive (such as recursive use during autonomous execution), fill the missing axes with conservative assumptions, andexplicitly state them as assumptions together with the conditional statementdoes

Axes to ask about and typical choices:

Axis Example question Typical answers
Verification method What should be run to know it is achieved? Test command exits 0 / 0 lint errors / build succeeds / a specific file exists
Scope constraints What must not be changed? Do not rewrite other tests / public API unchanged / specific dir untouchable
Stop upper bound After how many turns / minutes should it be cut off? or stop after 20 turns equivalent
Partial achievement Must all be required, or may some be excluded? Exclusion list for flaky tests / allowing skips for known failures

Step 3: Assembling the deliverables (completion conditions + execution brief)

Make the deliverable two-part.Completion condition statementis the measurable condition observed by the evaluator, Execution briefis the work instruction passed to the autonomous loop (including the subagent delegation policy).

3-1: Completion condition statement (/goal part passed to)

[検証可能ゴール: <検証コマンド> を実行して <期待する結果> になる]
[不変制約: ただし <触ってはいけないもの> は変更しない]
[上限: 達成できなければ <N> ターンで停止する]
  • For an output-only evaluator (default), write the verification command ashaving the agent itself execute and output it wording (so the evaluator can judge from the output). In a tool-capable adapter, the execution result itself can be judged, so this transcription is not mandatory
  • Keep it within the 4000 character limit. Do not put lengthy background explanations in the condition statement; move them to the execution brief
  • Subagent delegation is "how the work is done", so do not put it in the condition statement (the evaluator observes the achievement state, not the means)

3-2: Execution brief (work prompt passed to the autonomous loop)

When autonomous multi-turn execution is run naively, the main context gets filled with investigation and verification output, and it runs out of steam in the latter half of the loop. The brief mustalways include the subagent delegation policy:

## タスク
<何をするか (背景・設計指示はここに置く。条件文には入れない)>

## サブエージェント委譲方針 (必須スロット)
- 広い調査・grep・複数ファイル読みは調査系サブエージェントに委譲し、結論だけ受け取る
  (メインコンテキストにファイルダンプを溜めない)
- 独立した並行作業は複数サブエージェントに fan-out する
- テスト実行・レビューなどの検証もサブエージェントに投げ、要約だけ受ける
- メインループは「委譲先の結論を統合して次の一手を決める」役に徹する

## スコープ制約
<触ってはいけないもの・変えてはいけない挙動>
  • Do not delete or omit the delegation policy (if it is missing, it regresses to naive single-context execution)
  • Match the name of the delegation target to the target (subagent / task tool / worker agent / parallel agent / reviewer agent, etc.)
  • Only if the target agent does not have these delegation features, state that explicitly and replace it with the policy of "avoid long file dumps, compress investigation results into a short summary, then proceed to the next step in the main context"

Step 4: Self-check (anti-pattern matching)

Match the generated condition statement against the following, and if it applies, return to Step 3 and fix it:

  • Ambiguous words: "improve" / "clean up" / "きれいにする" — cannot be judged binarially
  • Implicit mixing of multiple goals: "Fix the tests and also tidy up the docs" — either bundle with and or split
  • Unobservable conditions: "once the review is approved" / "once the deployment is stable" — the evaluator can only see the agent output
  • Missing verification command: writing only "the tests pass" without mandating execution
  • Self-referential loophole: "report that it was achieved" — a condition where mere reporting counts as achievement is not acceptable
  • No upper limit: there is no safeguard against an infinite loop on an unachievable goal

Step 5: Output (save md file + present message)

The deliverable isin an environment where it can be written to the filesystem, always save it as an md file (do not end with just a message output). Condition statements and briefs tend to become long, and later /goal Because it may be re-pasted or reused in a separate session, volatile messages alone are not enough. Since the distribution-target development agents (Claude Code / Codex CLI, etc.) are all file-capable, saving is the default.Only in environments where writing is not possible, output the same # 完了条件 / # 実行ブリーフ / # 仮定 structure within the message so that the user can save it themselves.

  1. Save to an md file (mandatory in environments where writing is possible):
    • The save destination is the user-specified path. If unspecified, goal-<slug>.md in the working directory (slug is generated from the goal). In environments where a scratchpad is available, that may be used instead
    • File structure: # 完了条件 (the conditional statement from Step 3-1) → # 実行ブリーフ (Step 3-2) → If there are assumptions made in Step 2, # 仮定
    • After saving,report the file path to the user
  2. Also present in the message:
    • Claude Code: /goal <条件文> in a copy-pasteable code block. Since slash commands are typed by the user, do not execute them on the skill side. Either paste the execution brief as the initial prompt, or add a note to refer to the saved md
    • Other agents: Return the conditional statement as a "Definition of Done", and add a brief note about where it can be reused for autonomous loop stop determination, task definition, and review criteria
    • If assumptions were made in Step 2, also explicitly state the list of assumptions immediately after the conditional statement

Good examples / Bad examples

The following "good/bad" is a contrast of /goal passed tothe completion condition statement. The actual deliverable is saved as md by adding an execution brief (including the subagent delegation policy) to this.

Sample complete deliverable (the md to save)

# 完了条件
uv run pytest tests/unit を実行して全件 pass し、uv run ruff check src/ が 0 件になる。
ただし tests/ 配下の既存テストは修正しない。達成できなければ 15 ターンで停止。

# 実行ブリーフ
## タスク
失敗している unit テストを修正する。実装バグが原因ならプロダクションコードを直す。

## サブエージェント委譲方針
- 失敗原因の調査 (該当モジュールの grep・関連ファイル読み) は調査系サブエージェントに委譲し、
  結論だけ受け取る
- 修正後の検証 (pytest / ruff 実行) はテスト実行系サブエージェントに投げ、要約を受ける
- メインループは委譲結果を統合して次の修正対象を決める役に徹する

## スコープ制約
- tests/ 配下の既存テストは書き換えない
- 公開 import パスを変えない

Test repair type

# 良い
/goal uv run pytest tests/unit を実行して全件 pass し、uv run ruff check src/ が
0 件になる。ただし tests/ 配下の既存テストは修正しない。達成できなければ 15 ターンで停止。

# 悪い
/goal テスト周りをいい感じに直す        # 測定不可・検証コマンドなし・上限なし

Refactoring type

# 良い
/goal src/big_module.py を 3 つ以上のモジュールに分割し、各ファイルが 300 行以下に
なり、uv run pytest が分割前と同じ pass 数を維持する。公開 import パスは変えない。
20 ターンで停止。

# 悪い
/goal コードをきれいに分割する          # 「きれい」は判定不能

Backlog burn-down type

# 良い
/goal gh issue list --label quick-fix --state open の件数が 0 になる。各 issue は
修正 commit を作り issue 番号を commit message に含める。main には push しない。
30 ターンまたは全 issue 着手済みで停止。

# 悪い
/goal issue を全部片付ける             # 「片付ける」の定義がない・安全制約なし

Constraints / cautions

  • /goal specifications (version, character limit, evaluation model) may change due to changes on the Claude Code side. If the behavior differs from the explanation, prioritize the official documentation (the URL in Target Adapters). Constraints such as 4000 characters and output-only are specific to the output-only evaluator adapter, and do not apply to tool-capable / human-reviewed adapters
  • The conditional statement is for determining achievement. Work procedures, background, design instructions, and subagent delegation policy belong on the execution brief side, and must not be mixed into the conditional statement
  • In environments where writing is possible, always save the deliverable (completion conditions + execution brief) as md, and report the path. In environments where writing is not possible, output it within the message using the same structure
  • For goals that include destructive operations (push / deploy / delete), always include safety boundaries (e.g., "do not push to main") in the invariant constraints