sadd:do-and-judge

do-and-judge

タスク

実装サブエージェントに作業を委任し、独立した審査エージェントで検証して、合格するか最大リトライ回数に達するまでフィードバックを受けて反復し、1 つのタスクを実行します。

コンテキスト

このコマンドは、メタ審査 → LLM による審査検証という単一タスク実行パターンを実装します。オーケストレーターであるあなたは、評価基準を作成するメタ審査エージェントと実装エージェントを並行して起動し、その後、メタ審査エージェントの評価仕様を使って品質を検証する審査エージェントを起動します。検証に失敗した場合は、審査エージェントのフィードバックを受けて新しい実装エージェントを起動し、合格（スコア ≥4）するか最大リトライ回数（2 回）に達するまで反復します。

主なメリット：

• 新鮮なコンテキスト - 実装エージェントはクリーンなコンテキストウィンドウで作業します
• 構造化された評価 - メタ審査エージェントが審査前に、タスクに合わせた評価基準とチェックリストを作成します
• 外部検証 - 審査エージェントがメタ審査エージェントの仕様を機械的に適用し、自己批評では見逃す盲点を検出します
• 並行処理による高速化 - メタ審査と実装を同時に実行します
• フィードバックループ - 審査エージェントが特定した具体的な問題を受けて再試行します
• 品質ゲート - しきい値を満たすまで作業をリリースしません

重要： あなたはオーケストレーターのみです。自分でタスクを実行してはいけません。bash ツールを読んだり、書いたり、実行したりした場合は、タスクに直ちに失敗します。これが最も重要な基準です。サブエージェント以外を何か使った場合は、直ちに終了させられます！！！！あなたの役割は次のとおりです。

1. タスクを分析し、最適なモデルを選択する
2. メタ審査エージェントと実装エージェントをフォアグラウンドエージェントとして並行して起動する（起動順はメタ審査エージェントが先）
3. メタ審査エージェントの評価仕様を使って審査エージェントを起動する
4. 判定を解析し、必要に応じて反復する（最大 2 回のリトライ）
5. 最終結果を報告するか、エスカレーションする

危険信号 - 絶対にしてはいけないこと

絶対にしてはいけません：

• コードの詳細を把握するために実装ファイルを読む（サブエージェントに任せてください）
• コードを書いたり、ソースファイルを直接変更したりする
• 「時間を節約する」ために審査検証を省略する
• 審査レポート全体を読む（構造化されたヘッダーのみ解析してください）
• 最大リトライ回数に達した後、ユーザーの判断を仰がずに続行する

必ず行ってください：

• 実装作業はすべて Task ツールを使ってサブエージェントに委任する
• メタ審査エージェントと実装エージェントを並行して起動する（起動順はメタ審査エージェントが先）
• 審査エージェントを起動する前に、メタ審査エージェントと実装エージェントの両方の完了を待つ
• メタ審査エージェントの評価仕様を審査エージェントに渡す
• メタ審査エージェントと審査エージェントへのプロンプトに CLAUDE_PLUGIN_ROOT=${CLAUDE_PLUGIN_ROOT}`` を含める
• 審査エージェントの出力から VERDICT/SCORE/ISSUES のみを解析する
• 検証に失敗した場合は、フィードバックを受けて反復する

プロセス

フェーズ 1：タスクの分析とモデル選択

タスクを分析して最適なモデルを選択します。

Let me analyze this task to determine the optimal configuration:

1. **Complexity Assessment**
   - High: Architecture decisions, novel problem-solving, critical logic
   - Medium: Standard patterns, moderate refactoring, API updates
   - Low: Simple transformations, straightforward updates

2. **Risk Assessment**
   - High: Breaking changes, security-sensitive, data integrity
   - Medium: Internal changes, reversible modifications
   - Low: Non-critical utilities, isolated changes

3. **Scope Assessment**
   - Large: Multiple files, complex interactions
   - Medium: Single component, focused changes
   - Small: Minor modifications, single file

モデル選択ガイド：

モデル	使用する場合	例
opus	デフォルト／標準の選択肢です。どのタスクにも安全に使えます。正確さが重要な場合、判断に微妙なニュアンスが求められる場合、または迷った場合に使用します。	ほとんどの実装、コード作成、ビジネスロジック、アーキテクチャ上の判断
sonnet	複雑ではないものの作業量が多いタスク向けです。同様の手順が多く、処理するコンテキストが大きい、または作業が反復的な場合に使用します。	ファイルの一括更新、類似項目の大量処理、明確なパターンに沿った大規模なリファクタリング
haiku	単純な操作のみに使用します。判断を伴わない、簡単で機械的なタスク向けです。	ディレクトリの作成、ファイルの削除、簡単な設定編集、ファイルのコピー／移動

専門エージェント： sdd プラグインに含まれる一般的なエージェントには、sdd:developer、sdd:researcher、sdd:software-architect、sdd:tech-lead、sdd:qa-engineer があります。適切な専門エージェントが利用できない場合は、専門化されていない汎用エージェントを使用してください。タスクと専門エージェントに直接の関連がない場合、またはエージェントを利用できない場合は、必ず汎用エージェントを使用してください！

フェーズ 2：メタジャッジと実装エージェントをディスパッチする（並列）

重要：2 つの Task ツール呼び出しを同じメッセージ内で実行し、両方のエージェントを起動してください。メタジャッジが実装エージェントによる変更前の成果物を確認できるよう、メッセージ内ではメタジャッジを最初のツール呼び出しにしてください。

両方のエージェントをフォアグラウンドで実行します。フェーズ 3 に進む前に、両方の完了を待ってください。

2.1 メタジャッジへのプロンプト

メタジャッジは、この特定のタスクに合わせた評価仕様（ルーブリック、チェックリスト、採点基準）を生成します。評価仕様の YAML が返されます。

## Task

Generate an evaluation specification yaml for the following task. You will produce rubrics, checklists, and scoring criteria that a judge agent will use to evaluate the implementation artifact.

CLAUDE_PLUGIN_ROOT=`${CLAUDE_PLUGIN_ROOT}`

## User Prompt
{Original task description from user}

## Context
{Any relevant codebase context, file paths, constraints}

## Artifact Type
{code | documentation | configuration | etc.}

## Instructions
Return only the final evaluation specification YAML in your response.

Use Task tool:
  - description: "Meta-judge: {brief task summary}"
  - prompt: {meta-judge prompt}
  - model: opus
  - subagent_type: "sadd:meta-judge"

2.2 実装エージェントへのプロンプト

以下の必須要素を含む実装プロンプトを作成してください。

ゼロショットの思考連鎖プレフィックス（必須 — 必ず最初に記載）

## Reasoning Approach

Before taking any action, think through this task systematically.

Let's approach this step by step:

1. "Let me understand what this task requires..."
   - What is the specific objective?
   - What constraints exist?
   - What is the expected outcome?

2. "Let me explore the relevant code..."
   - What files are involved?
   - What patterns exist in the codebase?
   - What dependencies need consideration?

3. "Let me plan my approach..."
   - What specific modifications are needed?
   - What order should I make them?
   - What could go wrong?

4. "Let me verify my approach before implementing..."
   - Does my plan achieve the objective?
   - Am I following existing patterns?
   - Is there a simpler way?

Work through each step explicitly before implementing.

タスク本文

## Task
{Task description from user}

## Constraints
- Follow existing code patterns and conventions
- Make minimal changes to achieve the objective
- Do not introduce new dependencies without justification
- Ensure changes are testable

## Output
Provide your implementation along with a "Summary" section containing:
- Files modified (full paths)
- Key changes (3-5 bullet points)
- Any decisions made and rationale
- Potential concerns or follow-up needed

自己批評サフィックス（必須 — 必ず最後に記載）

## Self-Critique Verification (MANDATORY)

Before completing, verify your work. Do not submit unverified changes.

### Verification Questions

| # | Question | Evidence Required |
|---|----------|-------------------|
| 1 | Does my solution address ALL requirements? | [Specific evidence] |
| 2 | Did I follow existing code patterns? | [Pattern examples] |
| 3 | Are there any edge cases I missed? | [Edge case analysis] |
| 4 | Is my solution the simplest approach? | [Alternatives considered] |
| 5 | Would this pass code review? | [Quality check] |

### Answer Each Question with Evidence

Examine your solution and provide specific evidence for each question.

### Revise If Needed

If ANY verification question reveals a gap:
1. **FIX** - Address the specific gap identified
2. **RE-VERIFY** - Confirm the fix resolves the issue
3. **UPDATE** - Update the Summary section

CRITICAL: Do not submit until ALL verification questions have satisfactory answers.

ディスパッチ

タスクと利用可能なエージェントに基づき、最適なエージェントタイプを決定してください。たとえば、コード実装には sdd:developer エージェントを使用します。確信が持てない場合は、誤ったエージェントタイプをディスパッチするよりも general-purpose エージェントを使用してください。

Use Task tool:
  - description: "Implement: {brief task summary}"
  - prompt: {constructed prompt with CoT + task + self-critique}
  - model: {selected model}
  - subagent_type: "{selected agent type}"

2.3 並列ディスパッチの例

2 つの Task ツール呼び出しを同じメッセージ内で実行してください。メタジャッジを先に、実装エージェントを後にします。

Message with 2 tool calls:
  Tool call 1 (meta-judge):
    - description: "Meta-judge: {brief task summary}"
    - model: opus
    - subagent_type: "sadd:meta-judge"

  Tool call 2 (implementation):
    - description: "Implement: {brief task summary}"
    - model: {selected model}
    - subagent_type: "{selected agent type}"

フェーズ 3 に進む前に、両方の結果が返るまで待ってください。

フェーズ 3：ジャッジエージェントをディスパッチする

メタジャッジと実装エージェントの両方が完了した後、ジャッジエージェントをディスパッチしてください。

重要：メタジャッジの評価仕様 YAML をそのままジャッジに渡してください。省略や追加をせず、内容を一切変更せず、文章を短縮したり要約したりしないでください。

メタジャッジの出力から抽出するもの：

• 最終的な評価仕様 YAML

実装エージェントの出力から抽出するもの：

• 概要セクション（変更したファイル、主な変更点）
• 変更したファイルのパス

3.1 既存の変更セクションを分析する

ジャッジをディスパッチする前に、ジャッジに知らせる必要があるコードベース内の既存の変更があるかどうかを確認してください。「既存の変更」セクションにより、ジャッジが以前の変更を現在の実装エージェントの作業と取り違えるのを防ぎます。

含める場合：

• 同じセッション内で以前の「実行して判定」タスクが完了している
• スキルを実行する前にユーザーが手動で変更している（会話の文脈または git で確認できる）
• このタスクより前に実行された他のツールやエージェントによる変更

省略する場合：

• 既知の変更がない最初のタスクの場合は、このセクションを完全に省略する
• 同じタスク内で再試行する場合、実装エージェントが以前に行った試行を「既存の変更」として含めないでください。これらは現在のタスクの反復サイクルの一部です

内容に関するガイドライン：

• 概要レベルで記述します。タスクの説明、影響を受けるファイル／モジュールの一覧、変更の大まかな内容（作成、変更、削除）を含めます
• コードブロック、差分、行単位の詳細は含めず、簡潔にまとめます
• 出所を明確に示します。「以前のタスク：{説明}」、「ユーザーによる変更（現在のタスク開始前）」など
• 既存の変更の出所が複数ある場合は、それぞれ別の小見出しを使用します

重要：コードベース全体や git 履歴を読み込まないでください。概要レベルの git diff／status、または会話の文脈を使って、変更されたファイルを確認してください。

3.2 プロンプトと仕様 YAML を添えてジャッジを起動する

ジャッジプロンプトのテンプレート：

You are evaluating an implementation artifact against an evaluation specification produced by the meta judge.

CLAUDE_PLUGIN_ROOT=`${CLAUDE_PLUGIN_ROOT}`

## User Prompt
{Original task description from user}

{IF pre-existing changes are known, include the following section — otherwise omit entirely}

## Pre-existing Changes (Context Only)

The following changes were made BEFORE the current implementation agent started working. They are NOT part of the current task's output. Focus your evaluation on the current task's changes. Only verify pre-existing changed files/logic if they directly relate to the current task requirements.

### {Source of changes: e.g., "Previous Task: {task description}" or "User modifications (before current task)"}
{High-level summary: what was done, which files/modules were created or modified}

{END conditional section}

## Evaluation Specification

```yaml
{meta-judge's evaluation specification YAML}

実装エージェントの出力

{実装エージェントの概要セクション} {変更したファイルのパス}

指示

エージェントの指示で定義されているジャッジの全プロセスに従ってください。

出力

重要：回答の冒頭に、以下の構造化された評価レポートを YAML 形式で正確に出力してください。

CRITICAL: NEVER provide score threshold, in any format, including `threshold_pass` or anything different. Judge MUST not know what thershold for score is, in order to not be biased!!!

**Dispatch:**

Task ツールを使用：

• description: "ジャッジ：{タスクの簡潔な概要}"
• prompt: {メタジャッジの仕様 YAML をそのまま含め、該当する場合は既存の変更セクションも含めたジャッジ検証プロンプト}
• model: opus
• subagent_type: "sadd:judge"

フェーズ 4：判定結果を解析して反復する

判定結果を解析します（レポート全文は読まないでください）。

Extract from judge reply:
- VERDICT: PASS or FAIL
- SCORE: X.X/5.0
- ISSUES: List of problems (if any)
- IMPROVEMENTS: List of suggestions (if any)

判定ロジック：

If score ≥4:
  → VERDICT: PASS
  → Report success with summary
  → Include IMPROVEMENTS as optional enhancements

IF score ≥ 3.0 and all found issues are low priority, then:
  → VERDICT: PASS
  → Report success with summary
  → Include IMPROVEMENTS as optional enhancements

If score <4:
  → VERDICT: FAIL
  → Check retry count

  If retries < 3:
    → Dispatch retry implementation agent with judge feedback
    → Return to Phase 3 (judge verification with same meta-judge specification)

  If retries ≥ 3:
    → Escalate to user (see Error Handling)
    → Do NOT proceed without user decision

フェーズ 5：フィードバックを反映して再試行する（必要な場合）

再試行プロンプトのテンプレート：

## Retry Required

Your previous implementation did not pass judge verification.

## Original Task
{Original task description}

## Judge Feedback
VERDICT: FAIL
SCORE: {score}/5.0
ISSUES:
{list of issues from judge}

## Your Previous Changes
{files modified in previous attempt}

## Instructions
Let's fix the identified issues step by step.

1. Review each issue the judge identified
2. For each issue, determine the root cause
3. Plan the fix for each issue
4. Implement ALL fixes
5. Verify your fixes address each issue
6. Provide updated Summary section

CRITICAL: Focus on fixing the specific issues identified. Do not rewrite everything.

フェーズ 6：最終レポート

タスクが検証に合格したら、次のようにします。

## Execution Summary

**Task:** {original task description}
**Result:** ✅ PASS

### Verification
| Attempt | Score | Status |
|---------|-------|--------|
| 1 | {X.X}/5.0 | {PASS/FAIL} |
| 2 | {X.X}/5.0 | {PASS/FAIL} | (if retry occurred)

### Files Modified
- {file1}: {what changed}
- {file2}: {what changed}

### Key Changes
- {change 1}
- {change 2}

### Suggested Improvements (Optional)
{IMPROVEMENTS from judge, if any}

エラー処理

最大再試行回数を超えた場合

タスクが検証に2回失敗した場合：

1. 停止 - 先に進まないでください
2. 報告 - 次の内容を含む失敗分析を提示します。
   • 元のタスク要件
   • すべての判定結果とスコア
   • 再試行を通じて解消されなかった問題
3. エスカレーション - ユーザーに次の選択肢を提示します。
   • 再試行のために追加のコンテキストやガイダンスを提供する
   • タスク要件を変更する
   • タスクを中止する
4. 待機 - ユーザーの判断なしに先へ進まないでください

エスカレーションレポートの形式：

## Task Failed Verification (Max Retries Exceeded)

### Task Requirements
{original task description}

### Verification History
| Attempt | Score | Key Issues |
|---------|-------|------------|
| 1 | {X.X}/5.0 | {issues} |
| 2 | {X.X}/5.0 | {issues} |
| 3 | {X.X}/5.0 | {issues} |

### Persistent Issues
{Issues that appeared in multiple attempts}

### Options
1. **Provide guidance** - Give additional context for another retry
2. **Modify requirements** - Simplify or clarify task
3. **Abort** - Stop execution

Awaiting your decision...

例

例 1：ドキュメントの更新（初回で合格）

入力：

/do-and-judge Rewrite the API authentication section in docs/api-reference.md to cover the new OAuth2 flow

実行：

Phase 1: Task Analysis
  - Complexity: Medium (rewriting existing documentation with new technical flow)
  - Risk: Low (documentation only, no code changes)
  - Scope: Small (single file, focused section)
  → Model: opus
  → Agent type: general-purpose
    Reasoning: This is a documentation task — writing and restructuring
    prose, not implementing code. The sdd:developer agent is optimized
    for code implementation patterns, not technical writing. A
    general-purpose agent handles documentation tasks more effectively
    because it applies broader writing and reasoning skills without
    code-centric constraints.

Phase 2: Parallel Dispatch (single message, 2 tool calls)
  Tool call 1 — Meta-judge (Opus)...
    Meta-judge prompt sent:
    ┌─────────────────────────────────────────────────────────
    │ ## Task
    │ Generate an evaluation specification yaml for the
    │ following task. You will produce rubrics, checklists,
    │ and scoring criteria that a judge agent will use to
    │ evaluate the implementation artifact.
    │
    │ CLAUDE_PLUGIN_ROOT=...
    │
    │ ## User Prompt
    │ Rewrite the API authentication section in
    │ docs/api-reference.md to cover the new OAuth2 flow
    │
    │ ## Context
    │ Existing docs/api-reference.md contains an outdated
    │ "Authentication" section describing API key auth.
    │ The codebase recently migrated to OAuth2 with PKCE.
    │ Related source: src/auth/oauth2.ts, src/auth/config.ts.
    │
    │ ## Artifact Type
    │ documentation
    │
    │ ## Instructions
    │ Return only the final evaluation specification YAML
    │ in your response.
    └─────────────────────────────────────────────────────────
    → Generated evaluation specification YAML
    → 3 rubric dimensions (accuracy, completeness, clarity)
    → 5 checklist items

  Tool call 2 — Implementation (general-purpose + Opus)...
    Implementation prompt sent (abbreviated):
    ┌─────────────────────────────────────────────────────────
    │ ## Reasoning Approach
    │ Before taking any action, think through this task
    │ systematically.
    │ [... step-by-step reasoning template ...]
    │
    │ ## Task
    │ Rewrite the API authentication section in
    │ docs/api-reference.md to cover the new OAuth2 flow.
    │ Replace the outdated API key auth documentation with
    │ OAuth2 + PKCE flow documentation including token
    │ endpoints, scopes, refresh token handling, and
    │ example requests.
    │
    │ ## Constraints
    │ - Follow existing documentation patterns and conventions
    │ - Make minimal changes to achieve the objective
    │ - Do not introduce new dependencies without justification
    │ - Ensure changes are testable
    │
    │ ## Output
    │ Provide your implementation along with a "Summary"
    │ section containing:
    │ - Files modified (full paths)
    │ - Key changes (3-5 bullet points)
    │ - Any decisions made and rationale
    │ - Potential concerns or follow-up needed
    │
    │ ## Self-Critique Verification (MANDATORY)
    │ [... verification questions and revision process ...]
    └─────────────────────────────────────────────────────────
    → Rewrote Authentication section in docs/api-reference.md
    → Added OAuth2 flow diagram, token endpoints, scopes table
    → Added code examples for authorization and token refresh
    → Summary: 1 file modified, authentication section rewritten

Phase 3: Dispatch Judge (with meta-judge specification)
  NOTE: No pre-existing changes — first task on a clean codebase.
  The "Pre-existing Changes" section is OMITTED from the judge prompt.

  Judge prompt sent:
  ┌─────────────────────────────────────────────────────────
  │ You are evaluating an implementation artifact against
  │ an evaluation specification produced by the meta judge.
  │
  │ CLAUDE_PLUGIN_ROOT=...
  │
  │ ## User Prompt
  │ Rewrite the API authentication section in
  │ docs/api-reference.md to cover the new OAuth2 flow
  │
  │ ## Evaluation Specification
  │ ```yaml
  │ {meta-judge's evaluation specification YAML}
  │ ```
  │
  │ ## Implementation Output
  │ Files: docs/api-reference.md (modified)
  │ Key changes: Replaced API key auth section with OAuth2
  │ + PKCE flow, added token endpoints, scopes table,
  │ and code examples for authorization and refresh...
  │
  │ ## Instructions
  │ Follow your full judge process...
  └─────────────────────────────────────────────────────────

  Judge (sadd:judge + Opus)...
    → VERDICT: PASS, SCORE: 4.2/5.0
    → ISSUES: None
    → IMPROVEMENTS: Add error response examples for expired tokens

Phase 4: Parse Verdict
  → Score 4.2 ≥ 4.0 threshold → PASS
  → No retry needed (Phase 5 skipped)

Phase 6: Final Report
  ✅ PASS on attempt 1
  Files: docs/api-reference.md (modified)

例 2：複雑なタスク（再試行後に合格）

入力：

/do-and-judge Implement rate limiting middleware with configurable limits per endpoint

実行：

Phase 1: Task Analysis
  - Complexity: High (new feature, multiple concerns)
  - Risk: High (affects all endpoints)
  - Scope: Medium (single middleware)
  → Model: opus

Phase 2: Parallel Dispatch (Attempt 1)
  Tool call 1 — Meta-judge (Opus)...
    → Generated evaluation specification YAML
    → 4 rubric dimensions, 8 checklist items
  Tool call 2 — Implementation (sdd:developer + Opus)...
    → Created RateLimiter middleware
    → Added configuration schema

Phase 3: Dispatch Judge (with meta-judge specification)
  Judge (sadd:judge + Opus)...
    → VERDICT: FAIL, SCORE: 3.1/5.0
    → ISSUES:
      - Missing per-endpoint configuration
      - No Redis support for distributed deployments
    → IMPROVEMENTS: Add monitoring hooks

Phase 5: Retry with Feedback
  Implementation (sadd:meta-judge + Opus)...
    → Added endpoint-specific limits
    → Added Redis adapter option

Phase 3: Dispatch Judge (Attempt 2, same meta-judge specification)
  Judge (sadd:judge + Opus)...
    → VERDICT: PASS, SCORE: 4.4/5.0
    → IMPROVEMENTS: Add metrics export

Phase 6: Final Report
  ✅ PASS on attempt 2
  Files: RateLimiter.ts, config/rateLimits.ts, adapters/RedisAdapter.ts

例 3：エスカレーションが必要なタスク

入力：

/do-and-judge Migrate the database schema to support multi-tenancy

実行：

Phase 1: Task Analysis
  - Complexity: High
  - Risk: High (database schema change)
  → Model: opus

Phase 2: Parallel Dispatch
  Meta-judge → evaluation specification YAML
  Implementation → initial migration scaffolding

Attempt 1: FAIL (2.8/5.0) - Missing tenant isolation in queries
Attempt 2: FAIL (3.2/5.0) - Incomplete migration script
Attempt 3: FAIL (3.3/5.0) - Edge cases in existing data migration

ESCALATION:
  Persistent issue: Existing data migration requires business decisions
  about how to handle orphaned records.

  Options presented to user:
  1. Provide guidance on orphan handling
  2. Simplify to new tenants only
  3. Abort

User chose: Option 1 - "Delete orphaned records older than 1 year"

Attempt 4 (with guidance): PASS (4.1/5.0)

例 4：do-and-judge の連続実行（前のタスクからの既存の変更がある場合）

入力（1 回目の実行）：

/do-and-judge add basic authentication module

実行（1 回目）：

Phase 1: Task Analysis
  - Complexity: High (new feature, security-sensitive)
  - Risk: High (authentication is critical)
  - Scope: Medium (new module)
  → Model: opus
  - Pre-existing Changes: None

Phase 2: Parallel Dispatch (Attempt 1)
  Tool call 1 — Meta-judge (Opus)...
    Meta-judge prompt sent:
    ┌─────────────────────────────────────────────────────────
    │ ## Task
    │ Generate an evaluation specification yaml for the
    │ following task. You will produce rubrics, checklists,
    │ and scoring criteria that a judge agent will use to
    │ evaluate the implementation artifact.
    │
    │ CLAUDE_PLUGIN_ROOT=...
    │
    │ ## User Prompt
    │ Add basic authentication module
    │
    │ ## Context
    │ Express.js backend, src/auth/ directory does not exist
    │ yet. Existing middleware pattern in src/middleware/.
    │
    │ ## Artifact Type
    │ code
    │
    │ ## Instructions
    │ Return only the final evaluation specification YAML
    │ in your response.
    └─────────────────────────────────────────────────────────
    → Generated evaluation specification YAML
    → 4 rubric dimensions, 7 checklist items

  Tool call 2 — Implementation (sdd:developer + Opus)...
    Implementation prompt sent (abbreviated):
    ┌─────────────────────────────────────────────────────────
    │ ## Reasoning Approach
    │ Before taking any action, think through this task
    │ systematically.
    │ [... step-by-step reasoning template ...]
    │
    │ ## Task
    │ Add basic authentication module to the Express.js
    │ backend. Create login, logout, and register endpoints
    │ with proper middleware for route protection.
    │
    │ ## Constraints
    │ - Follow existing code patterns and conventions
    │ - Make minimal changes to achieve the objective
    │ - Do not introduce new dependencies without
    │   justification
    │ - Ensure changes are testable
    │
    │ ## Output
    │ Provide your implementation along with a "Summary"
    │ section containing:
    │ - Files modified (full paths)
    │ - Key changes (3-5 bullet points)
    │ - Any decisions made and rationale
    │ - Potential concerns or follow-up needed
    │
    │ ## Self-Critique Verification (MANDATORY)
    │ [... verification questions and revision process ...]
    └─────────────────────────────────────────────────────────
    → Created src/auth/AuthService.ts
    → Created src/auth/AuthMiddleware.ts
    → Created src/auth/auth.routes.ts
    → Modified src/app.ts
    → Summary: 4 files changed, auth module added

Phase 3: Dispatch Judge (with meta-judge specification)
  NOTE: No pre-existing changes — this is the first task on a clean codebase.
  The "Pre-existing Changes" section is OMITTED from the judge prompt.

  Judge prompt sent:
  ┌─────────────────────────────────────────────────────────
  │ You are evaluating an implementation artifact against
  │ an evaluation specification produced by the meta judge.
  │
  │ CLAUDE_PLUGIN_ROOT=...
  │
  │ ## User Prompt
  │ Add basic authentication module
  │
  │ ## Evaluation Specification
  │ ```yaml
  │ {meta-judge's evaluation specification YAML}
  │ ```
  │
  │ ## Implementation Output
  │ Files: src/auth/AuthService.ts (new), ...
  │ Key changes: Added login/logout/register endpoints...
  │
  │ ## Instructions
  │ Follow your full judge process...
  └─────────────────────────────────────────────────────────

  Judge (sadd:judge + Opus)...
    → VERDICT: FAIL, SCORE: 3.0/5.0
    → ISSUES:
      - Missing password hashing (plain-text storage)
      - No unit tests for AuthService
    → IMPROVEMENTS: Add rate limiting on login endpoint

Phase 5: Retry with Feedback (Attempt 2)
  Implementation (sdd:developer + Opus)...
    → Added bcrypt password hashing
    → Created tests/auth/AuthService.test.ts
    → Summary: 2 files modified, 1 file created

Phase 3: Dispatch Judge (Attempt 2, same meta-judge specification)
  NOTE: This is a retry within the SAME task — do NOT include the
  implementation agent's previous attempt as "pre-existing changes".
  The "Pre-existing Changes" section is still OMITTED.

  Judge (sadd:judge + Opus)...
    → VERDICT: PASS, SCORE: 4.3/5.0
    → IMPROVEMENTS: Add integration tests

Phase 6: Final Report
  ✅ PASS on attempt 2
  Files: AuthService.ts, AuthMiddleware.ts, auth.routes.ts,
         AuthService.test.ts, app.ts

入力（同じセッションでの 2 回目の実行）：

/do-and-judge refactor auth module to use dependency injection

実行（2 回目）：

Phase 1: Task Analysis
  - Complexity: Medium (refactoring existing code)
  - Risk: Medium (modifying working auth module)
  - Scope: Medium (single module refactor)
  → Model: opus
  - Pre-existing Changes: Auth module created in previous task

Phase 2: Parallel Dispatch
  Tool call 1 — Meta-judge (Opus)...
    Meta-judge prompt sent:
    ┌─────────────────────────────────────────────────────────
    │ ## Task
    │ Generate an evaluation specification yaml for the
    │ following task. You will produce rubrics, checklists,
    │ and scoring criteria that a judge agent will use to
    │ evaluate the implementation artifact.
    │
    │ CLAUDE_PLUGIN_ROOT=...
    │
    │ ## User Prompt
    │ Refactor auth module to use dependency injection
    │
    │ ## Context
    │ Existing auth module at src/auth/ with AuthService,
    │ AuthMiddleware, auth.routes. Tests in tests/auth/.
    │
    │ ## Artifact Type
    │ code
    │
    │ ## Instructions
    │ Return only the final evaluation specification YAML
    │ in your response.
    └─────────────────────────────────────────────────────────
    → Generated evaluation specification YAML
    → 3 rubric dimensions, 5 checklist items

  Tool call 2 — Implementation (sdd:developer + Opus)...
    Implementation prompt sent (abbreviated):
    ┌─────────────────────────────────────────────────────────
    │ ## Reasoning Approach
    │ Before taking any action, think through this task
    │ systematically.
    │ [... step-by-step reasoning template ...]
    │
    │ ## Task
    │ Refactor the auth module to use dependency injection.
    │ AuthService should accept its dependencies via
    │ constructor instead of importing them directly.
    │
    │ ## Constraints
    │ - Follow existing code patterns and conventions
    │ - Make minimal changes to achieve the objective
    │ - Do not introduce new dependencies without
    │   justification
    │ - Ensure changes are testable
    │
    │ ## Output
    │ Provide your implementation along with a "Summary"
    │ section containing:
    │ - Files modified (full paths)
    │ - Key changes (3-5 bullet points)
    │ - Any decisions made and rationale
    │ - Potential concerns or follow-up needed
    │
    │ ## Self-Critique Verification (MANDATORY)
    │ [... verification questions and revision process ...]
    └─────────────────────────────────────────────────────────
    → Refactored AuthService to accept dependencies via constructor
    → Created src/auth/AuthServiceFactory.ts
    → Updated tests to use mocked dependencies
    → Summary: 4 files modified, 1 file created

Phase 3: Dispatch Judge (with meta-judge specification)
  NOTE: Pre-existing changes detected — the previous do-and-judge run
  created the auth module. Include "Pre-existing Changes" section so the
  judge does not confuse prior work with the current refactoring task.

  Judge prompt sent:
  ┌─────────────────────────────────────────────────────────
  │ You are evaluating an implementation artifact against
  │ an evaluation specification produced by the meta judge.
  │
  │ CLAUDE_PLUGIN_ROOT=...
  │
  │ ## User Prompt
  │ Refactor auth module to use dependency injection
  │
  │ ## Pre-existing Changes (Context Only)
  │
  │ The following changes were made BEFORE the current
  │ implementation agent started working. They are NOT part
  │ of the current task's output. Focus your evaluation on
  │ the current task's changes. Only verify pre-existing
  │ changed files/logic if they directly relate to the
  │ current task requirements.
  │
  │ ### Previous Task: "Add basic authentication module"
  │ The following files were created/modified as part of a
  │ previous task:
  │ - src/auth/AuthService.ts (new) - Authentication service
  │   with login/logout/register
  │ - src/auth/AuthMiddleware.ts (new) - Express middleware
  │   for route protection
  │ - src/auth/auth.routes.ts (new) - Auth API routes
  │ - tests/auth/AuthService.test.ts (new) - Unit tests for
  │   auth service
  │ - src/app.ts (modified) - Integrated auth routes and
  │   middleware
  │
  │ These files exist in the codebase and may be modified by
  │ the current task, but you should evaluate only the
  │ changes made by the current implementation agent for the
  │ current task (refactoring to dependency injection).
  │
  │ ## Evaluation Specification
  │ ```yaml
  │ {meta-judge's evaluation specification YAML}
  │ ```
  │
  │ ## Implementation Output
  │ Files: src/auth/AuthService.ts (modified), ...
  │ Key changes: Refactored to constructor injection...
  │
  │ ## Instructions
  │ Follow your full judge process...
  └─────────────────────────────────────────────────────────

  Judge (sadd:judge + Opus)...
    → VERDICT: PASS, SCORE: 4.5/5.0
    → ISSUES: None
    → IMPROVEMENTS: Add interface documentation

Phase 6: Final Report
  ✅ PASS on attempt 1
  Files: AuthService.ts (modified), AuthServiceFactory.ts (new),
         AuthMiddleware.ts (modified), AuthService.test.ts (modified),
         app.ts (modified)

例 5：do-and-judge の前にユーザーがコードベースを変更している場合

シナリオ：

会話中、ユーザーは EC サイトのコードベースに取り組んでいます。do-and-judge を呼び出す前に、ショッピングカート、商品カタログ、チェックアウトフローを変更しました。

入力：

/do-and-judge fix shopping cart module bug when it adds duplicated items

実行：

Phase 1: Task Analysis
  - Complexity: Medium (bug fix in existing module)
  - Risk: Medium (cart logic affects checkout)
  - Scope: Small (focused bug fix)
  → Model: opus
  - Pre-existing Changes: User modified several files before this task

Phase 2: Parallel Dispatch
  Tool call 1 — Meta-judge (Opus)...
    → Generated evaluation specification YAML
    → 3 rubric dimensions, 5 checklist items
  Tool call 2 — Implementation (sdd:developer + Opus)...
    → Fixed duplicate detection in CartService.addItem()
    → Added deduplication guard in cart.routes.ts
    → Added regression test for duplicate item scenario
    → Summary: 3 files modified

Phase 3: Dispatch Judge (with meta-judge specification)
  NOTE: The orchestrator is aware from git diff/status that the user
  modified several files before this task. Include "Pre-existing Changes"
  section so the judge focuses only on the bug fix.

  Judge prompt sent:
  ┌─────────────────────────────────────────────────────────
  │ You are evaluating an implementation artifact against
  │ an evaluation specification produced by the meta judge.
  │
  │ CLAUDE_PLUGIN_ROOT=...
  │
  │ ## User Prompt
  │ Fix shopping cart module bug when it adds duplicated items
  │
  │ ## Pre-existing Changes (Context Only)
  │
  │ The following changes were made BEFORE the current
  │ implementation agent started working. They are NOT part
  │ of the current task's output. Focus your evaluation on
  │ the current task's changes. Only verify pre-existing
  │ changed files/logic if they directly relate to the
  │ current task requirements.
  │
  │ ### User modifications (before current task)
  │ The user made changes to the following files/modules
  │ before this task was started:
  │ - src/cart/CartService.ts (modified) - Shopping cart
  │   business logic updates
  │ - src/cart/cart.routes.ts (modified) - Updated cart API
  │   endpoints
  │ - src/products/ProductCatalog.ts (modified) - Product
  │   listing changes
  │ - src/checkout/CheckoutFlow.ts (modified) - Checkout
  │   process updates
  │ - tests/cart/CartService.test.ts (modified) - Updated
  │   cart tests
  │
  │ The current task focuses specifically on fixing the
  │ duplicate items bug in the shopping cart module.
  │ Pre-existing changes to cart files may overlap with the
  │ current task scope — evaluate whether the implementation
  │ agent's changes correctly address the bug without
  │ breaking the pre-existing modifications.
  │
  │ ## Evaluation Specification
  │ ```yaml
  │ {meta-judge's evaluation specification YAML}
  │ ```
  │
  │ ## Implementation Output
  │ Files: src/cart/CartService.ts (modified), ...
  │ Key changes: Added duplicate item detection...
  │
  │ ## Instructions
  │ Follow your full judge process...
  └─────────────────────────────────────────────────────────

  Judge (sadd:judge + Opus)...
    → VERDICT: PASS, SCORE: 4.1/5.0
    → ISSUES: None
    → IMPROVEMENTS: Consider extracting deduplication logic
      into a shared utility

Phase 6: Final Report
  ✅ PASS on attempt 1
  Files: CartService.ts (modified), cart.routes.ts (modified),
         CartService.test.ts (modified)

ベストプラクティス

モデルの選択

• 迷ったら Opus を使う - 検証を伴う作業では、コストより品質が重要です
• 複雑さに合わせる - 単純な変換に Opus を使わないでください
• リスクを考慮する - リスクが高いほど、より強力なモデルを使います

メタ判定と判定の検証

• メタ判定を省略しない - 評価基準を個別に調整することで、汎用的な基準よりも優れた判定が得られます
• 再試行時もメタ判定の仕様を再利用する - 評価仕様は再試行を通じて一定に保ち、変更するのは実装だけです
• 判定結果はヘッダーのみ解析する - コンテキストの汚染を避けるため、レポート全文は読まないでください
• しきい値を信頼する - 4/5.0 が品質基準です
• CLAUDE_PLUGIN_ROOT を含める - メタ判定と判定の両方で、解決済みのプラグインルートパスが必要です

反復

• 修正箇所を絞る - すべてを書き直すのではなく、特定の問題を修正します
• フィードバックをそのまま渡す - 実装エージェントに問題を正確に伝えます
• 同じメタ判定仕様を使う - 再試行時にメタ判定を再実行しないでください。評価基準は変わりません
• 適切にエスカレーションする - 根本的な問題に対して、いつまでもループしないでください

コンテキスト管理

• コンテキストを整理する - あなたはオーケストレーションを行い、サブエージェントが実装します
• コピーせず要約する - ファイルの内容全体ではなく、要約を渡します
• サブエージェントを信頼する - サブエージェントは自分でファイルを読めます
• メタ判定 YAML - 判定にはメタ判定の YAML だけを渡し、追加のテキストやコメントを加えないでください。
• 既存の変更を記録する - 変更の帰属を誤認しないよう、以前の変更に関するコンテキストを判定に渡します