user-invocable: true description: "[レビュー] Deep Review - 設計/セキュリティ/RDD整合の深掘りチェック"

[レビュー] Deep Review

入力: $ARGUMENTS

• PR番号（例: #123 または 123）
• 省略時: 現在のブランチの差分をmainと比較

🎯 目的

• 設計品質・セキュリティ・RDD整合を深くレビューする
• 既存スキルの観点を活用した多角的チェック
• mainマージ前の最終品質ゲート

対象範囲

実行手順

1. コンテキスト収集

RDD読み込み:

# プロジェクトの制約・技術スタックを確認
cat doc/input/rdd.md

差分取得:

# PR番号指定時
gh pr diff {PR_NUMBER}

# 省略時
git diff main...HEAD

変更ファイル一覧:

git diff --name-only main...HEAD

2. 関連スキル特定

変更内容に応じて適用するスキル観点を決定：

3. 多観点レビュー

3.1 セキュリティ観点

- [ ] 入力検証は適切か（サニタイズ、型チェック）
- [ ] 認可チェックは漏れていないか
- [ ] 秘密情報がハードコードされていないか
- [ ] SQLインジェクション/XSS/CSRFの脆弱性はないか
- [ ] エラーメッセージで内部情報を漏らしていないか

3.2 アーキテクチャ観点

- [ ] 依存の方向は正しいか（内→外への依存のみ）
- [ ] 責務が適切に分離されているか
- [ ] 既存の境界を壊していないか
- [ ] 新しい概念の導入は妥当か

3.3 設計品質観点

- [ ] 重複コードを作っていないか（既存の再利用）
- [ ] 単一責任原則を守っているか
- [ ] テスト可能な設計か
- [ ] 過剰な抽象化をしていないか

3.4 RDD整合観点

- [ ] 技術スタックの指定に従っているか
- [ ] 非機能要件を満たしているか
- [ ] 目標/非目標の範囲内か
- [ ] 制約事項を守っているか

3.5 複雑さ観点

- [ ] 関数/メソッドが長すぎないか（目安: 50行以下）
- [ ] ネストが深すぎないか（目安: 3段以下）
- [ ] 条件分岐が複雑すぎないか
- [ ] 認知負荷が高くないか（一度に理解すべき概念数）

4. 結果出力

## 🔍 Deep Review 結果

### 対象
- PR: #{PR_NUMBER} または ブランチ: {branch_name}
- 適用観点: セキュリティ, アーキテクチャ, 設計品質

### 🔴 Critical（マージ前に必須修正）
| 観点 | ファイル | 内容 | 推奨対応 |
|------|----------|------|----------|
| セキュリティ | src/api.ts:45 | SQLインジェクション脆弱性 | プレースホルダを使用 |

### 🟠 Warning（強く推奨）
| 観点 | ファイル | 内容 | 推奨対応 |
|------|----------|------|----------|
| 設計 | src/service.ts | 200行超の巨大関数 | 責務分割を検討 |
| RDD | src/auth.ts | JWT使用（RDDはSession指定） | 要確認/ADR |

### 🟡 Suggestion（検討推奨）
| 観点 | ファイル | 内容 | 推奨対応 |
|------|----------|------|----------|
| 複雑さ | src/calc.ts:30 | ネスト4段 | 早期リターンで簡素化 |

### 🟢 Good Practice（良い点）
- src/user.ts: 適切な入力検証
- src/repo.ts: 依存方向が正しい

### RDD整合チェック
- **技術スタック**: ✅ 準拠
- **非機能要件**: ✅ 準拠
- **制約事項**: ⚠️ 要確認（JWT vs Session）

### サマリ
| レベル | 件数 |
|--------|------|
| Critical | 1 |
| Warning | 2 |
| Suggestion | 1 |
| Good | 2 |

### 推奨アクション
1. Critical を修正してから再レビュー依頼
2. Warning は修正を強く推奨
3. RDD違反がある場合はADR-liteで変更要求

---

### 💬 所感

**設計の印象:**
{全体的な設計アプローチへの所感}

**特に良かった点:**
- {具体的に優れていた設計判断}
- {例: 責務分離が明確で拡張しやすい構造}
- {例: エッジケースの考慮が丁寧}

**成長ポイント:**
{今後さらに良くなるためのヒント（批判ではなく提案として）}

**総評:**
{前向きなまとめ。例: 「セキュリティ意識が高く、RDDに沿った堅実な実装です。Warningの点を改善すれば、長期運用でも安心できるコードになりますね！」}

出力先

PR番号指定時（⚠️ 確認あり）:

gh pr comment {PR_NUMBER} --body "{レビュー結果}"

省略時:

• 標準出力にレビュー結果を表示

判断基準

Critical（マージブロック）

• セキュリティ脆弱性
• データ損失の可能性
• RDDの明確な違反（承認なし）

Warning（強く推奨）

• 設計原則の違反
• 保守性の大幅な低下
• パフォーマンス問題

Suggestion（任意）

• より良い書き方の提案
• 軽微な改善点

自己評価

• 成功自信度: (1-10)
• 一言理由: {短く理由を記載}