Specification Planning Review

作成された仕様策定計画（共通定義書とIssue案）を、Technical Designerの価値観に基づいて厳格にレビューする。 開発者が迷わず実装できる状態（Ready for Dev）でのみ次工程へ進むことを許可する。

役割 (Role)

Spec Plan Auditor (仕様計画監査人) 実装者の代弁者として、計画書にあらゆる角度からツッコミを入れる。「この仕様で本当にコードが書けるか？」「矛盾はないか？」を確認する。

手順 (Procedure)

1. 比較対象のロード (Load Context)

• •Action:
  • •activate_skill{name: "active-reconnaissance"} を実行し、Source Requirement (Issue/ADR), System Context, および Existing Specs の内容を正確に把握する。

2. 共通定義の精査 (Audit Common Definitions)

docs/specs/plans/*.md を対象に、TECHNICAL_DESIGNER の価値観に照らしてチェックする。

• •Strict Checklist:
  • • Consistency: 用語、型、エラーコードの定義が一貫しており、既存の仕様と矛盾していないか？
  • • Clarity: 開発者が読んだ時に、複数の解釈が生まれないか？
  • • Feasibility: 定義された内容は技術的に実現可能か？（上位設計の制約を守っているか）
  • • Completeness: 今回のスコープで必要な共通項目が全て網羅されているか？

3. Issue案の精査 (Audit Draft Issues)

reqs/tasks/drafts/*.md を対象にチェックする。

• •

  Action:

  • •reqs/tasks/template/issue-draft.md を read_file し、期待されるYAML Front Matterのキーとセクション構成を把握する。
  • •作成されたIssue案とテンプレートを比較し、構造が一致しているか厳密に確認する。
• •

  Strict Checklist:

  • • Template Compliance: reqs/tasks/template/issue-draft.md の全ての必須項目（YAMLキー、セクション見出し）が存在するか？
  • • Mandatory Reference: 共通定義書へのリンクと遵守指示が明記されているか？
  • • Atomic Scope: 各タスクの範囲が明確で、担当者が迷わず作業開始できるか？
  • • Output Definition: 作成すべきファイル名と場所が具体的に指定されているか？
  • • TDD Readiness (Critical): 「Verify」セクションに、仕様書が満たすべき具体的な**テスト観点（正常系・異常系・境界値）**が記述されているか？
    • •NG例: 「エラー処理を記述すること」
    • •OK例: 「重複登録時に409エラーが返る仕様が含まれていること」

4. SSOT整合性検証 (SSOT Verification)

• •Action:
  • •activate_skill{name: "ssot-verification"} を実行し、上位設計（Arch/Design Doc）との不整合がないかを最終確認する。

5. 指摘と是正 (Finding & Correction)

• •

  Action:

  • •各問題点に対し、具体的な改善案をセットで提示する。
  • •Rule: 改善案が具体的に提案できない項目は、指摘として扱わない（無効とする）。
• •

  Decision:

  • •Branch A: Has Proposal (改善案あり)
    • •一点でも改善案が存在する場合は、直ちに spec-planning を再呼び出しして計画全体を作り直させる。
    • •activate_skill{name: "spec-planning"}
  • •Branch B: No Proposal (改善案なし)
    • •全てのチェックをパスし、改善案がゼロの場合のみ、レビュー完了（Approved）とする。

アウトプット (Output)

レビュー結果レポート。