菜单
作業ブランチの diff を複数観点(レンズ)で並列レビューするオーケストレーションスキル。「レビューして」「diff をレビュー」「〇〇観点で見て」などユーザーが明示的にコードレビューを依頼したときに必ず使用する。決定論スクリプトで差分を収集し、レンズごとに diff-reviewer サブエージェントを並列起動して結果を統合報告する。コードの修正は行わない。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | diff-review |
| description | 作業ブランチの diff を複数観点(レンズ)で並列レビューするオーケストレーションスキル。「レビューして」「diff をレビュー」「〇〇観点で見て」などユーザーが明示的にコードレビューを依頼したときに必ず使用する。決定論スクリプトで差分を収集し、レンズごとに diff-reviewer サブエージェントを並列起動して結果を統合報告する。コードの修正は行わない。 |
| user-invocable | true |
| argument-hint | [レビュー範囲や観点(例: origin/main 以降 / security 観点も)。省略時は既定レンズで全差分] |
フローは 4 段階: 1. 差分収集(決定論)→ 2. レンズごとに diff-reviewer agent を並列起動 → 3. 統合報告 → 4. 証跡出力。 レビューは読み取り専用。修正・コミットはこのスキルの範囲外で、ユーザーの指示があってから別途行う。
<skill-dir> はこのファイルのあるディレクトリ。
bash <skill-dir>/scripts/collect-diff.sh manifest [<base-ref>]
NO_CHANGES が返ったら「レビュー対象の変更がない」と報告して終了するmanifest はメインセッションで 1 回だけ実行し、出力を次段で各 agent の prompt にそのまま注入する(agent 側に再収集させない)。メインセッションで精読・分析はしない。
design(設計・可読性)/ test(テスト設計・網羅性)security(セキュリティ / OWASP Top 10)/ docs(ドキュメント整合)/ performance(計算量・N+1・データサイズ)/ compat(互換性・移行安全)/ ops(可観測性・運用)/ concurrency(並行性)/ spec(仕様一致)/ fresh-eyes(初見)design、「テスト」→ test、「セキュリティ」「security」→ security、「ドキュメント」「docs」→ docs、「パフォーマンス」「性能」→ performance、「互換」「マイグレーション」「移行」→ compat、「運用」「ログ」「可観測性」→ ops、「並行」「排他」「race」→ concurrency、「仕様」「要件」「依頼どおり」→ spec、「初見」「fresh eyes」→ fresh-eyes適用ルール:
適用レンズ 1 つにつき diff-reviewer agent を 1 体、1 メッセージ内で同時に起動する(直列にしない)。各 agent の prompt には必ず以下を含める:
レンズ: <lens>
基準ファイル: ${CLAUDE_PLUGIN_ROOT}/skills/diff-review/references/<lens>.md(レビュー開始前に Read すること)
ユーザーの依頼: <元の依頼の要約(範囲・重点の指定があれば含める)>
以下は収集済みの差分 manifest。manifest の再実行はしない。全文 diff が必要な単位のみ
${CLAUDE_PLUGIN_ROOT}/skills/diff-review/scripts/collect-diff.sh の commit / worktree / cumulative で取得する
(agent は独立コンテキストのため、ここだけは相対パスでなく絶対パス変数のまま渡す):
<manifest の出力をそのまま貼る>
manifest を全 agent に同一内容で渡すことで、レビュー範囲のスナップショットを固定する。
報告を 1 つに統合し、diff-reviewer の報告形式(must / want+ / want / nit の severity 順)で出力する:
ファイルパス:行番号 に複数レンズの指摘が重なったら 1 件に統合する。severity は最も重いものを採用し、レンズタグを併記する(例: [design][security])[PLAUSIBLE] マークは統合後も維持する以下をすべて満たしたときのみレビュー完了とする。1 つでも欠けたら未完了:
統合報告の後、レビュー証跡を以下の形式で書き出す:
tasks/diff-review/evidence.md (git 管理外、毎回上書き)
commit: <レビュー時 HEAD の full SHA>
lenses: <実施レンズをカンマ区切り>
must: <このレビュー実行で検出した must 指摘の件数>
PR 作成前ゲート hook がこのファイルを検査する(存在 && commit==現 HEAD && must==0 で通過)。
内部実装を見ず、入出力仕様だけから入力空間の分割でテストケースを機械的に導くブラックボックス技法群。 test-catalog の手法カタログの一部。同値分割(Equivalence Partitioning)、境界値分析(Boundary Value Analysis)、 ドメイン分析テスト(Domain Analysis、多変数の境界on/off/in/out)、デシジョンテーブル(Decision Table、条件の組合せとアクション) を検証したい、または割り当てたいときに使う。通常は test-catalog スキルの索引経由で 手法が選定された後にこのスキルを直接参照する。
gitコミット運用ルール。**主目的は論理的に独立した修正を都度・適切な粒度でコミットすること**、および plan モードで実装計画を立てる際に必ずコミット計画を plan 本文に含めること。メッセージ形式は Conventional Commits。「コミットして」「コミット分けて」「コミット計画を立てて」「分けてコミット」「実装計画を立てて」「planを立てて」「実行計画を作って」「リファクタリング計画」と依頼される、`git commit`を実行する、ExitPlanMode 前に plan を提示する、複数の独立した修正をまとめるか分けるか判断する、レビューコメント対応をコミットする、rebase/squash で履歴を整える、`gh pr create`時にPRタイトルをコミット流儀に揃える等の場面で必ず参照する。変更を約30〜50行の論理単位へ分割してコミットを積む実務手順は micro-commit スキル側が担い、本スキルは粒度の判断基準・plan 段階のコミット計画・メッセージ規約を定める(併用時は本スキルの基準で分割単位を決め、micro-commit で実行する)。
テストが flaky になる要因のうち、処理どうしの協調(タイミング・順序)が定まらないものへの体系的対策。 test-catalog の手法カタログの一部。並行・競合(共有状態への同時アクセス、レース窓の検出と直列化による封じ込め)、 テスト間順序・状態漏れ(実行順シャッフルでの炙り出し、beforeEach/afterEachでの初期化・後始末)、 検出3軸と隔離(quarantine)・retry緑詐称の戒めといった flaky 対策の共通方針 を検証したい、または割り当てたいときに使う。通常は test-catalog スキルの索引経由で 手法が選定された後にこのスキルを直接参照する。
自然言語の要求を EARS 記法 + 状態/ドメインモデルへ構造化し、TLA+ で設計を網羅検査し、 TLC の反例を Gherkin の受け入れ仕様に落とすまでの 3 重フィードバックループの入口(ルーター)。 ユーザーが「ループエンジニアリング」「EARS」「TLA+」「Gherkin」「設計を検証」「状態機械を検査」 「要求を形式化」と言ったとき、または並行・状態遷移・プロトコル設計の正しさを実装前に モデル検査で固めたいときに使用する。起動判断(2 問ゲート)を通った後、工程は loopeng-extract → loopeng-formalize → loopeng-modelcheck → loopeng-gherkin の各スキルへ委譲する。 設計は TLA+、実装の数学的証明は formal-verification(Lean)。
Automatically create conventional commit-style micro-commits by splitting changes into logical units of ~30-50 lines each. Use this skill whenever the user asks to commit, says "コミットして", "commit this", or when a feature, fix, or refactoring task is completed and changes need to be committed. Also trigger when the user mentions "マイクロコミット", "micro commit", "conventional commit", or asks to split changes into smaller commits. If you detect that a coding task has just been completed and there are uncommitted changes, suggest using this skill. Grain-size judgment and plan-stage commit planning are handled by the commit-flow skill; when both apply, commit-flow decides the split and this skill executes it.
test-catalog の手法カタログの一部。非機能テストの測定系(性能テスト、負荷テスト、 ストレステスト、スパイクテスト、ソークテスト/耐久テスト、スケーラビリティテスト、 キャパシティテスト)を検証したいときに使う。通常は test-catalog スキルの索引経由で 手法が選定された後にこのスキルを直接参照する。