Claude-skill-registry harness-review
Multi-perspective review supporting code, plan, and scope analysis. Auto-detects review type from context. Use when user mentions reviews, code review, plan review, scope analysis, security, performance, quality checks, PRs, diffs, or change review. Do NOT load for: implementation work, new feature development, bug fixes, or setup.
git clone https://github.com/majiayu000/claude-skill-registry
T=$(mktemp -d) && git clone --depth=1 https://github.com/majiayu000/claude-skill-registry "$T" && mkdir -p ~/.claude/skills && cp -r "$T/skills/data/harness-review" ~/.claude/skills/majiayu000-claude-skill-registry-harness-review && rm -rf "$T"
skills/data/harness-review/SKILL.mdReview Skills
コードレビュー、計画レビュー、スコープ分析を担当するスキル群です。 コンテキストからレビュータイプを自動判定します。
レビュータイプ(Context-Aware)
レビュータイプはコンテキストから自動判定されます:
| Recent Activity | Review Type | 4 Experts |
|---|---|---|
後 | Plan Review | Clarity, Feasibility, Dependencies, Acceptance |
後 | Code Review | Security, Performance, Quality, Accessibility |
| タスク追加後 | Scope Review | Scope-creep, Priority, Feasibility, Impact |
手動指定
/harness-review # 自動判定 /harness-review code # コードレビュー強制 /harness-review plan # 計画レビュー強制 /harness-review scope # スコープ分析強制
機能詳細(Code Review)
| 機能 | 詳細 |
|---|---|
| 変更レビュー | 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 |
機能詳細(Plan/Scope Review)
Plan Review と Scope Review は Codex エキスパートを使用します:
| レビュータイプ | エキスパート | 参照 |
|---|---|---|
| Plan Review | Clarity, Feasibility, Dependencies, Acceptance | 等 |
| Scope Review | Scope-creep, Priority, Feasibility, Impact | 等 |
詳細: ../codex-review/references/codex-parallel-review.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 並列レビュー(レビュータイプごとに4エキスパート)
Default モード(Claude 単体)
Claude が直接レビューを実行。小〜中規模の変更に最適。
Codex モード(並列エキスパート)
Codex MCP 経由でレビュータイプに応じた4つのエキスパートを 個別に並列呼び出し:
| Review Type | エキスパート |
|---|---|
| Code Review | Security, Performance, Quality, Accessibility |
| Plan Review | Clarity, Feasibility, Dependencies, Acceptance |
| Scope Review | Scope-creep, Priority, Feasibility, Impact |
⚠️ Codex モード実行時の必須ルール
絶対に1回の MCP 呼び出しで複数エキスパートをまとめないこと。
✅ 正しい: 4回の MCP 呼び出しを1つのレスポンス内で並列実行 ❌ 間違い: 1回の呼び出しで「全観点をレビューして」と依頼
実行手順:
- 呼び出すエキスパートを判定(全部ではなく必要なもののみ):
- 設定で
→ 除外enabled: false - CLI/バックエンド → Accessibility, SEO 除外
- ドキュメントのみ変更 → Quality, Architect, Plan Reviewer, Scope Analyst を優先(Security, Performance は除外可)
- 設定で
- 有効なエキスパートの
からプロンプトを 個別に読み込むexperts/*.md - 有効なエキスパートのみ
を 1つのレスポンス内で並列実行mcp__codex__codex - 各結果を統合して判定
詳細: 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)を順次読み込んで直列実行
🔧 MCP Code Intelligence ツールの活用
レビューでは MCP ツール(AST-Grep, LSP)を活用して精度を向上します。
重要:
で MCP サーバーが設定されている場合、標準ツール(Grep, Read)ではなく MCP ツールを優先使用してください。MCP ツールは構造的な検索が可能で、より正確な結果を得られます。/dev-tools-setup
AST-Grep MCP ツール(harness_ast_search)
構造的なコードパターン検索に使用します。正規表現ベースの Grep より精度が高く、コードスメル検出に最適です。
| 検出パターン | AST-Grep パターン | 用途 |
|---|---|---|
| Debug logs | | リリース前の残留ログ検出 |
| Empty catch | | エラー握りつぶし検出 |
| Unused async | | await なし async 検出 |
| Magic numbers | 数値リテラル検索 | ハードコード定数検出 |
使用例:
harness_ast_search pattern="console.log($$$)" language="typescript" path="src/" harness_ast_search pattern="catch ($ERR) { }" language="typescript" path="src/"
出力例:
🔍 AST-Grep Code Smell Scan Patterns checked: - console.log($$$) → Debug logs - catch ($ERR) { } → Empty catch blocks Results: ├── 3x console.log found (src/api/*.ts) ├── 1x empty catch block (src/utils/error.ts:45) └── 0x unused async
注:
が利用できない場合は、harness_ast_searchコマンド(Bash)または Grep にフォールバックします。sg
🔧 LSP 機能の活用
レビューでは LSP(Language Server Protocol)を活用して精度を向上します。
MCP 版優先:
MCP ツールが利用可能な場合は、標準 LSP ツールより優先して使用してください。harness_lsp_*
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つの観点すべてを自動で確認します