Diff review

Skill yasunori0418/skills/skills/git/diff-review

作業ブランチの diff を複数観点(レンズ)で並列レビューするオーケストレーションスキル。「レビューして」「diff をレビュー」「〇〇観点で見て」などユーザーが明示的にコードレビューを依頼したときに必ず使用する。決定論スクリプトで差分を収集し、レンズごとに diff-reviewer サブエージェントを並列起動して結果を統合報告する。コードの修正は行わない。From its SKILL.md

Install

npx -y skills add yasunori0418/skills --skill diff-review

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

9 stars9 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

11.9 KB, as published. Nobody here has run it

diff-review: 並列多観点 diff レビュー

フローは 3 段階: 1. 差分収集(決定論)→ 2. レンズごとに diff-reviewer agent を並列起動 → 3. 統合報告。レビューは読み取り専用。修正・コミットはこのスキルの範囲外で、ユーザーの指示があってから別途行う。

1. 差分収集

以下、<SKILL_DIR> はこのスキルの base directory(スキル起動時に表示される絶対パス)を指す。 agent への prompt に埋め込むときは必ず実際の絶対パスに展開する(<SKILL_DIR> のまま渡さない)。

<SKILL_DIR>/scripts/collect-diff.sh manifest [<base-ref>] を実行する。

出力: レビュー範囲(base / head の sha)・コミット一覧と統計・未コミット変更・未追跡ファイル・除外ファイル(lockfile 等は統計のみ)。総変更が小さければ全文 diff も同梱される
NO_CHANGES が返ったら「レビュー対象の変更がない」と報告して終了する
ユーザーがコミット範囲・ファイル等を指定した場合は base-ref 引数で範囲を合わせる

GROUND_TRUTH 節(あるときだけ現れる)

リポジトリに仕様・基本設計・テストケース(docs/dev/<対象>/spec.md 等)、規定パス外の仕様らしきファイル、またはタスク境界ファイル(.claude/task-boundary.json)があると、manifest に == GROUND_TRUTH == 節が追記される。無いリポジトリでは節ごと出ず、以降の分岐もすべて発火しない(従来動作)。

節は 3 系統を区別して出す:

節の内容	扱い
`対象: <名前>` + 規定パス / `明示指定(DIFF_REVIEW_GROUND_TRUTH)`	確定。そのまま判断基準に使う
`候補(規定パス外...)`	未確定。採否をユーザーに確認するまで判断基準に使わない(次項)
`タスク境界ファイル: ...`	各指摘にスコープ分類(境界内 / 境界外)を付けさせる

確定分が 1 つ以上あるとき、全レンズの prompt に共通ガードを追加し、spec レンズを既定に昇格する。確定分が無ければ従来どおり(共通ガードなし・既定レンズは design / test・全指摘を境界内として扱う)。

manifest はメインセッションで 1 回だけ実行し、出力を次段で各 agent の prompt にそのまま注入する(agent 側に再収集させない)。メインセッションで精読・分析はしない。

候補が出たときの確定手順(agent 起動前に必ず行う)

仕様書が docs/dev/ の規定パスに無く tmp_claude/ や design/ 等に置かれている場合、機械検出だけでは判断基準に載らず、仕様に根拠のある実装を「過剰・不要」と誤指摘する(オーバーレビュー)。候補節はこれを防ぐための提示であり、未確定のまま agent に渡してはいけない。

候補節があれば、agent を起動する前に AskUserQuestion で採否を確認する。選択肢は「列挙された候補を判断基準にする(推奨)」「一部だけ使う(パスを指定)」「使わない(候補は無視)」。質問の要点と候補パスはメッセージ本文にも列挙する
ユーザーが依頼文で仕様書のパスを既に示している場合(@path/to/spec.md 等)、この確認は省略し、そのパスを確定として扱う
採用が決まったパスを DIFF_REVIEW_GROUND_TRUTH に渡して manifest を再実行する (: 区切りで複数指定可。相対パスはリポジトリルート起点):
```
DIFF_REVIEW_GROUND_TRUTH="tmp_claude/20260715_foo_spec.md" <SKILL_DIR>/scripts/collect-diff.sh manifest [<base-ref>]
```
再実行後の manifest では採用パスが「明示指定」として確定側に並び、共通ガードと spec レンズ昇格が発火する
「使わない」が選ばれたら候補は無視し、確定分が無いものとして従来動作で進む

2. レンズ決定と並列起動

レンズ registry

既定(無指定時に適用): design(設計・可読性)/ test(テスト設計・網羅性)
条件付き既定: spec(仕様適合・あるべき変更の欠落)— manifest に GROUND_TRUTH 節があるときのみ既定に昇格する。節が無ければオプション扱い(明示指定時のみ)
オプション(指定時のみ適用): security(セキュリティ / OWASP Top 10)/ docs(ドキュメント整合)/ performance(計算量・N+1・データサイズ)/ compat(互換性・移行安全)/ ops(可観測性・運用)/ concurrency(並行性)
キーワード対応: 「設計」「可読性」→ design、「テスト」→ test、「仕様」「要求」「REQ」→ spec、「セキュリティ」「security」→ security、「ドキュメント」「docs」→ docs、「パフォーマンス」「性能」→ performance、「互換」「マイグレーション」「移行」→ compat、「運用」「ログ」「可観測性」→ ops、「並行」「排他」「race」→ concurrency

適用ルール:

追加指定(例: 「〇〇観点も見て」): 既定レンズに加えて指定レンズを適用する
絞り込み指定(例: 「〇〇だけ」「〇〇のみで」): 指定レンズだけを適用する。この場合 spec の昇格も行わない(ユーザーの明示指定が優先)
registry に無い観点を指定されたら、その観点名で agent を 1 体起動し一般知識でレビューさせる

並列起動

適用レンズ 1 つにつき diff-reviewer agent を 1 体、1 メッセージ内で同時に起動する(直列にしない)。

起動方式(厳守): Agent ツールを 1 メッセージ内に複数並べて直接起動し、各 agent の最終テキストを戻り値として受け取る。

エージェントチームを構成しない。team として起動する引数(team_name / name など、agent に識別名を与えて独立セッション化するもの)は使わない。チーム化すると結果の受け渡しが完了通知・SendMessage 経由の非同期経路になり、通知の取りこぼしでレビューを完走しても結果が親に届かず空転する事故が実際に起きている。 Agent の戻り値はハーネスが保証する同期経路なので取りこぼしが構造的に起こらない
「並列で走らせる」と「チームを組む」は別物。並列は必須、チーム化は禁止。この 2 つは両立する
起動後に完了通知・SendMessage を待ち受けて sleep で待機しない。Agent の戻り値が返った時点で結果は揃っている
万一いずれかの agent から結果が返らなかった場合は、待機を続けずそのレンズを「結果なし」として扱い、統合報告にその旨を明記する(必要なら当該レンズだけ再起動する)

各 agent の prompt には必ず以下を含める:

レンズ: <lens>
基準ファイル: <SKILL_DIR>/references/<lens>.md(レビュー開始前に Read すること)
ユーザーの依頼: <元の依頼の要約(範囲・重点の指定があれば含める)>

以下は収集済みの差分 manifest。manifest の再実行はしない。全文 diff が必要な単位のみ
<SKILL_DIR>/scripts/collect-diff.sh の commit / worktree / cumulative で取得する:

<manifest の出力をそのまま貼る>

manifest を全 agent に同一内容で渡すことで、レビュー範囲のスナップショットを固定する。

GROUND_TRUTH 節があるときの追記(全レンズ共通)

manifest に == GROUND_TRUTH == 節があるときに限り、全レンズの prompt に次のブロックを追記する (節が無いときは一切追記しない):

共通ガード(グラウンドトゥルース検出時):
- 仕様・テストケースに根拠のある実装を「過剰・不要」と指摘しない
- 削除・簡略化を提案する場合は、manifest の GROUND_TRUTH 節に挙がった spec.md / basic-design.md /
  test-case.md を確認し、REQ-# / CASE-# に抵触しないことを確かめてから指摘する
- 確認できない場合は指摘を出さないか [PLAUSIBLE] を付けて残す

節にタスク境界ファイル(.claude/task-boundary.json)の内容が含まれているときは、さらに次を追記する:

スコープ分類(タスク境界ファイル検出時):
各指摘に「タスク境界内」「境界外」の分類を付ける。判定は境界ファイルの allow glob と
指摘対象のファイルパスの照合による。allow に一致すれば境界内、一致しなければ境界外
(別タスク・別 PR で対応すべき指摘)。境界外の指摘は消さずに分類だけ付けて報告する。

境界ファイルが無ければこの追記はせず、全指摘を境界内として扱う(従来動作)。

3. 統合報告

受領突合(統合前に必ず行う)

統合に入る前に、起動したレンズ数と結果を受け取ったレンズ数を突合する。起動形態が何であれ、レビュアーの結果は最終テキストとして残る前提なので、欠落は必ず検知できる:

起動したレンズを列挙する(例: design / test / spec の 3 体)
各レンズについて、severity セクションを備えた報告本文を受け取れたかを確認する。完了通知・申し送りだけで指摘本文が無いものは未受領として数える
未受領のレンズがあれば、待機せずそのレンズだけ再起動する(同じ manifest・同じ prompt を渡す)
再起動しても受け取れなかったレンズは「結果なし」として確定し、統合報告の冒頭に どのレンズが欠落したかを明記する。欠落を黙って省略してはいけない (「3 レンズで見た」と読める報告を 2 レンズ分の内容で出すことが最も危険)

再起動は 1 レンズにつき 1 回まで。2 回目も駄目なら欠落として報告し、ユーザーの判断を仰ぐ。

統合

全レンズの受領を確認後、報告を 1 つに統合し、diff-reviewer の報告形式(must / want+ / want / nit の severity 順)で出力する:

冒頭に「対象: <範囲> / レンズ: <適用レンズ(受領/起動の内訳)>」を明記する
同一 ファイルパス:行番号 に複数レンズの指摘が重なったら 1 件に統合する。severity は最も重いものを採用し、レンズタグを併記する(例: [design][security])
[PLAUSIBLE] マークは統合後も維持する
全レンズで指摘ゼロなら「指摘なし」と明言する。褒め言葉・社交辞令は書かない

タスク境界ファイルが manifest にあった場合、統合報告をスコープで二分する:

「タスク境界内」節に境界内の指摘を severity 順で並べる(この節が主たる修正対象)
「境界外(別タスク・別 PR で対応)」節に境界外の指摘を並べ、各件に境界外と判定した理由 (どの allow glob にも一致しないパスであること)を 1 文で添える
分類が agent 間で割れた指摘は境界内側に寄せる(見落としを避ける)

境界ファイルが無ければ二分せず、従来どおり severity 順の 1 本の並びで報告する。