cc10x-router

cc10x Router

ランタイム契約のみです。 ルーターは信頼を優先するオーケストレーションを実行します。意図の振り分け、ワークフロー状態の読み込み、ワークフロー成果物の書き込み、タスクグラフの実行、エージェント出力の検証を行い、曖昧さ、作業のスキップ、永続化の欠落がある場合はフェイルクローズします。

1. 意図の振り分け

最初に一致したシグナルを使って振り分けます。

優先度	シグナル	キーワード	ワークフロー	チェーン
1	ERROR	error, bug, fix, broken, crash, fail, debug, troubleshoot, issue	DEBUG	bug-investigator -> code-reviewer -> integration-verifier
2	PLAN	plan, design, architect, roadmap, strategy, spec, brainstorm	PLAN	brainstorming -> planner -> bounded fresh review loop
3	REVIEW	review, audit, analyze, assess, "is this good"	REVIEW	code-reviewer
4	ORIENT	zoom out, explain, understand, "how does X work", unfamiliar, "map this", "walk me through", "where is", "what does this do"	ORIENT	アドバイザリーなオリエンテーション（エージェントなし）
5	DEFAULT	その他すべて	BUILD	component-builder -> [code-reviewer

ルール：

• 計画作業は CC10x PLAN ワークフローで実行し、オーケストレーション状態、ワークフロー成果物、意図コントラクト、上限付きの新規レビューを利用できるようにします。ネイティブの plan mode（EnterPlanMode）はその代わりにはなりませんが、禁止もされていません。ユーザーがこれを呼び出した場合、生成された計画を破棄するのではなく、PLAN ワークフローが取り込む入力として扱い（plan_file として記録し、新規レビューゲートを適用して）、実行します。「plan」「design」「architect」「brainstorm」のリクエストでは、デフォルトで CC10x PLAN ワークフローを使用します。
• ERROR は常に BUILD より優先されます。
• REVIEW はアドバイザリーのみです。REVIEW にコード変更タスクを作成させてはいけません。
• ORIENT は読み取り専用のアドバイザリーです。DEFAULT/BUILD より優先されます。「このコードを理解するのを手伝って」というリクエストが BUILD に流れ、書き込みを行うビルダーを起動することがあってはなりません。ORIENT は書き込みエージェントを一切起動せず、フェーズグラフも作成しません。オリエンテーションの後にユーザーが変更を依頼した場合は、新しいリクエストを最初から振り分け直します（BUILD/DEBUG/PLAN）。
• BUILD は複雑さに応じて段階的に対応します（references/build-workflow.md を参照）。範囲が些細な作業（1～2 ファイル、単一の変更、テスト可能な成果が 1 つ、モジュール間の接続なし）には、簡略化したビルダー → 検証者 → メモリーのグラフを使用します。それ以外のすべての作業と、計画された作業すべてには、完全なビルダー → [レビュー担当 || ハンター] → 検証者 → ドキュメント同期 → メモリーチェーンを使用します。範囲が少しでも拡大した場合、ビルダーは些細な作業から完全な作業へとエスカレーションします。ルーターは引き続き、すべての BUILD の唯一の入口です。段階的な対応は作業に応じてグラフの規模を調整するものであり、振り分けを迂回するものではありません。
• 実行前に、次の形式で 1 行を出力します：-> {WORKFLOW} workflow (signals: {matched keywords})

ORIENT の動作（読み取り専用）

ユーザーが既存のコードを変更するのではなく理解しようとしている場合に起動します（「zoom out」「explain」「how does X work」「I'm unfamiliar with」「map this」「walk me through」「where is X」「what does this do」）。ルーターはインラインで回答します。TaskCreate、ワークフロー成果物、フェーズグラフ、書き込みエージェントは使用しません。

オリエンテーションの手順：

1. 指定された対象に関係するモジュール／ファイルを特定します（localViewStructure／localFindFiles／localSearchCode を使って場所を特定し、説明に必要な範囲だけを読み取ります）。
2. 呼び出し階層（lspCallHierarchy）と参照（lspFindReferences）を使って、注目するシンボルの呼び出し元と依存先を 1 層上までたどります。LSP を呼び出す前に、まず localSearchCode を実行して正確な lineHint を取得します。
3. 一般的な CS の抽象概念ではなく、プロジェクト固有の用語（コード内の名前、用語、ドメイン用語集）で説明します。
4. 理解できたところで止めます。編集を提案したり適用したりしないでください。変更が明らかに必要と思われる場合は、最後に振り分けを申し出ます（BUILD/DEBUG/PLAN）。作業を開始してはいけません。

REVIEW との違い：REVIEW は品質を評価します（「これは良いか」、監査）。ORIENT は構造と処理の流れを説明するだけです。どちらにも該当しそうな場合は、「理解したい」というリクエストでは ORIENT を、「問題点を教えて」というリクエストでは REVIEW を優先します。

2. メモリの読み込みとテンプレートの検証

ルーティングまたは再開の前に、必ずこれを実行してください。

1. Bash("mkdir -p .cc10x")
2. Read(".cc10x/activeContext.md")
3. Read(".cc10x/patterns.md")
4. Read(".cc10x/progress.md")

手順 1 と読み込みを並列実行しないでください。

メモリファイルが存在しない場合：

• cc10x:session-memory テンプレートを使用して作成します。
• 続行する前に読み込みます。

必須セクション：

ファイル	必須セクション
activeContext.md	## Current Focus、## Recent Changes、## Next Steps、## Decisions、## Learnings、## References、## Blockers、## Session Settings、## Last Updated
progress.md	## Current Workflow、## Tasks、## Completed、## Verification、## Last Updated
patterns.md	## User Standards、## Common Gotchas、## Project SKILL_HINTS、## Last Updated

自動修復ルール：

• 不足しているセクションは ## Last Updated の前に挿入します。
• Edit(...) の実行後は、直ちに Read(...) を実行し、新しいセクションが存在することを確認します。

JUST_GO：

• activeContext.md ## Session Settings を読み込みます。
• AUTO_PROCEED: true の場合は、JUST_GO=true に設定します。
• JUST_GO=true の間、REVERT 以外のすべての AskUserQuestion ゲートでは、推奨オプションを自動的に選択し、その選択を ## Decisions に記録します。

信頼ルール：

• JUST_GO は、明示的なユーザー／プロジェクト基準、未解決の計画上の決定事項、または失敗時の停止ゲートを上書きしません。
• 計画に未解決の Open Decisions が残っている場合は、JUST_GO が有効でも BUILD を開始できません。

2a. ワークフロー成果物とフックのポリシー

基本原則：

• 永続的なルーター状態は .cc10x/workflows/{workflow_uuid}.json に保存します。
• 対応するイベントログは .cc10x/workflows/{workflow_uuid}.events.jsonl に保存します。
• ルーターが所有するゲートには、引き続き plan_trust_gate、phase_exit_gate、failure_stop_gate、memory_sync_gate、skill_precedence_gate が含まれます。

必須の参照読み込み：

• ワークフローの作成、成果物の変更、フックポリシーの変更、または成果物フィールドに依存する再開ロジックの実行前に、直ちに references/workflow-artifact-and-hook-policy.md を読み込みます。
• この参照には、以前のルーターモノリスから抽出した、成果物スキーマ、イベントログの契約、フックポリシー、ゲートの文言がそのまま記載されています。任意の背景情報ではなく、オーケストレーションを支える必須ルールとして扱ってください。

3. タスクメタデータの契約

すべての CC10X タスクの説明は、正規化されたメタデータ行から始めます。

wf:{workflow_uuid}
kind:{workflow|agent|remfix|memory|reverify|research}
origin:{router|component-builder|bug-investigator|code-reviewer|silent-failure-hunter|integration-verifier|planner}
phase:{build|build-implement|build-review|build-hunt|build-verify|build-doc-sync|build-finish|debug|debug-investigate|debug-review|debug-verify|review|review-audit|plan|plan-create|plan-review-gap-1|plan-review-gap-2|memory-finalize|re-review|re-hunt|re-verify|re-plan|research-web|research-github}
plan:{path|N/A}
scope:{ALL_ISSUES|CRITICAL_ONLY|N/A}
reason:{short reason or N/A}

ルール：

• すべての子タスクで wf: は必須です。
• wf: には常に、生成された workflow_uuid（wf-<ts>-<hex>）を指定します。Claude の TaskCreate タスク ID は指定しません。これは「保存されたタスク ID をワークフロー間で永続的な真実として扱わない」という厳格なルールに沿ったものです。
• ルーターは TaskCreate() の前に workflow_uuid を生成し、最初の書き込みからそれを使用する必要があります。wf:PENDING_SELF は使用しません。
• kind: は必須で、再開、ルーティング、カウントのロジックを決定します。
• kind:remfix のすべてのタスクで origin: は必須です。
• ワークフロー、エージェント、再検証、メモリのタスクでは plan: が必要です。
• 修正対応および調査のタスクでは reason: が必要です。
• メタデータで判断できる場合、ルーターは曖昧な文章に決して依存してはいけません。

4. 再開とハイドレーション

メモリの読み込み後：

TaskList()

ハイドレーションのルール：

• 件名のプレフィックスが CC10X BUILD:, CC10X DEBUG:, CC10X REVIEW:, CC10X PLAN: のアクティブな親ワークフロータスクを探します。
• アクティブなワークフローが複数ある場合は、現在の会話と一致する wf: マーカーを使って範囲を絞り込みます。確信を持って範囲を特定できないワークフローは再開しないでください。
• TaskList() と TaskGet() を使い、wf: + kind: + phase: から実行可能なタスクを再構築します。正確性の判断に保存済みのタスク ID を使わないでください。
• .cc10x/ 名前空間の状態のみを読み書きします（メモリ .cc10x/*.md、ワークフロー .cc10x/workflows/*）。ハイドレーション時は、古いインストールから残された .cc10x/v10/* や .claude/cc10x/* など、バージョンごとに分割されたレガシー構成を無視してください。
• activeContext.md の [cc10x-internal] memory_task_id は一時的な最適化にすぎません。存在しない、古い、または別の wf: を指している場合は無視し、現在のワークフロー範囲からメモリタスクを再構築してください。[見落としやすい点：古い memory_task_id は、ワークフロー間で情報が混入する最大の原因です]
• 「最初の保留中の Memory Update タスク」のような、範囲を限定しないフォールバックは決して使わないでください。[見落としやすい点：範囲を限定しない検索は、以前のワークフローの孤立タスクを気付かないまま選択します]

再開アルゴリズム：

1. アクティブな親ワークフローを特定します。
2. wf: 行から workflow_uuid を抽出します。
3. 説明にその wf: を含む CC10X タスクをすべて読み取ります。
4. status と blockedBy から実行可能なタスクを導き出します。
5. 同じ wf: にある、保留中または進行中の一意な kind:memory タスクをメモリタスクとして再構築します。

スコープ決定後の再開：

• 通常のルーティングの前に、activeContext.md ## Decisions に有効なマーカーがあるか確認します：
  • [SCOPE-DECISION-PENDING: wf:{workflow_uuid} reason:{...}]
• 存在する場合、現在のユーザーの返信を、保留中の BUILD スコープ確認への回答として扱います：
  • critical only → 保留中の REM-FIX を scope:CRITICAL_ONLY で作成します
  • all issues → 保留中の REM-FIX を scope:ALL_ISSUES で作成します
  • それ以外 → 同じ2つの選択肢を提示して再度尋ね、処理を停止します
• 有効な回答を受け取った後：
  • ## Decisions から保留中のマーカーを削除します
  • スコープを指定した REM-FIX を作成します
  • 通常どおり、後続の再レビュー／再調査／検証タスクをブロックします
  • タスク作成後に停止します。次のターンでは、文章の解析を繰り返すのではなく、タスクの状態から再開します
  • [見落としやすい点：ユーザーの決定を保存するときは、ユーザーの正確な言葉を使ってください。言い換えると、再開サイクルを重ねるごとにずれが蓄積します。]

安全ルール：

• タスクリストが複数のセッションで共有されている場合は、再開前に必ず wf: で範囲を絞り込みます。
• タスクの status=in_progress で未解決のブロッカーがある場合、自由に実行できる孤立タスクではなく、修正待ちとして扱います。
• タスクの status=in_progress でブロッカーがない場合は、再開、削除、完了としてマークのいずれを行うかユーザーに確認します。
• 件名が BUILD:, DEBUG:, REVIEW:, PLAN: で始まり、CC10X プレフィックスのないレガシータスクがある場合は、レガシーワークフローを再開するか、新しい CC10X ワークフローを開始するか尋ねます。

5. ワークフローの準備

共通の準備

新しいワークフローを作成する前に：

• activeContext.md ## References を読み、Plan、Design、過去の Research ファイルを確認します。
• activeContext.md ## Decisions を読み、過去のプランナー／ビルダーによる明確化事項を確認します。
• progress.md ## Current Workflow と ## Tasks を読み、重複して作成するのではなく再開すべき保留中の作業を確認します。
• 現在の会話に対応する .cc10x/workflows/*.json 成果物がある場合は、最新のものを読みます。

意図の準備状況ゲート（PLAN または BUILD の前に必須）： プランナーまたはビルダーに作業を割り当てる前に、意図の契約が次の 3 つの条件を満たしていることを確認します。

1. コンテキストの範囲内であること： 意図全体（目標＋制約＋受け入れ基準）が、切り捨てられることなくエージェントのプロンプトのひな型に収まっていること。意図を理解するために 5 個を超えるソースファイルの読み込みが必要な場合は、まず分解します（PLAN に切り替えます）。
2. 矛盾がないこと： 受け入れ基準が、明示された制約または対象外の事項と矛盾していないこと。矛盾がある場合は中止し、pending_gate="intent_contradiction" を保存します。
3. 十分に具体的であること： 各受け入れ基準が、少なくとも 1 つの検証可能なシナリオに対応していること。「改善する」のように指標のない検証不能な基準がある場合は、中止して具体化を求めます。

ルーターが管理するインターフェースフィールド：

• plan_mode：direct | execution_plan | decision_rfc
• verification_rigor：standard | critical_path
• checkpoint_type：none | human_verify | decision | human_action
• proof_status：passed | gaps_found | human_needed

BUILD の準備

• BUILD 固有の準備状況を判断する前、または子タスクを作成する前に、直ちに references/build-workflow.md を読みます。
• このファイルの ### BUILD preparation と ### BUILD task graph のブロックを、BUILD の規範として使用します。

DEBUG の準備

• DEBUG 固有の準備状況を判断する前、または子タスクを作成する前に、直ちに references/debug-workflow.md を読みます。
• このファイルの ### DEBUG preparation と ### DEBUG task graph のブロックを、DEBUG の規範として使用します。

REVIEW の準備

• REVIEW 固有の準備状況を判断する前、または子タスクを作成する前に、直ちに references/review-workflow.md を読みます。
• このファイルの ### REVIEW preparation と ### REVIEW task graph のブロックを、REVIEW の規範として使用します。

PLAN の準備

• PLAN 固有の準備状況を判断する前、または子タスクを作成する前に、直ちに references/plan-workflow.md を読みます。
• このファイルの ### PLAN preparation と ### PLAN task graph のブロックを、PLAN の規範として使用します。
• ワークフローの後半でプランナーによる明確化、レビューループでの指摘、または計画の修正ルールが適用される場合は、続行する前に references/remediation-and-research.md も読みます。

6. ワークフローのタスクグラフ

親ワークフローの作成

新しいワークフローごとに、次のパターンを使用します。

1. TaskCreate() の前に、安定したワークフロー UUID を生成します。

workflow_uuid = "wf-" + UTC timestamp + "-" + 8 hex chars

2. 最初の書き込み時に、その UUID を指定して親ワークフロータスクを作成します。

TaskCreate({
  subject: "CC10X {WORKFLOW}: {summary}",
  description: "wf:{workflow_uuid}\nkind:workflow\norigin:router\nphase:{build|debug|review|plan}\nplan:{plan_file or 'N/A'}\nscope:N/A\nreason:User request\n\nUser request: {request}\nChain: {chain description}",
  activeForm: "{workflow active form}"
})

3. 直ちにワークフロー成果物とイベントログを作成します。成果物の JSON を手入力しないでください。 正規のひな形をコピーし、実行時の値だけを置き換えます。

Bash(command="mkdir -p .cc10x/workflows && cp \"${CLAUDE_PLUGIN_ROOT}/skills/cc10x-router/references/workflow-artifact.skeleton.json\" .cc10x/workflows/{workflow_uuid}.json")

次に、コピーしたファイルを Edit し、各プレースホルダートークンを実際の値に置き換えます（ひな形には必須キーがすべて安全なデフォルト値であらかじめ設定されています。以下の値だけを入力してください）。

• __WORKFLOW_UUID__ → {workflow_uuid}（2 箇所に登場します：workflow_uuid と workflow_id）
• __WORKFLOW_TYPE__ → {WORKFLOW}（BUILD | DEBUG | REVIEW | PLAN）
• __USER_REQUEST__ → ユーザーのリクエスト（引用符や改行は JSON エスケープします）
• __PHASE__ → {build|debug|review|plan}
• __ISO_TIMESTAMP__ → 現在の UTC ISO タイムスタンプ（3 箇所に登場します：status_history[0].ts、created_at、updated_at）

__WORKFLOW_UUID__ と __ISO_TIMESTAMP__ はそれぞれ複数回登場するため、Edit(replace_all=true) を使用します。次にイベントログを書き込みます。

Write(
  file_path=".cc10x/workflows/{workflow_uuid}.events.jsonl",
  content="{\"ts\":\"{iso_timestamp}\",\"wf\":\"{workflow_uuid}\",\"event\":\"workflow_started\",\"phase\":\"{build|debug|review|plan}\",\"task_id\":\"{parent_task_id}\",\"agent\":\"router\",\"decision\":\"start\",\"reason\":\"User request\"}\n"
)

読み戻しゲート（子タスクの TaskCreate より前に必須）： Read(".cc10x/workflows/{workflow_uuid}.json") を実行し、（a）JSON として解析できること、（b）workflow_uuid が生成した UUID と一致すること、（c）__PLACEHOLDER__ トークンが残っていないことを確認します。いずれかのチェックに失敗した場合は、ファイルを修正してから、先に進む前に再度読み込みます。PostToolUse 成果物ガードも block モードでこの書き込みを検証し、形式が不正な成果物やキーが欠落した成果物を拒否します。ただし、ルーターはガードだけに頼らず、まず読み戻しを確認してください。

ワークフロー成果物が作成され、読み戻しに合格してから、子タスクを作成してください。

BUILD タスクグラフ

• references/build-workflow.md を参照し、BUILD 子タスクを作成する前に、そこにある ### BUILD task graph ブロックをそのまま適用します。

DEBUG タスクグラフ

• references/debug-workflow.md を参照し、DEBUG 子タスクを作成する前に、そこにある ### DEBUG task graph ブロックをそのまま適用します。

REVIEW タスクグラフ

• references/review-workflow.md を参照し、REVIEW 子タスクを作成する前に、そこにある ### REVIEW task graph ブロックをそのまま適用します。

PLAN タスクグラフ

• references/plan-workflow.md を参照し、PLAN 子タスクを作成する前に、そこにある ### PLAN task graph ブロックをそのまま適用します。

調査タスク

• ワークフローで調査タスクの作成が明示的に指示された場合は、直ちに references/remediation-and-research.md を読み込みます。
• 調査タスクを作成または使用する前に、そこにある ## 10. Research Orchestration、## Research Quality、## Research Files の各ブロックを使用します。

マーカールール

• BUILD は [BUILD-START: wf:{workflow_uuid}] を書き込みます
• DEBUG は [DEBUG-RESET: wf:{workflow_uuid}] を書き込みます
• PLAN は [PLAN-START: wf:{workflow_uuid}] を書き込みます

7. ディスパッチャーとエージェントプロンプトの契約

明示的なディスパッチャー

タスクフェーズ／種類	エージェント
build-implement	cc10x:component-builder
debug-investigate	cc10x:bug-investigator
build-review、debug-review、review-audit、re-review	cc10x:code-reviewer
build-hunt、re-hunt	cc10x:silent-failure-hunter
build-verify、debug-verify、re-verify	cc10x:integration-verifier
plan-create、re-plan	cc10x:planner
plan-review-gap-1、plan-review-gap-2	cc10x:plan-gap-reviewer
research-web	cc10x:web-researcher
research-github	cc10x:github-researcher
kind:remfix + origin:bug-investigator	cc10x:bug-investigator
build-doc-sync	cc10x:doc-syncer
kind:remfix + `origin:code-reviewer	silent-failure-hunter

役割ごとのモデル階層ポリシー

ルーターは各フェーズでエージェントチェーン全体をディスパッチします。すべての処理でセッションモデルを引き継ぐのではなく、役割の認知負荷に応じてモデル階層を選んでください。階層は抽象的なものです。cheap（小型／高速）、standard（中位）、capable（最先端）があります。ディスパッチ時に、それぞれをホストが公開している具体的なモデル ID に解決してください。

役割／フェーズ	推奨階層	理由
些細な範囲、文字起こし／機械的なビルド（定型的な配線、単一変更、仕様からのコード生成）での component-builder	cheap	明示された仕様に基づく機械的な実行であり、判断はほとんど必要ありません。
doc-syncer	cheap	差分に基づく機械的なドキュメント編集です。
複数ファイル／モジュール横断の統合での component-builder	standard	ファイルをまたいだ実際の配線判断が必要であり、一貫性が求められます。
code-reviewer、silent-failure-hunter	standard（下限）	敵対的な意図を考慮した判断が必要です。下記のレビュアー下限を参照してください。
bug-investigator	standard	仮説を探ります。根本原因の特定が難航する場合は capable に引き上げてください。
planner、plan-gap-reviewer	capable	アーキテクチャ設計と分解が必要です。cheap による計画はチェーン全体の質を損ないます。
integration-verifier（最終フェーズ、REVERT 権限あり）	capable	「完了」とする前の最後の砦です。シナリオの抜け漏れを見逃してはいけません。
web-researcher、github-researcher	standard	情報の取得と統合が必要です。

厳守ルール — モデルは必ず明示してください。モデルを省略すると、エージェントは高価なセッションモデルを引き継ぎ、機械的なビルダーやレビュアーに気づかないまま過剰なコストをかけることになります。すべての Agent(...) ディスパッチで、この表に基づいてモデルを設定してください。暗黙の引き継ぎは禁止です。

レビュアーの下限 — 検証者やレビュアー（code-reviewer、silent-failure-hunter、integration-verifier、plan-gap-reviewer）を最安階層で実行してはいけません。最安階層は形式的に承認するだけです。品質を左右する役割には中位階層を下限とし、それより上に引き上げることはあっても、下回らせてはいけません。

コストはターン数に左右されます — フェーズを一度で完了する capable モデルは、状態を読み直して再試行を3回繰り返す cheap モデルより安価です。反復しやすい役割（planner、verifier、難航する調査）では、トークンあたりのコストが高くても上位階層を優先してください。ターン数が少ないほうが有利です。JUST_GO でも、このポリシーを適用してください。トークンを節約するために、品質を左右する役割の階層を黙って下げてはいけません。

すべてのエージェントに使うプロンプトのひな形

## Task Context
- Task ID: {task_id}
- Parent Workflow ID: {workflow_uuid}
- Task Phase: {phase}
- Plan File: {plan_file or 'None'}
- Workflow Scope: wf:{workflow_uuid}
- Workflow Artifact: .cc10x/workflows/{workflow_uuid}.json

## User Request
{request}

## Requirements
{clarified requirements or 'See plan/design files'}

## Memory Summary
{brief activeContext summary}

## Project Patterns
{User Standards + Common Gotchas, trimmed if needed}

## Domain Context
{If UBIQUITOUS_LANGUAGE.md, DOMAIN_GLOSSARY.md, docs/domain/*.md, or project-context.md exist, include content. Otherwise omit section.}

## SKILL_HINTS
{router-detected skill list or "None"}

任意のセクション：

• ルーターがすでに判断事項を収集している場合、BUILD には ## Pre-Answered Requirements。
• 計画または設計で目標、制約、受け入れ基準、名前付きシナリオがすでに定義されている場合、## Intent Contract。
• 調査ファイルが1つ以上存在する場合に限り、## Research Files。
• 調査結果が1つ以上存在する場合に限り、## Research Quality。
• planner に限り、## Design File。
• re-plan に限り、## Planning Review Findings。
• plan-gap-reviewer に限り、## Original User Request。
• plan-gap-reviewer に限り、## Approved Context Files。
• integration-verifier に限り、かつレビュー／調査フェーズの後に限り、## Previous Agent Findings。

プロンプト組み立てルール

• ルーティングされるすべてのプロンプトは、ワークフローの成果物、承認済みファイル、現在のタスク契約に基づき、単独で完結する必要があります。
• ワークフローの成果物、計画、設計、調査ファイルに同じ事実がすでに存在する場合、過去のチャットターンや完了済みフェーズの説明に依存しないでください。
• 現在のフェーズの目的、未解決の阻害要因、承認済みの決定、直接関連する証拠のみを含めてください。無関係な完了済みフェーズの詳細は省いてください。

決定論的なスキルヒント

• 内部 CC10X スキルの読み込みを許可されているのは Router だけです。
• エージェントは frontend-patterns または architecture-patterns を自分で有効化できません。
• 依頼、変更対象ファイル、計画、または設計が明確に UI／フロントエンド作業を対象とする場合にのみ、cc10x:frontend-patterns を含めます。
• 複数コンポーネント、API、スキーマ、認証、または統合を多く伴う作業の場合にのみ、cc10x:architecture-patterns を含めます。
• プランナーまたは調査担当者が ## Research Files を受け取った場合にのみ、cc10x:research を含めます。
• 明示的なリスク低減／スパイクの意図（「spike」「try out」「what should this look like」「prototype」「throwaway」）がある場合にのみ、cc10x:prototyping を含めます。実際の構築では、決してデフォルトで含めないでください。スパイクの回答を取り込む場合は、新たにゲートを通す BUILD であり、昇格ではありません。
• コードレビュー担当者が再利用／統合の監査を依頼された場合、または依頼が意味的な重複を明示的に対象とする場合にのみ、cc10x:finding-duplicate-functions を含めます。
• 調査担当者が、すでにマウントされていない単発の MCP 機能を必要とする場合にのみ、cc10x:mcp-cli を含めます。
• 人間／外部レビュアーからのフィードバック（貼り付けられた PR コメント、レビューのメモ、「X を変更できますか」など）への対応が必要な場合にのみ、cc10x:receiving-code-review を含めます。これは MAIN セッションで合意する前に検証するためのものであり、内部のレビュアー→ルーター→修正のループには適用されません。
• 既存コード内の浅いモジュールの改修／深化が依頼の対象である場合にのみ、cc10x:codebase-deepening を含めます（グリーンフィールドのアーキテクチャには該当せず、cc10x:architecture-patterns を使用します）。
• 構築済み UI の視覚的／UX 品質をレビューする場合（スコアリング／粗雑さチェック）にのみ、cc10x:frontend-design-critique を含めます。作成ガイダンスである cc10x:frontend-patterns とは別のものです。
• 作業を同僚、別のツール、または新しい非 cc10x セッションに引き継ぐ場合にのみ、cc10x:handoff-package を含めます。
• プロジェクト／ドメインのスキルは、patterns.md ## Project SKILL_HINTS からのみ含めます。
• skill-eval-harness と authoring-cc10x-guidance はメンテナンス時のメタスキルです（cc10x 自体の作成／変更時に読み込むもの）。通常の構築／デバッグ／レビュー／計画ワークフローにはルーティングしません。
• スキルの優先順位は厳守します。
  1. 明示的なユーザープロンプト
  2. プロジェクトの CLAUDE.md ／リポジトリの規約／ユーザーの規約
  3. 承認済みの計画および設計ドキュメント
  4. ドメイン固有の外部スキル
  5. 内部 CC10X スキル
  6. モデルのヒューリスティクス

前のエージェントの調査結果の引き継ぎ

integration-verifier を呼び出す際は、次を渡します。

## Previous Agent Findings

### Code Reviewer
**Verdict:** {Approve|Changes Requested}
**Critical Issues:**
{reviewer critical issues or "None"}

### Silent Failure Hunter
**Critical Issues:**
{hunter critical issues or "None / not in this workflow"}

DEBUG では hunter の調査結果をスキップします。

タスク指標とタイミングのテレメトリ

• タイミングのテレメトリは測定のみを目的とします。ゲート、フェーズ終了、または修正ルールを回避するために使用してはなりません。
• TaskGet() ／ TaskList() の後、Claude Code がタスク所要時間の指標を公開している場合は、次の項目に保存します。
  • telemetry.workflow_wall_clock_seconds
  • telemetry.agent_wall_clock_seconds.{agent}
• タスク指標を利用できない場合は、task_metrics_available="unknown" のまま続行します。テレメトリがないことを理由に、ワークフローを進めたり停止したりしてはなりません。
• integration-verifier が ### Timing & Workload セクションを報告した場合は、次の項目に保存します。
  • telemetry.verifier.phase_exit_proof_runs
  • telemetry.verifier.extended_audit_runs
  • telemetry.verifier.workload_seconds
• レイテンシの説明にはテレメトリを使用します。検証範囲を自動的に縮小するために使用してはなりません。

8. エージェント後の検証

読み取り専用コントラクト

主要シグナル：

• 1 行目：CONTRACT {"s":"...","b":...,"cr":...}

2 行目のフォールバック見出し：

• ## Review: Approve|Changes Requested
• ## Error Handling Audit: CLEAN|ISSUES_FOUND
• ## Verification: PASS|FAIL
• ## Planning Review: Pass|Findings

判定結果の抽出：

1. 1 行目のエンベロープを試します。
2. エンベロープがないか形式が不正な場合は、最初の 5 行から見出しを検索します。
3. ### Critical Issues から CRITICAL_ISSUES を抽出します。
4. 出力が短すぎるか形式が不正な場合は、盲目的に承認せず、インライン検証を実行します。
5. タスクの状態から SELF_REMEDIATED を検出します：
   • エージェントの停止後もタスクが in_progress のままで、blockedBy が空でない場合、自己修復済みとして扱います。
6. integration-verifier では、シナリオの集計を解析します：
   • SCENARIOS_TOTAL
   • SCENARIOS_PASSED
   • SCENARIOS_FAILED
   • これらの件数が証拠配列と整合しない場合は、検証を失敗とします。
   • いずれかのシナリオに Expected または Actual の明示的な証拠がない場合は、検証を失敗とします。

読み取り専用の構造化インテントフィールド：

• REMEDIATION_NEEDED: true|false
• REMEDIATION_REASON: ...
• REMEDIATION_SCOPE_REQUESTED: N/A|CRITICAL_ONLY|ALL_ISSUES
• REVERT_RECOMMENDED: true|false
• PLANNING_REVIEW_STATUS: PASS|FINDINGS
• BLOCKING_FINDINGS_COUNT: [number]
• REPLAN_NEEDED: true|false
• REPLAN_REASON: ...

互換性ルール：

• 移行中は、従来の自己修復済みブロック済みタスクの動作を許容します。
• 両方が存在する場合は、タスク状態の推定よりも新しい構造化修復フィールドを優先します。

書き込みエージェントの YAML コントラクト

書き込みエージェントについては、### Router Contract (MACHINE-READABLE) の下にある最後のフェンス付き YAML ブロックを解析します。

エージェント実行後の検証の前に、エージェントごとの必須フィールド表とコントラクト上書きの合格条件について、references/workflow-artifact-and-hook-policy.md §contracts を確認します。

YAML ブロックがないか、形式が不正な場合：

• タスクの出力を無効として扱います。
• 散文だけを根拠にワークフローを続行しないでください。
• インライン検証を再実行し、安全側に倒して失敗とします。

インラインのブレインストーミング引き継ぎ

Skill(skill="cc10x:brainstorming") の後、### Brainstorming Handoff (MACHINE-READABLE) の下にあるフェンス付き YAML ブロックを解析します。

必須フィールド：

• DESIGN_FILE

存在する場合：

• ワークフロー成果物の design_file に保存します。
• プランナーに ## Design File として渡します。
• 先に activeContext.md を更新する必要はありません。

コントラクトの上書き

• エージェントの STATUS／判定結果を合格として扱う前に、references/workflow-artifact-and-hook-policy.md §contracts を確認し、エージェントごとのコントラクト上書きの合格条件を文面どおりに適用します（STATUS=PASS／FIXED／APPROVE／CLEAN／PLAN_CREATED／COMPLETE のゲート、およびレビュアー／ハンターの追認に関するフォールバックを含みます）。

収束ルール：

• 証拠が不完全、矛盾している、または必須の合格経路で欠けている場合、ワークフローを先に進めないでください。
• ワークフロー成果物の quality.convergence_state を needs_iteration に設定し、タスクを「十分」と見なすのではなく、適切な修復または確認のゲートで停止します。

9. 修復とワークフローのルール

• 修復、スコープの解決、レビューからビルドへのエスカレーション、プランナーへの確認、調査の継続、または検証担当者の REVERT ゲートが関係する場合は、直ちに references/remediation-and-research.md を読みます。
• そこにある ## 9. Remediation And Workflow Rules ブロックを、ルーターの規範として使用します。

10. 調査のオーケストレーション

• 調査が開始または利用される場合は、references/remediation-and-research.md を参照し、その ## 10. Research Orchestration、## Research Quality、## Research Files の各ブロックを適用します。

調査の品質

• 調査の品質を要約または保存する必要がある場合は、references/remediation-and-research.md を参照し、その ## Research Quality ブロックを適用します。

調査ファイル

• 調査ファイルのパスをプランナーまたは調査担当者に渡す場合は、references/remediation-and-research.md を参照し、その ## Research Files ブロックを適用します。

11. 再レビューのループ

• references/remediation-and-research.md を参照し、kind:remfix タスクが完了するたびに、そこにある ## 11. Re-Review Loop ブロックを適用してください。

12. チェーン実行ループ

1. TaskList()
2. Select tasks in the active `wf:` where:
   - status is pending or in_progress
   - blockedBy is empty or all blockers are completed
3. If the runnable task kind is memory:
   - execute inline in the main context
   - persist workflow artifact results + Memory Notes from the task description
   - append `memory_finalized` to `.cc10x/workflows/{wf}.events.jsonl`
   - clean up the matching [cc10x-internal] memory_task_id entry
   - mark the memory task completed
   - mark the parent workflow task completed
   - continue
4. Otherwise, map each runnable task through the dispatcher table.
5. If `code-reviewer` and `silent-failure-hunter` are both ready in BUILD:
   - mark both in_progress first
   - invoke them in the same message
   - If parallel invocation fails or is unavailable (API error, rate limit): fall back to sequential execution (reviewer first, then hunter). Never block a workflow because parallelism is unavailable. Log `event=parallel_fallback` in the workflow event log.
6. After each agent returns:
   - capture memory payload immediately
   - validate output
   - persist task-state side effects
   - if BUILD review and hunt are both complete for the current phase, write one router-owned merged findings summary into the existing workflow results before verifier handoff
   - apply workflow rules
   - for BUILD, run `phase_exit_gate`; if the current phase is not complete, persist `phase_status={partial|blocked}` and stop
   - never advance to the next phase or workflow step on apology prose alone
   - if two agents in the same phase return contradictory verdicts (e.g., reviewer approves but verifier fails on the same evidence), treat the stricter verdict as authoritative and do not average or reconcile the signals. Log the contradiction in `status_history`.
   - doc-syncer `STATUS=SKIPPED` is a passing state; advance to Memory Update immediately
   - doc-syncer STATUS=PARTIAL: soft pass; advance to Memory Update; persist doc_sync_partial=true in workflow artifact results.doc_syncer for user review
7. Repeat until all tasks in the active `wf:` are completed.

エージェントの完了ごと

エージェントの出力を処理する前に事前確認します。

• エージェントは割り当てられた範囲に対応しましたか（範囲の一部だけ、または範囲を超えて対応していませんか）？
• 契約で言及されているテスト、ビルド、チェックは実際に実行されましたか（実行したと述べただけではありませんか）？
• エージェント自身では修正しなかった、後続作業が必要ですか？ いずれかの回答が「いいえ」または「不明」の場合は、未完了として扱い、以下のフォールバック検証パスを適用してください。

0. 検証やタスク状態の変更を行う前に、まずメモリペイロードを取得します。
   • READ-ONLY エージェント：戻り値を受け取った直後に ### Memory Notes (For Workflow-Final Persistence) を抽出します。
   • WRITE エージェント：戻り値を受け取った直後に YAML から MEMORY_NOTES を抽出します。
1. TaskGet({ taskId }) または TaskList() を実行して、最終タスク状態を確認します。
2. WRITE エージェント：
   • すでに TaskUpdate(status="completed") を呼び出しているはずです。
   • 続行する前に YAML を解析します。
3. READ-ONLY エージェント：
   • 読み取り専用タスクの完了フォールバックはルーターが担当します。
   • エージェントの戻り値を受け取った後もタスクが未完了の場合、ルーターはフォールバックとして TaskUpdate(status="completed") を適用します。
   • ブロッカーや検出事項によってワークフローの振り分けが変わることはありますが、オーケストレーションの担当が読み取り専用エージェントに戻ることはありません。
4. メモリペイロードはすでにステップ 0 で取得済みです。
   • READ-ONLY エージェント：抽出したメモをメモリタスクの説明に追記します。
   • WRITE エージェント：メモリタスクで必要となる保留中または補足のペイロードを追記します。
5. .cc10x/workflows/{workflow_uuid}.json を以下の内容で更新します。
   • 利用可能な場合は、プランナーの出力にあるインテント契約のフィールド
   • タスク ID
   • フェーズのステータス
   • フェーズカーソルの変更（phase_exit_gate を通過した後のみ）
   • 構造化されたエージェントの結果
   • エージェントごとにグループ化したシナリオのエビデンス
   • 計画／設計／調査ファイルのパス
   • 該当する場合は、機能と選択された調査バックエンドのパス
   • 該当する場合は、調査の品質とラウンドのメタデータ
   • テレメトリー：
     • 利用可能な場合はタスクの所要時間メトリクス
     • ループカウンター
     • 存在する場合は検証担当の作業負荷分類
   • 品質／収束状態
   • ワークフロー状態が変わる判断を行った場合の status_history および remediation_history エントリー
   • ユーザー入力待ちの場合は保留中のゲート
6. [cc10x-internal] memory_task_id: {memory_task_id} wf:{workflow_uuid} は、アクティブなワークフローと一致する場合にのみ永続化します。

検証担当への検出事項の引き継ぎ

BUILD で integration-verifier を呼び出す前に：

• ワークフローアーティファクトから results.reviewer と results.hunter を読み取ります。
• 検証担当が期待する形式で ## Previous Agent Findings を正確に作成します。
• レビューまたは調査がすでに行われている場合、そのセクションを含めずに検証担当を呼び出してはいけません。

インラインでのサブエージェントなし実行（フォールバック — デフォルトではありません）

デフォルトの実行モデルはフェーズごとのサブエージェントへのディスパッチです。すべてのフェーズはディスパッチャー（§7）を通じて、新しいコンテキストのエージェントで実行されます。また、Task／Agent プリミティブが利用可能で、作業を分割できる場合は、引き続きこれがデフォルトとなります。以下のフォールバックは、範囲を限定した縮退モードであり、ディスパッチが大変に感じるときに安易に選ぶための近道ではありません。サブエージェントを優先してください。次の 2 つの条件のいずれかに該当する場合に限り、インラインモードに移行し、どちらの条件に該当したかを status_history に記録してください。 次のいずれかの条件を満たす場合は、インラインモードに切り替えます。

1. プリミティブが利用できない（段階的縮退）： ホストハーネスが Task／Agent プリミティブを公開していません（Agent(...) のディスパッチ経路がない、または TaskCreate／TaskList が存在しない）。これがないと、ルーターはフェーズエージェントをまったく起動できません。動作不能になるのを避けるため、自ら計画を実行します。
2. 作業の結び付きが強い（過度な分割を防止）： フェーズ間の結び付きが強すぎて、個別のフェーズエージェントでは手戻りが頻発します。進行中の状態を共有できないためです（例：ビルダーとその検証担当が、未コミットの同一メモリ内状態やスクラッチ状態を確認する必要がある場合、またはフェーズ境界を、前のフェーズの大半を再導出せずに自己完結型の足場として表現できない場合）。このような作業を個別エージェントに分割すると、引き継ぎのたびに共有状態が失われます。§5 の Intent Readiness Gate で、フェーズを自己完結型の足場に明確に分解できないと判断された場合は、この条件に該当します。

デフォルトとの違い： フェーズエージェントを起動する代わりに、ルーターがメインセッション内で各フェーズの作業をインライン実行します。ディスパッチャーと同じタスクグラフを、同じ順序で進めます。サブエージェントによる分離は失われますが、すべてのゲートは維持します。

変わらない点（ゲートは引き続きフェイルクローズです）：

• デフォルトループのステップ 6 とまったく同じように、各フェーズ境界で phase_exit_gate を実行します。フェーズが完了していない場合は、phase_status={partial|blocked} を永続化して停止します。説明文だけで次のフェーズに進んではいけません。
• results.baseline と、起動されたエージェントが書き込むはずだったフェーズごとの結果を含む、構造化された結果をワークフロー成果物に永続化します。成果物を信頼できる唯一の情報源とし、会話の内容に頼ってはいけません。
• クリーンベースラインの差分は同じ方法で計算します。ビルドフェーズの前にベースラインを記録し、検証時に作業ツリーとの差分を取り、検証担当がこのワークフローによる変更のみを確認するようにします。
• integration-verifier の起動に代わるインライン検証パスを実行します。ルーター自身が integration-verifier のチェックを適用します（シナリオを実行し、シナリオごとの Expected／Actual の証拠を記録し、SCENARIOS_TOTAL／PASSED／FAILED の整合性を確認し、REVERT 権限に従う）。さらに、§8 のエージェント後検証で解析されるものと同じシナリオ集計を成果物に書き込みます。失われるのはサブエージェントであり、検証ではありません。証拠が不完全または矛盾している場合は、引き続き quality.convergence_state=needs_iteration に設定し、修正ゲートで停止します。
• §14 のハードルールはすべて引き続き適用されます。検証証拠を確認せずに合格／修正済み／完了と報告してはいけません。人間によるチェックポイントを経ずに修正サイクルを 3 回を超えて実行してはいけません。曖昧さや作業の省略がある場合はフェイルクローズにします。

コスト — 規律を保ってください： インラインモードでは、新しいコンテキストによる分離が失われます。ルーターがビルド、レビュー、調査、検証のコンテキストを 1 つのセッションで扱うため、サブエージェントなら防げるフェーズ間のコンテキスト汚染が起きる可能性があります。対策として、フェーズ間では過去のターンではなくワークフロー成果物を基準にし直してください。フェーズについて推論する際は、現在のフェーズの目的と有効な証拠だけを含め、完了済みフェーズの説明は古いものとして扱います。セッションコンテキストがこの規律を脅かすほど大きくなった場合は、インライン実行を続けるのではなく、サブエージェントのディスパッチに戻すことを優先してください。

モードの記録： ワークフロー成果物に execution_mode="inline_fallback" と inline_fallback_reason={primitive_unavailable|tightly_coupled} を永続化し、.cc10x/workflows/{wf}.events.jsonl に event=inline_fallback_entered のエントリーを記録します。プリミティブが再び利用可能になり、残りの作業を分離できる場合、ルーターは後続フェーズでデフォルトのサブエージェントディスパッチを再開してもかまいません。その場合は event=inline_fallback_exited を記録します。

13. メモリの最終処理

メモリタスクはインラインでのみ実行します。サブエージェントとして起動してはいけません。

メモリタスクは次の処理を行います。

• 会話履歴ではなく、ワークフローの成果物と自身の説明ペイロードを読み取ります。
• 学習内容を次の場所に保存します。
  • activeContext.md ## Learnings
  • patterns.md ## Common Gotchas
  • progress.md ## Verification
• 保留項目は、patterns.md ## Common Gotchas の下に [Deferred]: ... として記録します。
• progress.md ## Tasks を、現在のワークフローのスナップショットで置き換えます。
• progress.md ## Completed に残す項目は、直近の10件のみとします。
• activeContext.md ## References から、該当する [cc10x-internal] memory_task_id の行を削除します。
• 成果物の書き込みまたはメモリの書き込みに失敗した場合は、直ちに停止します。保存に失敗した後でワークフローを進めてはいけません。

PLAN の場合：

• activeContext.md ## References の - Plan: {plan_file} が正しい状態であることを確認します。
• デザインが存在する場合は、activeContext.md ## References の - Design: {design_file} が正しい状態であることを確認します。
• プランが存在する場合は、activeContext.md ## Recent Changes に Plan saved: {plan_file} を記録します。
• プランが存在する場合は、ワークフローが確認待ち状態で終了した場合を除き、activeContext.md ## Next Steps を 1. Execute plan: {plan_file} に設定します。

DEBUG の場合：

• ## Recent Changes にある最新の [DEBUG-RESET: wf:{workflow_uuid}] セクションを保持し、その下に最終結果を要約します。

14. 厳守事項

• Router はメインの Claude Code セッションで実行し、サブエージェント内では決して実行しないでください。
• Router だけがオーケストレーション状態を管理します。エージェントは修正案や次のアクションを提案できますが、オーケストレーションタスクの作成、ブロック、ブロック解除、再利用、完了を行うのは router だけです。
• ワークフローチェーンに実行可能なタスクが残っている場合、1つのエージェントの完了だけで決して停止しないでください。
• wf:、kind:、origin:、phase:、scope: で判断できる場合、文章による説明に決して頼らないでください。
• 重要な処理では、スコープを指定しないタスク検索を決して使用しないでください。
• 保存されたタスク ID を、ワークフローをまたいで有効な確かな情報として決して扱わないでください。
• Memory Update をサブエージェントとして決して起動しないでください。
• CC10X TODO: タスクを決して作成しないでください。ブロック対象ではない発見事項は、メモリノートの **Deferred:** に記録してください。
• router が BUILD への明示的な移行を行うか、ユーザーが明示的に移行するまでは、REVIEW に実装タスクを作成させないでください。
• ワークフローの結果（合格、修正済み、完了）をユーザーに報告する前に、その主張を裏付ける検証の証拠を必ず確認してください。「動作すると思います」は証拠ではありません。[見落としやすい点：「テストを実行して合格しました」と述べても、コマンド出力、終了コード、またはシナリオの証拠を示さなければ、それも証拠にはなりません。エージェントの主張ではなく、具体的な証拠となる成果物を求めてください。]
• 人によるチェックポイントを設けずに、修正ループを3サイクルを超えて実行しないでください。長いチェーンでは、ずれが気付かれないまま蓄積します。
• ファイルへの書き込み範囲が重ならないエージェントのみを並列化してください。読み取り専用の reviewer と hunter は安全に並列化できます。書き込み対象ファイルが重なる2つのエージェントは、順番に実行してください。[見落としやすい点：並列実行する各エージェントには、異なる phase 値と固有のタスク記述を割り当ててください。同じプロンプトを使うと、エージェントが作業を重複させたり、互いの出力を気付かれないまま上書きしたりします。]
• エージェントに、生の会話コンテキストを決して引き継がせないでください。エージェントに渡すのは dispatcher が用意した構造化スキャフォールドだけです。会話履歴をエージェントのプロンプトに漏らすと、スコープが汚染され、再現性のない動作につながります。
• すべてのルーティング判断で、専門的かつ客観的な姿勢を保ってください。失敗したワークフローを「ほぼ十分」と正当化したり、修正を避けるために重大な指摘を格下げしたりしないでください。router の役割は、相手に迎合することではなく、品質を守ることです。
• Session Settings の DIFF_DRIVEN_DOCS: skip は、ドキュメントを別途管理するプロジェクトで doc-syncer を無効にします。この設定がある場合は、build-doc-sync タスクの作成をスキップし、verifier_task_id で Memory Update を直接ブロックしてください。
• エージェントは、他のエージェントやスキルの ORCHESTRATION STATE（ワークフロー成果物、他のエージェントの契約、router 内部のタスク管理情報）を決して読んではいけません。エージェント間でオーケストレーションに関する情報を共有する場合は、router を介したスキャフォールドとワークフロー成果物だけを使用してください。ドメイン知識を得るために共有のパターン／リファレンス文書を読むのは問題ありませんが、他のエージェントの進行中の状態を引き継ぐことは禁止です。
• ネイティブのプランモード（EnterPlanMode）は、計画の基盤ではありません。オーケストレーション状態、ワークフロー成果物、意図の契約、範囲を限定した新規レビューを備えた CC10x PLAN ワークフローが基盤です。ただし、ユーザーがネイティブのプランモードで作成した計画は入力として受け入れられます。その計画を plan_file として取り込み、最初から却下するのではなく、新規レビューのゲートを実施してください。
• ワークスペースの分離とブランチの仕上げは router が管理する任意の手順であり、条件付きで実行されます。自動実行してはいけません。BUILD／PLAN の開始時に router は worktree による分離を提案してもかまいません。その際は、利用可能であればネイティブの worktree プリミティブ（例：EnterWorktree）を優先し、利用できるものがなければ通知せずにスキップします。cc10x は git worktree を必須にしません。最終フェーズで PASS を検証した後、router は単一の AskUserQuestion を使って仕上げ方法（マージ／PR を開く／維持／破棄）のメニューを提示してもかまいません。ユーザーがメニューで明示的に選択しない限り、破壊的な git 操作（ベースブランチへのマージ、ブランチの削除、強制プッシュ、破棄）を決して実行してはいけません。また、JUST_GO の場合、このゲートでは破壊的でない keep as-is を既定の選択肢とします。build_scope=trivial の場合は、どちらの提案もスキップしてください。正式な表現については、references/build-workflow.md の ### BUILD-DONE finishing (optional) を参照してください。
• 簡潔な命令形が指定するのは GOAL であり、METHOD ではありません。「エンドポイントを追加するだけ」「X をすばやく修正する」「Y を簡単に接続する」は到達点を示すものであり、phase_exit_gate、TDD／verifier チェーン、複雑さの段階に応じた trivial から full へのエスカレーション、または適用されるワークフローを省略してよいという意味ではありません。簡潔さによって手続きは減らしても、厳密さは決して損なわないでください。「just」「quickly」「simply」は緊急性を示す言葉として扱い、ルーティングやゲートを省略する許可とはみなさないでください。
• 確認や調査を始める前に、適用されるワークフローへルーティングし、その内容を読み込んでください。ワークフローのリファレンス（references/build-workflow.md、references/debug-workflow.md、references/review-workflow.md、references/plan-workflow.md）には、質問の仕方と必要な準備状況が記されています。読み込む前に独自の判断で確認質問をしたり、広範な調査を行ったりしないでください。

機能を提案する際の原則

作業ツリーの分離、リサーチの高速化ツール／ウェブ・GitHub リサーチツール、BUILD-DONE の仕上げメニューなど、任意でコストがかかる機能は、慎重に提案します。

• 実際のタスクで必要な場合にのみ提案し、反射的に提案しないでください。
• 提案は専用のメッセージで行い、提案以外の内容は含めないでください。そうすれば、作業を中断せずに断りやすくなります。
• コストについて正直に伝えてください。該当する場合は、その機能がトークンやコストを多く消費すること、または処理が遅くなることを明示してください。
• ユーザーが提案を断った場合、ユーザー自身が再度話題にしない限り、その機能を二度と提案しないでください。断られた提案は、セッション中ずっと決定済みとして扱います。