mission-brief

mission-brief

このスキルでできること

mission-brief は、機能の説明を受け取り、ミッションブリーフ（目標、制約、成功基準）に整理し、プロンプト付きの順序立てられたステップリストを生成して、それらのステップを実行します。各ステップは、インストール済みの SDD スキルを起動するプロンプトを受け取ったサブエージェントに割り当てられます。YAML ワークフローファイルも、フレームワークごとのプロファイルも、プロファイルの検出も必要ありません。ステップのプロンプトでは、あらゆる SDD スキルセットで機能する標準的な SDD 用語（specify、plan、implement、converge）を使います。モデルから呼び出されるスキルは自動的に起動し、コマンドベースのフレームワークはファイル名で照合され、どちらも存在しない場合はサブエージェントが直接実行します。

使用するタイミング

• 「この機能を最初から最後まで構築する」場合：説明を入力すると、mission-brief がパイプラインを構成し、specify → plan → implement ↔ converge を実行します。
• サーキットブレーカーと監査証跡を備えた converge ループを使いたい場合。
• 中断されたミッションをセッションをまたいで再開したい場合（mission-brief --resume）。
• セッションをまたいで無人で実行したい場合（mission-brief --async）。

使用しないタイミング

• 小規模な編集を 1 つだけ行う場合 — そのまま作業してください。ミッションを使うと余分な手間がかかります。
• すでに仕様とタスクがあり、タスクを 1 つだけ実装したい場合 — implement スキルを直接呼び出してください。

ミッションブリーフのテンプレート

ステップを生成する前に、説明を次の形式に整理します。

## Mission Brief

**Goal**: <what to build — one sentence>
**Constraints**: <tech stack, limitations, dependencies, requirements>
**Non-Goals**: <what is explicitly out of scope — e.g., "no database storage, local memory cache only">
**Success Criteria**:
- <measurable outcome 1>
- <measurable outcome 2>
- <measurable outcome 3>

ブリーフには 2 つの目的があります。

1. 完了基準を事前に明確にする — converge ステップの独立性チェックに引き継がれます（チェッカーはこれらの基準に照らして検証します）。
2. ミッションのコンテキストを各ステップの委任プロンプトに引き継ぐ — これにより、各サブエージェントは前のステップを読み直さなくても、すべてのコンテキストを把握できます。

入力

$ARGUMENTS

上の $ARGUMENTS ブロック内のテキストが、そのままミッションの説明です。すぐに作業を進めてください。何を構築したいのか、ユーザーに尋ねないでください。

まず引数からフラグを解析し、残りのテキストを spec_description として扱います。

• --async / --sync — 実行モードのフラグ（設定のデフォルト値を上書きします）。
• --resume — 状態から明示的に再開します。
• その他すべて — ミッションの説明（spec_description）。

説明がなく、--resume も指定されていない場合：機能名から可能な範囲で説明を導き出します（Git ブランチ、または最後の状態）。--resume が指定されていて状態がない場合は、「中断されたミッションは見つかりませんでした」と報告して終了します。

機能名の導出：説明を小文字とハイフンで構成される文字列に変換し、ストップワード（a、an、the、new、to、with、for、add、fix、update）を除外します。例：「add a new react dashboard with telemetry」→ react-dashboard-telemetry。.adlc/workflow/runs/ にその名前のディレクトリがすでにある場合は、-2、-3 などを末尾に追加します。

フロー

すべてのパスは現在の作業ディレクトリ（エージェントが操作するプロジェクトルート）からの相対パスです。明示的に指定されていない限り、設定や状態をサブディレクトリ内で探さないでください。

フェーズ 0 — 設定

1. mkdir -p .adlc/workflow（および .adlc/workflow/tmp、.adlc/workflow/runs）を実行します。
2. .adlc/workflow/workflow-config.yml が存在しない場合は、スキルの config-template.yml（このファイルと同じディレクトリにあります）からコピーします。
3. .adlc/workflow/workflow-config.yml を読み込みます。フィールドがない場合のデフォルト値は次のとおりです。

workflow:
  execution: sync            # sync | async
  supervision: gated         # gated | hybrid | autonomous
  max_iterations: 5
  max_spec_corrections: 2
  circuit_breaker: 3
  quality_threshold: null    # optional 0-100, blocks DONE below threshold
  # models: { strong: "...", fast: "..." }   # optional

有効な実行モードを解決します。優先順位は --async/--sync フラグ > 設定の execution > sync です。--async が指定され、supervision が gated/hybrid の場合は、警告（「async ではゲートなしが必須です。自律実行します」）を出して、この実行に限り autonomous として扱います。

Phase 1 — 再開時の確認（--resume のみ）

<FEATURE_DIR> = .adlc/workflow/runs/<feature>/（Phase 4 で定義しますが、 ミッション完了の確認のため、ここで参照します）。

--resume が渡された場合：

1. .adlc/workflow/.mission-state.json を読み込みます。
2. <FEATURE_DIR>/mission-log.json が存在する場合 → 「feature X のミッションはすでに 完了しています。監査証跡：…」と報告 → 停止します。
3. completed_steps が空でない状態ファイルがある場合 → 再開します。state.steps からステップ リストを読み込み、最初の未完了ステップから Phase 5（実行）に進みます。
4. 状態がない場合 → 「中断されたミッションは見つかりませんでした。開始するには mission-brief \"<desc>\" を実行してください。」と報告 → 停止します。

--resume が渡されておらず、completed_steps が空でない状態ファイルがある場合は、確認を求めます — 「feature X のミッションが中断されています（N/M ステップ完了）。続行するには mission-brief --resume を実行するか、最初から開始することを確認してください（状態は破棄されます）。」状態を黙って上書きしてはいけません。

Phase 2 — ミッション概要

spec_description をミッション概要のテンプレートに沿って構成します。

1. 目標：中核となる目的を1文で抽出します。
2. 制約：説明とプロジェクトのコンテキスト（package.json、go.mod、言語ファイル、既存の仕様を確認）から、技術スタック、制限事項、要件を推測します。不明な点があればプレースホルダーを残し、ユーザーが記入するよう明示します。
3. 対象外：実装の焦点を保ち、シンプルにするため、明示的に除外すべき妥当な境界や機能を1〜2件推測します。推測できない場合は「なし」と記載します。
4. 成功基準：測定可能な成果を2〜5件導き出します。説明が曖昧な場合は、機能の種類に基づいて妥当な既定値を設定し、「提案 — 必要に応じて編集」と明記します。

概要をユーザーに提示します。

• 同期 + ゲートあり／ハイブリッド → 概要を表示し、続行前に確認または編集を求めます。
• 同期 + 自律型 → 成功基準が「TBD」または空の場合は、停止します：「自律モードには、確認可能な完了基準が必要です。」それ以外は確認なしで続行します。
• --async → 確認なしで続行します（自律型、ゲートなし）。

概要を .mission-state.json.brief に保存します。

Phase 3 — ルート分類とオプションフェーズ

spec／change／quick に分類します。

ルート	該当する場合	ステップ
spec	新機能、グリーンフィールド、「add/create/build」	ブレインストーミング? → 仕様策定 → 明確化? → 計画 → タスク → 分析? → 実装↺収束 → トレース?
change	変更、ブラウンフィールド、「fix/update/refactor」	仕様策定 → 実装↺収束
quick	小規模なタスク、簡単なタスク、「just/quick/simple」	実装のみ（概要全体を入力として使用）

spec ルートの場合のみ、オプションフェーズの候補を評価します（状態に記録し、監督がゲートあり／ハイブリッドの場合は、実行時のゲートでユーザーが各候補を承認します）。

フェーズ	候補となる条件
brainstorm	プロンプトがアーキテクチャに関するもの、または曖昧（「design」「approach」「compare」「how should we」、実行可能な解決策が複数ある）
clarify	成功基準が曖昧、または制約が不足している
analyze	ルートが spec（対称性のため）
trace	プロンプトに永続化、監査、トレーサビリティ、コンプライアンスが含まれる

Phase 4 — コマンドの検出とステップリストの生成

4a. コマンド／スキルの検出

references/agent-integrations.md（この SKILL.md と同じ場所にあります）を読み込みます。表に記載された各エージェントディレクトリについて、プロジェクトルートに存在するか確認します。検出したディレクトリを状態に記録します。

"discovered": {
  "skills_dirs": [".claude/skills"],
  "commands_dirs": [{"dir": ".opencode/commands", "ext": ".md"}]
}

この検出は生成時に一度だけ行い、--resume 時に再利用します。完全なアルゴリズムについては、リファレンスファイルを参照してください。

4a.1 ローカルスキルの一覧（汎用スキルルーティング）

スキルディレクトリを検出した後（4a）、すべての skills_dirs にあるインストール済みスキルを一覧にします。SKILL.md を含む各 <skills_dir>/<skill-name>/ サブディレクトリについて、次の手順を実行します。

1. SKILL.md のフロントマター（--- で囲まれた YAML）を読み取ります。
2. name と description を抽出します（フロントマターがない、または解析できない場合はディレクトリ名を使用します）。
3. discovered.local_skills にエントリを記録します。

"discovered": {
  "skills_dirs": [".claude/skills"],
  "commands_dirs": [{"dir": ".opencode/commands", "ext": ".md"}],
  "local_skills": [
    {"name": "tdd", "path": ".claude/skills/tdd", "description": "Test-driven development with red-green-refactor..."},
    {"name": "grill-me", "path": ".claude/skills/grill-me", "description": "Get relentlessly interviewed about a plan..."},
    {"name": "code-review", "path": ".claude/skills/code-review", "description": "Two-axis review of the diff..."}
  ]
}

この一覧はベンダーに依存しません。あらゆるソース（mattpocock/skills、addy osmani/agent-skills、superpowers、チーム独自のスキル、Agent-Skills標準に準拠したリポジトリなど）のスキルを取り込みます。この一覧は、ディスパッチ時（Phase 5）にすべてのサブエージェントへ渡されるため、LLM が現在のステップに適したスキルを判断します。フェーズとスキルをハードコードで対応付けるテーブルはありません。

4b. ステップリストの生成

ルートと、オプションフェーズの候補に基づいて、順序付きのステップリストを生成します。各ステップは構造化オブジェクトであり、state.steps に保存されます。

{
  "id": "specify",
  "phase": "specify",
  "tier": "strong",
  "prompt": "Write a feature specification for the goal below. ...",
  "status": "pending"
}

ステップリストはレビュー可能な成果物です。ゲート付き／ハイブリッドモードでは、実行前にユーザーに提示します。

## Mission Steps

1. [specify]  (strong) Write a feature specification for: react dashboard with telemetry
2. [plan]     (strong) Break down the specification into an implementation plan
3. [tasks]    (fast)   Generate the detailed task list from the plan
4. [implement](strong) Implement the next pending task from the plan
5. [converge] (fast)   Review the implementation against the spec and success criteria
   ↺ loop 4–5 until converged (max 5 iterations, circuit breaker 3)

quick ルートの場合：入力としてブリーフ全体を使う、単一の implement ステップです。

change ルートの場合：specify と implement↺converge のループです（オプションフェーズはありません）。

spec ルートの場合：ゲート付き候補としてオプションフェーズを挿入した、完全なパイプラインです。

ステップのプロンプト構築

各ステップの prompt は、次の3つの要素で構成されます。

1. フェーズの指示 — 各フェーズで使用する標準的な SDD 用語：

フェーズ	ティア	指示
brainstorm	strong	「以下の目標について、アプローチとトレードオフを検討してください。実行可能な解決策を複数検討し、推奨する設計を提示してください。」
specify	strong	「以下の目標について、機能仕様を作成してください。要件、制約、測定可能な成功基準を含めてください。」
clarify	fast	「仕様を確認し、チームに質問して、不明確な成功基準や不足している制約を解決してください。」
plan	strong	「仕様を、順序付けられた検証可能なタスクを含む実装計画に分解してください。」
tasks	fast	「計画から詳細なタスクリストを生成してください。各タスクには、正確なファイルパスと検証手順が必要です。」
analyze	fast	「実装前に、計画を批判的にレビューしてください。重要な判断はすべて検証してください。」
implement	strong	「計画内の未完了タスクのうち、次のものを実装してください。テスト駆動の手法に従ってください。」
converge	fast	「実装を仕様と成功基準に照らしてレビューしてください。独立して検証してください。あなたは作成者ではなく、チェッカーです。」
trace	fast	「この機能で行われた判断を、ADR または引き継ぎドキュメントとして記録してください。」

2. Mission Brief のコンテキスト — Phase 2 の目標、制約、成功基準を、各プロンプトに追加します。

3. 委任用ラッパー — 実行側がディスパッチ時（Phase 5）に追加します。このラッパーには discovered.local_skills が含まれ、サブエージェントは現在のステップでインストール済みのスキルを呼び出すかどうかを判断できます。

Phase 5 — ステップリストの実行

state.steps を反映した todowrite リストを作成します。completed_steps に含まれるステップは完了としてマークします。各ステップの後に更新します。

ステップのディスパッチ

status: pending の各ステップに対して：

1. 次を出力します：

   ## Workflow Step: <id>
   
   **Phase**: <phase> (<tier>)
   

2. ステップが converge ステップ（フェーズが converge）の場合、委任プロンプトの先頭に独立性に関するヒントを追加します：

   あなたは別のエージェントが作成した成果物を評価しています。実装が正しいと決めつけず、仕様に照らして独立に検証してください。各要件について、主要な情報源で失敗するかどうかを試してください（テストの実行、ファイルの確認、参照箇所の grep など）。あなたはチェッカーであり、作成者ではありません。

   重要：非目標に記載されている機能や実装が一切導入されていないことを確認してください。スコープ外の作業が実装されていた場合は、結果シグナルとして CONTINUE を報告し、概要に非目標への違反を記載してください。

3. 次のプロンプトをそのまま使用してサブエージェントに委任します：

   You are being invoked by the `mission-brief` executor.
   
   ## Task
   
   <step.prompt>
   
   ## Mission Brief
   
   **Goal**: <goal>
   **Constraints**: <constraints>
   **Non-Goals**: <non-goals>
   **Success Criteria**: <success criteria>
   
   ## Available Skills in This Workspace
   
   <LOCAL_SKILLS_LIST>
   
   The list above shows skills installed in this workspace from any source
   (ADLC team skills, mattpocock/skills, addy osmani/agent-skills,
   superpowers, or custom). Review each skill's name and description.
   If one matches the goal of your current task, **invoke it** (via the
   skill tool or by reading its SKILL.md inline) and use it to execute
   this step. If multiple skills could apply, pick the best fit. If none
   apply, proceed with direct execution.
   
   ## How to execute
   
   Try these in order:
   
   1. **Skill match**: If an installed skill's description matches this task,
      invoke it (via skill tool or by reading its SKILL.md inline).
   
   2. **Command match**: If a command file for this phase exists, read and
      execute it. <DISCOVERED_PATHS>
      Look for a file whose name matches the phase (e.g., `*specify*`,
      `*implement*`, `*converge*`).
   
   3. **Direct execution**: If neither exists, execute the task directly using
      your available tools.
   
   **Confidence Self-Estimation**:
   Evaluate your confidence (HIGH/MEDIUM/LOW) in this implementation or task. If
   you are missing critical context, have low confidence, or find the requirements
   ambiguous, report `Confidence score: LOW` (or `MEDIUM`) and list the specific
   unresolved details in your return summary.
   
   If you found a skill or command, note its name in your summary.
   
   Do NOT follow handoffs to other skills or commands — return your results to
   the executor when you finish.
   
   Return:
   1. A 1-2 sentence summary (mention which skill/command you used, if any).
   2. Files changed (if any).
   3. Test results (if any).
   4. Outcome signal: DONE | CONTINUE | SPEC_CORRECTION_NEEDED.
      - DONE: work is complete and verified.
      - CONTINUE: more work is needed (tasks remain, review found issues).
      - SPEC_CORRECTION_NEEDED: verification found spec-level issues that
        require re-running specify. Include a `spec_corrections` field with
        the specific issues.
   5. (optional) Quality score: "X/Y (Z%)" — if a verification skill ran
      quality gates, report the score.
   6. (optional) Gate summary: "N passed, M failed" — if quality gates were
      checked, list which passed and which failed.
   7. (optional) Confidence score: HIGH | MEDIUM | LOW. Self-estimated confidence in the correctness of your work.
   8. (optional) Unresolved details: <brief description of what is uncertain or missing context>.
   

   <LOCAL_SKILLS_LIST> は、discovered.local_skills から作成された形式付きリストに置き換えます。各項目にはスキル名、パス、説明が表示されます：

   - **tdd** (`.claude/skills/tdd`) — Test-driven development with red-green-refactor...
   - **grill-me** (`.claude/skills/grill-me`) — Get relentlessly interviewed about a plan...
   - **code-review** (`.claude/skills/code-review`) — Two-axis review of the diff...
   

   discovered.local_skills が空の場合、<LOCAL_SKILLS_LIST> は次の内容に置き換えます："このワークスペースでカスタムスキルは検出されませんでした。"

   <DISCOVERED_PATHS> は、state.discovered から検出されたディレクトリに置き換えます：

   • commands_dirs が空でない場合："次の場所を確認してください： .opencode/commands/ (.md)、.claude/commands/ (.md)、..."
   • skills_dirs が空でない場合："インストール済みスキルの場所： .claude/skills/、..."
   • 両方とも空の場合："ハーネスの commands/skills ディレクトリを確認するか、 references/agent-integrations.md で既知の場所を確認してください。"

4. サブエージェントの完了を待ちます。

5. 今すぐ .mission-state.json を更新します — 次のステップに進む前に行います。サブエージェントから返された値を、step_results.<id> の下に保存します：

   • 1～2文の概要を step_results.<id>.output として保存します
   • 信頼度スコアを step_results.<id>.confidence として保存します（指定がない場合は HIGH をデフォルトとして使用します）
   • 未解決の詳細を step_results.<id>.unresolved として保存します
   • <id> を completed_steps に追加します
   • state.steps[N].status = completed に設定します
   • 状態ファイルを書き込みます。サブエージェントからの応答全文は破棄します。

   信頼度エスカレーションゲート：解析された信頼度スコアが LOW で、アクティブな監督モードが autonomous または hybrid の場合：

   • このステップの検証に対する監督モードを gated に自動エスカレーションします。
   • 実行を停止し、サブエージェントの調査結果と未解決の詳細をユーザーに提示します：

     "⚠️ サブエージェントはステップ を完了しましたが、次の理由により信頼度が LOW と報告しました：[未解決の詳細]。監督モードは gated に自動エスカレーションされました。変更内容を確認し、続行する前に承認しますか？（yes/no）"

   • ステップリストを続行する前に、ユーザーの明示的な確認を待ちます。承認された場合は続行し、拒否された場合はミッションを一時停止します。

6. ステップが implement の場合、<FEATURE_DIR>/iterations.md に次を追加します：

   ## Iteration <N> - <date>
   - Files changed: <list>
   - Summary: <1-2 sentences>
   - Tests: <pass/fail>
   

7. converge サブエージェントが結果シグナルとして SPEC_CORRECTION_NEEDED を返した場合は、停止して Phase 6 に spec_correction_needed を返します。続行してはいけません。

ゲートステップ（sync、gated/hybrid のみ）

監督モードが gated または hybrid の場合、実行者はゲートをインラインで挿入します（個別のステップとしてではなく、実行者の動作として挿入します）：

• specify の後（gated + hybrid）："仕様が作成されました。実装の前に確認しますか？" と尋ねます → 続行／修正（specify を再実行）／中止。
• 各 implement の後（gated のみ）："実装が完了しました。収束確認を実行しますか？" と尋ねます → 続行／修正（implement を再実行）／中止。
• 最終承認（gated + hybrid）：converge の後に、"収束確認に合格しました。完了を確認して承認しますか？" と尋ねます → 承認／却下（一時停止）。

--async または autonomous の場合：ゲートも最終承認もありません。

ゲートの選択内容は step_results.<id>_gate.output.choice に保存します。

収束ループ（実装 ↔ 収束）

実装ステップと収束ステップは、do-while ループを形成します。

1. implement ステップを実行します（反復 N）。
2. converge ステップを実行します。
3. 収束サブエージェントの結果シグナルを確認します。
   • DONE → ループを終了し、フェーズ 6 に進みます。
   • CONTINUE → consecutive_tasks_appended をインクリメントし、サーキット ブレーカー（下記）を確認します。max_iterations 未満の場合は 1 に戻って 繰り返します。

追跡には反復プレフィックス付き IDを使用します。例：loop_0_implement、 loop_1_implement など。ステップの id はそのままにし、プレフィックスを付けるのは completed_steps のエントリーだけです。

サーキットブレーカー。 状態内で consecutive_tasks_appended を追跡します。各 収束ステップの後、シグナルが CONTINUE の場合はインクリメントし、DONE の場合は 0 に リセットします。カウンターが circuit_breaker（デフォルトは 3）に達した場合 → ループを停止し、failed を返します。「サーキットブレーカー：N 回連続で反復しても 収束しませんでした。人によるレビューが必要です — ループが収束していません。」 このカウンターは再開後も保持されます。

スコア回帰の追跡。 状態内で consecutive_score_regressions を追跡します （初期値は 0）。品質スコアを返す各収束ステップの後：

• 現在のスコア < 前回のスコア → consecutive_score_regressions をインクリメントします
• 現在のスコア >= 前回のスコア → 0 にリセットします
• consecutive_score_regressions が circuit_breaker（デフォルトは 3）に達した場合 → 停止します：「サーキットブレーカー：N 回連続でスコアが低下しました。品質が 悪化しています — 人によるレビューが必要です。」このカウンターは再開後も 保持されます。

品質しきい値の適用。 quality_threshold が設定され（null 以外）、収束 サブエージェントがしきい値を下回る品質スコアで DONE を返した場合 → 代わりに CONTINUE として扱います（必要な品質基準を満たしていないため、作業は完了していません）。

コンテキスト予算への配慮

各ステップの後、サブエージェントからの応答全文を要約して破棄します。5 ステップ以上 進んだ後は、積極的に次のように提案します：「セッションが長くなってきました — 続けることも、新しいチャットを開始して mission-brief --resume を実行することも できます。」応答が繰り返しになる場合は、新しいチャットを提案します。

フェーズ 6 — 完了時の処理

すべてのステップが完了したとき（またはシグナルによって戻るとき）は、そのシグナルに 応じて処理します。

spec_correction_needed（収束サブエージェントが SPEC_CORRECTION_NEEDED として返す場合）：

1. 状態を読み込みます。spec_corrections >= max_spec_corrections の場合 → 停止： 「仕様が評価に繰り返し失敗しています（N/M）。仕様に対する人によるレビューが 必要です。」確認できるよう、状態を保持します。
2. それ以外の場合：spec_corrections をインクリメントし、すべてのステップの状態を pending にリセットします（パイプラインを新規実行）。再実行し（フェーズ 5）、 フェーズ 6 を繰り返します。

converged または tasks_appended（ループ完了時）：

• sync + gated/hybrid → 人による承認が必要：iterations.md の監査証跡を表示し、 「収束チェックに合格しました。内容を確認して完了を承認しますか？」と尋ねます → 承認した場合は続行し、拒否した場合は一時停止します（「ミッションをレビューのため 一時停止しました。問題に対処した後、mission-brief --resume を実行してください。」）。
• sync + autonomous、または --async → 承認を省略します。
• .mission-state.json を .adlc/workflow/runs/<feature>/mission-log.json に移動します（監査証跡 — 削除しません）。
• 次の内容を報告します。

  ## Mission Complete
  - Feature: <feature>
  - Route: <route>
  - Execution: <sync|async>
  - Supervision: <mode>
  - Signal: <converged|tasks_appended>
  - Spec corrections: <n>/<max>
  - Audit trail: .adlc/workflow/runs/<feature>/mission-log.json
  

failed：エラーを報告し、確認できるよう状態を保持します。ユーザーは mission-brief --resume を再実行できます。

安全メカニズム

• 監督モード：gated（デフォルト）は途中で承認ゲートを設けます。autonomous は自由に実行しますが、確認可能な完了基準が必要です（「TBD」は拒否します）。hybrid は仕様レビューと最終承認時のみゲートを設けます。
• 信頼度のエスカレーション：サブエージェントが実行中に Confidence score: LOW を報告した場合、システムは autonomous／hybrid モードを上書きし、人間による対話型ゲートを強制します。
• 非目標の順守：Mission Brief には対象外の範囲が含まれます。converge ステップは独立した評価者として、非目標への違反を明示的に確認し、拒否します。
• 非同期ではゲートを設けない：--async と gated／hybrid の設定を併用すると、警告を表示して autonomous に切り替えます。
• 内部ループの上限：max_iterations（デフォルトは 5）。
• サーキットブレーカー：収束しない反復が連続 N 回に達すると停止します（デフォルトは 3）。無限ループを防ぎ、再開後も状態が維持されます。
• 外部ループの上限：max_spec_corrections（デフォルトは 2）。converge サブエージェントからの SPEC_CORRECTION_NEEDED シグナルで作動します。
• スコア低下の検出：品質スコアが N 回連続で低下傾向にある場合（circuit_breaker）、サブエージェントが CONTINUE を報告していてもループを停止します。
• 品質しきい値：設定されている場合、しきい値未満では DONE をブロックし、代わりに CONTINUE として扱います。
• converge の独立性に関するヒント：converge サブエージェントは独立して検証します。
• 監査証跡：iterations.md と mission-log.json。削除されません。
• 状態の永続化：.mission-state.json はコンテキストの圧縮や再起動後も保持されます。
• 明示的な再開：mission-brief --resume を使用します。新規の mission-brief は、中断した状態を上書きする前に確認します。

よくある正当化

正当化	実態
「小さなタスクだから、converge ループは省略します」	小さなタスクには quick ルート（実装のみ）を使用します。spec/change に分類した場合は、ループが重要な部分です。
「ゲートは後で実行します」	ゲートは早期に逸脱を検出するためのものです。仕様ゲートを省略すると、レビューされていない仕様に基づいて実装することになります。
「Async でもゲートを残して、私が回答できます」	非同期実行を監視している人はいません。Async ではゲートがなくなります。ゲートが必要な場合は sync を使用してください。
「状態ファイルは単なる邪魔なので、削除します」	これは再開と監査の仕組みです。削除すると、チェックポイントからの再開機能と監査証跡が失われます。
「再開するには mission-brief をもう一度実行すればよいです」	--resume を指定しないと確認を求められ、状態を上書きする可能性があります。mission-brief --resume を使用してください。
「Mission Brief は不要です。すぐにコーディングを始めます」	Brief によって成功基準が明示されます。これがなければ、converge ステップで照合する対象がありません。

危険信号

• 各ステップの後に .mission-state.json を書き込まずに実行する。
• --async 実行中にゲートを挿入する。
• Success Criteria が「TBD」の場合に、自律モードで Mission Brief を省略する。
• サブエージェントの応答全体を作業メモリに読み込む。要約して破棄する代わりに、全文を保持する。
• 確認せずに中断した状態を上書きする（--resume を指定せずに新規の mission-brief を実行する）。
• 完了時に .mission-state.json を mission-log.json に移動せず、削除する。
• state.discovered から検出したパスを使わず、特定のエージェントのコマンドディレクトリをハードコードする。
• converge サブエージェントからの SPEC_CORRECTION_NEEDED シグナルを無視し、DONE として処理を進める。
• サブエージェントの信頼度 LOW の報告を無視し、人間へのエスカレーションを行わずに処理を進める。
• 非目標への違反を報告せず、CONTINUE と判定しないまま converge ステップを通過させる。

検証

• .adlc/workflow/workflow-config.yml が存在します（存在しない場合はテンプレートからコピーされます）。
• .mission-state.json に次の内容が含まれています：brief（目標／制約／成功基準）、steps（フェーズ／ティア／プロンプト／ステータスを含む順序付きリスト）、discovered（skills_dirs + commands_dirs + local_skills）、completed_steps（単調に増加します）。
• iterations.md に実装ステップごとのエントリーが追加されます。
• 完了時に、.adlc/workflow/runs/<feature>/ の下に mission-log.json が存在します。
• 状態がない状態で --resume を実行すると、「中断されたミッションが見つかりません」と報告して停止します。
• mission-log.json がある状態で --resume を実行すると、「すでに完了しています」と報告します。
• 委任プロンプトには、ハードコードされたリストではなく、検出されたパスが含まれます。
• 委任プロンプトには、discovered.local_skills から作成された <LOCAL_SKILLS_LIST> が含まれます（リストが空の場合は「カスタムスキルは検出されませんでした」と表示されます）。
• ゲートステップは、同期実行かつゲート付き／ハイブリッド実行の場合にのみ表示され、--async では表示されません。
• converge からの SPEC_CORRECTION_NEEDED シグナルは Phase 6 にルーティングされます（DONE または CONTINUE として扱われません）。
• quality_threshold が設定されている場合、閾値を下回る converge のスコアは CONTINUE として扱われます。
• サブエージェントからの Confidence score: LOW の報告により、監督モードが自動的にゲート付きレビューに上書きされます。
• Non-Goals セクションが brief に正しく入力され、すべてのサブエージェントのプロンプトコンテキストに渡されます。

設定

• .adlc/workflow/workflow-config.yml — 実行、監督、予算、品質しきい値、任意のモデルマップ。config-template.yml を参照してください。
• references/agent-integrations.md — エージェントとディレクトリの完全な対応表。新しいエージェントの追加時や規約の変更時に更新してください。executor はコマンド／スキルの検出時にこのファイルを読み込みます。

セッション例

# Start a sync gated mission
mission-brief "add a new react dashboard with telemetry"

# Run unattended across sessions
mission-brief --async "refactor the auth module to use JWT"

# Resume after a session restart or a paused gate
mission-brief --resume