review-specification

name	review-specification
description	specification skill で生成された技術仕様書を、要件の網羅性・正確性/アーキテクチャ・技術選定の妥当性/API・データ設計の品質/テスト・品質保証戦略/実装計画・運用設計の5軸・100点満点で客観的に採点する。別エージェントを起動してレビューする（自己レビューしない）。「この技術仕様書をレビューして」「仕様書を採点して」等で使用。

/review-specification — 技術仕様書 品質レビュー（エージェント分離実行）

このスキルは別エージェントを起動してレビューを行う。現在のセッションでは直接レビューしない。 作成時の思考過程・設計判断・会話履歴をレビューエージェントに渡さないことで客観性を確保する。

対象: specification skill をもとに生成された技術仕様書 目的: 「要件の網羅性・正確性」「アーキテクチャ・技術選定の妥当性」「API・データ設計の品質」「テスト・品質保証戦略」「実装計画・運用設計」の5軸で技術仕様書を100点満点で評価する。

---

実行手順

ステップ1: 情報収集（この実装セッションで行う）

以下の事実情報のみを収集する。作成の意図・設計判断の説明は含めない。

収集対象:
1. レビュー対象の技術仕様書の全文
2. 以下の「レビュー前の必須確認事項」が文書内または作成者からの回答で判明しているか
   - 元となった企画書はどれか
   - 対象システムの規模感は（個人開発・スタートアップMVP・エンタープライズのいずれか）
   - 想定ユーザー数・トラフィック規模は
   - 開発チームの体制・スキルセットは
   - `specification` skill のどのセクションまで記載したか

上記が不明瞭な場合は、レビュー開始前に作成者へ確認すること。

ステップ2: レビューエージェント起動

Agent ツールを使い、以下の設定で別エージェントを起動する:

Agent ツールの設定:
- subagent_type: "general-purpose"
- description: "Review technical specification objectively"
- prompt: 以下のテンプレートに収集した情報を埋め込む

プロンプトテンプレート（レビューエージェントに渡す内容）:

あなたは作成者とは別の客観的なテックリードです。
以下の技術仕様書を、5項目・各20点・合計100点で評価してください。

## 行動原則
`.claude/skills/_shared/review-rubrics.yaml` の `common_principles`（evidence_based / citation_required / non_destructive）を Read して適用すること。

## レビュー対象文書
[ここに対象技術仕様書の全文を埋め込む]

## レビュー観点（5項目・各20点・合計100点）

### 1. 要件の網羅性・正確性 【配点：20点】

> 目的：企画書の要件が漏れなく技術仕様に落とし込まれており、機能要件・非機能要件が網羅され、実装者が迷わないレベルの具体性があるかを確認する。

- [ ] 企画書に記載されたすべての機能要件が技術仕様として定義されているか
- [ ] 非機能要件（パフォーマンス・可用性・セキュリティ・拡張性）が明示されているか
- [ ] 各機能の入力・処理・出力が曖昧さなく定義されているか
- [ ] 用語の定義が統一されており、企画書との用語の対応が明確か
- [ ] 優先度・フェーズ分けが明記され、MVPスコープが明確に線引きされているか
- [ ] 企画書にない暗黙の要件（認証・エラー処理・ログ等）が補完されているか

採点目安:
| 点数 | 基準 |
|------|------|
| 18〜20 | 企画書の全要件が漏れなく仕様化され、非機能要件・暗黙の要件まで網羅。実装者が迷わない具体性がある |
| 14〜17 | おおむね網羅されているが、一部の非機能要件または暗黙の要件が不足 |
| 10〜13 | 主要機能は仕様化されているが、要件の抜け漏れや曖昧な記述が散見される |
| 0〜9  | 企画書の要件が大幅に欠落しており、仕様書として不十分 |

### 2. アーキテクチャ・技術選定の妥当性 【配点：20点】

> 目的：技術スタックの選定に合理的な根拠があり、スケーラビリティ・保守性・セキュリティが考慮されたシステム構成になっているかを確認する。

- [ ] 技術スタック選定の根拠が明記されているか（なぜその技術を選んだか）
- [ ] システム構成図（アーキテクチャ図）が含まれ、コンポーネント間の関係が明確か
- [ ] スケーラビリティへの考慮があるか（水平スケール・キャッシュ・CDN等）
- [ ] 保守性・可読性への配慮があるか（コード規約・モジュール分割・依存関係管理）
- [ ] セキュリティ設計（認証・認可・暗号化・脆弱性対策）が含まれているか
- [ ] 技術選定がチームのスキルセットや開発体制に対して現実的であるか

採点目安:
| 点数 | 基準 |
|------|------|
| 18〜20 | 技術選定の根拠が明確で、スケーラビリティ・保守性・セキュリティすべてが考慮されている。システム構成図が明確 |
| 14〜17 | おおむね妥当だが、スケーラビリティまたはセキュリティの一部考慮が不足 |
| 10〜13 | 技術選定の根拠が薄く、アーキテクチャの全体像が不明瞭 |
| 0〜9  | 技術選定に根拠がなく、アーキテクチャ設計がほぼ存在しない |

### 3. API・データ設計の品質 【配点：20点】

> 目的：API設計の一貫性、データモデル・DB設計の正規化、エラーハンドリング・バリデーション設計が適切に行われているかを確認する。

- [ ] API設計（RESTful/GraphQL等）が一貫した規約に従っているか
- [ ] 各APIエンドポイントのリクエスト・レスポンス形式が具体的に定義されているか
- [ ] データモデル（エンティティ・リレーション）が正規化され、ER図またはスキーマ定義があるか
- [ ] バリデーションルール（入力値検証・型チェック・制約条件）が定義されているか
- [ ] エラーハンドリング（エラーコード・エラーメッセージ・リトライ戦略）が設計されているか
- [ ] データマイグレーション戦略（スキーマ変更時の対応方針）が考慮されているか

採点目安:
| 点数 | 基準 |
|------|------|
| 18〜20 | API設計が一貫し、データモデルが正規化され、バリデーション・エラーハンドリング・マイグレーション戦略まで含まれている |
| 14〜17 | おおむね品質は高いが、バリデーションルールまたはエラーハンドリングの一部が不足 |
| 10〜13 | API・データ設計が存在するが、一貫性に欠けるか詳細度が不足 |
| 0〜9  | API・データ設計がほぼなく、実装者が自力で設計する必要がある |

### 4. テスト・品質保証戦略 【配点：20点】

> 目的：テスト戦略が体系的に定義されており、CI/CD設計と監視・ログ・アラート設計が含まれているかを確認する。

- [ ] テスト戦略（単体テスト・結合テスト・E2Eテスト）の対象範囲と方針が定義されているか
- [ ] カバレッジ目標が数値で設定されているか（例：ライン80%以上）
- [ ] CI/CDパイプラインの設計（ビルド・テスト・デプロイの自動化フロー）が含まれているか
- [ ] 監視設計（ログ収集・メトリクス・ヘルスチェック）が定義されているか
- [ ] アラート設計（閾値・通知先・エスカレーションフロー）が含まれているか
- [ ] パフォーマンステスト（負荷テスト・ストレステスト）の計画があるか

採点目安:
| 点数 | 基準 |
|------|------|
| 18〜20 | テスト戦略・カバレッジ目標・CI/CD・監視・アラートがすべて設計されている |
| 14〜17 | テスト戦略は定義されているが、CI/CDまたは監視・アラートの一部が不足 |
| 10〜13 | テストへの言及はあるが、戦略が体系的でなく目標値も不明確 |
| 0〜9  | テスト・品質保証に関する記述がほぼなく、品質担保の見通しが立たない |

### 5. 実装計画・運用設計 【配点：20点】

> 目的：フェーズ分け・マイルストーンが現実的に設定され、デプロイ戦略・障害対応・運用コスト見積もりが含まれているかを確認する。

- [ ] フェーズ分け・マイルストーンが具体的な期間付きで定義されているか
- [ ] 各フェーズの完了条件（Definition of Done）が明確か
- [ ] デプロイ戦略（Blue-Green/カナリア/ローリング等）が定義されているか
- [ ] 障害対応手順（インシデント対応フロー・ロールバック手順）が記載されているか
- [ ] 運用コスト見積もり（インフラ・外部サービス・人件費の概算）が含まれているか
- [ ] 技術的負債の管理方針（リファクタリング計画・ドキュメント更新頻度）が示されているか

採点目安:
| 点数 | 基準 |
|------|------|
| 18〜20 | フェーズ・デプロイ戦略・障害対応・運用コスト・技術的負債管理がすべて含まれている |
| 14〜17 | おおむね計画されているが、運用コストまたは障害対応の一部が不足 |
| 10〜13 | フェーズ分けはあるが、デプロイ・障害対応・運用設計が表面的 |
| 0〜9  | 実装計画・運用設計がほぼなく、開発着手後の見通しが立たない |

## 採点方法（総合点：100点満点）

`.claude/skills/_shared/review-rubrics.yaml` を Read し、`verdict_scales.rank5_100` の bands/meaning に従って S/A/B/C/D を判定すること（点数帯・各段階の対応方針は同ファイルが SoT）。**指摘単位の重大度 (2026-08-31 追加)**: 各観点の個別指摘には同ファイルの `severity` (HIGH/MEDIUM/LOW) を付す (総合点の算出方法は変更しない)。

## 出力（レビュー結果出力フォーマット）

```markdown
# 技術仕様書 レビュー結果

## 基本情報
- 仕様書タイトル：
- レビュー日：
- 元企画書：
- システム規模（個人開発 / スタートアップMVP / エンタープライズ）：

## 総合評価
- **総合点：XX点 / 100点**
- **判定：X（S/A/B/C/D）**

## 観点別採点

| # | 観点 | 配点 | 得点 | 主なコメント |
|---|------|------|------|-------------|
| 1 | 要件の網羅性・正確性 | 20 | | |
| 2 | アーキテクチャ・技術選定の妥当性 | 20 | | |
| 3 | API・データ設計の品質 | 20 | | |
| 4 | テスト・品質保証戦略 | 20 | | |
| 5 | 実装計画・運用設計 | 20 | | |

## 良かった点（Keep）

## 改善提案（Problem / Try）

## 具体的な強化が必要な箇所

| 観点 | 現状 | 不足している点 | 補強案 |
|------|------|---------------|--------|
| | | | |

## 重要チェック項目

| 項目 | 記載 | コメント |
|------|------|----------|
| 機能要件の網羅 | ✅ / ❌ | |
| 非機能要件の定義 | ✅ / ❌ | |
| システム構成図 | ✅ / ❌ | |
| API設計 | ✅ / ❌ | |
| データモデル定義 | ✅ / ❌ | |
| テスト戦略 | ✅ / ❌ | |
| CI/CDパイプライン | ✅ / ❌ | |
| 監視・アラート設計 | ✅ / ❌ | |
| デプロイ戦略 | ✅ / ❌ | |
| 運用コスト見積もり | ✅ / ❌ | |

## 次のアクション推奨

（S/A判定の場合）→ 開発チームへ引き渡し、実装を開始する
（B以下の場合）→ 上記改善提案を反映してから再レビュー

## 補足コメント

### ステップ3: 結果の報告

レビューエージェントから返却された結果を、そのままユーザーに表示する。
要約や解釈を加えない（レビューの客観性を維持するため）。

---

## 注意事項

- **絶対に実装セッション内で直接レビューしない**。必ず Agent ツールで別エージェントを起動すること
- レビュワーは元ファイルを絶対に編集してはならない。改善点は具体的に指摘し、修正案は「提案」として記載する
- 上記「レビュー前の必須確認事項」が文書から読み取れない場合は、作成者へ確認する

## 参照ドキュメント

- 元プロンプト（詳細確認用）: `workflows/business-planning/review-specification.md`
- 前ステップ（技術仕様書作成）: `specification` skill