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.

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/harness-review" ~/.claude/skills/majiayu000-claude-skill-registry-harness-review && rm -rf "$T"
manifest: skills/data/harness-review/SKILL.md
source content

Review Skills

コードレビュー、計画レビュー、スコープ分析を担当するスキル群です。 コンテキストからレビュータイプを自動判定します。

レビュータイプ(Context-Aware)

レビュータイプはコンテキストから自動判定されます:

Recent ActivityReview Type4 Experts
/plan-with-agent
Plan ReviewClarity, Feasibility, Dependencies, Acceptance
/work
Code ReviewSecurity, Performance, Quality, Accessibility
タスク追加後Scope ReviewScope-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/OGPSee 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 ReviewClarity, Feasibility, Dependencies, Acceptance
../codex-review/references/experts/clarity-expert.md
Scope ReviewScope-creep, Priority, Feasibility, Impact
../codex-review/references/experts/scope-creep-expert.md

詳細: ../codex-review/references/codex-parallel-review.md

実行手順

  1. 品質判定ゲート(Step 0)
  2. 残コンテキスト確認(Codex モード時)(Step 1)
  3. ユーザーのリクエストを分類
  4. (Claude-mem 有効時)過去のレビュー指摘を検索
  5. 並列実行の判定(下記参照)
  6. 上記の「機能詳細」から適切な参照ファイルを読む、または並列サブエージェント起動
  7. 結果を統合してレビュー完了

入力の優先順位

  • 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.tsxviewport, OGP タグ, Twitter Card

クロスプラットフォーム重点レビュー

パスチェック項目
src/components/, app/レスポンシブ(固定幅チェック)
*.css, *.scss, tailwind100vw 使用、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影響を受けるエンドポイント

レビューフロー:

  1. 変更ファイルを特定
  2. LSP.findReferences
    で影響範囲を列挙
  3. 影響を受けるファイルも含めてレビュー

使用例:

# 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 ReviewSecurity, Performance, Quality, Accessibility
Plan ReviewClarity, Feasibility, Dependencies, Acceptance
Scope ReviewScope-creep, Priority, Feasibility, Impact

⚠️ Codex モード実行時の必須ルール

絶対に1回の MCP 呼び出しで複数エキスパートをまとめないこと。

✅ 正しい: 4回の MCP 呼び出しを1つのレスポンス内で並列実行
❌ 間違い: 1回の呼び出しで「全観点をレビューして」と依頼

実行手順:

  1. 呼び出すエキスパートを判定(全部ではなく必要なもののみ):
    • 設定で
      enabled: false
      → 除外
    • CLI/バックエンド → Accessibility, SEO 除外
    • ドキュメントのみ変更 → Quality, Architect, Plan Reviewer, Scope Analyst を優先(Security, Performance は除外可)
  2. 有効なエキスパートの
    experts/*.md
    からプロンプトを 個別に読み込む
  3. 有効なエキスパートのみ
    mcp__codex__codex
    1つのレスポンス内で並列実行
  4. 各結果を統合して判定

詳細: 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)を活用して精度を向上します。

重要:

/dev-tools-setup
で MCP サーバーが設定されている場合、標準ツール(Grep, Read)ではなく MCP ツールを優先使用してください。MCP ツールは構造的な検索が可能で、より正確な結果を得られます。

AST-Grep MCP ツール(harness_ast_search)

構造的なコードパターン検索に使用します。正規表現ベースの Grep より精度が高く、コードスメル検出に最適です。

検出パターンAST-Grep パターン用途
Debug logs
console.log($$$)
リリース前の残留ログ検出
Empty catch
catch ($ERR) { }
エラー握りつぶし検出
Unused async
async function $NAME($$$) { $BODY }
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
が利用できない場合は、
sg
コマンド(Bash)または Grep にフォールバックします。


🔧 LSP 機能の活用

レビューでは LSP(Language Server Protocol)を活用して精度を向上します。

MCP 版優先:

harness_lsp_*
MCP ツールが利用可能な場合は、標準 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

→ テストでカバー済み ✅

詳細: docs/LSP_INTEGRATION.md


VibeCoder 向け

📝 コードチェックを依頼するときの言い方

1. **「チェックして」**
   - 全体的に問題がないか見てもらう

2. **「セキュリティ大丈夫?」**
   - 悪意ある攻撃に耐えられるかチェック

3. **「遅くない?」**
   - 速度に問題がないかチェック

4. **「誰でも使える?」**
   - 障害のある方でも使えるかチェック

💡 ヒント: 「全部チェックして」と言えば、
4つの観点すべてを自動で確認します