Phase 1: DISCOVER

Sub-Agent: OutputCollector (model: haiku)

• Tools: Read
• Prompt: パイプラインからの最終出力を収集します。6つの必須フィールド(root_cause、evidence、fix_plan、rollback、tests、confidence)のうち、どれが存在するかを確認します。
• Output: { fields_present[], fields_missing[], confidence_value }
• Gate: 出力が収集されたこと

Phase 2: PLAN

Sub-Agent: GateDesigner (model: sonnet)

• Prompt: 各フィールドの合格/不合格を定義します。フィールドは以下の場合に有効です：空でない、具体的なコンテンツがある(プレースホルダーではない)、confidence >= 0.70。
• Output: { gates[{field, present, valid, reason}] }
• Gate: 6つのゲートが定義されたこと

Phase 3: IMPLEMENT

Sub-Agent: GateChecker (model: haiku)

• Prompt: 各ゲートを確認します。フィールドが存在するか？空でないか？confidence >= 0.70 か？6つのフィールドすべて存在するか？
• Output: { gates_checked[], all_pass: boolean, blocking[] }
• Gate: すべての 6つのゲートが確認されたこと

Phase 4: VERIFY

Sub-Agent: DecisionMaker (model: haiku)

• Prompt: 6つのゲートがすべて合格し、かつ confidence >= 0.70 の場合は APPROVED。具体的なブロック問題をリストして REJECTED。部分的な承認は決してありません。
• Output: { decision: "APPROVED"|"REJECTED", blocking[], confidence }
• Gate: 決定が下されたこと

Phase 5: DELIVER

Sub-Agent: CriticReporter (model: haiku)

• Prompt: 最終判定を出力します。REJECTED の場合、どのフィールドが不足/無効で、何を修正すべきかを正確にリストします。
• Output: { approved: boolean, blocking[], fix_suggestions[], confidence }
• Gate: 判定が配信されたこと

Contingency

出力が 6 つのフィールドのうち 0 つの場合 → 直ちに REJECTED。不足しているフィールドを埋めようとしないでください。 confidence が境界値 (0.70) ちょうどの場合 → APPROVED ですが「限界値 — より多くの証拠を追加してください」とフラグを立てます。

---

Critic ロール スキル

Purpose: 品質ゲートおよび出力契約の検証をエンドツーエンドで自動化します。

Role: 4エージェント診断パイプラインの品質ゲート。

Create → Handle → Run (E2E)

Create

• 品質ゲートを定義します (confidence >= 0.70、すべてのフィールドが存在)
• 不足/部分的な出力に対するブロック規則を追加します
• 部分的な承認はなく、APPROVED または REJECTED のみ

Handle

• 受信: 完全な出力契約 (root cause、evidence、fix plan、rollback、tests、confidence)
• 確認: confidence >= 0.70
• 確認: 6つのフィールドすべてが存在し、空でない
• 出力: APPROVED または REJECTED(具体的なブロック問題をリスト)

Run

• 完全なパイプライン: node src/local-pipeline.js または UI 送信
• Critic が confidence < 0.70 の場合にブロックすることを確認
• Critic が任意のフィールドが不足している場合にブロックすることを確認
• すべてのゲートが合格した場合のみ APPROVED であることを確認

Output Contract (Required Fields)

1. Root Cause – インシデントが発生した理由
2. Evidence – リポジトリからのファイル:行の引用
3. Fix Plan – 解決するための具体的な手順
4. Rollback Plan – 修正を元に戻す方法
5. Tests – 修正を検証する方法
6. Confidence – スコア >= 0.70

Constraints

• ✓ confidence < 0.70 の場合ブロック
• ✓ 任意のフィールドが不足している場合ブロック
• ✓ REJECTED の場合、具体的なブロック問題をリスト
• ✗ 部分的な承認なし

Related Skills

• evidence-proof – テストに支持された信頼度
• backend-reliability – ゲートロジックのエラーハンドリング