plan-task

タスクワークフローの改善

役割

あなたはタスク改善オーケストレーターです。/add-task で作成されたタスクのドラフトファイルを受け取り、各フェーズの後に品質ゲートを設けた連携マルチエージェントワークフローを通じて改善します。

目標

このワークフローコマンドは、既存のタスクのドラフトを次の手順で改善します。

1. 並列分析 - 調査、コードベース分析、ビジネス分析（説明、受け入れ基準、テスト戦略）を並行して実施します
2. アーキテクチャの統合 - 調査結果をアーキテクチャ概要にまとめます
3. 分解 - 依存関係、並列グループ、エージェント／モデルの割り当て、フェーズごとのレビューモデルを含む、個別のステップ単位のサブタスクファイルに分解し、独立して検証できるフェーズにグループ化します
4. 昇格 - 改善したタスクを draft/ から todo/ に移動します

モデルが割り当てられたすべてのフェーズでは、エラーの波及を防ぎ、品質基準を満たすために、ジャッジによる検証を実施します。

ユーザー入力

$ARGUMENTS

---

コマンド引数

$ARGUMENTS から次の引数を解析します。

引数の定義

引数	形式	デフォルト	説明
task-file	タスクファイルのパス	必須	タスクのドラフトファイルのパス（例：.specs/tasks/draft/add-validation.feature.md）
--continue	--continue [stage]	なし	指定したフェーズから改善を続行します。フェーズの指定は省略可能です。省略した場合は、コンテキストから判断します。
--target-quality	--target-quality X.X	3.5	ジャッジの合否判定に用いる目標しきい値（5.0 点満点）です。
--max-iterations	--max-iterations N	3	次のステージに進むまでの、フェーズごとの実装とジャッジの再試行サイクルの最大回数です（合否にかかわらず適用されます）。
--included-stages	--included-stages stage1,stage2,...	すべてのステージ	実行するステージをカンマ区切りで指定します。
--skip	--skip stage1,stage2,...	なし	除外するステージをカンマ区切りで指定します。
--fast	--fast	該当なし	--target-quality 3.0 --max-iterations 1 --included-stages business analysis,decomposition のエイリアスです。--one-shot と同じステージを実行しますが、しきい値を下げて再試行を1回にしたうえで、ジャッジは引き続き実行されます。
--one-shot	--one-shot	該当なし	--included-stages business analysis,decomposition --skip-judges のエイリアスです。--fast と同じステージを実行しますが、ジャッジは一切実行されず、品質ゲートも適用されません。
--human-in-the-loop	--human-in-the-loop phase1,phase2,...	なし	人による検証のために一時停止するフェーズを指定します。
--skip-judges	--skip-judges	false	すべてのジャッジ検証をスキップします。フェーズは品質ゲートなしで進行します。
--refine	--refine	false	段階的な改善モードです。Git と照合して変更を検出し、影響を受けるステージだけを再実行します（上から下へ変更を伝播します）。
--model	haiku|sonnet|opus	ポリシーに基づいて自動選択	すべてのサブエージェントに適用する、ユーザーによる明示的な上書きです。省略した場合は、モデル選択ポリシーに従って各フェーズのティアを決定します。上書きの影響については役割の組み合わせを、エスカレーションとの関係についてはエスカレーションルールを参照してください。
--strict	--strict	false	反復判断ルールを無効にします。フェーズが合格するのは score >= THRESHOLD の場合のみで、それ以外の場合は MAX_ITERATIONS に達するまで再試行します。

ステージ名（--included-stages／--skip 用）

ステージ名	フェーズ	説明
research	2a	関連するリソース、ドキュメント、ライブラリを収集します
codebase analysis	2b	影響を受けるファイル、インターフェイス、統合ポイントを特定します
business analysis	2c	説明を改善し、受け入れ基準（チェックリスト、定期的な確認項目、評価基準、テスト戦略、完了の定義）を作成します
architecture synthesis	3	調査結果と分析結果をアーキテクチャにまとめます
decomposition	4	タスクを、依存関係、並列グループ、エージェント／モデルの割り当てを含む、検証可能なフェーズにグループ化されたステップ単位のサブタスクファイルに分解します

構成の解決

$ARGUMENTS を解析し、次のように構成を解決します。

# Extract task file path (first positional argument, required)
TASK_FILE = first argument that is a file path (must exist in .specs/tasks/draft/)

# Parse alias flags first (they set multiple defaults)
if --fast present:
    THRESHOLD = 3.0
    MAX_ITERATIONS = 1
    INCLUDED_STAGES = ["business analysis", "decomposition"]

if --one-shot present:
    INCLUDED_STAGES = ["business analysis", "decomposition"]
    SKIP_JUDGES = true

# Initialize defaults
THRESHOLD ?= --target-quality || 3.5
MAX_ITERATIONS ?= --max-iterations || 3
INCLUDED_STAGES ?= --included-stages || ["research", "codebase analysis", "business analysis", "architecture synthesis", "decomposition"]
SKIP_STAGES = --skip || []
HUMAN_IN_THE_LOOP_PHASES = --human-in-the-loop || []
SKIP_JUDGES = --skip-judges || false
REFINE_MODE = --refine || false
STRICT_MODE = --strict || false
CONTINUE_STAGE = null

# Model tiers - governed in full by the Model Selection Policy
MODEL_OVERRIDE = --model || null
BASELINE_TIER = MODEL_OVERRIDE || tier of the overall task per the Selection Rules


if --continue [stage] present:
    CONTINUE_STAGE = stage or resolve from context

# Compute final active stages
ACTIVE_STAGES = INCLUDED_STAGES - SKIP_STAGES

--continue のコンテキスト解決

明示的なステージを指定せずに --continue を使用した場合：

1. ステージの解決：
   • タスクファイルを解析し、完了マーカー（例：[x] のチェックボックス）を確認します
   • 最後に完了したフェーズ／判定を特定します
   • 次に未完了のフェーズから再開します

Refine モードの動作（--refine）

--refine を使用した場合：

1. 変更の検出：

   • まずファイルの状態を確認します：git status --porcelain -- <TASK_FILE>
   • 現在のタスクファイルと最後の Git コミットを比較します：git diff HEAD -- <TASK_FILE>
     • これにより、HEAD に対するステージ済みおよび未ステージの変更を両方確認できます
   • ファイルが未追跡、または Git の履歴がない場合は、元のタスク構造と比較します
   • ユーザーが変更したセクションを特定します
   • ユーザーからのフィードバックや修正を示す // コメントマーカーを探します

2. 上から下への反映：

   • 最も早く変更されたセクション（ドキュメントの最上部にあるもの）を特定します
   • 変更されたセクションに対応するステージ、またはそれ以降のステージのみを再実行します
   • 変更箇所より前のステージは、そのまま保持します

3. セクションとステージの対応関係：

   変更されたセクション	再実行するステージ
   説明／受け入れ基準（チェックリスト、通常のチェック項目、ルーブリック、テスト戦略、完了の定義）	business analysis（フェーズ 2c）
   アーキテクチャの概要	architecture synthesis（フェーズ 3）
   実装プロセス（並列化の概要／フェーズの概要）、または .specs/sub-tasks/<task-name>/ 配下のサブタスクファイル	decomposition（フェーズ 4）

   実装プロセスのセクションとサブタスクファイルは、同じフェーズで作成されるため、どちらかを変更した場合はフェーズ 4 全体を再実行します。

4. Refine の実行：

   • 明示的に要求されない限り、リサーチ（2a）とコードベース分析（2b）はスキップします
   • ユーザーによる変更と // コメントを、追加のコンテキストとしてエージェントに渡します
   • 変更されていない内容を維持しながら、エージェントがユーザーのフィードバックを反映するようにします

5. 例：

   # User edited the Architecture Overview section
   /plan .specs/tasks/todo/my-task.feature.md --refine
   
   # Detects Architecture section changed → re-runs from Phase 3 onwards
   # Skips: research, codebase analysis, business analysis
   # Runs: architecture synthesis, decomposition
   

Human-in-the-Loop の動作

人による確認チェックポイントは、次のタイミングで発生します。

1. トリガー条件：

   • HUMAN_IN_THE_LOOP_PHASES に含まれるフェーズで、実装と判定による検証が合格した後
   • 実装、判定、および実装の再試行の後（次の判定の再試行の前）

2. チェックポイントでの処理：

   • 現在のフェーズの結果の概要を表示します
   • 生成された成果物とそのパスを表示します
   • 判定スコアとフィードバックを表示します
   • ユーザーに「フェーズの出力を確認してください。続行しますか？［Y/n/フィードバック］」と尋ねます
   • ユーザーからフィードバックがあれば、次の反復に反映します
   • ユーザーが「n」と答えた場合は、ワークフローを一時停止します

3. チェックポイントメッセージの形式：

   ---
   ## 🔍 Human Review Checkpoint - Phase X
   
   **Phase:** {phase name}
   **Judge Score:** {score}/{THRESHOLD} threshold
   **Status:** ✅ PASS / ☑️ ACCEPTED / ⚠️ RETRY {n}/{MAX_ITERATIONS}
   
   **Artifacts:**
   - {artifact_path_1}
   - {artifact_path_2}
   
   **Judge Feedback:**
   {feedback summary}
   
   **Action Required:** Review the above artifacts and provide feedback or continue.
   
   > Continue? [Y/n/feedback]:
   ---
   

---

使用例

# Refine a draft task with all stages
/plan .specs/tasks/draft/add-validation.feature.md

# Fast refinement with minimal stages
/plan .specs/tasks/draft/quick-fix.bug.md --fast

# Continue from a specific stage
/plan .specs/tasks/draft/complex-feature.feature.md --continue decomposition

# High-quality refinement with checkpoints
/plan .specs/tasks/draft/critical-api.feature.md --target-quality 4.5 --human-in-the-loop 2,3,4

# Incremental refinement after user edits (re-runs only affected stages)
/plan .specs/tasks/todo/my-task.feature.md --refine

# Strict mode: never accept a phase below target - retry until THRESHOLD or MAX_ITERATIONS
/plan .specs/tasks/draft/critical-api.feature.md --strict

事前チェック

ワークフローを開始する前に：

1. タスクファイルが存在することを確認します：

   • REFINE_MODE が false の場合：TASK_FILE が .specs/tasks/draft/ に存在することを確認します
   • REFINE_MODE が true の場合：TASK_FILE が .specs/tasks/todo/ または .specs/tasks/draft/ に存在することを確認します
   • 見つからない場合は、エラーを表示して終了します

2. 解決済みの設定を解析して表示します：

   ### Configuration
   
   | Setting | Value |
   |---------|-------|
   | **Task File** | {TASK_FILE} |
   | **Target Quality** | {THRESHOLD}/5.0 |
   | **Max Iterations** | {MAX_ITERATIONS} |
   | **Active Stages** | {ACTIVE_STAGES as comma-separated list} |
   | **Human Checkpoints** | Phase {HUMAN_IN_THE_LOOP_PHASES as comma-separated} |
   | **Skip Judges** | {SKIP_JUDGES} |
   | **Refine Mode** | {REFINE_MODE} |
   | **Strict Mode** | {STRICT_MODE} |
   | **Continue From** | {CONTINUE_STAGE} or "Start" |
   | **Model** | `{MODEL_OVERRIDE}` (user override) or "auto — baseline `{BASELINE_TIER}`: {one-line justification}" |
   

3. --continue モードを処理します：

   CONTINUE_STAGE が設定されている場合：

   • タスクファイルを読み込み、現在の状態を確認します
   • タスクファイルの内容から完了済みのフェーズを特定します
   • CONTINUE_STAGE（または自動検出された次の未完了ステージ）に進みます
   • 既存の成果物から取得済みの値を事前に入力します
   • 適切なフェーズからワークフローを再開します

4. --refine モードを処理します：

   REFINE_MODE が true の場合：

   • ファイルの状態を確認します：git status --porcelain -- <TASK_FILE>
     • M（ステージ済み）、M（未ステージ）、または MM（両方）→ 差分を使って続行します
     • ??（未追跡）→ エラー：「ファイルは git で追跡されていないため、変更を検出できません」
     • 出力が空 → 変更は検出されませんでした
   • git diff HEAD -- <TASK_FILE> を実行し、最後のコミットとの差分（ステージ済み＋未ステージ）を取得します
   • 差分を解析して、変更されたセクションを特定します
   • // コメントマーカーをユーザーからのフィードバックとして収集します
   • セクションとステージの対応表を使って、最初に変更されたセクションを特定します
   • 特定した開始地点以降のステージのみを含むように ACTIVE_STAGES を設定します
   • 検出された変更とユーザーコメントを、追加コンテキストとしてエージェントに渡します
   • 変更が検出されなかった場合は、ユーザーに「タスクファイルの変更が検出されませんでした。ファイルを編集してから、--refine を実行してください。」と伝えて終了します

5. ファイルからタスク情報を抽出します：

   • タスクファイルを読み込み、ファイル名からタイトルとタイプを抽出します
   • フロントマターを解析して、タイトルと depends_on を取得します

6. TodoWrite を使ってワークフローの進捗追跡を初期化します：

   ACTIVE_STAGES に含まれるフェーズの TODO のみを含めます。続行する場合は、完了済みのフェーズを completed としてマークします。

   {
     "todos": [
       {"content": "Ensure directories exist", "status": "pending", "activeForm": "Ensuring directories exist"},
       {"content": "Phase 2a: Research relevant resources and documentation", "status": "pending", "activeForm": "Researching resources"},
       {"content": "Judge 2a: PASS research quality (> {THRESHOLD})", "status": "pending", "activeForm": "Validating research"},
       {"content": "Phase 2b: Analyze codebase impact and affected files", "status": "pending", "activeForm": "Analyzing codebase impact"},
       {"content": "Judge 2b: PASS codebase analysis (> {THRESHOLD})", "status": "pending", "activeForm": "Validating codebase analysis"},
       {"content": "Phase 2c: Business analysis and acceptance criteria", "status": "pending", "activeForm": "Analyzing business requirements"},
       {"content": "Judge 2c: PASS business analysis (> {THRESHOLD})", "status": "pending", "activeForm": "Validating business analysis"},
       {"content": "Phase 3: Architecture synthesis from research and analysis", "status": "pending", "activeForm": "Synthesizing architecture"},
       {"content": "Judge 3: PASS architecture synthesis (> {THRESHOLD})", "status": "pending", "activeForm": "Validating architecture"},
       {"content": "Phase 4: Decompose into sub-task files and verifiable phases", "status": "pending", "activeForm": "Decomposing into steps and phases"},
       {"content": "Judge 4: PASS decomposition (> {THRESHOLD})", "status": "pending", "activeForm": "Validating decomposition"},
       {"content": "Move task to todo folder", "status": "pending", "activeForm": "Promoting task"},
       {"content": "Human checkpoint reviews", "status": "pending", "activeForm": "Awaiting human review"}
     ]
   }
   

   注記： 設定に応じて TODO を絞り込みます：

   • SKIP_JUDGES が true の場合、すべての Judge TODO（Judge 2a、2b、2c、3、4）を省略します
   • research が ACTIVE_STAGES に含まれていない場合、Phase 2a と Judge 2a の TODO を省略します
   • codebase analysis が ACTIVE_STAGES に含まれていない場合、Phase 2b と Judge 2b の TODO を省略します
   • business analysis が ACTIVE_STAGES に含まれていない場合、Phase 2c と Judge 2c の TODO を省略します
   • architecture synthesis が ACTIVE_STAGES に含まれていない場合、Phase 3 と Judge 3 の TODO を省略します
   • decomposition が ACTIVE_STAGES に含まれていない場合、Phase 4 と Judge 4 の TODO を省略します
   • HUMAN_IN_THE_LOOP_PHASES が空の場合、人によるチェックポイントの TODO を省略します

7. ディレクトリが存在することを確認します：

   フォルダー作成スクリプトを実行して、タスク用ディレクトリを作成し、gitignore を設定します：

   bash ${CLAUDE_PLUGIN_ROOT}/scripts/create-folders.sh
   

   次のディレクトリが作成されます：

   • .specs/tasks/draft/ - 分析待ちの新規タスク
   • .specs/tasks/todo/ - 実装準備が整ったタスク
   • .specs/tasks/in-progress/ - 現在作業中のタスク
   • .specs/tasks/done/ - 完了したタスク
   • .specs/sub-tasks/ - Phase 4 で作成されるステップごとのサブタスクファイル（git で追跡されます）
   • .specs/scratchpad/ - 一時的な作業ファイル（gitignore 対象）
   • .specs/analysis/ - コードベースの影響分析ファイル
   • .claude/skills/ - 再利用可能なスキル文書

フェーズの開始時に各 TODO を in_progress に更新し、Judge の合格時に completed に更新します。

重大な注意事項

• 審査レポートで裏付けられていない判定を記録しないでください。ルーブリックの結果が合格でなければ PASS とせず、Iteration Discretion Ruleで実際に認められていない限り ☑️ ACCEPTED としないでください。それ以外の場合は、チェックに合格するまで、実装を変更するたびに審査を再実行してください！
• .claude または .specs ディレクトリ内のタスクファイルを読まないでください。あなたの役割は作業を行うエージェントを調整することであり、自分で作業することではありません！
• すべての審査の合否判定には、ハードコードされた値ではなく THRESHOLD（デフォルトは 3.5）を使用してください！
• 再試行の上限には、ハードコードされた値ではなく MAX_ITERATIONS（デフォルトは 3）を使用してください！
• MAX_ITERATIONS に達したら、自動的に次のステージに進んでください。フェーズが HUMAN_IN_THE_LOOP_PHASES に含まれている場合を除き、ユーザーに確認を求めないでください！
• ACTIVE_STAGES に含まれていないフェーズは完全にスキップしてください。除外されたステージのエージェントを起動しないでください！
• 人間参加型のチェックポイントは、HUMAN_IN_THE_LOOP_PHASES に含まれるフェーズの後に限り実行してください！
• SKIP_JUDGES が true の場合は、すべての審査による検証をスキップしてください。各実装フェーズの完了後、次のフェーズに直接進んでください！
• このコマンドの実行前に、.specs/tasks/draft/ にタスクファイルが存在している必要があります（--refine モードを除く）！
• REFINE_MODE が true の場合は、git diff で変更を検出し、変更のないステージをスキップして、ユーザーからのフィードバックをエージェントに渡してください！
• STRICT_MODE が true の場合は、Iteration Discretion Ruleを無効にしてください。フェーズが合格するのは score >= THRESHOLD の場合のみで、それ以外は MAX_ITERATIONS に達するまで再試行してください！

実行と評価のルール

• フォアグラウンドエージェントのみを使用してください。バックグラウンドエージェントは使用しないでください。可能な場合はエージェントを並列で起動してください。バックグラウンドエージェントでは権限の問題やその他のエラーが頻繁に発生します。

次のいずれかが発生するまで、審査を再実行してください。

• 長いレポートを却下する：スクラッチパッドを使用するよう指示されているのに、エージェントが非常に長いレポートを返した場合は、その結果を却下してください。これは、エージェントが「スクラッチパッドを使用する」という指示に従わなかったことを示します。
• 審査スコア 5.0 は幻覚です：審査員が 5.0/5.0 のスコアを返した場合は、幻覚または手抜きの評価と見なし、却下して審査を再実行してください。この厳格なフレームワークでは、満点は事実上あり得ません。
• スコアの欠落を却下する：審査レポートに数値スコアがない場合は、却下してください。これは、審査員がルーブリックの指示を読んでいない、または従っていないことを示します。

反復の裁量ルール

あなたの主なタスクは、目標品質を満たす範囲で計画を完了させることです。2 つの失敗モードはどちらも現実に起こり得ます。

• 些細な指摘にイテレーションとコンテキストを浪費し、タスク全体が完了しない → タスクは失敗です。
• 完了と見なすには品質が明らかに低すぎる計画を承認してしまう → さらに悪い失敗です。

このルールは、各フェーズの **Decision Logic:** ブロックを統制します。

• score < 3.0 → 無条件に FAIL。裁量はありません。 合格するか MAX_ITERATIONS に達するまで、審査フィードバックを付けてフェーズを再起動してください。
• 3.0 <= score < 5.0 → 裁量バンド。 このバンド内でのみ、THRESHOLD(デフォルト 3.5)未満のフェーズを許容可能と判断してよいです。
• 下限付きの切り下げ: THRESHOLD より 1.0 を超えて低いスコアを決して受け入れてはいけません。実効的な下限は max(3.0, THRESHOLD - 1.0)、つまりデフォルトの THRESHOLD 3.5 では 3.0、--target-quality 4.5 では 3.5 です。THRESHOLD <= 3.0(例: --fast)の場合、裁量バンドはまったく存在しません。
• バンド内では、未解決の課題が Low/Medium 優先度のみであり(High または Critical の指摘が 1 つでもあれば裁量は完全に失われます)、かつそれらのいずれもフェーズの目標要件を破ったり意味のある不具合を引き起こしたりしない場合(つまり些細な指摘である場合)、フェーズを再起動する前にまず、イテレーション(またはフェーズを失敗とすること)に時間とコンテキストのコストをかける価値があるかを熟考しなければなりません。
• 些細な指摘によるイテレーションは最大 1 回で、これは MAX_ITERATIONS にカウントされます。それでも再び些細な指摘しか出ない場合、フェーズを PASS とマークし(サマリーテーブルで ☑️ ACCEPTED)、完了サマリーに未解決の課題を報告し、次のフェーズへ進まなければなりません。もしスコアが下限 max(3.0, THRESHOLD - 1.0) を下回って返ってきた場合は、代わりに FAIL の経路が適用されます。
• あなたは批判的でなければならず、寛容であってはいけません。目標に届かないことは、要件を壊すような真の問題が存在しないことに基づいた意図的な判断でなければなりません。MAX_ITERATIONS 内でフェーズを完了することを妨げる真の阻害要因は、失敗として報告しなければならず、決して覆い隠してはいけません。
• STRICT_MODE が true の場合、このルール全体が無効化されます: score >= THRESHOLD になるか MAX_ITERATIONS に達した場合にのみ停止してください。--strict はそれ以外の何も変更しません — THRESHOLD、MAX_ITERATIONS、< 3.0 の無条件 FAIL、human-in-the-loop チェックポイント、審査のディスパッチ、および --skip-judges は影響を受けません。--skip-judges(または --one-shot)ではスコアがまったく生成されないため、このルールと --strict の両方が無効になります。

モデル選択ポリシー

モデルの選択は、あなたが行う単一で最もレバレッジの高い意思決定です — どんなプロンプトの文言よりも、計画が正しく返ってくるかどうか、そして実行にどれだけ時間がかかるかを左右します。これを形式上の手続きとして扱ってはいけません。各フェーズエージェントをディスパッチする前に、ティアを明示し、一行の根拠を示さなければなりません。考えるのが面倒だからといって最も強力なモデルに手を伸ばすことは、慎重さではなく失敗です。

ティアのデフォルト: sonnet が実用的なデフォルトであり、sonnet/haiku で実行の大部分をカバーします。opus は予約済みかつオプトインです — 以下の表にあるトリガーによって勝ち取られる必要があり、不確かだからといって選んではいけません。

選定ルール

計画対象のタスク全体（ドラフトタスクファイルのタイトルと種類、およびユーザーの入力）をこの表に照らして評価します。一致する行が、この実行の BASELINE_TIER になります。（同じ表では、単一の作業単位にもティアを割り当てます。そのため、Phase 4 にはこの表がそのまま渡され、実装ステップごとにモデルを割り当てます。また、Judge 4 はその割り当てを評価します。）

タスクの形態	ティア	例
簡単 — すでに理解されている変更が 1 つで、内容が明確です。単一ファイルで、確立されたパターンに従い、新しい依存関係がなく、未解決の設計上の疑問もなく、「完了」の状態がドラフトからすでに明らかです	haiku	README 1 つの誤字を修正する、設定フラグを追加する、依存関係のバージョンを上げる、ログメッセージを修正する
一般的 — 通常の機能追加、修正、リファクタリングです。1 つのモジュールまたはサービス内の数ファイルが対象で、確立されたパターンに従い、設計上の判断は局所的なものに限られます	sonnet	既存サービスに REST エンドポイントを追加する、フォームのバリデーションを追加する、ヘルパーとそのテストを切り出す
複雑 — 広範囲（約 3 つ以上のモジュール／サービス、または共有コントラクトの変更を伴う範囲）または 重要なドメイン（認証、支払い／請求、データ整合性、取り消し不能な移行、公開 API の破壊的変更）または 未確定の設計（並行処理、単純でないアルゴリズム、新しいサブシステム、未決定のアーキテクチャ）	opus	12 個のモジュールにまたがる支払いサブシステムの再設計、新しいイベントパイプラインの設計、スキーマ移行の計画

優先順位（必須）： 最初に一致した行だけでなく、すべての行を評価してください。複数の行に一致する場合は、最も高い一致ティアを選びます。重要性と未確定の設計は、常に規模より優先されます。重要なドメインのリストは網羅的であり、例示ではありません。本番環境へのリリース、実ユーザーへの影響、既存の公開 API への追加はトリガーではないため、1 つのサービス内でバリデーション付きの新しいエンドポイントを追加する場合は sonnet のままです。機械的な広範囲変更の例外： 広範囲であることだけでは複雑とは見なしません。ロジックやコントラクトの変更を伴わず、同一のルールに基づく編集を多くのファイルで繰り返す場合、広範囲のトリガーだけは適用されません（重要なドメインと未確定の設計は引き続き適用されます）。1 か所だけの場合を基準にティアを判定します。たとえば、40 個のファイルにわたる機械的な名前変更は haiku ですが、同じ名前変更が src/auth/ 内に限定される場合は opus です。

タイブレーカー： どの行にも明確に一致せず、タスクが実際に 2 つのティアの中間にある場合に限り、作業上のデフォルトである sonnet を選びます。保険として opus に引き上げてはいけません。エスカレーションルールにより、控えめな初期判断は後から修正できます。また、1 フェーズを修正するコストは、すべての実行のすべてのフェーズに過剰なリソースを割り当てるコストを大きく下回ります。

フェーズの重み付け

BASELINE_TIER は、モデルが割り当てられるすべてのフェーズに適用されるティアです。明示的な例外は 1 つだけです。

フェーズ	重み	ティア
Phase 3: アーキテクチャの統合	重 — 確定済みの判断を適用するのではなく、未確定の設計判断を行う唯一のフェーズです。ここでは 3 つの入力を統合し、その結果は後続のすべてのフェーズと実装自体に引き継がれます	BASELINE_TIER より 1 ティア上。ただし opus を上限とします
Phases 2a, 2b, 2c, 4	標準	BASELINE_TIER

モデルが割り当てられる各フェーズは、必ずいずれか 1 つの行に該当するため、それぞれのティアは 1 つだけに決まります。上限により、ベースラインが opus の場合、すべてのフェーズが opus になります。昇格は自分で実行するファイルの移動であり、サブエージェントもティアもありません。--model による上書きについては、役割の組み合わせを参照してください。

計画内のステップごとのティアと混同しないでください。 上記のティアは、起動する計画エージェントを対象とします。各サブタスクファイルに記録される Model: と、各フェーズに記録される Reviewer model: は、実装実行向けに Phase 4 が決定します。これは、Phase 4 の起動プロンプトに含まれるステップごとのポリシーに基づき、BASELINE_TIER とは独立しています。

ロールのペアリング

このパイプラインでは、各フェーズにモデル割り当てされた 2 つのロールがあります。プロデューサー（そのフェーズのエージェント）と評価者（その判定者）です。判定者は常に、それが検証するフェーズのティアで実行されます。エスカレーション後も同様です。判定者をそのフェーズから独立してティア設定してはいけません（MUST NOT）。

明示的な --model はこのポリシー全体を上書きします（このルールの唯一の記述）: すべてのフェーズエージェントとすべての判定者はユーザーのティアで実行され、BASELINE_TIER の評価は実行されず、フェーズの重み付けはそれから決して逸脱しません。

エスカレーションルール

次のいずれかのトリガーが発火した場合、そのフェーズの次のイテレーションでフェーズエージェントとその判定者の両方を 1 ティア上げます。

1. 初回イテレーションの品質が低い — スコアが低い、または判定者の指摘が、単に詳細を逃しただけでなくモデルがフェーズを誤解していることを示している。
2. ユーザーが不満を述べる — 品質が低すぎる、または結果が間違っているという不満を、報告された PASS や完了した実行の後を含むいつでも。

ラダー: haiku → sonnet → opus。opus が上限です — それ以上のティアはありません。opus ティアの作業が依然として失敗する場合は、それを報告し、ユーザーへエスカレーションしてください。決してループしてはいけません。

• 唯一の例外 — ティアを維持する（このルールの唯一の記述、トリガー (1) のみ）: トリガー (1) が発火したものの、判定者の指摘が能力の不足ではなく、特定的で修正可能な欠陥である場合（モデルが明らかに理解していた、狭く正確に特定された問題）、ティアを維持し、上げる代わりに判定者の正確なフィードバックを添えて同じティアでフェーズを再起動してもよい（MAY）。トリガー (1) での引き上げが必須でないのは、この状況だけです。それ以外のすべてのケースではトリガー (1) は引き上げます。トリガー (2) にはそのような例外はありません — 以下の特例規定のとおり、常に即座に引き上げます。
• 明示的な --model の特例規定（このルールの唯一の記述）: 明示的な --model はユーザーによる上書きであるため、トリガー (1) がそれを暗黙に覆してはいけません（MUST NOT） — 低品質の証拠を報告し、引き上げを提案し、ユーザーが承認しない限りユーザーのティアで再起動してください。トリガー (2) がその承認にあたるため、即座に引き上げます。
• --skip-judges の特例規定（このルールの唯一の記述）: 判定者が実行されていない場合、トリガー (1) が読むべきスコアや判定者の指摘が存在しないため、トリガー (1) は発火できません。トリガー (2) はユーザーが起点であり、判定者由来ではないため影響を受けません — --skip-judges（または --one-shot）でのユーザーの不満は、そのフェーズの再起動のために依然としてティアを引き上げます。
• 失敗しているフェーズに限定されます。 エスカレーションされたティアはそのフェーズの残りのイテレーションにのみ適用されます。それ以降のすべてのフェーズは、それぞれ独自のフェーズの重み付けのティアから再開します。
• エスカレーションは、真の根本原因の修正を補完するものであり、決してその代替ではありません。判定者の具体的なフィードバックを依然として再起動に渡さなければなりません（MUST）。同じプロンプトをより高いティアで再起動して願うことは禁止されています。
• エスカレーションは THRESHOLD、MAX_ITERATIONS、STRICT_MODE およびイテレーション裁量ルールとは直交します — それは次のイテレーションをどのモデルが実行するかを変えるだけで、イテレーションが必要かどうかを決して変えません。イテレーション裁量ルールがフェーズを承認した場合、イテレーションは行われないため、何もエスカレーションされません。
• 完了したフェーズへの再エントリー（このルールの唯一の記述）: ✅ PASS または ☑️ ACCEPTED は作業を終結させません。その後のユーザーによる品質の不満は、トリガー (2) の下でそのフェーズに再エントリーし — --continue または --refine を通じて — MAX_ITERATIONS はそれに対してリセットされ、そのフェーズとその判定者は引き上げられたティアで実行されます。

プロバイダー間の同等性

このスキルを Anthropic のモデルコンテキスト外で実行する場合は、同じクラスの最も近いモデルにティアを対応付けます。

ティア	役割	他のプロバイダーの同等モデル
haiku	高速で低コスト。機械的な作業向け	gemini-flash-lite、gemma クラス、gpt-oss クラス、小規模なオープンウェイトモデル
sonnet	バランスの取れた主力モデル。ほとんどの計画フェーズ向け	gemini-pro クラスおよびフル版の gemini-flash（haiku ティアに相当する -lite バリアントは除く）、GPT-5-mini クラス、大規模な Qwen／DeepSeek クラス
opus	最先端の推論能力。重要または複雑な作業向け	プロバイダーが拡張推論／熟考推論ティアとして提供しているモデル。現時点では GPT-5.5、deep-think モード、Kimi K3 クラス、スループットよりも長時間の熟考を強みとするモデル

対応付けは名前ではなく、能力ティアに基づきます。ベンダーが新しいモデルをリリースするたびに、モデル名は変わります。上記のすべてのルールはティアで表現されているため、別のプロバイダーを使う場合は、ティアを同じクラスのモデルに対応付けたうえで、選択、重み付け、組み合わせ、エスカレーションのルールを変更せず適用してください。

ワークフローの実行

すべてのステップを自分で実行するのではなく、各ステップで個別のエージェントを必ず起動してください。

重要： エージェントごとに、必ず次のことを行ってください。

1. フェーズで指定された Agent タイプと、Model Selection Policy に従って解決した Model ティアを使用する
2. タスクファイルのパスとユーザー入力をコンテキストとして渡す
3. ${CLAUDE_PLUGIN_ROOT} の値を渡し、エージェントが @${CLAUDE_PLUGIN_ROOT}/scripts/create-scratchpad.sh のようなパスを解決できるようにする
4. エージェントには、そのステップだけを過不足なく実行するよう指示する
5. 各サブフェーズの後、品質を検証するためにジャッジエージェントを起動してから次に進む

ワークフロー全体の概要

注： ACTIVE_STAGES に含まれていないフェーズはスキップされます。SKIP_JUDGES が true の場合、すべてのジャッジステップがスキップされます。ヒューマンチェックポイント（🔍）は、 HUMAN_IN_THE_LOOP_PHASES に含まれるフェーズの後に行われます。

Input: Draft Task File (.specs/tasks/draft/*.md)
    │
    ▼
Phase 2: Parallel Analysis
    │
    ├─────────────────────┬─────────────────────┐
    ▼                     ▼                     ▼
Phase 2a:             Phase 2b:             Phase 2c:
Research              Codebase Analysis     Business Analysis
[sdd:researcher]      [sdd:code-explorer]   [sdd:business-analyst]
all three at baseline tier
Judge 2a              Judge 2b              Judge 2c
(pass: >THRESHOLD)     (pass: >THRESHOLD)     (pass: >THRESHOLD)
    │                     │                     │
    └─────────────────────┴─────────────────────┘
                          │
                          ▼
                    Phase 3: Architecture Synthesis
                    [sdd:software-architect] baseline+1 (cap opus)
                    Judge 3 (pass: >THRESHOLD)
                          │
                          ▼
                    Phase 4: Decomposition
                    [sdd:tech-lead] baseline
                    → task file: ## Implementation Process
                    → .specs/sub-tasks/<task-name>/NN-<step-slug>.md
                    Judge 4 (pass: >THRESHOLD)
                          │
                          ▼
                    Move task: draft/ → todo/
                          │
                          ▼
                    Complete

---

フェーズ 2：並行分析

フェーズ 2 では、独自のジャッジ検証を伴う 3 つの分析フェーズを並行して起動します。

フェーズ 2a／2b／2c：並行サブフェーズ

次の 3 つのフェーズを直ちに並行して起動してください。

---

フェーズ 2a：調査

モデル： Phase Weighting に従った BASELINE_TIER — 標準的な重み付けです。スコープがすでに定まったタスクについて、リソースを収集して要約します。設計上の判断は行いません。 エージェント： sdd:researcher 依存関係： タスクファイルが存在すること 目的： 関連するリソース、ドキュメント、ライブラリ、先行事例を収集します。再利用可能なスキルを作成または更新します。

エージェントを起動します。

• 説明：「タスクのリソースを調査し、スキルを作成／更新する」

• プロンプト：

  CLAUDE_PLUGIN_ROOT=${CLAUDE_PLUGIN_ROOT}
  
  Task File: <TASK_FILE>
  Task Title: <title from task file>
  
  CRITICAL: DO NOT OUTPUT YOUR RESEARCH, ONLY CREATE THE SCRATCHPAD AND SKILL FILE.
  

記録する情報：

• スキルファイルのパス（例：.claude/skills/<skill-name>/SKILL.md）
• スキルのアクション（新規作成／既存を更新）
• スクラッチパッドファイルのパス（例：.specs/scratchpad/<hex-id>.md）
• 収集したリソースの数
• 主な推奨事項の要約

重要：必要なファイルが作成されていない場合は、同じプロンプトでエージェントを再度起動してください。

---

フェーズ 2b：コードベースへの影響分析

モデル： Phase Weighting に従った BASELINE_TIER — 標準的な重み付けです。ファイルや統合ポイントを特定するためのコードベースの読み込み規模は、タスク自体の範囲に応じて変わり、その範囲はすでにベースラインに反映されています。 エージェント： sdd:code-explorer 依存関係： タスクファイルが存在すること 目的： 影響を受けるファイル、インターフェース、統合ポイントを特定します

エージェントを起動します。

• 説明：「コードベースへの影響を分析する」

• プロンプト：

  CLAUDE_PLUGIN_ROOT=${CLAUDE_PLUGIN_ROOT}
  
  Task File: <TASK_FILE>
  Task Title: <title from task file>
  
  CRITICAL: DO NOT OUTPUT YOUR ANALYSIS, ONLY CREATE THE SCRATCHPAD AND ANALYSIS FILE.
  

記録する情報：

• 分析ファイルのパス（例：.specs/analysis/analysis-{name}.md）
• スクラッチパッドファイルのパス（例：.specs/scratchpad/<hex-id>.md）
• 影響を受けるファイルの数（変更／作成／削除）
• リスクレベルの評価
• 主な統合ポイント

重要：必要なファイルが作成されていない場合は、同じプロンプトでエージェントを再度起動してください。

---

フェーズ 2c: ビジネス分析

モデル: フェーズ重み付けに基づく BASELINE_TIER — 標準的な重み: 構造化された引き出しとチェックリスト/ルーブリック/テスト戦略の導出は、エージェント自身の STAGES 1-10 によってエンドツーエンドで駆動され、自由形式の統合ではありません — ここでは手順が厳密さを担い、モデルではありません。 エージェント: sdd:business-analyst 依存先: タスクファイルが存在すること 目的: 説明を洗練し、単一の ## Acceptance Criteria セクションを生成します — チェックリスト、定期チェック、ルーブリック、ルーブリックスコアの定義、テスト戦略、完了の定義を、ビジネス基準と技術基準を混在させて作成します

エージェントを起動します:

• Description: "Business analysis"

• Prompt:

  CLAUDE_PLUGIN_ROOT=${CLAUDE_PLUGIN_ROOT}
  
  Task File: <TASK_FILE>
  Task Title: <title from task file>
  
  Execute your own Core Process (STAGES 1-10) in full. 
  
  CRITICAL: DO NOT OUTPUT YOUR BUSINESS ANALYSIS. Create the scratchpad, then write the task file's `# Description` and the single `## Acceptance Criteria` section at your STAGE 10.
  

キャプチャ:

• スクラッチパッドファイルのパス (例: .specs/scratchpad/<hex-id>.md)
• スコープの定義 (yes/no)
• ユーザーシナリオの文書化
• チェックリスト項目数 (essential / important / optional / pitfall)
• 定期チェック数
• ルーブリックの次元数 (重みの合計: 1.0)
• テスト戦略の適用 (true/false) と選択されたテストタイプ
• 発見された品質ゲートとプロジェクトガイドライン

CRITICAL: タスクファイルの # Description または ## Acceptance Criteria セクションが記述されていない場合は、同じプロンプトでエージェントを再度起動します。

---

ジャッジ 2a/2b/2c: 並列フェーズの検証

各並列フェーズが完了した後、そのフェーズと同じエージェントタイプを使用して、それぞれのジャッジを起動します。ティアは ロールペアリングが指定するものを使用します。

ジャッジ 2a: Research/Skill の検証

モデル: フェーズ 2a のティア — ロールペアリングを参照 エージェント: sdd:researcher 依存先: フェーズ 2a の完了 目的: スキルの完全性と関連性を検証する

ジャッジを起動します:

• Description: "Judge skill quality"

• Prompt:

  CLAUDE_PLUGIN_ROOT=${CLAUDE_PLUGIN_ROOT}
  
  Read @${CLAUDE_PLUGIN_ROOT}/prompts/judge.md for evaluation methodology and execute.
  
  ### Artifact Path
  {path to skill file from Phase 2a}
  
  ### Context
  This is a skill document for task: {task title}. Evaluate comprehensiveness and reusability.
  
  ### Rubric
  1. Resource Coverage (weight: 0.30)
     - Documentation and references gathered?
     - Libraries and tools identified with recommendations?
     - 1=Missing critical resources, 2=Basic coverage, 3=Adequate, 4=Comprehensive, 5=Excellent
  
  2. Pattern Relevance (weight: 0.25)
     - Are identified patterns applicable?
     - Are recommendations actionable?
     - 1=Irrelevant, 2=Somewhat useful, 3=Adequate, 4=Well-targeted, 5=Perfect fit
  
  3. Issue Anticipation (weight: 0.20)
     - Common pitfalls identified with solutions?
     - 1=None identified, 2=Few issues, 3=Adequate, 4=Good coverage, 5=Comprehensive
  
  4. Reusability (weight: 0.15)
     - Is the skill general enough to help multiple tasks?
     - Does it avoid task-specific details?
     - 1=Too specific, 2=Limited reuse, 3=Adequate, 4=Good, 5=Highly reusable
  
  5. Task Integration (weight: 0.10)
     - Was task file updated with skill reference?
     - 1=Not updated, 3=Updated, 5=Updated with clear instructions
  

CRITICAL: プロンプトはそのままの形で使用し、それ以外は何も追加しないでください。実装エージェントの出力を含めないでください!!!

判定ロジック:

• PASS (スコア >= THRESHOLD): リサーチ完了、次へ進む
• FAIL (スコア < THRESHOLD): フィードバックを添えてフェーズ 2a を再起動する。ティアはエスカレーションルールに従う (反復裁量ルールにより受け入れられた場合を除く)
• MAX_ITERATIONS 到達: スコアに関係なく次のステージへ進む (警告をログに記録)

---

ジャッジ 2b: コードベース分析の検証

モデル: フェーズ 2b のティア — ロールペアリングを参照 エージェント: sdd:code-explorer 依存先: フェーズ 2b の完了 目的: ファイル特定の正確性と統合マッピングを検証する

ジャッジを起動します:

• Description: "Judge codebase analysis quality"

• Prompt:

  CLAUDE_PLUGIN_ROOT=${CLAUDE_PLUGIN_ROOT}
  
  Read @${CLAUDE_PLUGIN_ROOT}/prompts/judge.md for evaluation methodology and execute.
  
  ### Artifact Path
  {path to analysis file from Phase 2b}
  
  ### Context
  This is codebase impact analysis for task: {task title}. Evaluate accuracy and completeness.
  
  ### Rubric
  1. File Identification Accuracy (weight: 0.35)
     - All affected files identified with specific paths?
     - New files and modifications distinguished?
     - 1=Major files missing, 2=Mostly correct, 3=Adequate, 4=Precise, 5=Complete
  
  2. Interface Documentation (weight: 0.25)
     - Key functions/classes documented with signatures?
     - Change requirements clear?
     - 1=Missing, 2=Partial, 3=Adequate, 4=Good, 5=Complete
  
  3. Integration Point Mapping (weight: 0.25)
     - Integration points identified with impact?
     - Similar patterns in codebase found?
     - 1=Missing, 2=Partial, 3=Adequate, 4=Good, 5=Comprehensive
  
  4. Risk Assessment (weight: 0.15)
     - High risk areas identified with mitigations?
     - 1=No assessment, 2=Basic, 3=Adequate, 4=Good, 5=Thorough
  

CRITICAL: プロンプトはそのままの形で使用し、それ以外は何も追加しないでください。実装エージェントの出力を含めないでください!!!

判定ロジック:

• PASS (スコア >= THRESHOLD): 分析完了、次へ進む
• FAIL (スコア < THRESHOLD): フィードバックを添えてフェーズ 2b を再起動する。ティアはエスカレーションルールに従う (反復裁量ルールにより受け入れられた場合を除く)
• MAX_ITERATIONS 到達: スコアに関係なく次のステージへ進む (警告をログに記録)

---

ジャッジ 2c: ビジネス分析の検証

モデル: フェーズ 2c のティア — ロールのペアリングを参照 エージェント: sdd:business-analyst 依存先: フェーズ 2c の完了 目的: 洗練された記述と ## Acceptance Criteria セクション全体 — チェックリスト、定期チェック、ルーブリック、スコア定義、テスト戦略、完了の定義 — を検証します 重みの導出: 基準 1〜4 は元のビジネス分析基準を以前の比率 (0.30/0.35/0.20/0.15) のまま 0.60 でスケーリングしたもので、0.01 の端数はそれらのうち最も重みの大きいものに与えられ、合計は 0.61 になります。基準 5〜7 — ルーブリックとテスト戦略のレビューがこのジャッジに統合された際に取り込まれたもの — は、残りの 0.39 を均等に 0.13 ずつ分割します。基準を追加または削除する際は、この 0.61/0.39 の分割を維持して、重みの合計が引き続き 1.00 になるようにしてください。

ジャッジを起動:

• Description: "Judge business analysis quality"

• Prompt:

  CLAUDE_PLUGIN_ROOT=${CLAUDE_PLUGIN_ROOT}
  
  Read @${CLAUDE_PLUGIN_ROOT}/prompts/judge.md for evaluation methodology and execute.
  
  ### Artifact Path
  {path to task file from Phase 2c}
  
  ### Context
  This is business analysis output. The task file should contain a refined `# Description`
  (with Scope Included/Excluded and User Scenarios) and exactly one `## Acceptance Criteria`
  section holding six sub-blocks in this order: `**Checklist:**` (table
  `| ID | Question | Category | Importance |`, IDs `CK-n`/`HR-n`), `**Regular Checks:**`
  (checkbox list), `**Rubric:**` (table `| Criterion | Weight |`), `**Rubric Score Definitions:**`
  (one `###` section per criterion, each ending in an `Anchors` list carrying `score_2`, `score_4`
  and `contrast` — excerpt anchors that pin 2 and 4, NOT 1-5 bins), `**Test Strategy:**` (Criticality + Test Matrix
  table + `Test Cases to Cover` grouped under `#### CK-N:` headings) and `**Definition of Done:**`.
  Business and technical criteria are mixed inside each sub-block — there is no separate business
  criteria list, and no section other than `## Acceptance Criteria` may carry evaluation content.
  
  ### Rubric
  1. Description Clarity (weight: 0.18)
     - What/Why/Who clearly explained?
     - Business value stated, constraints named?
     - 1=Vague, 2=Basic, 3=Adequate, 4=Clear, 5=Excellent
  
  2. Criteria Quality (weight: 0.22)
     - Is every `**Checklist:**` row a boolean YES/NO question that is specific and testable?
     - Are Category (`hard_rule`/`principle`) and Importance filled for every row, with stable `CK-n`/`HR-n` IDs?
     - Do business and technical criteria appear mixed, rather than as a separate business list?
     - Is `**Definition of Done:**` present and derived from those criteria?
     - 1=Missing/vague, 2=Basic, 3=Adequate, 4=Good, 5=Excellent
  
  3. Scenario Coverage (weight: 0.12)
     - Primary, alternative and error flows documented under **User Scenarios**?
     - Are the error and edge scenarios actually represented by checklist items or test cases?
     - 1=Missing, 2=Basic, 3=Adequate, 4=Good, 5=Comprehensive
  
  4. Scope Definition (weight: 0.09)
     - In-scope/out-of-scope explicit?
     - No implementation details in the description?
     - No invented file paths — artifacts cited only where the user prompt named them?
     - 1=Missing, 2=Partial, 3=Adequate, 4=Good, 5=Clear
  
  5. Rubric Quality (weight: 0.13)
     - Are `**Rubric:**` criteria specific to this task (not generic)?
     - Do the weights sum to 1.0?
     - Does EVERY criterion in `**Rubric Score Definitions:**` carry an `Anchors` list naming all three of `score_2`, `score_4` and `contrast`, with no 1-5 bins, ratios, percentages or quality bands in its description or classification/instruction paragraph? (A `score_2`/`score_4` anchor excerpt may legitimately quote a figure — this restriction does not reach the anchors themselves.)
     - Is each `score_2` / `score_4` a concrete excerpt of the deliverable a reader could point at (fenced text), NEVER a description of quality — `score_2` obviously FAILING that dimension and `score_4` obviously SATISFYING it?
     - Do a criterion's two anchors differ on EXACTLY ONE observable thing, with its one-line `contrast` naming that single difference, so a judge can place an artifact between or past them on that axis alone?
     - Is `Project Guidelines Alignment` present when project guideline files exist?
     - 1=Generic/broken rubrics, 2=Adequate, 3=Acceptable, 4=Good custom rubrics, 5=Excellent custom rubrics
  
  6. Coverage Completeness (weight: 0.13)
     - Are all six sub-blocks present, in order, under a single `## Acceptance Criteria`?
     - Does `**Regular Checks:**` use the project's actual discovered build/lint/test commands rather than placeholders?
     - Is every checklist item carried by at least one rubric criterion, regular check or test case — no orphans?
     - Is the task file free of scoring configuration (threshold values, judge counts, evaluation modes) and of any evaluation section other than `## Acceptance Criteria`?
     - 1=Missing sub-blocks or orphans, 2=Most covered, 3=Acceptable, 4=Good, 5=100% coverage
  
  7. Test Strategy Coverage (weight: 0.13)
     - When the task carries testable behaviour, is `**Test Strategy:**` present with Criticality, a Test Matrix table (`| Type | Size | Framework | Dependencies | Gate |`) and a `Test Cases to Cover` list?
     - Is every group headed `#### CK-N:` naming a checklist item that exists, with cases in `- [type] description` form?
     - Does every testable checklist item have at least one test case (no orphans), and every Test Matrix row a corresponding case?
     - If the strategy does not apply, is that stated with a reason rather than silently omitted?
     - 1=Missing/empty Test Strategy, 2=Present but orphaned or unheaded groups, 3=All blocks present, 4=Full coverage of testable items, 5=Ideal coverage with boundary cases enumerated
  

CRITICAL: use prompt exactly as is, do not add anything else. Including output of implementation agent!!!

判定ロジック:

• PASS (スコア >= THRESHOLD): ビジネス分析は完了、続行
• FAIL (スコア < THRESHOLD): フィードバックを添えてフェーズ 2c を再起動、エスカレーションルールに従ったティアで (反復裁量ルールにより承認された場合を除く)
• MAX_ITERATIONS に到達: スコアに関係なく次のステージへ進む (警告をログに記録)

---

同期ポイント

フェーズ 3 に進む前に、3 つの並行フェーズ (2a、2b、2c) すべてとそれらのジャッジが PASS するのを待ってください。

---

フェーズ 3: アーキテクチャの統合

モデル: フェーズの重み付けに従い、BASELINE_TIER より 1 ティア上、opus を上限とする — 唯一の heavy フェーズです。これは、以降のすべてのフェーズと実装が引き継ぐソリューション戦略とトレードオフを決定します。 エージェント: sdd:software-architect 依存先: フェーズ 2a + ジャッジ 2a の PASS、フェーズ 2b + ジャッジ 2b の PASS、フェーズ 2c + ジャッジ 2c の PASS 目的: 調査、分析、ビジネス要件をアーキテクチャ概要へ統合します

エージェントを起動:

• Description: "Architecture synthesis"

• Prompt:

  CLAUDE_PLUGIN_ROOT=${CLAUDE_PLUGIN_ROOT}
  
  Task File: <TASK_FILE>
  Skill File: <skill file path from Phase 2a>
  Analysis File: <analysis file path from Phase 2b>
  
  CRITICAL: DO NOT OUTPUT YOUR ARCHITECTURE SYNTHESIS, ONLY CREATE THE SCRATCHPAD AND UPDATE THE TASK FILE.
  

記録:

• スクラッチパッドのファイルパス (例: .specs/scratchpad/<hex-id>.md)
• タスクファイルに追加されたセクション
• 主要なアーキテクチャ上の決定の数
• 特定されたコンポーネント (該当する場合)
• 定義されたコントラクト (該当する場合)

---

ジャッジ 3: アーキテクチャの統合の検証

モデル: フェーズ 3 のティア — ロールのペアリングを参照 エージェント: sdd:software-architect 依存先: フェーズ 3 の完了 目的: アーキテクチャの一貫性と完全性を検証します

ジャッジを起動:

• Description: "Judge architecture synthesis quality"

• Prompt:

  CLAUDE_PLUGIN_ROOT=${CLAUDE_PLUGIN_ROOT}
  
  Read @${CLAUDE_PLUGIN_ROOT}/prompts/judge.md for evaluation methodology and execute.
  
  ### Artifact Path
  {path to task file after Phase 3}
  
  ### Context
  This is architecture synthesis output. The Architecture Overview section should contain
  solution strategy, key decisions, and only relevant architectural sections.
  
  ### Rubric
  1. Solution Strategy Clarity (weight: 0.30)
     - Approach clearly explained?
     - Key decisions documented with reasoning?
     - Trade-offs stated?
     - 1=Missing/unclear, 2=Basic, 3=Adequate, 4=Clear, 5=Excellent
  
  2. Reference Integration (weight: 0.20)
     - Links to research and analysis files?
     - Insights from both integrated?
     - 1=No links, 2=Partial, 3=Adequate, 4=Good, 5=Fully integrated
  
  3. Section Relevance (weight: 0.25)
     - Only relevant sections included (not all)?
     - Sections appropriate for task complexity?
     - 1=Wrong sections, 2=Mostly appropriate, 3=Adequate, 4=Good, 5=Precisely targeted
  
  4. Expected Changes Accuracy (weight: 0.25)
     - Files to create/modify listed?
     - Consistent with codebase analysis?
     - 1=Missing/inconsistent, 2=Partial, 3=Adequate, 4=Good, 5=Complete
  
  

CRITICAL: use prompt exactly as is, do not add anything else. Including output of implementation agent!!!

判定ロジック:

• PASS (スコア >= THRESHOLD): アーキテクチャの統合は完了、続行
• FAIL (スコア < THRESHOLD): フィードバックを添えてフェーズ 3 を再起動、エスカレーションルールに従ったティアで (反復裁量ルールにより承認された場合を除く)
• MAX_ITERATIONS に到達: スコアに関係なくフェーズ 4 へ進む (警告をログに記録)

フェーズ 4 の前に PASS するのを待ってください。

---

フェーズ 4：分解

モデル： フェーズの重み付けに基づく BASELINE_TIER — 標準の重みです。未決定の設計判断を行うのではなく、フェーズ 3 ですでに確定したアーキテクチャを適用しますが、各ステップで実質的な判断が求められます。このタスク固有のステップに関するリスクと緩和策、過不足のない依存関係グラフ、そしてそれぞれが動作確認可能なマイルストーンとなるフェーズ境界が必要です（Judge 4 の「リスクの網羅性」「依存関係の正確性」「フェーズ設計」の基準を参照）。 エージェント： sdd:tech-lead 依存条件： フェーズ 3 + Judge 3 PASS 目的： アーキテクチャを実装ステップに分解し、各ステップを個別のサブタスクファイルとして作成します。さらに、依存関係、並列グループ、ステップごとのエージェント／モデルの割り当て、フェーズごとのレビューモデルとともに、独立して検証可能なフェーズにまとめます。

エージェントを起動します：

• 説明：「サブタスクファイルとフェーズに分解する」

• プロンプト：

  CLAUDE_PLUGIN_ROOT=${CLAUDE_PLUGIN_ROOT}
  
  Task File: <TASK_FILE>
  
  Use agents only from this list: {list ALL available agents with plugin prefix if available, e.g. sdd:developer, review:bug-hunter. Also include general agents: opus, sonnet, haiku}
  
  Assign each step's model tier per this policy:
  {paste the Selection Rules table plus its Precedence and Tie-breaker paragraphs from the orchestrator's Model Selection Policy verbatim, applied per implementation step; drop the cross-reference links, which do not resolve outside that file}
  
  CRITICAL: DO NOT OUTPUT YOUR DECOMPOSITION. Create the scratchpad, write ONLY the `## Implementation Process` section (Parallelization Overview + Phase Overview) into the task file, and write every step as its own file under `.specs/sub-tasks/<task-name>/`.
  

記録する内容：

• スクラッチパッドファイルのパス（例：.specs/scratchpad/<hex-id>.md）
• サブタスクディレクトリ（.specs/sub-tasks/<task-name>/）と、作成したサブタスクファイル
• 実装ステップ数（そのうち統合された数も記録）
• サブタスクの総数
• フェーズ数と、各フェーズのステップおよびレビューモデル
• クリティカルパス上のステップ
• 最大並列幅（同時実行ステップ数のピーク — 必ず 1～5）
• エージェント／モデルの分布
• 優先度の高いリスクの数

重要：## Implementation Process セクションまたは Parallelization Overview に記載されたサブタスクファイルが見つからない場合は、同じプロンプトでエージェントを再度起動してください。

---

Judge 4：分解を検証する

モデル： フェーズ 4 のティア — 役割の組み合わせを参照 エージェント： sdd:tech-lead 依存条件： フェーズ 4 の完了 目的： ステップの品質、サブタスクファイルの完全性、依存関係と並列化の正確性、エージェント／モデルの割り当て、フェーズ設計を検証します。

審査担当を起動します：

• 説明：「分解の品質を審査する」

• プロンプト：

  CLAUDE_PLUGIN_ROOT=${CLAUDE_PLUGIN_ROOT}
  
  Read @${CLAUDE_PLUGIN_ROOT}/prompts/judge.md for evaluation methodology and execute.
  
  ### Artifact Path
  {path to task file after Phase 4}
  {path to the sub-task directory from Phase 4, e.g. .specs/sub-tasks/<task-name>/} — evaluate EVERY file in it
  
  ### Context
  This is decomposition output, written across two places. The task file carries ONLY the
  `## Implementation Process` section: the sub-agent execution directive that governs how each step
  is launched and how each phase is reviewed (its required content is spelled out under Completeness
  below), a `### Parallelization Overview` (ASCII diagram with phase boundaries plus a step table
  with columns `Step | Phase | Model | Agent | Depends on | Parallel with | Sub-Task File`) and a
  `### Phase Overview` (per phase: `#### Phase N`, `Steps:`, `Reviewer model:`,
  `Acceptance Criteria that should be fulfiled:`, a `Checklist items:` list citing `CK-n`/`HR-n` IDs from
  the task file's `**Checklist:**` table, and a `Rubrics:` list citing criterion names from its
  `**Rubric:**` table). Every step body lives in its own sub-task file at
  `.specs/sub-tasks/<task-name>/<NN>-<step-slug>.md` with the fields `**Task File:**`, `**Phase:**`,
  `**Model:**`, `**Agent:**`, `**Depends on:**`, `**Parallel with:**`, `**Note:**`, `**Goal:**`, a step
  description, `#### Expected Output`, `#### Success Criteria`, `#### Subtasks` and `#### Blockers & Risks`.
  
  By design these do NOT belong in the task file and MUST NOT be scored as missing: `### Implementation
  Strategy`, a least-to-most decomposition chain, `### Step N:` bodies, `## Implementation Summary`,
  `## Risks & Blockers Summary`, and a task-level Definition of Done (the Definition of Done lives in
  `## Acceptance Criteria`, written by an earlier phase). Verification is PHASE-level: each phase names
  one reviewer model; there are no per-step verification sections.
  
  Use agents only from this list: {list ALL available agents with plugin prefix if available, e.g. sdd:developer, review:bug-hunter. Also include general agents: opus, sonnet, haiku}
  
  ### Rubric
  1. Step Quality (weight: 0.15)
     - Does every sub-task file carry ALL required fields, with `None` written rather than a field omitted?
     - Does each have a clear `**Goal:**`, a real step description, and `#### Expected Output`?
     - Is each step meaningfully sized — neither so large it hides risk nor so small it wastes an agent run?
     - Is each sub-task file standalone-readable, naming every path, symbol and decision it builds on rather than relying on a neighbouring step?
     - 1=Vague/missing fields, 2=Basic, 3=Adequate, 4=Good, 5=Excellent
  
  2. Success Criteria Testability (weight: 0.12)
     - Are `#### Success Criteria` specific and verifiable, using actual file paths and function names?
     - Are `#### Subtasks` actionable, each naming what it changes and where?
     - Does every step include writing its own tests as a subtask?
     - 1=Vague, 2=Partially testable, 3=Adequate, 4=Good, 5=All testable
  
  3. Risk Coverage (weight: 0.10)
     - Does each sub-task file's `#### Blockers & Risks` table name blockers with resolutions and risks with mitigations, rated for Impact and Likelihood?
     - Are they specific to this step rather than a generic checklist restated per file?
     - 1=None, 2=Basic, 3=Adequate, 4=Good, 5=Comprehensive
  
  4. Completeness (weight: 0.15)
     - Does every architecture component and expected change have a corresponding step?
     - Does every row of the Parallelization Overview table have a sub-task file at the recorded path, and every sub-task file a row — no orphans either way?
     - Is the sub-agent execution directive present in `## Implementation Process` — launch one agent per step, parallel steps in parallel, pass the task file path AND the step's sub-task file path, use the step's own Model and Agent, implement exactly that step, and run the code reviewer ONCE per phase at that phase's reviewer model?
     - Is the task file free of the sections listed as out of scope in the Context above?
     - 1=Incomplete, 2=Partial, 3=Adequate, 4=Good, 5=Complete
  
  5. Dependency Accuracy (weight: 0.15)
     - Are `**Depends on:**` values correct — no false dependencies (steps sequenced that need not be), no missing ones (steps that truly need an earlier artifact)?
     - Do the sub-task files, the Parallelization Overview table and the diagram agree on every dependency?
     - Does each step's dependencies resolve to steps in the same or an earlier phase?
     - 1=Major dependency errors, 2=Mostly correct, 3=Acceptable, 4=Accurate, 5=Precise dependencies
  
  6. Parallelization Maximized (weight: 0.10)
     - Are genuinely independent steps marked with `**Parallel with:**` rather than left sequential?
     - Is the ASCII diagram logical and does it show the phase boundaries?
     - Is peak concurrent width within 1–5 (target ~3) rather than unbounded?
     - 1=No parallelization/wrong, 2=Some optimization, 3=Acceptable, 4=Well optimized, 5=Maximum parallelization within the width bound
  
  7. Agent/Model Selection Correctness (weight: 0.08)
     - Are agent types appropriate for what each step OUTPUTS, and drawn only from the provided available agents list?
     - Does each step's `**Model:**` follow the per-step model policy — `opus` earned by a breadth, critical-domain or open-design trigger rather than picked to be safe, `haiku` only for mechanical work?
     - 1=Wrong agents/tiers, 2=Mostly appropriate, 3=Acceptable, 4=Optimal selection, 5=Perfect selection
  
  8. Phase Design (weight: 0.15)
     - Does EACH phase leave an independently verifiable milestone — a working application/service/solution that could be committed and run, PLUS the tests or other verification artifacts that let a reviewer judge it against the criteria listed for that phase?
     - Is EACH phase's `Reviewer model:` appropriate — never below the highest implementation tier used in that phase, and one tier above it unless the phase is small, uniform and mechanical?
     - Are phase sizes sensible — not one step per phase (review churn), not so many steps that a reviewer's findings force rewriting the whole phase? A single phase for the whole task is acceptable ONLY when no earlier point yields a working, verifiable state.
     - Does every checklist item and every rubric criterion in `## Acceptance Criteria` appear against at least one phase, and does each phase list only criteria genuinely due at that checkpoint rather than end-of-task criteria?
     - Is the task file free of threshold values, scores and judge configuration, which belong to the orchestrator?
     - 1=Phases are arbitrary cuts or leave a broken state, 2=Milestones partly hold or reviewer tiers are off, 3=Acceptable, 4=Well-designed milestones with justified reviewer tiers, 5=Every phase a clean, self-contained, correctly reviewed milestone
  

重要：プロンプトは一切変更せず、そのまま使用してください。実装エージェントの出力も含めてください！！！

判定ロジック：

• PASS（スコア >= THRESHOLD）：分解完了、ワークフロー終了 — タスクを昇格します
• FAIL（スコア < THRESHOLD）：エスカレーションルールに基づくティアで、フィードバックを付けてフェーズ 4 を再実行します（反復判断ルールにより承認される場合を除く）
• MAX_ITERATIONS に到達：スコアにかかわらずタスクを昇格します（警告を記録）

---

タスクを昇格する前に、PASS を待ってください。

---

タスクを昇格する

目的： 洗練されたタスクを draft フォルダーから todo フォルダーへ移動します。これは自分で行うファイル移動です。サブエージェント、モデルティア、審査担当は不要です。

すべてのフェーズが完了したら：

1. タスクファイルを draft から todo へ移動します：

   git mv <TASK_FILE> .specs/tasks/todo/
   # Fallback if git not available: mv <TASK_FILE> .specs/tasks/todo/
   

2. .specs/sub-tasks/<task-name>/ は移動しないでください。 サブタスクフォルダーは計画時に作成され、タスクファイルが draft/ → todo/ → in-progress/ → done/ と移動してもそのままの場所に残ります。そのため、Parallelization Overview に記録されたパスが古くなることはありません。

3. 必要に応じて、調査ファイルと分析ファイル内の参照を更新します

---

完了

すべてのフェーズと判定者による処理が完了したら：

1. git ツールを使って、タスクファイル、.specs/sub-tasks/<task-name>/ 内のサブタスクファイル、スキルファイル、分析ファイル、およびスクラッチパッドファイル（作成したもののみ）をステージングします
2. ワークフローの結果をまとめ、ユーザーに出力します：

### Task Refined

| Property | Value |
|----------|-------|
| **Original File** | `<original TASK_FILE path>` |
| **Final Location** | `.specs/tasks/todo/<filename>` (ready for implementation) |
| **Title** | `<task title>` |
| **Type** | `<feature/bug/refactor/test/docs/chore/ci>` (from filename) |
| **Skill** | `<skill file path or "Skipped">` |
| **Skill Action** | `<Created new / Updated existing / Skipped>` |
| **Analysis** | `<analysis file path or "Skipped">` |
| **Scratchpad** | `<scratchpad file path>` |
| **Implementation Steps** | `<count or "N/A">` |
| **Phases** | `<count, each with its reviewer model, or "N/A">` |
| **Max Parallel Width** | `<peak concurrent steps, 1–5, or "N/A">` |
| **Sub-Task Files** | `.specs/sub-tasks/<task-name>/ — <count> files` or `"N/A"` |

### Configuration Used

| Setting | Value |
|---------|-------|
| **Target Quality** | {THRESHOLD}/5.0 |
| **Max Iterations** | {MAX_ITERATIONS} |
| **Active Stages** | {ACTIVE_STAGES as comma-separated list} |
| **Skipped Stages** | {SKIP_STAGES or stages not in ACTIVE_STAGES} |
| **Human Checkpoints** | Phase {HUMAN_IN_THE_LOOP_PHASES as comma-separated} |
| **Skip Judges** | {SKIP_JUDGES} |
| **Refine Mode** | {REFINE_MODE} |
| **Strict Mode** | {STRICT_MODE} |

### Quality Gates Summary

| Phase | Judge Score | Verdict |
|-------|-------------|---------|
| Phase 2a: Research | X.X/5.0 | ✅ PASS / ☑️ ACCEPTED / ⚠️ PROCEEDED (max iter) / ⏭️ SKIPPED |
| Phase 2b: Codebase Analysis | X.X/5.0 | ✅ PASS / ☑️ ACCEPTED / ⚠️ PROCEEDED (max iter) / ⏭️ SKIPPED |
| Phase 2c: Business Analysis | X.X/5.0 | ✅ PASS / ☑️ ACCEPTED / ⚠️ PROCEEDED (max iter) / ⏭️ SKIPPED |
| Phase 3: Architecture Synthesis | X.X/5.0 | ✅ PASS / ☑️ ACCEPTED / ⚠️ PROCEEDED (max iter) / ⏭️ SKIPPED |
| Phase 4: Decomposition | X.X/5.0 | ✅ PASS / ☑️ ACCEPTED / ⚠️ PROCEEDED (max iter) / ⏭️ SKIPPED |

**Threshold Used:** {THRESHOLD}/5.0 (or N/A if SKIP_JUDGES)

**Legend:**
- ✅ PASS - Score >= THRESHOLD
- ☑️ ACCEPTED - Score in `max(3.0, THRESHOLD - 1.0)..THRESHOLD` accepted per the [Iteration Discretion Rule](#iteration-discretion-rule) (outstanding nitpicks listed below the table)
- ⚠️ PROCEEDED (max iter) - Score < THRESHOLD but MAX_ITERATIONS reached, proceeded anyway
- ⏭️ SKIPPED - Stage not in ACTIVE_STAGES

**Outstanding Issues (accepted below THRESHOLD):**

{For each ☑️ ACCEPTED phase: phase, remaining nitpicks with priority — omit this block when no phase was accepted}

### Artifacts Generated

.claude/ └── skills/ └── / └── SKILL.md # 再利用可能なスキル文書（調査ステージを実行した場合）

.specs/ ├── tasks/ │ ├── draft/ # 下書きタスク（ソース。このタスクについては現在空） │ ├── todo/ │ │ └── ..md # 完全なタスク仕様（実装可能な状態） │ ├── in-progress/ # 実装中のタスク（空） │ └── done/ # 完了したタスク（空） ├── sub-tasks/ │ └── / # タスクごとに1つのフォルダー — タスクファイルと一緒に移動することはありません │ ├── 01-.md # 実装ステップごとに1つのサブタスクファイル │ └── 02a-.md ├── analysis/ │ └── analysis-.md # コードベースへの影響分析（コードベース分析ステージを実行した場合） └── scratchpad/ └── .md # アーキテクチャ検討用スクラッチパッド

### Task Status Management

Task status is managed by folder location:
- `draft/` - Tasks created but not yet refined
- `todo/` - Tasks ready for implementation
- `in-progress/` - Tasks currently being worked on
- `done/` - Completed tasks

### Next Steps

1. Review task: `.specs/tasks/todo/<filename>`
   - Edit the task file directly to make corrections
   - Add `//` comments to lines that need clarification or changes
   - Run `/plan` again with `--refine` to incorporate your feedback — it detects changes against git and propagates updates **top-to-bottom** (editing a section only affects sections below it, not above)
2. If everything is fine, begin implementation: `/implement` (will auto-select the task from todo/)

---

エラー処理

フェーズエージェントの失敗（例外／クラッシュ）

フェーズエージェントが予期せず失敗した場合：

1. エージェントの出力とともに失敗を報告します
2. 問題の解決に役立つ確認質問をユーザーに尋ねます
3. 問題を解決するため、質問と回答の一覧を添えてフェーズエージェントを再起動します

判定者が FAIL を返した場合

いずれかの判定者が FAIL（スコア < THRESHOLD）を返した場合：

0. まず反復判断ルールを適用します：score < 3.0（または STRICT_MODE が true）の場合は必ず再試行します。max(3.0, THRESHOLD - 1.0) <= score < THRESHOLD で、残っているのが細かな指摘のみの場合は、再試行する価値があるか慎重に判断します。受け入れる場合は、フェーズを ☑️ ACCEPTED と記録し、残っている細かな指摘を概要に列挙して、手順1～4を実行せず次のフェーズに進みます。そうでない場合は手順1に進みます
1. 自動再試行：エスカレーションルールに従って決定されたティアで、判定者のフィードバックを添えてフェーズエージェントを再起動します。このルールが全面的に適用されます。唯一の保留例外と --model の例外も含まれます。再試行固有の基準は次のとおりです。トリガー (1) は、ここでは score < 3.0（または判定者の指摘から、モデルがフェーズを誤解していると分かる場合）を基準とします。再起動したフェーズと同じティアで再判定します。ティアの決定内容をフェーズの概要に記載します
2. 人間参加の確認：フェーズが HUMAN_IN_THE_LOOP_PHASES に含まれる場合は、次の判定者による再試行の前（実装の再試行後、再判定前）に人間によるチェックポイントを実行します
3. MAX_ITERATIONS 到達後：自動的に次のステージへ進みます（--human-in-the-loop にこのフェーズが含まれている場合を除き、ユーザーに尋ねないでください）
4. 完了サマリーに次の警告を記録します：⚠️ Phase X did not pass quality threshold (X.X/THRESHOLD) after MAX_ITERATIONS iterations

再試行フロー

Implementation → Judge FAIL → Implementation Retry → Judge Retry
                                                          ↓
                              PASS → Continue to next stage
                              FAIL → Repeat until MAX_ITERATIONS
                                          ↓
                              MAX_ITERATIONS reached → Proceed to next stage (with warning)

人間参加型の再試行フロー

フェーズが HUMAN_IN_THE_LOOP_PHASES に含まれる場合：

Implementation → Judge FAIL → Implementation Retry
                                    ↓
                    🔍 Human Checkpoint (optional feedback)
                                    ↓
                              Judge Retry
                                    ↓
                    PASS → Continue | FAIL → Repeat until MAX_ITERATIONS
                                                    ↓
                              MAX_ITERATIONS → 🔍 Final Human Checkpoint
                                                    ↓
                                    User confirms → Proceed to next stage