design-review

name	design-review
description	設計書を5.0点満点で評価。完全性・一貫性・明確性・実現可能性・リスク管理の5軸で矛盾検出・改善提案。設計レビュー時に使用。
disable-model-invocation	true

Design Document Review

設計書を 5.0 点満点で評価し、矛盾検出・改善を行う。

Evaluation (各1.0点)

軸	1.0	0.5	0.0
完全性	全セクション網羅	一部欠落	主要欠落
一貫性	矛盾なし	軽微な不整合	重大な矛盾
明確性	曖昧さなし	一部曖昧	意図不明多数
実現可能性	具体的で実装可能	一部検証不足	非現実的
リスク管理	網羅的	主要のみ	記述なし

スコア: 4.5+=本番OK / 3.5+=良好 / 2.5+=要改善 / <2.5=大幅見直し

Required Sections

必須: 概要 / 背景・動機 / ゴール・非ゴール / 設計詳細 / 代替案 推奨: API定義 / データモデル / エラー処理 / テスト戦略 / マイグレーション 任意: パフォーマンス / セキュリティ / 可観測性 / ロールバック / タイムライン / 依存関係

Review Process

Phase 1: 構造チェック

必須セクション存在、用語統一性、図表参照整合性

Phase 2: 内容チェック

記述の深さ、具体例の有無、判断根拠、前提条件の明示

Phase 3: 矛盾検出

パターン	例
ゴール vs 設計	「高可用性」なのに単一障害点
非ゴール vs 実装	非ゴールの内容が設計に混入
要件 vs 却下理由	代替案却下理由が要件と矛盾
性能 vs 設計	低レイテンシ要件で同期処理多用
用語不統一	「ユーザー」「利用者」「アカウント」混在

Phase 4: ベストプラクティス照合

• アーキテクチャ: 単一責任、疎結合、Blast Radius局所化
• 運用: デプロイ戦略、SLO/SLI、ランブック
• データ: 冪等性、TTL、バックアップ、GDPR
• セキュリティ: 認証認可、入力バリデーション、TLS、OWASP Top 10
• テスト: Unit/Integration/E2E/負荷/カオスエンジニアリング

Output Format

# Design Review Report

## Score: X.X / 5.0
| 軸 | スコア | 判定 |
|---|---|---|
| 完全性 | X.X | ✅/⚠️/❌ |
...

## Critical Issues
- [ ] {issue} — {section} — {fix}

## Warnings
- [ ] {issue} — {section} — {improvement}

## Contradictions
- {sectionA} vs {sectionB} — {detail}

## Actions (priority order)
1. **[P0]** {action} — {reason}

Auto-Improvement

スコア 4.5 未満 → Critical Issues の修正案提示 → ユーザー確認 → 適用 → 再評価（最大3回）

注意: 設計意図は変更しない。追記は [ADDED BY REVIEW] タグ付き。

Reference Formats

• Google Design Doc: Context, Goals/Non-goals, Design, Alternatives, Cross-cutting
• ADR: Status, Context, Decision, Consequences
• RFC: Problem, Solution, Design, Drawbacks, Alternatives, Unresolved

Anti-Patterns

Pattern	Detection
手段の目的化	「なぜ」なく「何を」だけ
楽観バイアス	リスクが空 or 「特になし」
スコープクリープ	非ゴール内容が設計に混入
暗黙の前提	「〜とする」「〜と仮定」の欠如
過剰設計	現時点で不要な抽象化レイヤー