sdd:plan

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

役割

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

目標

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

1. 並列分析 - 調査、コードベース分析、ビジネス分析を並行して実施します
2. アーキテクチャの統合 - 調査結果を統合してアーキテクチャの概要を作成します
3. 分解 - リスクを踏まえながら実装手順に分解します
4. 並列化 - 最大限に並列実行できるよう手順を再編成します
5. 検証 - LLM-as-Judge による検証セクションを追加します
6. 昇格 - 改善したタスクを 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	N/A	--target-quality 3.0 --max-iterations 1 --included-stages business analysis,decomposition,verifications のエイリアスです
--one-shot	--one-shot	N/A	--included-stages business analysis,decomposition --skip-judges のエイリアスです。品質ゲートを設けず、最小限の改善を行います。
--human-in-the-loop	--human-in-the-loop phase1,phase2,...	なし	人による検証のため一時停止するフェーズを指定します。
--skip-judges	--skip-judges	false	すべてのジャッジ検証をスキップします。フェーズは品質ゲートなしで進行します。
--refine	--refine	false	差分改善モードです。Git の変更を検出し、影響を受けるステージだけを再実行します（上から下へ伝播）。

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

ステージ名	フェーズ	説明
research	2a	関連するリソース、ドキュメント、ライブラリを収集します
codebase analysis	2b	影響を受けるファイル、インターフェース、統合ポイントを特定します
business analysis	2c	説明を改善し、受け入れ基準を作成します
architecture synthesis	3	調査と分析の結果を統合してアーキテクチャを作成します
decomposition	4	リスクを踏まえながら実装手順に分解します
parallelize	5	並列実行できるよう手順を再編成します
verifications	6	LLM-as-Judge による検証ルーブリックを追加します

設定の解決

$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", "verifications"]

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", "parallelize", "verifications"]
SKIP_STAGES = --skip || []
HUMAN_IN_THE_LOOP_PHASES = --human-in-the-loop || []
SKIP_JUDGES = --skip-judges || false
REFINE_MODE = --refine || false
CONTINUE_STAGE = null

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 を使用すると、次のように動作します。

1. 変更の検出：

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

2. 上から下への反映：

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

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

   変更されたセクション	再実行するステージ
   説明 / 受け入れ基準	business analysis（Phase 2c）
   アーキテクチャ概要	architecture synthesis（Phase 3）
   実装プロセス / 手順	decomposition（Phase 4）
   並列化 / 依存関係	parallelize（Phase 5）
   検証セクション	verifications（Phase 6）

4. リファインの実行：

   • 明示的に要求されない限り、調査（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, parallelize, verifications
   

Human-in-the-Loop の動作

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

1. トリガー条件：

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

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

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

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

   ---
   ## 🔍 Human Review Checkpoint - Phase X
   
   **Phase:** {phase name}
   **Judge Score:** {score}/{THRESHOLD} threshold
   **Status:** ✅ PASS / ⚠️ 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,5,6

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

事前確認

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

1. タスクファイルの存在を確認します：

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

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} |
   | **Continue From** | {CONTINUE_STAGE} or "Start" |
   

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> を実行して、最終コミットとの差分（ステージ済み＋未ステージ）をすべて取得します
   • 差分を解析して、変更されたセクションを特定します
   • // コメントマーカーをユーザーからのフィードバックとして収集します
   • Section-to-Stage Mapping を使って、最も早い変更セクションを特定します
   • 決定した開始地点以降のステージのみを含むよう ACTIVE_STAGES を設定します
   • 検出された変更とユーザーコメントを、追加のコンテキストとしてエージェントに渡します
   • 変更が検出されなかった場合は、ユーザーに「タスクファイルに変更が検出されませんでした。まずファイルを編集してから、--refine を実行してください。」と伝えて終了します

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

   • タスクファイルを読み取り、ファイル名からタイトルとタイプを抽出します
   • frontmatter を解析して、title と 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 implementation steps", "status": "pending", "activeForm": "Decomposing into steps"},
       {"content": "Judge 4: PASS decomposition (> {THRESHOLD})", "status": "pending", "activeForm": "Validating decomposition"},
       {"content": "Phase 5: Parallelize implementation steps", "status": "pending", "activeForm": "Parallelizing steps"},
       {"content": "Judge 5: PASS parallelization (> {THRESHOLD})", "status": "pending", "activeForm": "Validating parallelization"},
       {"content": "Phase 6: Define verification rubrics", "status": "pending", "activeForm": "Defining verifications"},
       {"content": "Judge 6: PASS verifications (> {THRESHOLD})", "status": "pending", "activeForm": "Validating verifications"},
       {"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、5、6）を省略します
   • 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 を省略します
   • parallelize が ACTIVE_STAGES に含まれない場合、Phase 5 と Judge 5 の todo を省略します
   • verifications が ACTIVE_STAGES に含まれない場合、Phase 6 と Judge 6 の 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/scratchpad/ - 一時作業ファイル（gitignore 対象）
   • .specs/analysis/ - コードベースの影響分析ファイル
   • .claude/skills/ - 再利用可能なスキルドキュメント

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

重大な注意事項

• ルーブリックに合格していない判定者に PASS を付けないでください。チェックに合格するまで、実装を変更するたびに判定を再実行してください！
• .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 で変更を検出し、変更のないステージをスキップして、ユーザーからのフィードバックをエージェントに渡してください！

実行と評価のルール

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

次のいずれかが発生するまで、有効な結果が得られるまで判定を再実行してください。

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

ワークフローの実行

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

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

1. ステップで指定された Agent タイプと Model を使用する
2. タスクファイルのパスとユーザー入力をコンテキストとして提供する
3. エージェントが @${CLAUDE_PLUGIN_ROOT}/scripts/create-scratchpad.sh のようなパスを解決できるよう、${CLAUDE_PLUGIN_ROOT} の値を提供する
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 sonnet]   [sdd:code-explorer sonnet]  [sdd:business-analyst opus]
Judge 2a              Judge 2b              Judge 2c
(pass: >THRESHOLD)     (pass: >THRESHOLD)     (pass: >THRESHOLD)
    │                     │                     │
    └─────────────────────┴─────────────────────┘
                          │
                          ▼
                    Phase 3: Architecture Synthesis
                    [sdd:software-architect opus]
                    Judge 3 (pass: >THRESHOLD)
                          │
                          ▼
                    Phase 4: Decomposition
                    [sdd:tech-lead opus]
                    Judge 4 (pass: >THRESHOLD)
                          │
                          ▼
                    Phase 5: Parallelize
                    [sdd:team-lead opus]
                    Judge 5 (pass: >THRESHOLD)
                          │
                          ▼
                    Phase 6: Verifications
                    [sdd:qa-engineer opus]
                    Judge 6 (pass: >THRESHOLD)
                          │
                          ▼
                    Move task: draft/ → todo/
                          │
                          ▼
                    Complete

---

フェーズ 2：並列分析

フェーズ 2 では、それぞれに独自の判定検証がある 3 つの分析フェーズを並行して開始します。

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

次の 3 つのフェーズを、直ちに並行して開始します。

---

フェーズ 2a：調査

モデル： sonnet エージェント： 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）
• 収集したリソースの数
• 推奨事項の要約

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

---

Phase 2b：コードベースへの影響分析

モデル： sonnet エージェント： 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）
• 影響を受けるファイルの数（変更／作成／削除）
• リスクレベルの評価
• 主な統合ポイント

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

---

Phase 2c：ビジネス分析

モデル： opus エージェント： sdd:business-analyst 依存関係： タスクファイルが存在すること 目的： 説明を改善し、受け入れ基準を作成します

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

• 説明：「ビジネス分析」

• プロンプト：

  CLAUDE_PLUGIN_ROOT=${CLAUDE_PLUGIN_ROOT}
  
  Read ${CLAUDE_PLUGIN_ROOT}/skills/plan/analyse-business-requirements.md and execute it exactly as is!
  
  Task File: <TASK_FILE>
  Task Title: <title from task file>
  
  CRITICAL: DO NOT OUTPUT YOUR BUSINESS ANALYSIS, ONLY CREATE THE SCRATCHPAD AND UPDATE THE TASK FILE.
  

記録する項目：

• スクラッチパッドファイルのパス（例：.specs/scratchpad/<hex-id>.md）
• 受け入れ基準の数
• スコープが定義されているか（はい／いいえ）
• 文書化されたユーザーシナリオ

---

Judge 2a/2b/2c：並列フェーズを検証する

各並列フェーズの完了後、同じエージェントタイプとモデルで対応するジャッジを起動します。

Judge 2a：調査／スキルを検証する

モデル： sonnet エージェント： sdd:researcher 依存関係： Phase 2a の完了 目的： スキルの完全性と関連性を検証します

ジャッジを起動します：

• 説明：「スキルの品質を判定」

• プロンプト：

  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
  

重要：プロンプトはそのまま正確に使用し、ほかには何も追加しないでください。実装エージェントの出力も含めないでください！！！

判定ロジック：

• PASS（スコア >= THRESHOLD）：調査完了。次に進みます
• FAIL（スコア < THRESHOLD）：フィードバックを付けて Phase 2a を再起動します
• MAX_ITERATIONS に到達：スコアにかかわらず次のステージに進みます（警告を記録）

---

Judge 2b：コードベース分析を検証する

モデル： sonnet エージェント： sdd:code-explorer 依存関係： Phase 2b の完了 目的： ファイル特定の正確性と統合マッピングを検証します

ジャッジを起動します：

• 説明：「コードベース分析の品質を判定」

• プロンプト：

  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
  

重要：プロンプトはそのまま正確に使用し、ほかには何も追加しないでください。実装エージェントの出力も含めないでください！！！

判定ロジック：

• PASS（スコア >= THRESHOLD）：分析完了。次に進みます
• FAIL（スコア < THRESHOLD）：フィードバックを付けて Phase 2b を再起動します
• MAX_ITERATIONS に到達：スコアにかかわらず次のステージに進みます（警告を記録）

---

Judge 2c：ビジネス分析を検証する

モデル： opus エージェント： sdd:business-analyst 依存関係： Phase 2c の完了 目的： 受け入れ基準の品質とスコープの定義を検証します

ジャッジを起動します：

• 説明：「ビジネス分析の品質を判定」

• プロンプト：

  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. Evaluate description clarity and acceptance criteria quality.
  
  ### Rubric
  1. Description Clarity (weight: 0.30)
     - What/Why clearly explained?
     - Scope boundaries defined?
     - 1=Vague, 2=Basic, 3=Adequate, 4=Clear, 5=Excellent
  
  2. Acceptance Criteria Quality (weight: 0.35)
     - Criteria specific and testable?
     - Given/When/Then format for complex criteria?
     - 1=Missing/vague, 2=Basic, 3=Adequate, 4=Good, 5=Excellent
  
  3. Scenario Coverage (weight: 0.20)
     - Primary flow documented?
     - Error scenarios considered?
     - 1=Missing, 2=Basic, 3=Adequate, 4=Good, 5=Comprehensive
  
  4. Scope Definition (weight: 0.15)
     - In-scope/out-of-scope explicit?
     - No implementation details in description?
     - 1=Missing, 2=Partial, 3=Adequate, 4=Good, 5=Clear
  

重要：プロンプトはそのまま正確に使用し、ほかには何も追加しないでください。実装エージェントの出力も含めないでください！！！

判定ロジック：

• PASS（スコア >= THRESHOLD）：ビジネス分析完了。次に進みます
• FAIL（スコア < THRESHOLD）：フィードバックを付けて Phase 2c を再起動します
• MAX_ITERATIONS に到達：スコアにかかわらず次のステージに進みます（警告を記録）

---

同期ポイント

Phase 3 に進む前に、3 つすべての並列フェーズ（2a、2b、2c）と、それぞれのジャッジが PASS になるまで待機してください。

---

Phase 3：アーキテクチャの統合

モデル： opus エージェント： sdd:software-architect 依存関係： Phase 2a + Judge 2a が PASS、Phase 2b + Judge 2b が PASS、Phase 2c + Judge 2c が PASS 目的： 調査、分析、ビジネス要件を統合して、アーキテクチャの概要を作成します

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

• 説明：「アーキテクチャの統合」

• プロンプト：

  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: アーキテクチャ合成の検証

モデル: opus エージェント: sdd:software-architect 依存先: フェーズ 3 の完了 目的: アーキテクチャの一貫性と完全性を検証する

ジャッジを起動します:

• 説明: "アーキテクチャ合成の品質をジャッジする"

• プロンプト:

  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
  
  

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

判定ロジック:

• PASS (スコア >= THRESHOLD): アーキテクチャ合成が完了、続行
• FAIL (スコア < THRESHOLD): フィードバックを付けてフェーズ 3 を再起動
• MAX_ITERATIONS に到達: スコアに関係なくフェーズ 4 へ進む (警告をログに記録)

フェーズ 4 の前に PASS を待機します。

---

フェーズ 4: 分解

モデル: opus エージェント: sdd:tech-lead 依存先: フェーズ 3 + ジャッジ 3 の PASS 目的: アーキテクチャを、成功基準とリスクを伴う実装ステップに分解する

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

• 説明: "実装ステップに分解する"

• プロンプト:

  CLAUDE_PLUGIN_ROOT=${CLAUDE_PLUGIN_ROOT}
  
  Task File: <TASK_FILE>
  
  CRITICAL: DO NOT OUTPUT YOUR DECOMPOSITION, ONLY CREATE THE SCRATCHPAD AND UPDATE THE TASK FILE.
  

取得:

• スクラッチパッドのファイルパス (例: .specs/scratchpad/<hex-id>.md)
• 実装ステップ数
• サブタスクの総数
• クリティカルパスのステップ
• 優先度の高いリスクの数

---

ジャッジ 4: 分解の検証

モデル: opus エージェント: 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}
  
  ### Context
  This is decomposition output. The Implementation Process section should contain
  ordered steps with success criteria, subtasks, blockers, and risks.
  
  ### Rubric
  1. Step Quality (weight: 0.30)
     - Each step has clear goal, output, success criteria?
     - Steps ordered by dependency?
     - No step too large (>Large estimate)?
     - 1=Vague/missing, 2=Basic, 3=Adequate, 4=Good, 5=Excellent
  
  2. Success Criteria Testability (weight: 0.25)
     - Criteria specific and verifiable?
     - Use actual file paths, function names?
     - Subtasks clearly defined with actionable descriptions?
     - 1=Vague, 2=Partially testable, 3=Adequate, 4=Good, 5=All testable
  
  3. Risk Coverage (weight: 0.25)
     - Blockers identified with resolutions?
     - Risks identified with mitigations?
     - High-risk tasks identified with decomposition recommendations?
     - 1=None, 2=Basic, 3=Adequate, 4=Good, 5=Comprehensive
  
  4. Completeness (weight: 0.20)
     - All architecture components have corresponding steps?
     - Implementation summary table present?
     - Definition of Done included?
     - Phases organized: Setup → Foundational → User Stories → Polish?
     - 1=Incomplete, 2=Partial, 3=Adequate, 4=Good, 5=Complete
  

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

判定ロジック:

• PASS (スコア >= THRESHOLD): 分解が完了、フェーズ 5 へ進む
• FAIL (スコア < THRESHOLD): フィードバックを付けてフェーズ 4 を再起動
• MAX_ITERATIONS に到達: スコアに関係なくフェーズ 5 へ進む (警告をログに記録)

フェーズ 5 の前に PASS を待機します。

---

フェーズ 5: ステップの並列化

モデル: opus エージェント: sdd:team-lead 依存先: フェーズ 4 + ジャッジ 4 の 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, code-review:bug-hunter. Also include general agents: opus, sonnet, haiku}
  
  CRITICAL: DO NOT OUTPUT YOUR PARALLELIZATION, ONLY CREATE THE SCRATCHPAD AND UPDATE THE TASK FILE.
  

取得:

• スクラッチパッドのファイルパス (例: .specs/scratchpad/<hex-id>.md)
• 再編成されたステップ数
• 最大並列化深度
• エージェント配分の概要

---

ジャッジ 5: 並列化の検証

モデル: opus エージェント: sdd:team-lead 依存先: フェーズ 5 の完了 目的: 依存関係の正確性と並列化の最適化を検証する

ジャッジを起動します:

• 説明: "並列化の品質をジャッジする"

• プロンプト:

  CLAUDE_PLUGIN_ROOT=${CLAUDE_PLUGIN_ROOT}
  
  Read @${CLAUDE_PLUGIN_ROOT}/prompts/judge.md for evaluation methodology and execute.
  
  ### Artifact Path
  {path to parallelized task file from Phase 5}
  
  ### Context
  This is the output of Phase 5: Parallelize Steps. The artifact should contain implementation steps
  reorganized for maximum parallel execution with explicit dependencies, agent assignments, and
  parallelization diagram.
  
  Use agents only from this list: {list ALL available agents with plugin prefix if available, e.g. sdd:developer, code-review:bug-hunter. Also include general agents: opus, sonnet, haiku}
  
  ### Rubric
  1. Dependency Accuracy (weight: 0.35)
     - Are step dependencies correctly identified?
     - No false dependencies (steps marked dependent when they're not)?
     - No missing dependencies (steps that actually depend on others)?
     - 1=Major dependency errors, 2=Mostly correct, 3=Acceptable, 5=Precise dependencies
  
  2. Parallelization Maximized (weight: 0.30)
     - Are parallelizable steps correctly marked with "Parallel with:"?
     - Is the parallelization diagram logical?
     - 1=No parallelization/wrong, 2=Some optimization, 3=Acceptable, 5=Maximum parallelization
  
  3. Agent Selection Correctness (weight: 0.20)
     - Are agent types appropriate for outputs (opus by default, haiku for trivial, sonnet for simple but high in volume)?
     - Does selection follow the Agent Selection Guide?
     - Are only agents from the provided available agents list used?
     - 1=Wrong agents, 2=Mostly appropriate, 3=Acceptable, 4=Optimal selection, 5=Perfect selection
  
  4. Execution Directive Present (weight: 0.15)
     - Is the sub-agent execution directive present?
     - Are "MUST" requirements for parallel execution clear?
     - 1=Missing directive, 2=Partial, 3=Acceptable, 4=Complete directive, 5=Perfect directive
  

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

判定ロジック:

• PASS (スコア >= THRESHOLD): フェーズ 6 へ進む
• FAIL (スコア < THRESHOLD): フィードバックを付けてフェーズ 5 を再起動
• MAX_ITERATIONS に到達: スコアに関係なくフェーズ 6 へ進む (警告をログに記録)

フェーズ 6 の前に PASS を待機します。

---

フェーズ 6: 検証の定義

モデル: opus エージェント: sdd:qa-engineer 依存先: フェーズ 5 + ジャッジ 5 の PASS 目的: ルーブリックを伴う LLM-as-Judge 検証セクションを追加する

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

• 説明: "検証ルーブリックを定義する"

• プロンプト:

  CLAUDE_PLUGIN_ROOT=${CLAUDE_PLUGIN_ROOT}
  
  Task File: <TASK_FILE>
  
  CRITICAL: DO NOT OUTPUT YOUR VERIFICATIONS, ONLY CREATE THE SCRATCHPAD AND UPDATE THE TASK FILE.
  

取得:

• スクラッチパッドのファイルパス (例: .specs/scratchpad/<hex-id>.md)
• 検証を伴うステップ数
• 定義された評価の総数
• 検証の内訳 (パネル/項目単位/なし)

---

判定者 6：検証内容の妥当性確認

モデル： opus エージェント： sdd:qa-engineer 依存関係： Phase 6 の完了 目的： 検証基準としきい値の妥当性を確認します

判定者を起動します：

• 説明：「検証品質の判定」

• プロンプト：

  CLAUDE_PLUGIN_ROOT=${CLAUDE_PLUGIN_ROOT}
  
  Read @${CLAUDE_PLUGIN_ROOT}/prompts/judge.md for evaluation methodology and execute.
  
  ### Artifact Path
  {path to task file with verifications from Phase 6}
  
  ### Context
  This is the output of Phase 6: Define Verifications. The artifact should contain LLM-as-Judge
  verification sections for each implementation step, including verification levels, custom rubrics,
  thresholds, and a verification summary table.
  
  ### Rubric
  1. Verification Level Appropriateness (weight: 0.30)
     - Do verification levels match artifact criticality?
     - HIGH criticality → Panel, MEDIUM → Single/Per-Item, LOW/NONE → None?
     - 1=Mismatched levels, 2=Mostly appropriate, 3=Acceptable, 5=Precisely calibrated
  
  2. Rubric Quality (weight: 0.30)
     - Are criteria specific to the artifact type (not generic)?
     - Do weights sum to 1.0?
     - Are descriptions clear and measurable?
     - 1=Generic/broken rubrics, 2=Adequate, 3=Acceptable, 5=Excellent custom rubrics
  
  3. Threshold Appropriateness (weight: 0.20)
     - Are thresholds reasonable (typically 4.0/5.0)?
     - Higher for critical, lower for experimental?
     - 1=Wrong thresholds, 2=Standard applied, 3=Acceptable, 5=Context-appropriate
  
  4. Coverage Completeness (weight: 0.20)
     - Does every step have a Verification section?
     - Is the Verification Summary table present?
     - 1=Missing verifications, 2=Most covered, 3=Acceptable, 5=100% coverage
  

重要：プロンプトはそのまま使用し、ほかには何も追加しないでください。実装エージェントの出力も含めないでください。

判定ロジック：

• PASS（スコア >= THRESHOLD）：ワークフローを完了し、タスクを昇格させます
• FAIL（スコア < THRESHOLD）：フィードバックを添えて Phase 6 を再起動します
• MAX_ITERATIONS に到達：スコアにかかわらずワークフローを完了します（警告を記録）

---

Phase 7：タスクの昇格

目的： 改良したタスクを draft フォルダーから todo フォルダーに移動します

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

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

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

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

---

完了

実行したすべてのフェーズと判定者が完了した後：

1. git ツールを使用して、タスクファイル、スキルファイル、分析ファイル、スクラッチパッドファイル（作成されたもののみ）をステージングします
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">` |
| **Parallelization Depth** | `<max parallel agents or "N/A">` |
| **Total Verifications** | `<count 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} |

### Quality Gates Summary

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

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

**Legend:**
- ✅ PASS - Score >= THRESHOLD
- ⚠️ PROCEEDED (max iter) - Score < THRESHOLD but MAX_ITERATIONS reached, proceeded anyway
- ⏭️ SKIPPED - Stage not in ACTIVE_STAGES

### Artifacts Generated

.claude/ └── skills/ └── / └── SKILL.md # 再利用可能なスキルドキュメント（調査ステージが実行された場合） .specs/ ├── tasks/ │ ├── draft/ # タスクの下書き（元の場所。このタスクは現在空） │ ├── todo/ │ │ └── ..md # 完成したタスク仕様（実装可能な状態） │ ├── in-progress/ # 実装中のタスク（空） │ └── done/ # 完了したタスク（空） ├── 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）を返した場合：

1. 自動再試行：判定者のフィードバックを添えてフェーズエージェントを再起動します
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