OpenSkillIndex← back to search
claude-codeautomation

Claude-skill-registry deep-review

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

install
source · Clone the upstream repo
git clone https://github.com/majiayu000/claude-skill-registry
Claude Code · Install into ~/.claude/skills/
T=$(mktemp -d) && git clone --depth=1 https://github.com/majiayu000/claude-skill-registry "$T" && mkdir -p ~/.claude/skills && cp -r "$T/skills/data/deep-review" ~/.claude/skills/majiayu000-claude-skill-registry-deep-review && rm -rf "$T"
manifest: skills/data/deep-review/SKILL.md
tags
#code-review#security#architecture#design-patterns#rdd
source content

[レビュー] Deep Review

入力: $ARGUMENTS

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

🎯 目的

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

対象範囲

観点参照スキルチェック内容
セキュリティ
/security-expert
OWASP基本、入力検証、認可、秘密情報
アーキテクチャ
/architecture-expert
境界、依存方向、責務分離
設計品質
/developer-specialist
SOLID原則、重複回避、適切な抽象度
RDD整合-doc/input/rdd.md との整合性
複雑さ-認知負荷、循環複雑度、ネスト深度
アクセシビリティ
/accessibility-engineer
UI変更時のみ
フロントエンド
/react
, 
/svelte
等		該当技術スタック時のみ

実行手順

1. コンテキスト収集

RDD読み込み:

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

差分取得:

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

# 省略時
git diff main...HEAD

変更ファイル一覧:

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

2. 関連スキル特定

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

変更種別適用スキル
API/認証security-expert
DB/データ層architecture-expert
ビジネスロジックdeveloper-specialist
UIコンポーネントreact/svelte + accessibility-engineer
設定/インフラsecurity-expert

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)
  • 一言理由: {短く理由を記載}