Reviews code for quality, security, performance, and accessibility issues. Use when user mentions レビュー, review, コードレビュー, セキュリティ, パフォーマンス, 品質チェック, セルフレビュー, PR, diff, 変更確認. Do NOT load for: 実装作業, 新機能開発, バグ修正, セットアップ.
Installation
Details
Usage
After installing, this skill will be available to your AI coding assistant.
Verify installation:
skills listSkill Instructions
name: review description: "Reviews code for quality, security, performance, and accessibility issues. Use when user mentions レビュー, review, コードレビュー, セキュリティ, パフォーマンス, 品質チェック, セルフレビュー, PR, diff, 変更確認. Do NOT load for: 実装作業, 新機能開発, バグ修正, セットアップ." allowed-tools: ["Read", "Grep", "Glob", "Bash", "Task"] context: fork
Review Skills
コードレビューと品質チェックを担当するスキル群です。
機能詳細
| 機能 | 詳細 |
|---|---|
| 変更レビュー | See references/changes-review.md |
| 品質チェック | See references/quality-review.md |
| セキュリティ | See references/security-review.md |
| パフォーマンス | See references/performance-review.md |
| アクセシビリティ | See references/accessibility-review.md |
| SEO/OGP | See references/seo-review.md |
| Codex 統合 | See references/codex-integration.md |
| コミット判定 | See references/commit-judgment-logic.md |
実行手順
- 品質判定ゲート(Step 0)
- 残コンテキスト確認(Codex モード時)(Step 1)
- ユーザーのリクエストを分類
- (Claude-mem 有効時)過去のレビュー指摘を検索
- 並列実行の判定(下記参照)
- 上記の「機能詳細」から適切な参照ファイルを読む、または並列サブエージェント起動
- 結果を統合してレビュー完了
入力の優先順位
filesが渡されている場合は そのファイルのみ を対象にレビューするfilesが渡されていない場合はgit_diffから変更箇所を推定するcontext_from: code_contentが渡されている場合は その内容を優先 してレビューする
Step 0: 品質判定ゲート(レビュー重点領域の特定)
レビュー開始前に変更内容を分析し、重点領域を特定:
変更ファイル分析
↓
┌─────────────────────────────────────────┐
│ 品質判定ゲート │
├─────────────────────────────────────────┤
│ 判定項目: │
│ ├── カバレッジ不足?(テストなし) │
│ ├── セキュリティ注意?(auth/api/) │
│ ├── a11y 注意?(UI コンポーネント) │
│ └── パフォーマンス注意?(DB/ループ) │
└─────────────────────────────────────────┘
↓
重点レビュー領域を決定
カバレッジ判定
| 状況 | 指摘内容 |
|---|---|
| 新規ファイルにテストなし | 「テストが不足しています」 |
| 変更ファイルのテストが古い | 「テストの更新を検討してください」 |
| カバレッジ < 60% | 「カバレッジ向上を推奨」 |
セキュリティ重点レビュー
| パス | 追加チェック項目 |
|---|---|
| auth/, api/ | OWASP Top 10 チェックリスト |
| 入力処理 | サニタイズ、バリデーション |
| DB クエリ | パラメータ化確認 |
a11y 重点レビュー
| パス | チェック項目 |
|---|---|
| src/components/ | alt, aria, キーボード操作 |
| src/pages/ | 見出し構造, フォーカス管理 |
パフォーマンス重点レビュー
| パターン | 警告内容 |
|---|---|
| ループ内 DB クエリ | N+1 クエリの可能性 |
| 大規模データ処理 | ページネーション検討 |
| useEffect 乱用 | レンダリング最適化 |
SEO/OGP 重点レビュー
| パス | チェック項目 |
|---|---|
| src/pages/, app/ | title, description, canonical |
| public/ | robots.txt, sitemap.xml, OGP 画像 |
| layout.tsx, _document.tsx | viewport, OGP タグ, Twitter Card |
クロスプラットフォーム重点レビュー
| パス | チェック項目 |
|---|---|
| src/components/, app/ | レスポンシブ(固定幅チェック) |
| *.css, *.scss, tailwind | 100vw 使用、overflow 設定 |
| public/ | favicon, apple-touch-icon |
重点レビュー統合出力
📊 品質判定結果 → 重点レビュー領域
| 判定 | 該当 | 対象ファイル |
|------|------|-------------|
| セキュリティ | ⚠️ | src/api/auth.ts |
| カバレッジ | ⚠️ | src/utils/helpers.ts (テストなし) |
| a11y | ✅ | - |
| パフォーマンス | ✅ | - |
| SEO/OGP | ⚠️ | app/layout.tsx (OGP 未設定) |
| クロスプラットフォーム | ✅ | - |
→ セキュリティ・カバレッジ・SEO を重点的にレビュー
LSP ベースの影響分析(推奨)
変更レビュー時に LSP ツールで影響範囲を確認:
| 変更タイプ | LSP 操作 | 確認内容 |
|---|---|---|
| 関数シグネチャ変更 | findReferences | 全呼び出し元が対応済みか |
| 型定義変更 | findReferences | 使用箇所での型互換性 |
| API 変更 | incomingCalls | 影響を受けるエンドポイント |
レビューフロー:
- 変更ファイルを特定
LSP.findReferencesで影響範囲を列挙- 影響を受けるファイルも含めてレビュー
使用例:
# 1. 変更された関数の参照箇所を確認
LSP operation=findReferences filePath="src/api/user.ts" line=42 character=15
# 2. 関数の呼び出し階層を確認
LSP operation=incomingCalls filePath="src/api/user.ts" line=42 character=15
# 3. 型定義の使用箇所を確認
LSP operation=findReferences filePath="src/types/api.ts" line=10 character=12
出力例:
🔍 LSP 影響分析結果
変更: updateUserProfile() のシグネチャ変更
影響を受ける箇所:
├── src/pages/profile.tsx:89 ⚠️ 引数更新必要
├── src/pages/settings.tsx:145 ⚠️ 引数更新必要
├── tests/user.test.ts:67 ✅ 更新済み
└── src/api/admin.ts:23 ⚠️ 引数更新必要
→ 3箇所で引数の更新が必要
注: LSP サーバーが設定されている言語でのみ動作します。
Step 1: 残コンテキスト確認(Codex モード時)
Codex モード(review.mode: codex)の場合は、残コンテキストが 30%以下なら /compact を先に実行してください。
注意: /compact 後も余裕が少ない場合は縮退せず続行します。
Step 2: 過去のレビュー指摘検索(Memory-Enhanced)
Claude-mem が有効な場合、レビュー開始前に過去の類似指摘を検索:
# mem-search で過去のレビュー指摘を検索
mem-search: type:review "{変更ファイルのパターン}"
mem-search: concepts:security "{セキュリティ関連のキーワード}"
mem-search: concepts:gotcha "{変更箇所に関連するキーワード}"
表示例:
📚 過去のレビュー指摘(関連あり)
| 日付 | 指摘内容 | ファイル |
|------|---------|---------|
| 2024-01-15 | XSS脆弱性: innerHTML 使用禁止 | src/components/*.tsx |
| 2024-01-20 | N+1クエリ: prefetch 必須 | src/api/*.ts |
💡 今回のレビューで上記パターンを重点チェック
注: Claude-mem が未設定の場合、このステップはスキップされます。
レビューモードの選択
レビュースキルは 2 つのモードで動作します:
設定確認: .claude-code-harness.config.yaml
↓
├── review.mode: default → Claude 単体レビュー
└── review.mode: codex → Codex 並列レビュー(8 エキスパート)
Default モード(Claude 単体)
Claude が直接レビューを実行。小〜中規模の変更に最適。
Codex モード(並列エキスパート)
Codex MCP 経由で最大 8 つの専門エキスパートを 個別に並列呼び出し(不要なエキスパートは除外):
| エキスパート | 観点 | プロンプトファイル |
|---|---|---|
| Security | OWASP Top 10、認証、インジェクション | experts/security-expert.md |
| Accessibility | WCAG 2.1 AA、セマンティック HTML | experts/accessibility-expert.md |
| Performance | N+1 クエリ、レンダリング、アルゴリズム | experts/performance-expert.md |
| Quality | 可読性、保守性、ベストプラクティス | experts/quality-expert.md |
| SEO | メタタグ、OGP、サイトマップ | experts/seo-expert.md |
| Architect | 設計、トレードオフ、スケーラビリティ | experts/architect-expert.md |
| Plan Reviewer | 計画の完全性、明確性、検証可能性 | experts/plan-reviewer-expert.md |
| Scope Analyst | 要件分析、曖昧さ検出、リスク | experts/scope-analyst-expert.md |
⚠️ Codex モード実行時の必須ルール
絶対に1回の MCP 呼び出しで複数エキスパートをまとめないこと。
✅ 正しい: 8回の MCP 呼び出しを1つのレスポンス内で並列実行
❌ 間違い: 1回の呼び出しで「全観点をレビューして」と依頼
実行手順:
- 呼び出すエキスパートを判定(全部ではなく必要なもののみ):
- 設定で
enabled: false→ 除外 - CLI/バックエンド → Accessibility, SEO 除外
- ドキュメントのみ変更 → Quality, Architect, Plan Reviewer, Scope Analyst を優先(Security, Performance は除外可)
- 設定で
- 有効なエキスパートの
experts/*.mdからプロンプトを 個別に読み込む - 有効なエキスパートのみ
mcp__codex__codexを 1つのレスポンス内で並列実行 - 各結果を統合して判定
詳細: codex-review/references/codex-parallel-review.md
Codex モード有効化:
/codex-mode on
詳細: references/codex-integration.md
並列サブエージェント起動(Default モード)
以下の条件を両方満たす場合、Task tool で code-reviewer を並列起動:
- レビュー観点 >= 2(例: セキュリティ + パフォーマンス)
- 変更ファイル >= 5
起動パターン(1つのレスポンス内で複数の Task tool を同時呼び出し):
Task tool 並列呼び出し:
#1: subagent_type="code-reviewer"
prompt="セキュリティ観点でレビュー: {files}"
#2: subagent_type="code-reviewer"
prompt="パフォーマンス観点でレビュー: {files}"
#3: subagent_type="code-reviewer"
prompt="コード品質観点でレビュー: {files}"
小規模な場合(条件を満たさない):
- 子スキル(doc.md)を順次読み込んで直列実行
🔧 LSP 機能の活用
レビューでは LSP(Language Server Protocol)を活用して精度を向上します。
LSP をレビューに統合
| レビュー観点 | LSP 活用方法 |
|---|---|
| 品質 | Diagnostics で型エラー・未使用変数を自動検出 |
| セキュリティ | Find-references で機密データの流れを追跡 |
| パフォーマンス | Go-to-definition で重い処理の実装を確認 |
LSP Diagnostics の出力例
📊 LSP 診断結果
| ファイル | エラー | 警告 |
|---------|--------|------|
| src/components/Form.tsx | 0 | 2 |
| src/utils/api.ts | 1 | 0 |
⚠️ 1件のエラーを検出
→ レビューで指摘事項に追加
Find-references による影響分析
🔍 変更影響分析
変更: validateInput()
参照箇所:
├── src/pages/signup.tsx:34
├── src/pages/settings.tsx:56
└── tests/validate.test.ts:12
→ テストでカバー済み ✅
VibeCoder 向け
📝 コードチェックを依頼するときの言い方
1. **「チェックして」**
- 全体的に問題がないか見てもらう
2. **「セキュリティ大丈夫?」**
- 悪意ある攻撃に耐えられるかチェック
3. **「遅くない?」**
- 速度に問題がないかチェック
4. **「誰でも使える?」**
- 障害のある方でも使えるかチェック
💡 ヒント: 「全部チェックして」と言えば、
4つの観点すべてを自動で確認します
More by Chachamaru127
View allSets up deployment, analytics, and health monitoring for projects. Use when user mentions デプロイ, deploy, Vercel, Netlify, 公開, アナリティクス, analytics, GA, Google Analytics, 環境診断, health check. Do NOT load for: 実装作業, ローカル開発, レビュー, セットアップ.
Implements features and writes code based on Plans.md tasks. Use when user mentions 実装, implement, 機能追加, コードを書いて, 機能を作って, feature, coding, 新機能, implementing functions, classes, or features, 新しい関数. Do not use for review or build verification.
Initializes session with environment check and task status overview. Use when user mentions セッション開始, 作業開始, 状況確認, what should I work on, start session. Do NOT load for: 実装作業, レビュー, セッション途中の作業.
Configures 2-Agent workflow between PM and implementation roles. Use when user mentions 2-Agent, 2エージェント, PM連携設定, Cursor設定, Cursor連携, 2-agent運用. Do NOT load for: 単独運用, ワークフロー実行, ハンドオフ処理.
