goal-driven-workflow

目標駆動型の長時間実行ワークフロー

検証可能な目標に向けて、エージェントを数時間にわたって自律実行します。主なハーネスの例は、Claude Code のネイティブな /goal（条件＋評価ループ）です。このスキルでは、要件との整合、受け入れ基準の階層化、サブエージェントのコンテキスト管理、実行後のレポートに加え、/goal が利用できない場合の汎用フォールバックを提供します。 ステージ 1～3 は読み取り専用の設計段階です。ステージ 4 は実行、ステージ 5 はレポートと受け入れです。デフォルトは手動モード（各ステージの終了時に一時停止）です。単独で呼び出された場合、「自动模式」／「自动跑」／「auto mode」でも、ステージ 1～3 とステージ 4 の開始承認時に一時停止します。これらの確認を省略したり、ハーネスを開始したりすることはありません。キューの子として呼び出された場合は、Stage-exit policy（以下を参照）に従います。 出力テンプレート：reference.md。

呼び出し規約

• トリガーワード（description に基づく）： 「goal 长跑」「goal run」「goal-driven」「目标驱动长跑」「一个 goal 下去跑」「长跑目标」「无人值守跑任务」「goal-run」／goal run、goal-driven、long-run goal、autonomous run、run until done
• コマンド形式：/goal-driven-workflow xxx、/goal-run xxx
• デフォルトの動作：xxx を目標として実行するタスクとして扱い、ステージ 1（明確化）に進みます。xxx にすでに具体的で検証可能な目標と受け入れ基準が含まれている場合は、テンプレート 1（固定ブロックまたはステージ 1 が不要であることを示す明示的な行）を出力し、それについて 1 回確認を得たうえで、ステージ 2 に進みます。この確認は、設計確認済みとなるためのステージ 1 完了として扱います。
• 適用対象外：単一ステップの編集、検証可能な終了状態がないタスク、または定期的な /loop 形式のポーリングや、通常の単一ターンの自動承認が適したタスク。ステージごとの成果物と判定に基づく、完了まで実行し続けるループではない、ステージゲート付き PDCA 向けの単発タスクは、solve-workflow／opsx-solve-workflow に直接振り分けます。ディスパッチ時のエンジン選択は、キューレイヤー（goal-driven-queue）が担います。

強い依存関係

Frontmatter の dependencies を参照してください。前提条件の確認に合格しない場合、フローを中止します。

• clarifying-question-discipline — ステージ 1 の明確化
• completion-evidence-discipline — ステージ 2／5 の受け入れ証拠
• design-approval-gate — Armed 状態に移行する、単独実行時のステージ 4 開始承認の一時停止（以下の長時間実行時の相違点を参照）
• intake-interview-discipline — ステージ 1 の詳細なインテーク（曖昧さを限定したインタビュー → アプローチの比較 → 固定 → 開始前のセルフレビュー）、ステージ 4 実行中の自己回答ルール、ステージ 5 の台帳提示
• ai-proxy-discipline — プロキシのチェックポイント（Stage-exit policy: ai-proxy）：モード未指定時のインテーク Q&A、範囲を限定した契約承認（Launch ではなく Arm）、ステージ 5 のレポート確認。このポリシーを持つカードに限り、スキルが見つからない場合は中止します。
• context-budget-discipline — ステージ 3 のコンテキスト計画の定量化（圧縮しきい値／フェーズからリセット境界への対応表／台帳のパス）および予算の節目におけるステージ 4 のしきい値確認
• figma-pixel-implement／figma-pixel-verify — インストールが必須です。目標のテキストに figma.com または node-id= が含まれる場合、あるいはユーザーがピクセル単位での復元を求める場合は、両方を読み込みます。

関連項目（参考情報）：solve-workflow（完全な PDCA）、docs/7x24-agent-reliability-handbook.md のハンドブック §8。

前提スキルの確認

ステージ 1 の前、起動時に、すべての強い依存関係について確認します。

1. 利用可能なスキルをスキャンします
2. すべて見つかった場合 → 続行します
3. 不足がある場合 → 不足している依存関係の通知（reference.md § 前提スキルの確認 — 不足時の通知）を表示し、ただちに中止します

ダウングレード禁止：強い依存関係が不足している場合は中止します。黙って簡略化してはなりません。

---

経路の選択（簡易）

長時間実行の規模は、ステージ 2 の目標条件と予算ですでに示されています。確度の高い単一ファイルの変更では、ステージ 2／3 を簡潔に保ちます（目標条件 1 つ＋最小限のサブエージェント計画）。複数モジュールにまたがる作業やドメイン横断の作業では、サブエージェントの分担とコンテキスト手法を詳細に計画します。ステージ 5（レポート＋人間による受け入れ）は省略できません。

---

ステージの概要

ステージ	ツールの権限	手動停止	必須の出力
1 明確化と出力仕様	❌ 読み取り／書き込み	⛔ 停止して確認を待つ	再記述 + テンプレート 1
2 受け入れ条件 + 目標条件	✅ 読み取り；❌ 編集／書き込み	⛔ 停止して確認を待つ	テンプレート 2 + 4 部構成の条件
3 サブエージェントの分担とコンテキスト	✅ 読み取り；❌ 編集／書き込み	⛔ 停止して確認を待つ	テンプレート 3
4 長時間実行の開始	✅ すべて	単独：⛔ Armed 状態で待機して Launch を待つ／キューの子：カードに実行指示が記載されたら開始	テンプレート 4 + 実行ログ
5 報告と受け入れ	✅ Bash；❌ 編集／書き込み	⛔ 停止して確認を待つ	テンプレート 5

手動モードでは、⛔ のたびに一時停止します。単独の呼び出しでは、自動モードでもステージ 1、2、3、およびステージ 4 の開始承認時の一時停止（Armed）で停止します。明示的な Launch 指示があるまでハーネスを開始しません。ステージ 5 では必ず人による受け入れを待ちます。キューの子の呼び出しは Stage-exit policy に従い、単独実行の Armed 待機には入りません。

キューの子と単独実行

この呼び出しがキューの子に該当するのは、このターンのユーザー／オーケストレーターによるディスパッチメッセージで、ステージ 1 の入力として凍結されたタスクカード（少なくとも凍結済み決定事項ブロック）がインラインで埋め込まれている場合のみです。会話履歴やディスク上の .goal-driven/ カードは該当しません。.goal-driven/queues/ をスキャンしないでください。呼び出し元が送信していない queue-child フラグを要求しないでください。それ以外の呼び出しはすべて単独実行です。

単独実行の実行前状態

• 設計確認済み：ステージ 1～3 が人の判断のもとで確認済みであり、かつステージ 4 の開始承認（最終的な目標条件 + 予算 + 付随チェックリスト）が確認済みです。途中から開始する場合でも、テンプレート 1 + 1 回の確認が必要です（上記参照）。
• Armed：設計確認が完了しています。明示的な Launch 指示があるまで長時間実行を開始しないことを通知してください。ステージ 4 の実行を開始しないでください。
• Launch：「开跑」 / "launch" / "start the run" / 「开始长跑」（および明らかな同義の翻訳）の場合のみ、ステージ 4 の実行を開始します。Launch に該当しない例：「自动模式」 / 「自动跑」 / "auto mode"；単独の「好的」 / "ok" / 「继续」 / "confirm"。Launch の後は、ステージ 1～4 を再度確認しないでください。設計確認が未完了の場合、Launch を拒否し、残りの確認を続けます。
• キューの子はこの状態遷移をスキップします。カードに記録された承認が、開始承認ゲートの証跡となります。

---

ステージ 1：要件と出力契約の明確化

⚠️ clarifying-question-discipline に従ってください（1 ターンにつき質問は 1 つ。明確になるまで複数回やり取りし、まず明確化して、急いで回答しないでください）。 🔒 詳細なヒアリング：intake-interview-discipline を読み込み、§A（詳細なヒアリング → アプローチの確定 → 範囲を限定したローンチ前の自己レビュー）を実施します。存在階層によって深さを決定します。存在する場合（デフォルト）は、意思決定ごとに質問し、影響の大きい項目では掘り下げ、3 部構成の基本を実施します。存在しないことが宣言済み、または構造上不在の場合は、1 回確認したうえで、変更せずに台帳全体を使用します。 📦 任意のトレーサビリティ：プロジェクトに openspec/ ディレクトリがあり、使用可能な openspec CLI（または同等のもの）がある場合、ヒアリングで traceability: openspec | none を選択肢として提示します。デフォルトはオフです。プロジェクトのポリシーで必須にでき、ユーザーの明示的な選択が優先されます。Template 1 に記録してください。 🎭 ステージ終了ポリシー：Template 1 に manual | ai-proxy | auto を記録します（キューの子はカードの interaction-budget ticket からこのポリシーを継承し、トリガーワードによるモード伝播より優先されます）。proxy = ai-proxy-discipline が、その規約に従って列挙されたチェックポイント（不在モードでのヒアリング Q&A、制約付き事前承認としての契約承認（Arms しますが、Launch はしません）、ステージ 5 のレポート確認）で人間の役割を担います。manual = 手動モードで一時停止します。auto = 実行中の質問に誰が回答するか（明示された例外と §B に従います）。単独実行では、auto によってステージ 1～3 の確認を省略したり、ステージ 4 のローンチ承認待ちを省略したり、Launch とみなしたりしてはなりません。

1. 目標を言い換える。目標／成果物／制約／期待される結果を抽出します。
2. 不明点がなくなるまで、各ターンで最も重要な質問を必ず 1 つだけ尋ねます（質問の選定は clarifying-question-discipline に従い、完了判定は intake-interview-discipline に従います）。推奨回答を添えた選択式を優先し、ホストに構造化 UI がない場合は自由記述に切り替えます。
3. アプローチの比較と確定 — 読み込んだ規律の §A ステップ 4～6（アプローチの比較 → 確定 → ローンチ前の自己レビュー）に従います。確定した決定のブロックは Template 1（reference.md の「Stage 1」）に記載します。
4. 出力契約：成果物と「完了」の基準について合意します。
5. 出力と結果を事前に判定します（ステージ 2 を参照）。エージェントが自己検証できる基準（出力型）と、人間による判断が必要な基準（結果型）を区別します。
6. 確定した決定のブロックを含め、Template 1（reference.md の「Stage 1」）に記入します。

無人でのヒアリング：キューの子の条件に該当する場合、インライン化されたカードの確定済み決定をこのステージに適用します。そのカードに確定済みの決定がない場合は、セルフアンサーモード（intake-interview-discipline 統合ガイド §4）でヒアリングを実行し、すべての回答を仮定として明示します。単独実行では、セルフアンサーによって Design-checked を完了してはなりません。人間の役割による確認がない場合、Launch を拒否します。

危険信号：複数の確認質問や未解決事項を 1 つのメッセージにまとめて提示すること。明確化の途中で回答を急ぐこと。明確化を急いで切り上げ、実行に進むこと。「とにかく良いものを作る」のような曖昧な目標。対象範囲と対象外の境界を定めないこと。アプローチの確定と自己レビュー（詳細なヒアリングでの確定）を行わずにローンチすること。ディスク上の .goal-driven/ カードをキューの子の供給元として扱うこと。

ステージ 2：受け入れ基準とゴール条件

ゴール条件は、凍結されたアプローチ（ステージ 1 での凍結）から導き出します。このステージでは、その上に受け入れ基準を重ねます。方針を再検討することはありません。凍結されたアプローチに問題があるように見える場合は、開始後ではなく、開始前に伝えてください。

1. 受け入れ基準を 3 つの層に分けて設定します（reference.md § ステージ 2 — テンプレート 2）：

   • 必須（機械で検証可能）→ エージェントが自己検証し、ゴールハーネスの条件になります
   • 準必須（LLM による判定＋決定論的チェッカー）→ 任意の品質ゲート
   • 人による確認（成果物の種類に応じた基準）→ ステージ 5 で人が受け入れを判断します
   • ゴールのテキストに figma.com または node-id= が含まれる場合、あるいはユーザーがピクセル単位での復元（像素级还原）を求めている場合、ピクセルの幾何情報は必須です。その部分文字列がスコープの根拠となります。指定されたチェックは、figma-pixel-verify の scripts/check-figma-verify-report.mjs が 0 で終了することです。これらの項目は準必須でも、人による確認の対象でもありません。表示されるテキストの確認、表示フラグ、リストの長さでは、必須項目を満たしません。実行中は figma-pixel-implement と figma-pixel-verify を読み込み、その手順に従ってください。同じテキストに 参考、match the existing、または same as も含まれる場合は、その事実を verify に渡し、名前が指定されたコントロールのインタラクション状態を項目として追加してください。

2. 4 つの要素を使ってゴール条件を設計します。主要なハーネス（/goal）の評価器はトランスクリプトのみを読み取り、コマンドの実行やファイルの読み取りは行いません。そのため、条件はエージェント自身の出力で実証できるものにする必要があります。

   <one measurable end state> + <stated check: how the agent proves it> + <constraints that must not change> + <budget clause: "or stop after N turns / N minutes">
   

   • 良い例：test/auth のすべてのテストに合格し、lint のステップがクリーンである
   • 良い例：旧 API のすべての呼び出し箇所が移行され、ビルドが成功すること。20 ターン経過したら終了する
   • 悪い例：アプリが本番環境で使用できる状態である（トランスクリプト内で検証できるものがありません）

3. 予算の指定は必須です — 主要な /goal ハーネスには、トークン予算が組み込まれていません。必ず または N ターン経過したら終了する（または時間に関する条件）を追加してください。

4. 複合的な目標は分割し、それぞれに検証可能な終了状態がある、順次実行する目標の連鎖にしてください。

5. 確認用に、テンプレート 2 ＋最終的な 4 要素の条件を出力してください。

traceability: openspec が有効な場合、成果物は次のように対応します。proposal ← ステージ 1 で凍結したアプローチとその理由、design ← このステージの受け入れ基準の分類と条件、tasks ← ステージ 3 の計画（openspec new change "<slug>"。実行の進行に合わせてチェックボックスを更新します）。

危険信号：曖昧な条件（無限ループや成功の幻覚を招く）、1 回のハーネス実行に複数の巨大な目標を詰め込むこと、予算条件がないこと、制約が気付かれないまま破られる可能性があること。

ステージ 3：サブエージェントの分担とコンテキスト管理

理由：コンテキストの劣化 — トランスクリプトが長くなるにつれて、想起の精度が低下します。すべてを1つのコンテキストに保持する長時間の実行では、パフォーマンスが低下します。分割は最適化ではなく、必須要件です。

1. 分担の原則：メインエージェントは高レベルの計画と統合（および目標条件）を保持し、サブエージェントはクリーンなコンテキストで詳細な作業を行い、**簡潔な要約（1～2kトークン）**のみを返します。
2. コンテキスト手法を選択します（reference.md § ステージ 3）：
   • サブエージェントアーキテクチャ — 並行した調査／複数モジュールにまたがる作業
   • 圧縮 — 長い会話の流れ。しきい値と復旧ルールは context-budget-discipline に従います（ウィンドウの約60～70％で予防的に実施し、上限付近だけを基準にしないでください）
   • 構造化されたメモ — マイルストーン主導の反復作業（NOTES.md／メモリー）
3. context-budget-discipline に従ってコンテキスト計画を定量化します：（a）コンテキストウィンドウに対する割合で示した圧縮しきい値、（b）計画したライフサイクルにおけるフェーズ→リセット境界の対応表、（c）セッション引き継ぎ用の台帳パスを明記してください。いずれかの要素が欠けた計画では、ステージ 4 の開始承認が得られません。
4. 各サブエージェントのタスク、最小限のツールセット、出力契約、完了条件、失敗時の対応を定義します。相互バイアスを避けるため、独立したハーネス（執筆者とレビュアーの分離）を優先してください。
5. テンプレート 3に記入します。

危険信号：メインエージェントがサブエージェントの詳細を取り込みすぎる（コンテキストが戻ってくる）、出力契約のないサブエージェント、無制限のツールセット。

ステージ 4：長時間実行を開始する

開始承認（単独実行）：承認パターンには design-approval-gate を読み込んでください。最終的なゴール条件＋予算＋付属チェックリストを確認します。この確認によって Armed 状態になりますが、低影響の実行や自動モード（design-approval-gate の一般的な自動実行による例外でもこの一時停止は省略されません）を含め、ハーネスを開始してはなりません。高影響の条件（無人実行／大きな予算／取り消し不能）も同じ一時停止の対象であり、承認時に実行する二度目の手順は発生しません。キューの子タスクでは、インラインカードに記録された承認を留痕として使用し、この単独実行の一時停止は行いません。

開始指示（単独実行）：Armed 状態になった後、かつ上記の定義済みリストにある明示的な開始フレーズを受け取った後にのみ、実行を開始してください。「自动跑」／「auto mode」／単独の確認は開始指示ではありません。プロキシは Design-checked まで進めてもかまいませんが、開始指示を出してはなりません。

1. 事前確認（意図優先；reference.md § ステージ 4）。かっこ内は主要ハーネスの例です。
   • リポジトリのルートにあるターンごとのプロジェクト規約ファイル（例：CLAUDE.md） — 複数ターンにわたって一貫性を保てるよう、アーキテクチャ、コーディング規約、受け入れルールを記述します。
   • 編集後の検証フック（例：PostToolUse の lint／型チェック） — 実行中に問題を検出します。
   • 定型的なツール書き込みには自動承認モードを使用します。これがないと、ファイルを書き込むたびに長時間実行が停止します。
   • 凍結済みの決定を引き継ぐ：実行プロンプト／契約に、凍結したアプローチとチケット台帳のパス（intake-interview-discipline）、およびトレーサビリティが有効な場合は openspec 変更パスを含めます。これにより、実行中に人間がいなくても「何が凍結されていたか」を確認できます。
   • ステージ 2 で定めた予算（ターン数／時間／トークン数）を確認します。
2. 開始（環境に応じて選択）：
   • 対話型ゴールハーネス：利用可能であれば、例として /goal <condition>。
   • ハーネスをラップする非対話型エージェント CLI：例として claude -p "/goal <condition>" --output-format stream-json --verbose。
   • フォールバック（ゴールハーネスがない場合）：手動の上限付きループ — 作業する → 受け入れチェックリストに照らして検証する → 未達なら続ける（予算の範囲内）→ 達成したら停止する。明示的な停止条件が必要です。
3. 実行中の判断ルール：実行中の判断は intake-interview-discipline §B に従います（自己回答の優先順位：凍結済みの契約 → 調査済みの事実 → 保守的なデフォルト。凍結したアプローチを否定する証拠がある場合は、明確に停止してチケットを報告し、黙って方針を変更してはなりません）。
4. 監視：ハーネスの状態（経過時間、ターン数、トークン数、最新の評価理由）を確認し、環境のキャンセル操作（例：Ctrl+C／/goal clear）で早めに中断します。予算の各マイルストーン（予算の半分／3 分の 1 ごと）に、評価理由、残りの予算、異常を記した実行ログを 1 行記録します。各マイルストーンでは context-budget-discipline に従ってコンパクションのしきい値も評価します（超えた場合は、次の安全な時点でリセットし、まず台帳に記録します）。進捗が継続的にない場合は、予算を使い切るのではなく、早めに中断します。
5. テンプレート 4 を出力します。単独実行の場合：Design-checked が未完了なら開始指示を拒否してチェックを続けます。Armed 状態の場合は、定義済みリストの開始指示を待ち、それを受け取ってからハーネスを開始します。キューの子タスクの場合は、Stage-exit policy に従って実行を開始します（カードの承認はすでに留痕されています）。

危険信号：自動承認モードを省略する（書き込み時に実行が停止する）；予算がない；ターンごとの規約ファイルがない；一連のゴールではなく巨大なゴールを 1 つにする；実行中に黙ってアプローチを変更する（intake-interview-discipline の厳守ルール 2 に違反）；Design-checked が未完了のままハーネスを開始する；「自动跑」や単独の「ok」／「confirm」を開始指示として扱う；開始承認と実行の開始をひとまとめにする。

ステージ 5：完了報告と人間による受け入れ

completion-evidence-discipline に従ってください。「完了／合格」と主張するには、今回のターンで得た最新の証拠（コマンド出力／テスト結果／ファイル差分）が必要です。各項目に Executed（コマンド＋出力の要約）または Pending（手動での対応が必要）とラベルを付けてください。

1. メインエージェントが構造化された完了報告（reference.md § ステージ 5 — テンプレート 5）を作成します。内容は、目標の振り返り、受け入れ状況（ハード／ソフト／人間）、番号付きの検証チェックリスト（目標達成状況と再提示した契約との照合／凍結したアプローチとの比較＋逸脱／テストと証拠の Executed–Pending ラベル／機能面と非機能面に分けた副作用／ロジックのエンドツーエンドレビュー）、成果物＋検証証拠、残件／リスク、費用、および決定／仮定の台帳（intake-interview-discipline §C — 未解決のチケット、確信度の低い仮定、誤っていた場合の影響が大きい項目を、人間の判断のために明示する。クリーンストップのチケットも含む）です。Stage-exit policy: ai-proxy の場合、ai-proxy-discipline に従い、チェックリストを新しいコンテキストのプロキシに渡します（判定にタグを付けます。不合格項目は再検証またはチケット化のために差し戻されます）。
2. traceability: openspec が有効な場合：変更に対して openspec validate を実行し、機械検証可能な証拠が揃ったら変更をアーカイブします（メイン仕様を同期します）。両方を報告内の証拠項目として記録します。結果の種類に関する指摘は、新規または改訂された変更に反映し、アーカイブを妨げる要因にはしません。
3. 人間による受け入れ：
   • 機械検証可能な項目：エージェントが報告し、抜き取り確認を行います。
   • 結果レベルの項目：人間が判断します。ハーネスの評価器は出力を検証しますが、結果を判断することはありません。
4. フィードバックループ：受け入れ時の指摘を、次回の実行におけるテンプレート 1 に反映します。

危険信号：証拠なしに「完了」と主張すること、エージェントが結果レベルの項目を自動的に合格とすること。

---

モードのライフサイクル

• 手動（デフォルト）：ステージ 1、2、3、ステージ 4 の起動承認待ち（Armed）、およびステージ 5 で一時停止します。起動には引き続き、対象を限定したリスト形式の指示が必要です。
• 自動（「自动模式」／「自动跑」／「auto mode」）：単独実行の場合でも、ステージ 1、2、3、およびステージ 4 の起動承認待ちで一時停止します。これらの確認を省略せず、ハーネスも開始しません（自動モードを示す言葉は Launch ではありません）。ステージ 5 は必ず人間による受け入れで終了します。キューの子実行では、実行中の質問に誰が答えるかについて Stage-exit policy に従い、2 回目の Armed 待ちは挿入しません。
• 手動への復帰：自動モードは、完了時（ステージ 5 の受け入れ後を含む）または中断時に、必ず手動モードに戻ります。自動モードへの再移行には明示的なトリガーが必要です。暗黙の継続によって再び有効になることはありません。
• 長時間実行の場合：実行が終了したら（目標達成または予算の消尽）、制御を人間に戻します。明示的な確認なしに新しい目標を自動開始したり、予算を自動で延長したりしないでください。

---

よくある間違い

間違い	結果	修正方法
決定論的チェッカーなしで自己修正する	「修正」によって、正常に動作していた結果が悪化する	決定論的チェッカーで検出された失敗に対してのみ反復し、修正のたびに再検証する
エージェントが結果レベルの項目を合格とする	実際に受け入れられていないのに「完了」とされる	結果の種類に関する基準は、ステージ 5 で人間が判断する
メインのハーネス CLI だけが使えるプラットフォームだと見なす	他のエージェントがスキルを実行できない	ステージ 4 では、意図優先の起動と汎用フォールバックに従う