Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/mh4gf/claude-code/reviewnpx skills add MH4GF/claude-code --skill reviewgit clone --depth 1 https://github.com/MH4GF/claude-codeWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00257 | $0.01712 |
| Opus 5 | $0.00129 | $0.00856 |
| Sonnet 5 | $0.00051 | $0.00342 |
| Haiku 4.5 | $0.00026 | $0.00171 |
Grade A, and why
review scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 3d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 103 lines — stays where its author put it; the contents beside it link to each section on GitHub.
review
ブランチ diff の構造化レビューを担うメタレイヤ skill。観点を自前で抱え込まない方針を取る。次のとおり委譲する
- 表層ノイズ → deslop
- 設計レベル → thermo-nuclear
- 言語固有 (TS / Go) → ts-review / go-review
- ナラティブ (markdown / script / 設定) → narrative-review
review 自身は呼び出しと振り分け、最終レポートのまとめだけを行う。
守ること
振る舞いはレポート-only に限定する。コードへの edit は一切しない。HOTL 原則の徹底で、ユーザーが「自分のレビューを通すまで外へは何も出したくない」と明言している。
観点を網羅できる気がしても重複指摘を作らない。同じ箇所へ複数の角度から書くと明確に嫌われる。
該当なしの場合は「指摘事項なし」と明記する。でっちあげは禁止。
文体は日本語、箇条書き、簡潔。長文ナラティブは書かない。
フロー
1. 対象 diff の特定
PR URL / branch / コミット範囲の指定をユーザーへ確認する。未指定なら git diff origin/main...HEAD を既定とする。main の無いリポでは master、ユーザーの明示があるならそれに従う。
2. 変更ファイルの言語振り分け
git diff --name-only origin/main...HEAD | sort -u
拡張子で振り分ける
*.ts/*.tsx→ ts-review skill を呼ぶ*.go→ go-review skill を呼ぶ*.md/*.sh/*.sb/*.json→ narrative-review skill を呼ぶ- それ以外 (
*.sql/*.rs等) はこの skill で直接見る
混在時は該当する子 skill を順に呼び、それぞれの指摘事項をまとめる。
3. 表層ノイズの委譲判定
deslop が表層ノイズ (過剰コメント / 防御的 try/catch / 不要 any / 深ネスト / 周辺と不整合な書き方) を担当している。表層ノイズが多そうなら自分で同じ観点を書かず、/deslop の先行実行をユーザーへ提案する。流さない判断なら表層は軽く言及して終わる。
4. 設計再フレーミング機会の委譲判定
設計レベル (1000 行越え / レイヤ越境 / スパゲッティ成長 / 薄いラッパー) を見て「構造ごと消せそう」と感じたら、自身では深追いせず、候補だけ列挙して /thermo-nuclear-code-quality-review を呼ぶか確認する。thermo-nuclear は重く尖ったレビューなので、明示要求が無い限り起動しない。
5. 残った領域を直接レビュー
言語別 skill / deslop / thermo-nuclear のいずれにも当てはまらない領域を自分で見る。代表的には次のとおり
- 命名 — 関数 / 変数 / ファイルの命名が周辺と揃っているか
- 凝集 — 1 関数が複数の責務を抱えていないか
- API 設計 — 公開関数の signature が呼び出し側で扱いづらくないか
- 規約遵守 — 周辺コードと書き方が乖離していないか (フォーマッタが見ない範囲)
報告フォーマット
次のテンプレで出力する。
## レビュー結果
対象: `<base>...<head>` (変更 <N> ファイル)
### 指摘事項
- `path/to/file.ts:42` — 現状: <観察> / 問題: <なぜ良くないか> / 提案: <修正案>
- `path/to/file.ts:80` — ...
### 委譲提案
- 表層ノイズが <件数> あり。`/deslop` で一括検出を推奨
- 設計再フレーミング候補が <件数> あり。`/thermo-nuclear-code-quality-review` で深掘り推奨
(該当なしの場合は「指摘事項なし」と書く)
優先度は付けない。挙げた指摘事項はすべて呼び出し元が対応する前提。
子 skill を呼ぶときの注意
ts-review / go-review / narrative-review を呼ぶときは、対象ファイルパスを引数で渡す。
/ts-review <file1>.ts <file2>.tsx
/go-review <file1>.go <file2>.go
/narrative-review <file1>.md <file2>.sh
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 3d ago First seen · 103 lines · 257 tokens per session scan A a8c7011a216b
review is a skill published in the GitHub repository MH4GF/claude-code (2 stars, last pushed 4d ago), licensed MIT. It adds 257 tokens to every session and 1,712 once invoked, about $0.0013 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
systematic-debugging
Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes.
brainstorming
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.
auto-perf-optimize
Run agent-driven VS Code performance or memory investigations. Use when asked to launch Code OSS, automate a VS Code scenario, run the Chat memory smoke runner, capture renderer heap snapshots, take workflow screenshots, compare run summaries, or drive a repeatable scenario before heap-snapshot analysis.
chat-perf
Run chat perf benchmarks and memory leak checks against the local dev build or any published VS Code version. Use when investigating chat rendering regressions, validating perf-sensitive changes to chat UI, or checking for memory leaks in the chat response pipeline.
chat-pet-sprite-creation
Use when creating or changing VS Code chat pet sprite art, sprite sheets, state animations, eye treatments, Stable/Insiders variants, or pet transitions under src/vs/workbench/contrib/chat/browser/widget/media/chatPet.
cpu-profile-analysis
Analyze V8/Chrome CPU profiles (.cpuprofile) and DevTools trace files (Trace-.json). Use when: profiling performance, investigating slow functions, comparing code paths, finding bottlenecks, analyzing timeToRequest, understanding call trees from sampling profiler data, analyzing layout/paint/rendering, investigating…