sdd:implement

検証付きタスクの実装

タスクの仕様とサブエージェントを活用して、最高の品質でソリューションを実装してください。重大な事情がない限り、または作業が完了するまでは、必ず作業を続けてください。重大な事情がない限り、質問は避けてください。実装エージェントを起動し、評価者による検証を行い、問題が解決するまで反復してから次のステップに進んでください。

LLM-as-Judge を使用した自動品質検証を実施しながら、タスクの実装手順を進めてください。

ユーザー入力

$ARGUMENTS

---

コマンド引数

$ARGUMENTS から次の引数を解析してください。

引数の定義

引数	形式	デフォルト	説明
task-file	パスまたはファイル名	自動検出	タスクファイル名またはパス（例：add-validation.feature.md）
--continue	--continue	なし	最後に完了したステップから実装を続けます。まず評価者を起動して状態を検証し、その後、実装エージェントとともに反復します。
--refine	--refine	false	段階的な改良モードです。git と照合して変更を検出し、影響を受けたステップ（変更されたステップ以降）のみを再実装します。
--human-in-the-loop	--human-in-the-loop [step1,step2,...]	なし	指定したステップの後で、人による確認のために一時停止します。ステップを指定しない場合は、各ステップの後で一時停止します。
--target-quality	--target-quality X.X または --target-quality X.X,Y.Y	4.0（標準）／4.5（重要）	目標しきい値（5.0 段階）。単一の値を指定すると、両方に適用されます。カンマ区切りの 2 つの値を指定すると、標準、重要の順に適用されます。
--max-iterations	--max-iterations N	3	ステップごとの修正→検証サイクルの最大回数です。デフォルトは 3 回です。制限なしにするには unlimited を指定します。
--skip-judges	--skip-judges	false	すべての評価者による検証チェックをスキップします。品質ゲートなしで各ステップを進めます。

設定の解決

$ARGUMENTS を解析し、次のように設定を解決してください。

# Extract task file (first positional argument, optional - auto-detect if not provided)
TASK_FILE = first argument that is a file path or filename

# Parse --target-quality (supports single value or two comma-separated values)
if --target-quality has single value X.X:
    THRESHOLD_FOR_STANDARD_COMPONENTS = X.X
    THRESHOLD_FOR_CRITICAL_COMPONENTS = X.X
elif --target-quality has two values X.X,Y.Y:
    THRESHOLD_FOR_STANDARD_COMPONENTS = X.X
    THRESHOLD_FOR_CRITICAL_COMPONENTS = Y.Y
else:
    THRESHOLD_FOR_STANDARD_COMPONENTS = 4.0  # default
    THRESHOLD_FOR_CRITICAL_COMPONENTS = 4.5  # default

# Initialize other defaults
MAX_ITERATIONS = --max-iterations || 3  # default is 3 iterations 
HUMAN_IN_THE_LOOP_STEPS = --human-in-the-loop || [] (empty = none, "*" = all)
SKIP_JUDGES = --skip-judges || false
REFINE_MODE = --refine || false
CONTINUE_MODE = --continue || false

# Special handling for --human-in-the-loop without step list
if --human-in-the-loop present without step numbers:
    HUMAN_IN_THE_LOOP_STEPS = "*" (all steps)

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

--continue を使用する場合：

1. ステップの解決：

   • タスクファイルで、ステップのタイトルにある [DONE] マーカーを解析します。
   • 最後の未完了ステップを特定します。
   • 最後の未完了ステップの成果物を検証するため、評価者を起動します。
   • 評価者が PASS を返した場合：ステップを完了としてマークし、次のステップから再開します。
   • 評価者が FAIL を返した場合：そのステップを再実装し、PASS になるまで反復します。

2. 状態の復元：

   • タスクファイルの場所（in-progress/、todo/、done/）を確認します。
   • todo/ にある場合は、続行する前に in-progress/ に移動します。
   • 既存の成果物から取得済みの値を事前入力します。

リファインモードの動作（--refine）

--refine を使用すると、タスクファイルではなくプロジェクトファイルの変更を検出し、それらを実装ステップに対応付けて、再検証が必要な内容を判断します。

1. 変更されたプロジェクトファイルの検出：

   まず、git の状態に基づいて比較対象を判断します。

   # Check for staged changes
   STAGED=$(git diff --cached --name-only)
   
   # Check for unstaged changes
   UNSTAGED=$(git diff --name-only)
   

   比較ロジック：

   ステージ済み	未ステージ	比較対象	コマンド
   はい	はい	ステージ済み（未ステージの変更のみ）	git diff --name-only
   はい	いいえ	最後のコミット	git diff HEAD --name-only
   いいえ	はい	最後のコミット	git diff HEAD --name-only
   いいえ	いいえ	変更なし	メッセージを表示して終了

   • ステージ済みの変更と未ステージの変更が両方ある場合：作業ディレクトリとステージングエリアを比較します（未ステージの変更のみ）。
   • ステージ済みの変更または未ステージの変更のどちらか一方のみの場合：最後のコミットと比較します。
   • これにより、リファインは進行中の最新の作業を対象にします。

2. 変更を実装ステップに対応付ける：

   • タスクファイルを読み取り、実装ステップの一覧を取得します。
   • 変更された各ファイルについて、どのステップで作成・変更されたかを判断します。
     • ステップの「期待される出力」セクションでファイルパスを確認します。
     • ステップのサブタスクにファイルへの参照がないか確認します。
     • #### Verification セクションでステップの成果物を確認します。
   • 対応付けを作成します：{changed_file → step_number}

3. 影響を受けるステップの特定：

   • 変更されたファイルに関連付けられているすべてのステップを特定します。
   • 最も早い影響対象のステップを開始点とします。
   • そのステップ以降のすべてのステップで再検証が必要です。
   • 影響を受けない前のステップはそのまま維持されます。

4. リファインの実行：

   • 影響を受ける各ステップについて、順番に次の処理を行います。
     • 判定エージェントを起動し、ユーザーの変更も含めてステップの成果物を検証します。
     • 判定が PASS の場合：ステップを完了としてマークし、次に進みます。
     • 判定が FAIL の場合：ユーザーの変更をコンテキストとして実装エージェントを起動し、その後、再検証します。
   • ユーザーによる手動修正は維持されます。実装エージェントはそれを上書きせず、土台として活用します。

5. 例：

   # User manually fixed src/validation/validation.service.ts
   # (This file was created in Step 2)
   
   /implement my-task.feature.md --refine
   
   # Detects: src/validation/validation.service.ts modified
   # Maps to: Step 2 (Create ValidationService)
   # Action: Launch judge for Step 2
   #   - If PASS: User's fix is good, proceed to Step 3
   #   - If FAIL: Implementation agent align rest of the code with user changes, without overwriting user's changes
   # Continues: Step 3, Step 4... (re-verify all subsequent steps)
   

6. 複数のファイルが変更された場合：

   # User edited files from Step 2 AND Step 4
   
   /implement my-task.feature.md --refine
   
   # Detects: Files from Step 2 and Step 4 modified
   # Earliest affected: Step 2
   # Re-verifies: Step 2, Step 3, Step 4, Step 5...
   # (Step 3 re-verified even though no direct changes, because it depends on Step 2)
   

7. ステージ済みの変更と未ステージの変更：

   # Scenario: User staged some changes, then made more edits
   # Staged: src/validation/validation.service.ts (git add done)
   # Unstaged: src/validation/validators/email.validator.ts (still editing)
   
   /implement my-task.feature.md --refine
   
   # Detects: Both staged AND unstaged changes exist
   # Mode: Compares unstaged only (working dir vs staging)
   # Only email.validator.ts is considered for refine
   # Staged changes are preserved, not re-verified
   
   # --
   
   # Scenario: User only has staged changes (ready to commit)
   # Staged: src/validation/validation.service.ts
   # Unstaged: none
   
   /implement my-task.feature.md --refine
   
   # Detects: Only staged changes
   # Mode: Compares against last commit
   # validation.service.ts changes are verified
   

Human-in-the-Loop の動作

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

1. トリガー条件：

   • HUMAN_IN_THE_LOOP_STEPS に含まれるステップで、実装と判定による検証が PASS した後
   • 実装、判定、実装の再試行の後（次の判定再試行の前）
   • HUMAN_IN_THE_LOOP_STEPS が "*" の場合、すべてのステップの後

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

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

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

   ---
   ## 🔍 Human Review Checkpoint - Step X
   
   **Step:** {step title}
   **Step Type:** {standard/critical}
   **Judge Score:** {score}/{threshold for step type} threshold
   **Status:** ✅ PASS / 🔄 ITERATING (attempt {n})
   
   **Artifacts Created/Modified:**
   - {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]:
   ---
   

---

タスクの選択とステータス管理

タスクのステータスフォルダー

タスクのステータスは、フォルダーの場所で管理されます。

• .specs/tasks/todo/ - 実装待ちのタスク
• .specs/tasks/in-progress/ - 現在作業中のタスク
• .specs/tasks/done/ - 完了したタスク

ステータスの遷移

タイミング	アクション
実装開始時	タスクを todo/ から in-progress/ に移動します
最終検証が PASS の場合	タスクを in-progress/ から done/ に移動します
実装失敗（ユーザーが中止）	in-progress/ に残します

---

重要：あなたの役割はオーケストレーターのみです

あなたの役割はディスパッチと集約です。作業自体は行いません。

サブエージェントのコンテキストを適切に構築してください。

重要：各サブエージェント（実装および評価）には、次の情報を渡す必要があります。

• タスクファイルのパス
• ステップ番号
• 項目番号（該当する場合）
• 成果物のパス（該当する場合）
• エージェントが @${CLAUDE_PLUGIN_ROOT}/scripts/create-scratchpad.sh のようなパスを解決できるよう、${CLAUDE_PLUGIN_ROOT} の値

実行すること

• タスクファイルを一度だけ読みます（フェーズ 1 のみ）
• Task ツールを使ってサブエージェントを起動します
• サブエージェントから報告を受け取ります
• ジャッジの確認後にステージを完了済みにします
• 結果を集約してユーザーに報告します

絶対にしないこと

禁止事項	理由	代わりに行うこと
実装結果を読む	コンテキストの肥大化 → コマンドの喪失	作成した内容はサブエージェントに報告させます
参照ファイルを読む	パターンを理解するのはサブエージェントの役割です	サブエージェントへのプロンプトにパスを記載します
成果物を「確認する」ために読む	コンテキストの肥大化 → 検証内容を忘れる	ジャッジエージェントを起動します
自分でコードの品質を評価する	自分の役割ではなく、忘れやすくなります	ジャッジエージェントを起動します
「簡単だから」と検証を省略する	すべての検証が必須です	必ずジャッジエージェントを起動します

合理化を防ぐルール

こう考えたら：「何が作成されたか理解するために、このファイルを読もう」 → STOP。 サブエージェントの報告で作成内容を把握できます。その情報を使ってください。

こう考えたら：「これが正しいか、さっと確認しよう」 → STOP。 ジャッジエージェントを起動してください。それはあなたの役割ではありません。

こう考えたら：「簡単すぎて検証する必要はない」 → STOP。 タスクで検証が指定されているなら、ジャッジを起動してください。例外はありません。

こう考えたら：「適切なプロンプトを書くには、参照ファイルを読む必要がある」 → STOP。 サブエージェントへのプロンプトに参照ファイルのパスを記載してください。参照ファイルはサブエージェントが読みます。

重要な理由

オーケストレーターが自分でファイルを読む ＝ コンテキストの超過 ＝ コマンドの喪失 ＝ 手順の失念。毎回こうなります。

オーケストレーターが「さっと確認」する ＝ ジャッジエージェントを省略 ＝ 品質の崩壊 ＝ 成果物の失敗。

コンテキストウィンドウは貴重です。保護し、すべてを委任してください。

---

重要

設定ルール

• 標準ステップには THRESHOLD_FOR_STANDARD_COMPONENTS（デフォルト 4.0）を使用します。
• タスクファイルでクリティカルと指定されたステップには THRESHOLD_FOR_CRITICAL_COMPONENTS（デフォルト 4.5）を使用します。
• デフォルトは 3 回の反復です — 3 回の修正→検証サイクル後に停止し、警告を添えて次のステップに進みます。
• MAX_ITERATIONS が unlimited に設定されている場合：品質基準を満たすまで反復します（上限なし）。
• 人間参加型チェックポイントは HUMAN_IN_THE_LOOP_STEPS に指定されたステップの後にのみ実施します（"*" の場合はすべてのステップ）。
• SKIP_JUDGES が true の場合：すべてのジャッジによる検証をスキップし、各実装の完了後に直接次のステップへ進みます。
• CONTINUE_MODE が true の場合：RESUME_FROM_STEP までスキップし、すでに完了したステップを再実装しません。
• REFINE_MODE が true の場合：変更されたプロジェクトファイルを検出してステップに対応付け、REFINE_FROM_STEP から再検証します。ユーザーによる修正は保持します。

実行と評価のルール

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

有効な結果が得られるまでジャッジを再起動してください。ただし、次のいずれかが発生した場合は除きます。

• 長すぎる報告は却下：スクラッチパッドを使うよう指示したにもかかわらず、エージェントが非常に長い報告を返した場合は、その結果を却下してください。これは「スクラッチパッドを使う」という指示に従わなかったことを示します。
• ジャッジスコア 5.0 は幻覚：ジャッジが 5.0/5.0 を返した場合は、幻覚または杜撰な評価とみなし、却下してジャッジを再実行してください。この厳格なフレームワークでは、完璧なスコアは事実上あり得ません。
• スコアがない報告は却下：ジャッジの報告に数値スコアがない場合は却下してください。これは、ジャッジがルーブリックの指示を読んでいないか、従っていないことを示します。

---

概要

このコマンドは、複数ステップからなるタスクの実装を次のようにオーケストレーションします。

1. ステップの依存関係を考慮した順次実行
2. 依存関係が許す場合の並列実行
3. ジャッジエージェントを使った、クリティカルなステップの自動検証
4. 重要度の高い成果物に対する LLM パネル（PoLL）
5. 立場によるバイアスを軽減した集約投票
6. 各ジャッジの合格後に確認を行うステージ追跡

---

ワークフローの全体像

Phase 0: Select Task & Move to In-Progress
    │
    ├─── Use provided task file name or auto-select from todo/ (if only 1 task)
    ├─── Move task: todo/ → in-progress/
    │
    ▼
Phase 1: Load Task
    │
    ▼
Phase 2: Execute Steps
    │
    ├─── For each step in dependency order:
    │    │
    │    ▼
    │    ┌─────────────────────────────────────────────────┐
    │    │ Launch sdd:developer agent                          │
    │    │ (implementation)                                │
    │    └─────────────────┬───────────────────────────────┘
    │                      │
    │                      ▼
    │    ┌─────────────────────────────────────────────────┐
    │    │ Launch judge agent(s)                           │
    │    │ (verification per #### Verification section)    │
    │    └─────────────────┬───────────────────────────────┘
    │                      │
    │                      ▼
    │    ┌─────────────────────────────────────────────────┐
    │    │ Judge PASS? → Mark step complete in task file   │
    │    │ Judge FAIL? → Fix and re-verify (max 2 retries) │
    │    └─────────────────────────────────────────────────┘
    │
    ▼
Phase 3: Final Verification
    │
    ├─── Verify all Definition of Done items
    │    │
    │    ▼
    │    ┌─────────────────────────────────────────────────┐
    │    │ Launch judge agent                              │
    │    │ (verify all DoD items)                          │
    │    └─────────────────┬───────────────────────────────┘
    │                      │
    │                      ▼
    │    ┌─────────────────────────────────────────────────┐
    │    │ All PASS? → Proceed to Phase 4                  │
    │    │ Any FAIL? → Fix and re-verify (iterate)         │
    │    └─────────────────────────────────────────────────┘
    │
    ▼
Phase 4: Move Task to Done
    │
    ├─── Move task: in-progress/ → done/
    │
    ▼
Phase 5: Final Report

---

フェーズ 0：ユーザー入力を解析してタスクを選択する

ユーザー入力を解析して、タスクファイルのパスと引数を取得します。

ステップ 0.1：タスクファイルを解決する

$ARGUMENTS が空、またはフラグのみの場合：

1. まず進行中フォルダーを確認します：

   ls .specs/tasks/in-progress/*.md 2>/dev/null
   

   • ファイルがちょうど 1 つの場合 → $TASK_FILE にそのファイルを、$TASK_FOLDER に in-progress を設定します
   • ファイルが複数ある場合 → 一覧表示して、ユーザーに「進行中のタスクが複数あります。どれを続けますか？」と尋ねます
   • ファイルがない場合 → ステップ 2 に進みます

2. todo フォルダーを確認します：

   ls .specs/tasks/todo/*.md 2>/dev/null
   

   • ファイルがちょうど 1 つの場合 → $TASK_FILE にそのファイルを、$TASK_FOLDER に todo を設定します
   • ファイルが複数ある場合 → 一覧表示して、ユーザーに「todo のタスクが複数あります。どれを実装しますか？」と尋ねます
   • ファイルがない場合 → 「利用可能なタスクはありません。まず /add-task で作成してください。」と報告して停止します

$ARGUMENTS にタスクファイル名が含まれる場合：

1. 次の順序でファイルを検索します：in-progress/ → todo/ → done/
2. $TASK_FILE と $TASK_FOLDER を適切に設定します
3. ファイルが見つからない場合は、エラーを報告して停止します

ステップ 0.2：進行中に移動する（必要な場合）

タスクが todo/ フォルダーにある場合：

git mv .specs/tasks/todo/$TASK_FILE .specs/tasks/in-progress/
# Fallback if git not available: mv .specs/tasks/todo/$TASK_FILE .specs/tasks/in-progress/

$TASK_PATH を .specs/tasks/in-progress/$TASK_FILE に更新します

タスクがすでに in-progress/ にある場合： $TASK_PATH を .specs/tasks/in-progress/$TASK_FILE に設定します

ステップ 0.3：フラグを解析して設定を初期化する

$ARGUMENTS のすべてのフラグを解析し、設定を初期化します。 解決した設定を表示します：

### Configuration

| Setting | Value |
|---------|-------|
| **Task File** | {TASK_PATH} |
| **Standard Components Threshold** | {THRESHOLD_FOR_STANDARD_COMPONENTS}/5.0 |
| **Critical Components Threshold** | {THRESHOLD_FOR_CRITICAL_COMPONENTS}/5.0 |
| **Max Iterations** | {MAX_ITERATIONS or "3"} |
| **Human Checkpoints** | {HUMAN_IN_THE_LOOP_STEPS as comma-separated or "All steps" or "None"} |
| **Skip Judges** | {SKIP_JUDGES} |
| **Continue Mode** | {CONTINUE_MODE} |
| **Refine Mode** | {REFINE_MODE} |

ステップ 0.4：続行モードを処理する

CONTINUE_MODE が true の場合：

1. 最後に完了したステップを特定します：

   • タスクファイルを解析し、ステップタイトルにある [DONE] マーカーを確認します
   • [DONE] が付いた最も大きいステップ番号を見つけます
   • LAST_COMPLETED_STEP にその番号を設定します（該当するものがなければ 0）

2. 最後に完了したステップを検証します（該当する場合）：

   • LAST_COMPLETED_STEP > 0 の場合：
     • そのステップの成果物を検証するため、ジャッジエージェントを起動します
     • ジャッジが PASS の場合：RESUME_FROM_STEP = LAST_COMPLETED_STEP + 1 に設定します
     • ジャッジが FAIL の場合：RESUME_FROM_STEP = LAST_COMPLETED_STEP に設定します（再実装）

3. 再開位置に進みます：

   • フェーズ 2 では、RESUME_FROM_STEP より前のすべてのステップをスキップします
   • RESUME_FROM_STEP から実行を続けます

ステップ 0.5：調整モードを処理する

REFINE_MODE が true の場合：

1. 変更されたプロジェクトファイルを検出します：

   # Check for staged and unstaged changes
   STAGED=$(git diff --cached --name-only)
   UNSTAGED=$(git diff --name-only)
   

   比較モードを決定します：

   if STAGED is not empty AND UNSTAGED is not empty:
       # Both staged and unstaged - use unstaged only
       CHANGED_FILES = git diff --name-only  # working dir vs staging
       COMPARISON_MODE = "unstaged_only"
   elif STAGED is not empty OR UNSTAGED is not empty:
       # Only one type - compare against last commit
       CHANGED_FILES = git diff HEAD --name-only
       COMPARISON_MODE = "vs_last_commit"
   else:
       # No changes
       Report: "No project changes detected. Make edits first, then run --refine."
       Exit
   

2. タスクファイルを読み込み、ステップとファイルの対応関係を抽出します：

   • タスクファイルを読み、実装ステップを取得します
   • 各ステップについて、以下から作成または変更するファイルを抽出します：
     • 「Expected Output」セクション
     • ファイルパスに言及しているサブタスクの説明
     • #### Verification の成果物パス
   • 対応関係を構築します：STEP_FILE_MAP = {step_number → [file_paths]}

3. 変更されたファイルをステップに対応付けます：

   AFFECTED_STEPS = []
   for each changed_file:
       for step_number, file_list in STEP_FILE_MAP:
           if changed_file matches any path in file_list:
               AFFECTED_STEPS.append(step_number)
   

   • 該当するステップがない場合：「変更されたファイルはどの実装ステップにも対応していません。手動で検証してください。」

4. 調整範囲を決定します：

   • REFINE_FROM_STEP = min(AFFECTED_STEPS) # 影響を受ける最も早いステップ
   • REFINE_FROM_STEP 以降のすべてのステップを再検証する必要があります
   • REFINE_FROM_STEP より前のステップはそのまま保持します

5. 変更ファイルのコンテキストを保存します：

   • CHANGED_FILES = 変更されたファイルパスの一覧
   • USER_CHANGES_CONTEXT = 影響を受けるファイルの git diff 出力
   • このコンテキストをジャッジエージェントと実装エージェントに渡します
   • エージェントはユーザーの修正を上書きせず、それを踏まえて作業します

フェーズ 1：タスクを読み込んで分析する

ファイルを読み込むのは、このフェーズだけです。

ステップ 1.1：タスクの詳細を読み込む

タスクファイルを 1 回だけ読み込みます：

Read $TASK_PATH

この読み込み後、実行の残りの間、他のファイルを読み込んではいけません。

ステップ 1.2：実装ステップを特定する

## Implementation Process セクションを解析します。

• 依存関係を含むすべてのステップを一覧表示します
• Parallel with: の注記があるステップを特定します
• #### Verification セクションに基づいて、各ステップに必要な検証を分類します。

検証レベル	使用する場合	判定設定
なし	単純な操作（mkdir、delete）	検証をスキップ
単一の判定者	重要度の低い成果物	判定者 1 人、しきい値 4.0/5.0
2 人の判定者によるパネル	重要な成果物	判定者 2 人、中央値による投票、しきい値 4.5/5.0
アイテムごとの判定者	類似するアイテムが複数ある場合	アイテムごとに判定者 1 人、並列実行

ステップ 1.3：Todo リストを作成する

すべての実装ステップを含め、検証要件を明記した TodoWrite を作成します。

{
  "todos": [
    {"content": "Step 1: [Title] - [Verification Level]", "status": "pending", "activeForm": "Implementing Step 1"},
    {"content": "Step 2: [Title] - [Verification Level]", "status": "pending", "activeForm": "Implementing Step 2"}
  ]
}

---

フェーズ 2：実装ステップを実行する

依存関係の順に各ステップを実行します。

パターン A：単純なステップ（検証なし）

1. 開発エージェントを起動する：

Task ツールで以下を指定します。

• エージェントタイプ：sdd:developer
• モデル：ステップで指定されているモデル、または既定の opus
• 説明：「Implement Step [N]: [Title]」
• プロンプト：

Implement Step [N]: [Step Title]

Task File: $TASK_PATH
Step Number: [N]

Your task:
- Execute ONLY Step [N]: [Step Title]
- Do NOT execute any other steps
- Follow the Expected Output and Success Criteria exactly

When complete, report:
1. What files were created/modified (paths)
2. Confirmation that success criteria are met
3. Any issues encountered

2. エージェントの報告を使用する（検証なし）

• エージェントが作成したものを報告します → この情報を使用します
• 作成されたファイルを自分で読まないでください
• このパターンでは検証を行いません（単純な操作）

3. ステップを完了としてマークする

• タスクファイルを更新します。
  • ステップタイトルに [DONE] を付けます（例：### Step 1: Setup [DONE]）
  • ステップのサブタスクを [X] で完了としてマークします
• Todo を completed に更新します

---

パターン B：重要なステップ（2 件の評価パネル）

1. 開発エージェントを起動する：

Task ツールで以下を指定します。

• エージェントタイプ：sdd:developer
• モデル：ステップで指定されているモデル、または既定の opus
• 説明：「Implement Step [N]: [Title]」
• プロンプト：

Implement Step [N]: [Step Title]

Task File: $TASK_PATH
Step Number: [N]

Your task:
- Execute ONLY Step [N]: [Step Title]
- Do NOT execute any other steps
- Follow the Expected Output and Success Criteria exactly

When complete, report:
1. What files were created/modified (paths)
2. Confirmation of completion
3. Self-critique summary

2. 完了を待つ

• エージェントの報告を受け取ります
• 報告に記載された成果物のパスを確認します
• 成果物を自分で読まないでください

3. 2 つの評価エージェントを並列で起動する（必須）：

⚠️ 必須：このパターンでは評価エージェントを起動する必要があります。これらの評価を必ず実行してください。省略しないでください。自分で検証しないでください。

評価には sdd:developer エージェントタイプを使用します

評価 1 と 2（同じプロンプト構成で両方を並列起動します）：

CLAUDE_PLUGIN_ROOT=${CLAUDE_PLUGIN_ROOT}

Read @${CLAUDE_PLUGIN_ROOT}/prompts/judge.md for evaluation methodology.

Evaluate artifact at: [artifact_path from implementation agent report]

**Chain-of-Thought Requirement:** Justification MUST be provided BEFORE score for each criterion.

Rubric:
[paste rubric table from #### Verification section]

Context:
- Read $TASK_PATH
- Verify Step [N] ONLY: [Step Title]
- Threshold: [from #### Verification section]
- Reference pattern: [if specified in #### Verification section]

You can verify the artifact works - run tests, check imports, validate syntax.

Return: scores per criterion with evidence, overall weighted score, PASS/FAIL, improvements if FAIL.

4. 結果を集約する：

• 基準ごとの中央値スコアを計算します
• 分散が大きい基準（std > 1.0）にフラグを付けます
• 全体の中央値がしきい値以上なら合格です

5. しきい値を決定する：

• タスクファイルでステップが重要としてマークされているか確認します（#### Verification セクションまたはステップのメタデータ）
• 重要な場合：THRESHOLD_FOR_CRITICAL_COMPONENTS を使用します
• 標準の場合：THRESHOLD_FOR_STANDARD_COMPONENTS を使用します

6. 不合格の場合：合格するまで繰り返す（既定の最大 3 回）

• 判定者からのフィードバックとともに、問題点を実装エージェントに提示します
• 判定者のフィードバックを取り入れて再実装します（要件に沿ってコードを整え、refine モードではユーザーの変更を保持します）
• 判定者による再検証を行います
• 合格するまで繰り返します - 品質しきい値に達するか最大反復回数に到達するまで、修正 → 検証のサイクルを続けます
• MAX_ITERATIONS に達した場合（既定値は 3）：
  • 警告を記録します：「Step [N] did not pass after {MAX_ITERATIONS} iterations」
  • 次のステップに進みます（無期限に処理を止めないでください）

7. 合格の場合：ステップを完了としてマークする

• タスクファイルを更新します。
  • ステップタイトルに [DONE] を付けます（例：### Step 2: Create Service [DONE]）
  • ステップのサブタスクを [X] で完了としてマークします
• Todo を completed に更新します
• 判定者のスコアを追跡記録に記録します

8. ヒューマン・イン・ザ・ループのチェックポイント（該当する場合）：

ステップが合格した後に限り、ステップ番号が HUMAN_IN_THE_LOOP_STEPS に含まれている場合（または HUMAN_IN_THE_LOOP_STEPS == "*" の場合）：

---
## 🔍 Human Review Checkpoint - Step [N]

**Step:** [Step Title]
**Judge Score:** [score]/[threshold for step type] threshold
**Status:** ✅ PASS

**Artifacts Created/Modified:**
- [artifact_path_1]
- [artifact_path_2]

**Judge Feedback:**
[feedback summary from judges]

**Action Required:** Review the above artifacts and provide feedback or continue.

> Continue? [Y/n/feedback]:
---

• ユーザーからフィードバックがある場合：次のステップ用に保存するか、そのフィードバックを反映して現在のステップを再実装します
• ユーザーが「n」と入力した場合：ワークフローを一時停止し、現在の進捗を報告します
• ユーザーが「Y」と入力した場合、または続行した場合：次のステップに進みます

パターン C：複数項目のステップ（項目ごとの評価）

類似した項目を複数作成するステップの場合：

1. 開発エージェントを項目ごとに並列で起動します：

各項目に対して Task ツールを使用します（すべて並列で起動します）。

• エージェントタイプ：sdd:developer
• モデル：指定されたもの、またはデフォルトで opus
• 説明：「Implement Step [N], Item: [Name]」
• プロンプト：

Implement Step [N], Item: [Item Name]

Task File: $TASK_PATH
Step Number: [N]
Item: [Item Name]

Your task:
- Create ONLY [item_name] from Step [N]
- Do NOT create other items or steps
- Follow the Expected Output and Success Criteria exactly

When complete, report:
1. File path created
2. Confirmation of completion
3. Self-critique summary

2. すべての完了を待ちます

• すべてのエージェントのレポートを収集します
• すべての成果物のパスを記録します
• 作成されたファイルは自分で読まないでください

3. 評価エージェントを項目ごとに並列で起動します

⚠️ 必須：評価エージェントを起動してください。省略しないでください。自分で検証しないでください。

評価には sdd:developer エージェントタイプを使用します。

各項目に対して：

CLAUDE_PLUGIN_ROOT=${CLAUDE_PLUGIN_ROOT}

Read @${CLAUDE_PLUGIN_ROOT}/prompts/judge.md for evaluation methodology.

Evaluate artifact at: [item_path from implementation agent report]

**Chain-of-Thought Requirement:** Justification MUST be provided BEFORE score for each criterion.

Rubric:
[paste rubric from #### Verification section]

Context:
- Read $TASK_PATH
- Verify Step [N]: [Step Title]
- Verify ONLY this Item: [Item Name]
- Threshold: [from #### Verification section]

You can verify the artifact works - run tests, check syntax, confirm dependencies.

Return: scores with evidence, overall score, PASS/FAIL, improvements if FAIL.

4. すべての結果を収集します

5. 集計結果を報告します：

• 合格した項目：X/Y
• 修正が必要な項目：[具体的な問題とともに一覧表示]

6. しきい値を決定します：

• タスクファイル（#### Verification セクションまたはステップのメタデータ）で、そのステップがクリティカルとしてマークされているか確認します
• クリティカルな場合：THRESHOLD_FOR_CRITICAL_COMPONENTS を使用します
• 標準の場合：THRESHOLD_FOR_STANDARD_COMPONENTS を使用します

7. 不合格項目がある場合：すべて合格するまで繰り返します

• 不合格項目と審査エージェントのフィードバックを実装エージェントに提示します
• フィードバックを反映して、不合格項目のみを再実装します（精緻化モードではユーザーの変更を保持します）
• 審査エージェントで不合格項目を再検証します
• すべて合格するまで繰り返します — すべての項目が品質しきい値を満たすか、最大反復回数に達するまで、修正 → 検証のサイクルを続けます
• MAX_ITERATIONS に達した場合（デフォルトは 3）：
  • 警告を記録します：「Step [N] has {X} items that did not pass after {MAX_ITERATIONS} iterations」
  • 次のステップに進みます（無期限に処理を止めないでください）

8. すべて合格したら：ステップを完了としてマークします

• タスクファイルを更新します：
  • ステップのタイトルに [DONE] を付けます（例：### Step 3: Create Items [DONE]）
  • ステップのサブタスクを [X] で完了としてマークします
• todo を completed に更新します
• 追跡用に合格率を記録します

9. 該当する場合は Human-in-the-Loop のチェックポイントを実施します：

すべての項目が合格した後に限り、ステップ番号が HUMAN_IN_THE_LOOP_STEPS に含まれる場合（または HUMAN_IN_THE_LOOP_STEPS == "*" の場合）：

---
## 🔍 Human Review Checkpoint - Step [N]

**Step:** [Step Title]
**Items Passed:** X/Y
**Status:** ✅ ALL PASS

**Artifacts Created:**
- [item_1_path]
- [item_2_path]
- ...

**Action Required:** Review the above artifacts and provide feedback or continue.

> Continue? [Y/n/feedback]:
---

• ユーザーからフィードバックがあった場合：次のステップ用に保存するか、フィードバックを反映して項目を再実装します
• ユーザーが「n」と答えた場合：ワークフローを一時停止し、現在の進捗を報告します
• ユーザーが「Y」と答えた場合、または続行した場合：次のステップに進みます

---

⚠️ チェックポイント：最終検証に進む前に

最終検証に進む前に、ルールに従ったことを確認してください。

• すべての実装に対して sdd:developer エージェントを起動しましたか？
• すべての検証に対して評価エージェントを起動しましたか？
• 審査エージェントの合格後に限り、ステップを完了としてマークしましたか？
• 成果物ファイルを自分で読まずに済ませましたか？

タスクファイル以外のファイルを読んだ場合、手順を誤っています。停止してやり直してください。

---

フェーズ 3：最終検証

すべての実装ステップが完了したら、タスクが「完了の定義」のすべての基準を満たしていることを検証します。

ステップ 3.1：「完了の定義」の検証を開始します

Task ツールを以下の設定で使用します：

• エージェントタイプ：sdd:developer
• モデル：opus
• 説明：「Verify Definition of Done」
• プロンプト：

CLAUDE_PLUGIN_ROOT=${CLAUDE_PLUGIN_ROOT}

Verify all Definition of Done items in the task file.

Task File: $TASK_PATH

Your task:
1. Read the task file and locate the "## Definition of Done (Task Level)" section
2. Go through each checkbox item one by one
3. For each item, verify if it passes by:
   - Running appropriate tests (unit tests, E2E tests)
   - Checking build/compilation status
   - Verifying file existence and correctness
   - Checking code patterns and linting
4. You MUST mark each item in task file that passed verification with `[X]`
5. Return a structured report:
- List ALL Definition of Done items
- Status for each:
   - ✅ PASS - if the item is complete and verified
   - ❌ FAIL - if the item fails verification, with specific reason why
   - ⚠️ BLOCKED - if the item cannot be verified due to a blocker
- Evidence for each status
- Specific issues for any failures
- Overall pass rate

Be thorough - check everything the task requires.

ステップ 3.2：検証結果を確認します

• 検証レポートを受け取ります
• 合格した項目と不合格の項目を確認します
• 審査レポートですべての項目が合格と判定された場合、タスクファイルの末尾を読み、すべての DoD 項目が [X] とマークされていることを必ず確認してください

ステップ 3.3：不合格項目を修正します（該当する場合）

「完了の定義」の項目に不合格がある場合：

1. 不合格項目ごとに開発エージェントを起動します：

Fix Definition of Done item: [Item Description]

Task File: $TASK_PATH

Current Status:
[paste failure details from verification report]

Your task:
1. Fix the specific issue identified
2. Verify the fix resolves the problem
3. Ensure no regressions (all tests still pass)

Return:
- What was fixed
- Confirmation the item now passes
- Any related changes made

2. 修正後に再検証します：

検証エージェントをもう一度起動し（ステップ 3.1）、すべての項目が合格したことを確認します。

3. 必要に応じて繰り返します：

「完了の定義」のすべての項目が合格するまで、修正 → 検証のサイクルを繰り返します。

---

フェーズ 4：タスクを完了フォルダーに移動します

「完了の定義」のすべての項目が合格したら、タスクを完了フォルダーに移動します。

ステップ 4.1：完了を確認します

タスクファイル内で「完了の定義」のすべての項目が完了としてマークされていることを確認します。

ステップ 4.2：タスクを移動します

# Extract just the filename from $TASK_PATH
TASK_FILENAME=$(basename $TASK_PATH)

# Move from in-progress to done
git mv .specs/tasks/in-progress/$TASK_FILENAME .specs/tasks/done/
# Fallback if git not available: mv .specs/tasks/in-progress/$TASK_FILENAME .specs/tasks/done/

---

フェーズ 5：集計とレポート

パネル投票アルゴリズム

2 件以上の評価を使用する場合は、以下の手順に従って手動で計算します。

• 手順を追って考え、各手順の結果を個別に出力してください。
• 手順を省略しないでください。

ステップ 1：基準ごとのスコアを収集する

各基準とすべての評価のスコアを記載した表を作成します。

基準	評価 1	評価 2	中央値	差
[名前 1]	X.X	X.X	?	?
[名前 2]	X.X	X.X	?	?

ステップ 2：各基準の中央値を計算する

評価が 2 件の場合：中央値 =（スコア 1 + スコア 2）/ 2

評価が 3 件以上の場合：スコアを並べ替え、中央の値を取ります（件数が偶数の場合は、中央の 2 つの値の平均を取ります）。

ステップ 3：分散が大きいか確認する

分散が大きい = 評価者の意見が大きく異なる（差が 2.0 点を超える）

式：|Eval1 - Eval2| > 2.0 → 分散が大きいとしてフラグを付ける

ステップ 4：加重総合スコアを計算する

各基準の中央値に重みを掛け、合計します。

Overall = (Criterion1_Median × Weight1) + (Criterion2_Median × Weight2) + ...

ステップ 5：合格／不合格を判定する

総合スコアをしきい値と比較します。

• Overall ≥ Threshold → 合格 ✅
• Overall < Threshold → 不合格 ❌

---

意見の相違への対応

評価に大きな意見の相違がある場合（いずれかの基準で差が 2.0 を超える場合）：

1. 該当する基準にフラグを付けます
2. 両方の評価者の判断理由を提示します
3. ユーザーに「評価者の間で [基準] に関する意見が一致していません。手動で確認しますか？」と尋ねます
4. はいの場合：根拠を提示し、ユーザーの判断を仰ぎます
5. いいえの場合：中央値を使用します（保守的な方法）

最終レポート

すべての手順が完了し、DoD の検証に合格した後：

## Implementation Summary

### Task Status
- Task Status: `done` ✅
- All Definition of Done items: X/X PASS (100%)

### Configuration Used

| Setting | Value |
|---------|-------|
| **Standard Components Threshold** | {THRESHOLD_FOR_STANDARD_COMPONENTS}/5.0 |
| **Critical Components Threshold** | {THRESHOLD_FOR_CRITICAL_COMPONENTS}/5.0 |
| **Max Iterations** | {MAX_ITERATIONS or "3"} |
| **Human Checkpoints** | {HUMAN_IN_THE_LOOP_STEPS or "None"} |
| **Skip Judges** | {SKIP_JUDGES} |
| **Continue Mode** | {CONTINUE_MODE} |
| **Refine Mode** | {REFINE_MODE} |

### Steps Completed

| Step | Title | Status | Verification | Score | Iterations | Judge Confirmed |
|------|-------|--------|--------------|-------|------------|-----------------|
| 1    | [Title] | ✅ | Skipped | N/A | 1 | - |
| 2    | [Title] | ✅ | Panel (2) | 4.5/5 | 1 | ✅ |
| 3    | [Title] | ✅ | Per-Item | 5/5 passed | 2 | ✅ |
| 4    | [Title] | ✅ | Single | 4.2/5 | 3 | ✅ |

**Legend:**
- ✅ PASS - Score >= threshold for step type
- ⚠️ MAX_ITER - Did not pass but MAX_ITERATIONS reached, proceeded anyway
- ⏭️ SKIPPED - Step skipped (continue/refine mode)

### Verification Summary

- Total steps: X
- Steps with verification: Y
- Passed on first try: Z
- Required iteration: W
- Total iterations across all steps: V
- Final pass rate: 100%

### Definition of Done Verification

| Item | Status | Evidence |
|------|--------|----------|
| [DoD Item 1] | ✅ PASS | [Brief evidence] |
| [DoD Item 2] | ✅ PASS | [Brief evidence] |
| ... | ... | ... |

**Issues Fixed During Verification:**
1. [Issue]: [How it was fixed]
2. [Issue]: [How it was fixed]

### High-Variance Criteria (Evaluators Disagreed)

- [Criterion] in [Step]: Eval 1 scored X, Eval 2 scored Y

### Human Review Summary (if --human-in-the-loop used)

| Step | Checkpoint | User Action | Feedback Incorporated |
|------|------------|-------------|----------------------|
| 2    | After PASS | Continued | - |
| 4    | After iteration 2 | Feedback | "Improve error messages" |
| 6    | After PASS | Continued | - |

### Task File Updated

- Task moved from `in-progress/` to `done/` folder
- All step titles marked `[DONE]`
- All step subtasks marked `[X]`
- All Definition of Done items marked `[X]`

### Recommendations

1. [Any follow-up actions]
2. [Suggested improvements]

---

実行フロー図

┌──────────────────────────────────────────────────────────────┐
│                IMPLEMENT TASK WITH VERIFICATION               │
├──────────────────────────────────────────────────────────────┤
│                                                               │
│  Phase 0: Select Task                                         │
│  ┌─────────────────────────────────────────────────────────┐  │
│  │ Use provided name or auto-select from todo/ (if 1 task) │  │
│  │ → Move task from todo/ to in-progress/                  │  │
│  └─────────────────────────────────────────────────────────┘  │
│                           │                                   │
│                           ▼                                   │
│  Phase 1: Load Task                                           │
│  ┌─────────────────────────────────────────────────────────┐  │
│  │ Read $TASK_PATH → Parse steps                           │  │
│  │ → Extract #### Verification specs → Create TodoWrite    │  │
│  └─────────────────────────────────────────────────────────┘  │
│                           │                                   │
│                           ▼                                   │
│  Phase 2: Execute Steps (Respecting Dependencies)             │
│  ┌─────────────────────────────────────────────────────────┐  │
│  │                                                          │  │
│  │  For each step:                                          │  │
│  │                                                          │  │
│  │  ┌──────────────┐    ┌───────────────┐    ┌───────────┐ │  │
│  │  │ developer    │───▶│ Judge Agent   │───▶│ PASS?     │ │  │
│  │  │ Agent        │    │ (verify)      │    │           │ │  │
│  │  └──────────────┘    └───────────────┘    └───────────┘ │  │
│  │                                                │   │     │  │
│  │                                               Yes  No    │  │
│  │                                                │   │     │  │
│  │                                                ▼   ▼     │  │
│  │                                    ┌────────┐  Fix & │   │  │
│  │                                    │ Mark   │  Retry │   │  │
│  │                                    │Complete│  ↺     │   │  │
│  │                                    └────────┘        │   │  │
│  └─────────────────────────────────────────────────────────┘  │
│                           │                                   │
│                           ▼                                   │
│  Phase 3: Final Verification                                  │
│  ┌─────────────────────────────────────────────────────────┐  │
│  │                                                         │  │
│  │  ┌──────────────┐    ┌───────────────┐    ┌───────────┐ │  │
│  │  │ Judge Agent  │───▶│ All DoD       │───▶│ All PASS? │ │  │
│  │  │ (verify DoD) │    │ items checked │    │           │ │  │
│  │  └──────────────┘    └───────────────┘    └───────────┘ │  │
│  │                                                │   │    │  │
│  │                                               Yes  No   │  │
│  │                                                │   │    │  │
│  │                                                ▼   ▼    │  │
│  │                                                Fix &    │  │
│  │                                                Retry    │  │
│  │                                                ↺        │  │
│  │                                                         │  │
│  └─────────────────────────────────────────────────────────┘  │
│                           │                                   │
│                           ▼                                   │
│  Phase 4: Move Task to Done                                   │
│  ┌─────────────────────────────────────────────────────────┐  │
│  │ mv in-progress/$TASK → done/$TASK                       │  │
│  └─────────────────────────────────────────────────────────┘  │
│                           │                                   │
│                           ▼                                   │
│  Phase 5: Aggregate & Report                                  │
│  ┌─────────────────────────────────────────────────────────┐  │
│  │ Collect all verification results                        │  │
│  │ → Calculate aggregate metrics                           │  │
│  │ → Generate final report                                 │  │
│  │ → Present to user                                       │  │
│  └─────────────────────────────────────────────────────────┘  │
│                                                               │
└──────────────────────────────────────────────────────────────┘

---

使用例

基本的な使用方法

# Implement a specific task
/implement add-validation.feature.md

# Auto-select task from todo/ or in-progress/ (if only 1 task)
/implement

# Continue from last completed step
/implement add-validation.feature.md --continue

# Refine after user fixes project files (detects changes, re-verifies affected steps)
/implement add-validation.feature.md --refine

# Human review after every step
/implement add-validation.feature.md --human-in-the-loop

# Human review after specific steps only
/implement add-validation.feature.md --human-in-the-loop 2,4,6

# Higher quality threshold (stricter) - sets both standard and critical to 4.5
/implement add-validation.feature.md --target-quality 4.5

# Different thresholds for standard (3.5) and critical (4.5) components
/implement add-validation.feature.md --target-quality 3.5,4.5

# Lower quality threshold for both (faster convergence)
/implement add-validation.feature.md --target-quality 3.5

# Unlimited iterations (default is 3)
/implement add-validation.feature.md --max-iterations unlimited

# Skip all judge verifications (fast but no quality gates)
/implement add-validation.feature.md --skip-judges

# Combined: continue with human review
/implement add-validation.feature.md --continue --human-in-the-loop

例 1：機能の実装

User: /implement add-validation.feature.md

Phase 0: Task Selection...
Found task in: .specs/tasks/todo/add-validation.feature.md
Moving to in-progress: .specs/tasks/in-progress/add-validation.feature.md

Phase 1: Loading task...
Task: "Add form validation service"
Steps identified: 4 steps

Verification plan (from #### Verification sections):
- Step 1: No verification (directory creation)
- Step 2: Panel of 2 evaluations (ValidationService)
- Step 3: Per-item evaluations (3 validators)
- Step 4: Single evaluation (integration)

Phase 2: Executing...

Step 1: Launching sdd:developer agent...
  Agent: "Implement Step 1: Create Directory Structure..."
  Result: ✅ Directories created
  Verification: Skipped (simple operation)
  Status: ✅ COMPLETE

Step 2: Launching sdd:developer agent...
  Agent: "Implement Step 2: Create ValidationService..."
  Result: Files created, tests passing

  Launching 2 judge agents in parallel...
  Judge 1: 4.3/5.0 - PASS
  Judge 2: 4.5/5.0 - PASS
  Panel Result: 4.4/5.0 ✅
  Status: ✅ COMPLETE (Judge Confirmed)

[Continue for all steps...]

Phase 3: Final Verification...
Launching DoD verification agent...
  Agent: "Verify all Definition of Done items..."
  Result: 4/4 items PASS ✅

Phase 4: Moving task to done...
  mv .specs/tasks/in-progress/add-validation.feature.md .specs/tasks/done/

Phase 5: Final Report
Implementation complete.
- 4/4 steps completed
- 6 artifacts verified
- All passed first try
- Definition of Done: 4/4 PASS
- Task location: .specs/tasks/done/add-validation.feature.md ✅

例 2：DoD 項目の失敗への対応

[All steps complete...]

Phase 3: Final Verification...
Launching DoD verification agent...
  Agent: "Verify all Definition of Done items..."
  Result: 3/4 items PASS, 1 FAIL ❌

Failing item:
- "Code follows ESLint rules": 356 errors found

Should I attempt to fix this issue? [Y/n]

User: Y

Launching sdd:developer agent...
  Agent: "Fix ESLint errors..."
  Result: Fixed 356 errors, 0 warnings ✅

Re-launching DoD verification agent...
  Agent: "Re-verify all Definition of Done items..."
  Result: 4/4 items PASS ✅

Phase 4: Moving task to done...
All DoD checkboxes marked complete ✅

Phase 5: Final Report
Task verification complete.
- All DoD items now PASS
- 1 issue fixed (ESLint errors)
- Task location: .specs/tasks/done/ ✅

例 3：検証失敗への対応

Step 3 Implementation complete.
Launching judge agents...

Judge 1: 3.5/5.0 - FAIL (threshold 4.0)
Judge 2: 3.2/5.0 - FAIL

Issues found:
- Test Coverage: 2.5/5
  Evidence: "Missing edge case tests for empty input"
  Justification: "Success criteria requires edge case coverage"
- Pattern Adherence: 3.0/5
  Evidence: "Uses custom Result type instead of project standard"
  Justification: "Should use existing Result<T, E> from src/types"

Should I attempt to fix these issues? [Y/n]

User: Y

Launching sdd:developer agent with feedback...
Agent: "Fix Step 3: Address judge feedback..."
Result: Issues fixed, tests added

Re-launching judge agents...
Judge 1: 4.2/5.0 - PASS
Judge 2: 4.4/5.0 - PASS
Panel Result: 4.3/5.0 ✅
Status: ✅ COMPLETE (Judge Confirmed)

例 4：中断した箇所から続行する

User: /implement add-validation.feature.md --continue

Phase 0: Parsing flags...
Configuration:
- Continue Mode: true
- Target Quality: 4.0/5.0 (default)

Scanning task file for completed steps...
Found: Step 1 [DONE], Step 2 [DONE]
Last completed: Step 2

Verifying Step 2 artifacts...
Launching judge agent for Step 3...
Judge: 4.3/5.0 - PASS ✅
Marking step as complete in task file...

Resuming from Step 4...

Step 3: Launching sdd:developer agent...
[continues normally from Step 4]

例 5：ユーザーによる修正後の改善

# User manually fixed src/validation/validation.service.ts
# (This file was created in Step 2: Create ValidationService)

User: /implement add-validation.feature.md --refine

Phase 0: Parsing flags...
Configuration:
- Refine Mode: true

Detecting changed project files...
Changed files:
- src/validation/validation.service.ts (modified)

Mapping files to implementation steps...
- src/validation/validation.service.ts → Step 2 (Create ValidationService)

Earliest affected step: Step 2
Preserving: Step 1 (unchanged)
Re-verifying from: Step 2 onwards

Step 2: Launching judge to verify rest of logic with user's changes...
Judge: 4.3/5.0 - PASS ✅
Rest of logic is not affected, proceeding...

Step 3: Launching judge to verify...
Judge: typescript error detected in file
Launching imeplementation agent to fix the error, and align logic with user's changes...

Launching judge to verify fixed logic...
Judge: 4.5/5.0 - PASS ✅

[continues verifying remaining steps...]

All steps verified with user's changes incorporated ✅

例 6：人間参加型レビュー

User: /implement add-validation.feature.md --human-in-the-loop

Configuration:
- Human Checkpoints: All steps

Step 1: Launching sdd:developer agent...
Result: Directories created ✅

---
## 🔍 Human Review Checkpoint - Step 1

**Step:** Create Directory Structure
**Judge Score:** N/A (no verification)
**Status:** ✅ COMPLETE

**Artifacts Created:**
- src/validation/
- src/validation/tests/

**Action Required:** Review the above artifacts and provide feedback or continue.

> Continue? [Y/n/feedback]: Y
---

Step 2: Launching sdd:developer agent...
Result: ValidationService created ✅

Launching judge agents...
Judge 1: 4.5/5.0 - PASS
Judge 2: 4.3/5.0 - PASS
Panel Result: 4.4/5.0 ✅

---
## 🔍 Human Review Checkpoint - Step 2

**Step:** Create ValidationService
**Judge Score:** 4.4/5.0 (threshold: 4.0)
**Status:** ✅ PASS

**Artifacts Created:**
- src/validation/validation.service.ts
- src/validation/tests/validation.service.spec.ts

**Judge Feedback:**
- All criteria met
- Test coverage comprehensive

**Action Required:** Review the above artifacts and provide feedback or continue.

> Continue? [Y/n/feedback]: The error messages could be more descriptive
---

Incorporating feedback: "error messages could be more descriptive"
Re-launching sdd:developer agent with feedback...
[iteration continues]

例 7：厳格な品質しきい値

User: /implement critical-api.feature.md --target-quality 4.5

Configuration:
- Target Quality: 4.5/5.0

Step 2: Implementing critical API endpoint...
Result: Endpoint created

Launching judge agents...
Judge 1: 4.2/5.0 - FAIL (threshold: 4.5)
Judge 2: 4.3/5.0 - FAIL

Iteration 1: Re-implementing with feedback...
[fixes applied]

Launching judge agents...
Judge 1: 4.4/5.0 - FAIL
Judge 2: 4.5/5.0 - PASS

Iteration 2: Re-implementing with feedback...
[more fixes applied]

Launching judge agents...
Judge 1: 4.6/5.0 - PASS
Judge 2: 4.5/5.0 - PASS
Panel Result: 4.55/5.0 ✅

Status: ✅ COMPLETE (passed on iteration 2)

---

エラー処理

実装の失敗

sdd:developer エージェントが失敗を報告した場合：

1. 失敗の詳細をユーザーに提示します
2. 解決に役立つ可能性のある確認質問をします
3. 確認事項を反映して、sdd:developer エージェントを再度起動します

判定者間の意見の相違

判定者の意見が大きく異なる場合（差が 2.0 を超える場合）：

1. 根拠とともに両方の見解を提示します
2. 「判定者の意見が一致していません。どのように判断しますか？」とユーザーに解決を求めます
3. ユーザーの判断に基づいて進めます

改善モード：変更が検出されない

--refine モードでプロジェクト内に Git の変更が見つからない場合：

1. 「前回のコミット以降、プロジェクトファイルの変更は検出されませんでした。」と報告します
2. 「まずプロジェクトファイルを編集してから、もう一度 --refine を実行してください。」と提案します
3. または、「--refine を付けずに実行し、すべての手順を再実装してください。」と提案します

改善モード：変更が手順に対応しない

--refine モードで変更されたファイルが見つかったものの、実装手順に対応するものがない場合：

1. 「変更されたファイルは、どの実装手順の想定出力にも一致しません。」と報告します
2. 検出された変更ファイルを一覧表示します
3. 「手動で確認するか、--refine を付けずに実行してすべての手順を再検証してください。」と提案します

---

チェックリスト

実装を完了する前に：

設定の処理

• $ARGUMENTS からすべてのフラグを正しく解析した
• 標準手順に THRESHOLD_FOR_STANDARD_COMPONENTS を使用した
• 重要な手順に THRESHOLD_FOR_CRITICAL_COMPONENTS を使用した
• 品質しきい値を満たすまで繰り返した（または MAX_ITERATIONS に達した。デフォルトは 3）
• HUMAN_IN_THE_LOOP_STEPS に含まれる手順に対してのみ、人間参加型チェックポイントを実行した
• SKIP_JUDGES が true の場合：すべての判定者による検証をスキップした
• CONTINUE_MODE が true の場合：最後の手順を確認し、正しく再開した
• REFINE_MODE が true の場合：変更されたプロジェクトファイルを検出して手順に対応付け、影響を受ける最も早い手順から再検証した

コンテキストの保護（重大）

• タスクファイル（.specs/tasks/in-progress/ 内の $TASK_PATH）のみを読み取ったこと。他のファイルは読み取っていないこと
• 実装の出力、参照ファイル、成果物を読み取っていないこと
• 状況の確認にはサブエージェントの報告を使用し、確認するためにファイルを読み取っていないこと

委任

• すべての実装を Task ツール経由で sdd:developer エージェントに実施させたこと
• すべての評価を Task ツール経由で sdd:developer エージェントに実施させたこと
• 自分では検証を一切実施していないこと
• 検証手順を省略していないこと（SKIP_JUDGES が true の場合を除く）

ステージの追跡

• 判定者が PASS と判定した後にのみ、各ステップを完了としてマークしたこと（または SKIP_JUDGES の場合は直ちにマークしたこと）
• 各ステップの完了後にタスクファイルを更新したこと：
  • ステップのタイトルに [DONE] を付けたこと
  • サブタスクに [X] を付けたこと
• 各ステップの完了後に ToDo リストを更新したこと

実行の品質

• すべてのステップを依存関係の順序どおりに実行したこと
• 並列ステップを逐次ではなく同時に開始したこと
• 各 sdd:developer エージェントに、対象のステップを明記した焦点の絞られたプロンプトを渡したこと
• すべての重要な成果物を判定者が評価したこと（SKIP_JUDGES の場合を除く）
• 重大性の高い成果物では、パネルによる投票を使用したこと
• すべての評価プロンプトに思考過程の提示要件を含めたこと
• 品質基準を満たすまで、評価に失敗した成果物の修正を繰り返したこと
• 判定者の確認状況を記載した最終報告書を作成したこと
• 評価者間で意見の相違があった場合、その旨をユーザーに伝えたこと

Human-in-the-Loop（有効な場合）

• HUMAN_IN_THE_LOOP_STEPS の各ステップ後にチェックポイントを表示したこと
• その後の反復やステップにユーザーのフィードバックを反映したこと
• ユーザーからの要求に応じてワークフローを一時停止したこと

最終検証と完了

• Definition of Done の検証エージェントを起動したこと
• すべての DoD 項目を検証し、PASS／FAIL／BLOCKED のステータスを付けたこと
• FAIL の DoD 項目を sdd:developer エージェント経由で修正したこと
• 修正後に再検証を実施したこと
• タスクを in-progress/ フォルダーから done/ フォルダーに移動したこと
• タスクファイル内のすべての DoD チェックボックスに [X] を付けたこと
• 最終検証レポートをユーザーに提示したこと

---

付録 A：検証仕様のリファレンス

この付録では、タスクファイル内で検証をどのように指定するかを説明します。フェーズ 2（ステップの実行）では、これらの仕様を参照して各成果物の検証方法を確認します。

タスクファイルでの検証要件の定義方法

タスクファイルでは、各実装ステップ内の #### Verification セクションで検証要件を定義します。これらのセクションには、次の内容を指定します。

必須項目

1. レベル：検証の複雑さ

   • None - 単純な操作（mkdir、delete）- 検証を省略
   • Single Judge - 重大ではない成果物 - 判定者 1 名、しきい値 4.0/5.0
   • Panel of 2 Judges - 重要な成果物 - 判定者 2 名、中央値による投票、しきい値 4.0/5.0 または 4.5/5.0
   • Per-Item Judges - 類似項目が複数ある場合 - 項目ごとに判定者 1 名、並列実行

2. 成果物：検証対象のファイルパス

   • 例：src/decision/decision.service.ts、src/decision/tests/decision.service.spec.ts

3. しきい値：合格に必要な最低スコア

   • 標準的な品質では通常 4.0/5.0
   • 重要なコンポーネントでは 4.5/5.0 の場合もあります

4. 評価基準：重み付き基準の表（以下の形式を参照）

5. 参照パターン（任意）：適切な実装例へのパス

   • 例：NestJS のサービスパターンを参照する src/app.service.ts

評価基準の形式

タスクファイルの評価基準には、次の Markdown テーブル形式を使用します。

| Criterion | Weight | Description |
|-----------|--------|-------------|
| [Name 1]  | 0.XX   | [What to evaluate] |
| [Name 2]  | 0.XX   | [What to evaluate] |
| ...       | ...    | ...         |

要件：

• 重みの合計は必ず 1.0 にすること
• 各基準には明確で測定可能な説明を付けること
• 評価基準ごとに通常 3～6 項目を含めること

例：

| Criterion | Weight | Description |
|-----------|--------|-------------|
| Type Correctness | 0.35 | Types match specification exactly |
| API Contract Alignment | 0.25 | Aligns with documented API contract |
| Export Structure | 0.20 | Barrel exports correctly expose all types |
| Code Quality | 0.20 | Follows project TypeScript conventions |

評価スケール

評価者が成果物を評価する際は、各評価基準について次の5段階スケールを使用します。

• 1（不十分）：要件を満たしていません

  • 必須要素が欠けています
  • 要件を根本的に誤解しています

• 2（平均以下）：複数の問題があり、要件を部分的にしか満たしていません

  • 正しい要素もありますが、大きな不足があります
  • 大幅なやり直しが必要です

• 3（適切）：基本的な要件を満たしています

  • 機能しますが、最小限の実装です
  • 品質や完全性を改善する余地があります

• 4（良好）：すべての要件を満たしており、軽微な問題が少しあります

  • 堅実な実装です
  • 少し手を加えることで、さらに洗練できます

• 5（優秀）：要件を超えています

  • 例外的に高品質です
  • 求められた内容を超えています
  • 参考実装として活用できます

実行中の検証仕様の使用

フェーズ2（ステップの実行）中：

1. sdd:developer エージェントが実装を完了した後
2. タスクファイルのステップにある #### Verification セクションを読みます
3. Level、Artifact paths、Threshold、Rubric、Reference Pattern を抽出します
4. Level に基づいて、適切な評価エージェントを起動します
5. 評価者に次の情報を提供します：Artifact path、Rubric、Threshold、Reference Pattern
6. 評価者の結果を集計し、PASS／FAIL を判定します
7. FAIL の場合は、sdd:developer エージェントを起動して問題を修正し、再検証します

タスクファイル内の検証セクションの例：

#### Verification

**Level:** Panel of 2 Judges with Aggregated Voting
**Artifact:** `src/decision/decision.service.ts`, `src/decision/tests/decision.service.spec.ts`

**Rubric:**

| Criterion | Weight | Description |
|-----------|--------|-------------|
| Routing Logic | 0.20 | Correctly routes by customerType |
| Drip Feed Implementation | 0.25 | 2% random approval for rejected New customers only |
| Response Formatting | 0.20 | Correct decision outcome, triggeredRules preserved, ISO 8601 timestamp |
| Testability | 0.15 | Injectable randomGenerator enables deterministic testing |
| Test Coverage | 0.20 | Unit tests cover approval, rejection, drip feed, routing, timestamp |

**Reference Pattern:** NestJS service patterns, ZenEngineService API

この仕様では、次のことが指示されています。

• 評価エージェントを2つ並行して起動する
• サービスファイルとテストファイルの両方を評価させる
• 指定された重みを使用した5つの評価基準によるルーブリックを使う
• 閾値は評価者に渡さず、評価者の平均スコアとの比較にのみ使用する
• 比較のために既存の NestJS パターンを参照する