prd-to-goal

prd-to-goal — PRD → /goal への分解

PRD／issue／仕様書を、コピーして貼り付けられる単一の /goal 行に変換します。/goal の難しいところは、実行することではありません。終了する（収束する）、テスト可能な真偽値である（反証可能）、そしてエージェントが主観的な判断なしに実際に確認できる（観測可能）until 句を書くことです。このスキルを使えば、この分解を再現可能にできます。

1. 使用するタイミング

次の場合に使用してください：

• 書かれた PRD、GitHub issue、仕様書があり、それを対象に /goal を実行したい場合。
• 過去の /goal の実行が、until 句が曖昧（until tests pass、until done、until design is good）だったために、脱線したり、ループしたり、トークンを消費したりした場合。
• 中止の予算（ターン数、トークン数、進捗なしのしきい値）を正当化する必要がある場合。

次の場合は使用しないでください：

• 失敗するテストがそのまま受け入れ基準になる、単発のバグ修正。/goal until pnpm test -- auth.spec.ts passes を実行してください。
• 書かれた PRD がない場合。まず write-prd を実行してください。雰囲気だけでは分解できません。
• 破壊的、または取り消し不可能な作業（DB マイグレーション、大量のファイル削除）。/goal は再試行します。DROP TABLE の再試行は避けたいはずです。

2. スキルが受け付ける入力

入力	方法
貼り付けた PRD テキスト	引数として渡すか、呼び出した後にチャットへ貼り付けます。
GitHub issue	gh issue view <N> --json title,body,labels — スキルは body を読み取ります。
仕様書ファイル	Markdown／テキストファイルのパスを指定すると、スキルが Read で読み取ります。
ADR／設計ドキュメント	仕様書ファイルと同じです。

3. 分解アルゴリズム

1. 受け入れ基準を抽出します。 すべての MUST、SHOULD、Definition of Done、Acceptance Criteria、チェックボックス形式の行を取り出します。ドキュメントに該当する項目がない場合は、そこで終了し、まず write-prd を実行するようユーザーに伝えてください。収束の対象となるものがありません。

2. 各基準を観測可能な真偽値に対応付けます。 各基準は、シェルで確認可能な単一のアサーションに変換する必要があります。観測可能な状態の例：

   • test -f path/to/file（ファイルが存在する）
   • pnpm test -- pattern passes（テストコマンドが終了コード 0 で終了する）
   • gh pr view <N> --json state | jq -r .state == "MERGED"
   • wc -l < src/auth.ts が範囲内の数値を返す
   • pnpm lint が終了コード 0 で終了する
   • curl -sf $URL が 2xx を返す

3. 観測できない基準を除外します。 主観的な判断に依存する基準（code is clean、design feels right、users are happy）は、削除するか書き換えてください。代替指標（lint exits 0、Lighthouse score > 90、NPS survey ID exists）を見つけるか、その基準は /goal の対象外であることをユーザーに伝えてください。

4. until 句を組み立てます。 観測可能なアサーションを優先度順に AND で連結します。ループを早期に短絡させるため、最も安価で失敗する可能性が高いチェックを先にします。アサーションは 3〜5 個が適切です。通常、7 個を超える場合は PRD が 2 つに分けられることを示しています。

5. 予算を同じ条件に含めます。 Claude Code では、1 セッションにつき目標は 1 つだけ設定でき、設定のたびに置き換わります。上限はその単一の条件の中に記述します （…, or stop after 15 turns）。2 つ目のコマンドではありません。妥当なターン数の上限：

   • 単一の機能なら 15、リファクタリングなら 30、バグ修正なら 5。

   2 つ目の /goal 行は絶対に出力しないでください。 2 つ目の行は安全策を追加しません。新しい条件として解析され、最初の条件を置き換え、すべての受け入れアサーションが破棄された状態で、予算だけが目標として設定されたセッションになります。このスキルが以前出力していた abort-if 形式は、Claude Code の構文ではありませんでした。2.1.226 のバイナリに対して grep -c -a -F 'abort-if' を実行すると 0 が返り、357 件のアーカイブ済み変更履歴のいずれにも記載されていません。2026-08-08 に確認済み（#3312）。

4. 出力テンプレート

スキルは、貼り付けて使える行をちょうど 1 行出力します：

/goal until <assertion_1> AND <assertion_2> AND <assertion_3>, or stop after <N> turns

まず、その行だけを単独で出力してください。ユーザーがコピーできるよう、行を囲むフェンス付きコードブロックを使ってもかまいません。アサーションの順序や grep では証明できないことなどの補足は、行の後に簡潔に記載してください。2 つ目の /goal 行は絶対に出力しないでください。また、入力に観測可能な受け入れ基準がない場合（アルゴリズムのステップ 1）は、goal 行を一切出力せず、その旨を伝えて write-prd を案内してください。

オプション：ルーブリックの生成（.claude/rubric.json）

合否のブール値を超える評価付きフィードバックをユーザーが求める場合、このスキルは ork-rubric/1.0 に準拠した .claude/rubric.json（スキーマ：${CLAUDE_PLUGIN_ROOT}/shared/rubric.schema.json）を生成してもかまいません。各受け入れ条件を1つの評価軸に対応付けます。

{
  "rubric": "ork-rubric/1.0",
  "skill": "prd-to-goal",
  "dimensions": [
    { "name": "regression_test_added", "weight": 0.4, "min_pass": 8, "min_blocker": 3 },
    { "name": "auth_suite_green",      "weight": 0.4, "min_pass": 10, "min_blocker": 5 },
    { "name": "lint_clean",            "weight": 0.2, "min_pass": 10, "min_blocker": 0 }
  ]
}

スコアは0～10です（min_pass はソフトフロア、min_blocker は総合スコアにかかわらず適用されるハードブロッカーです）。評価軸の重みの合計は1.0でなければなりません。詳細な仕様についてはスキーマを参照してください。

このファイルは、意図的に**/goal の実行前にユーザーが編集できる**ようになっています。そこが重要な点です。重みや min_pass のしきい値を調整することで、アサーションを書き換えずにユーザーの判断をループに反映できます（ルーブリックを環境フィードバックとして用いる方法、Lance Martin 2026-06-09）。タイムアウト後の採点処理（§8）では、ルーブリックが存在する場合、それをユーザーの意図として扱います。これは文字どおりのアサーション文より優先されます。

5. 実例

例 A — バグ修正 PRD

入力（issue の本文）：

Title: Login fails on emails containing "+"
Acceptance Criteria:
- New regression test in tests/auth/test_login.py covers email with "+"
- The new test passes
- All existing auth tests still pass

出力：

/goal until test -f tests/auth/test_login.py AND pnpm test -- tests/auth/test_login.py passes AND pnpm test -- tests/auth passes, or stop after 5 turns

理由：ファイルの存在確認は最も低コストのチェックです。対象を絞ったテストは回帰の判定基準であり、広範な認証テストスイートは副作用を検出します。

例 B — 機能追加 PRD

入力（PRD の抜粋）：

Feature: User Avatar Endpoint
MUST:
- New route GET /users/:id/avatar registered
- Returns 200 with { url: string, updatedAt: ISO8601 } for known user
- Returns 404 for unknown user
- Integration test covers both cases
- OpenAPI spec updated

出力：

/goal until grep -q "users/:id/avatar" src/routes/users.ts AND pnpm test -- tests/integration/users.avatar.spec.ts passes AND grep -q "/users/{id}/avatar" openapi.yaml AND pnpm lint passes, or stop after 15 turns

理由：ルートの grep により、スタブのまま接続されていないハンドラーを検出します。統合テストの仕様には200と404の両方が記述されています。OpenAPI の grep でドキュメントに関する MUST を適用し、lint で型付けが不完全なコードのリリースを防ぎます。

例 C — リファクタリング PRD

入力（PRD の抜粋）：

Refactor: split monolithic src/auth.ts (1842 LOC) into per-strategy files
Definition of Done:
- src/auth.ts under 200 LOC
- New files in src/auth/strategies/*.ts cover oauth, jwt, password
- All auth tests still pass
- Lint clean
- No new files outside src/auth/

出力：

/goal until [ $(wc -l < src/auth.ts) -lt 200 ] AND test -f src/auth/strategies/oauth.ts AND test -f src/auth/strategies/jwt.ts AND test -f src/auth/strategies/password.ts AND pnpm test -- tests/auth passes AND pnpm lint passes, or stop after 30 turns

理由：LOC の上限が収束を示すシグナルです。これがなければ、/goal は延々と「改善」を続けられます。ファイルの存在確認で構造上の分割を明確にし、テストと lint で正しさを担保します。リファクタリングはバグ修正より時間がかかるため、予算は多めに設定します。

6. レシピライブラリ — 事前構築済みループ

§3～5 では、仕様からカスタムの /goal 行を生成しますが、レシピライブラリには、繰り返し使われる自律型ループ向けのレシピがすぐ使える状態で用意されています。それぞれ、生成された行と同じく、収束可能・反証可能・予算設定済みのルールに従い、ork のワーカースキルをループ形式で包んでいます。

レシピ	使用する場面	ワーカー
🧪 カバレッジ向上	カバレッジを有意義な形で目標まで上げる	cover
🔴 本番エラーの一掃	対応可能なエラーのバックログを解消する	fix-issue
📚 ドキュメントの乖離を一掃	ドキュメント／リファレンスがコードから乖離している	audit-full
⚡ ページ読み込み予算	ページのレイテンシが予算を超過している	performance
🧹 リポジトリのクリーンアップ	古いメモリ／状態が蓄積している	dream
✅ 品質の連続達成	1回の成功だけでは信用できない（不安定なテストスイート）	verify
🎫 チケット → PR 準備完了	issue を CI が成功する PR まで進める	fix-issue → create-pr
🧼 型／lint の未解消項目ゼロ	抑制設定を使わずに型／lint のバックログを解消する	fixer agent

すべてのレシピ（正確な1行の /goal until …, or stop after N turns、収束を示すシグナル、レシピごとのガードレール）は references/recipe-library.md にあります。このファイルは、skills.sh の ork-loops パック向けにリポジトリ内の情報源として用意されています（まだ構築されていません。Forward Future の Loop Library チャンネルで使われています）。そのため、ループのレシピを配布し、各パスの実行に必要な仕組みは ork が提供できます。

7. 反パターン

悪い例	問題点	良い例
/goal until tests pass	どのテストですか？既存のものですか、新しいものですか？どのコマンドで実行しますか？エージェントはすでに成功している任意のサブセットを選んで、完了したと主張できます。	/goal until pnpm test -- tests/auth/test_login.py passes AND pnpm test -- tests/auth passes
/goal until the code looks clean	反証できません。エージェントは「きれいに見える」かどうかを確認できないため、すぐに成功を宣言するか、いつまでも終わりません。	/goal until pnpm lint passes AND [ $(wc -l < src/auth.ts) -lt 200 ]
/goal until done	上限がありません。終了条件がなく、寛大な , or stop after 50 turns と組み合わさると、一晩で500Kトークンを消費する実行につながります。	観測可能なアサーションを3～5個選んでください。それができない場合、PRD の準備ができていません。write-prd に進んでください。

8. タイムアウト後のアサーション評価

/goal ループがターン数の上限に達した場合、同じ行を再試行せず、ループ中のエージェントに自分のアサーションを批評させないでください。コンテキストを新たにした評価エージェントを起動し、アサーションセット自体を監査させます。

# Bare-eval pattern — independent context window, zero shared state:
Bash("CLAUDE_CODE_FORK_SUBAGENT=1 claude -p --bare \"$(cat /tmp/grader-prompt.txt)\"")
# or: Agent(subagent_type="general-purpose", prompt=grader_prompt)  # fresh spawn, no producer prose

評価エージェントには、/goal の行、.claude/rubric.json（出力されている場合）、直近 N ターンの圧縮された要約、そして新たに再生成されたリポジトリ状態の証拠を渡します。評価エージェントは、次のいずれかの判定を返します。

判定	診断	アクション
tighten	アサーションが弱すぎます。エージェントは実際に成功しなくても条件を満たせます	より厳格に修正した行で再実行します
loosen	記述どおりではアサーションを満たせません（パスが誤っている、上限が実現不可能、テストスイートが事前に壊れている）	達成可能な内容に修正した行で再実行します
abort	タスクが本当にブロックされています（アクセス権がない、仕様に矛盾がある、環境が壊れている）	停止し、ブロッカーをユーザーに伝えます

評価は独立したコンテキストウィンドウで行う必要があります。自己批評は決して行わないでください（評価エージェントは生成側のコンテキストを共有しないため、検証用サブエージェントは自己批評を上回ります。Lance Martin、2026-06-09）。予算：タイムアウトごとに評価エージェントの呼び出しは 1 回までとし、評価エージェント自身をループさせないでください。

完全なパターン（プロンプトテンプレート、独立性のルール、実例）：${CLAUDE_PLUGIN_ROOT}/skills/chain-patterns/references/assertion-grader.md。

9. 関連スキル

• ork:write-prd — 入力に受け入れ基準がない場合は、最初に実行します。
• ork:brainstorm — PRD 自体に異論があり、ゴールを記述する前に選択肢を検討したい場合に役立ちます。
• ork:audit-full — /goal の終了後に audit-full を実行し、アサーションがエンドツーエンドで実際に満たされたことを確認します（ループではブール値を信頼しますが、監査では意図を再確認します）。