メニュー
Review code changes against requirements and quality standards before merge. Use when dispatching a review subagent, after major features, before merging, or when the user asks for a code review. Requires reading the actual diff.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | code-reviewer |
| description | Review code changes against requirements and quality standards before merge. Use when dispatching a review subagent, after major features, before merging, or when the user asks for a code review. Requires reading the actual diff. |
Senior code review: compare implemented work to requirements/plan, read the actual diff, and catch issues before they cascade. Produce a written review only — do not modify code unless the user explicitly asks you to fix findings.
Core principle: Review early, review often. Never approve code you did not read.
Bar for merge: All project tests pass, including edge-case and stress coverage for changed behavior. "Happy path only" is not sufficient — hunt difficult inputs until confidence is justified or gaps are filed as blocking issues.
Project-specific stacks, test commands, and domain rules live in that repo's
CLAUDE.md and .claude/rules/ — apply them after this generic pass.
Mandatory:
Optional:
| Input | What to fill in |
|---|---|
| Description | Brief summary of what was built |
| Plan / requirements | Task text, plan file path, issue, or acceptance criteria |
| Git range | BASE_SHA … HEAD_SHA, or explicit file list if uncommitted |
git diff --stat {BASE_SHA}..{HEAD_SHA}
git diff {BASE_SHA}..{HEAD_SHA}
If work is uncommitted: git diff and git diff --cached, or review named paths.
git diff --stat then the full diff; open changed files for context
(callers, tests, config) — not only hunks.pytest, npm test, etc.).
Re-run after any fix loop until everything is green before a Yes verdict.Treat untested or failing edge behavior as bugs until proven otherwise.
Reviewer must:
pytest path/to/test_foo.py -k edge, minimal
repro scripts, property/fuzz checks where the repo supports them.Implementer must (before requesting review):
Difficult cases to consider (adapt to domain):
| Category | Examples |
|---|---|
| Empty / minimal | n=0, empty list, single element, unset optional |
| Boundaries | off-by-one, max length, overflow, saturation |
| Invalid input | wrong type, out-of-range, malformed config |
| Failure modes | I/O error, timeout, partial write, OOM handling |
| Concurrency | race, double init, non-idempotent retry |
| Numerics | NaN, Inf, denormal, ill-conditioned, dtype mismatch |
If stress tests cannot be run (missing GPU, data, credentials), say so explicitly and lower confidence — do not imply full verification.
pytest: 142 passed)Categorize by actual severity — not everything is Critical.
Use exactly these sections:
[Specific, file-backed positives. If none after reading, say what you checked.]
[Bugs, security, data loss, broken functionality, wrong results]
[Missing features, architecture problems, weak error handling, test gaps]
[Style, micro-optimizations, doc polish]
For each issue:
[Optional improvements to code, architecture, or process — not blocking]
Ready to merge? Yes | No | With fixes
Reasoning: [1–2 sentences, technical]
Tests: [command run, pass/fail count; edge/stress cases run or gaps noted]
Yes only if: diff read, plan met, full test suite green, and no unresolved
Critical/Important issues (including missing edge coverage for high-risk paths).
State which files you read and which tests you ran.
DO:
path:line, not "improve error handling")DON'T:
When spawning a reviewer, pass only work product context — not the implementer's full chat history:
You are a code reviewer. Apply the **code-reviewer** skill.
## What was implemented
{DESCRIPTION}
## Requirements / plan
{PLAN_OR_REQUIREMENTS}
## Git range
Base: {BASE_SHA}
Head: {HEAD_SHA}
Run:
git diff --stat {BASE_SHA}..{HEAD_SHA}
git diff {BASE_SHA}..{HEAD_SHA}
Also read: {PROJECT_CLAUDE_MD} and project test commands if present.
Run the full test suite. Stress-test edge cases for changed code. Do not approve
unless all tests pass and edge coverage is adequate for the diff.
Output per the skill's format. Do not modify code.
For receiving review feedback: verify each item against the codebase before implementing; clarify unclear items before partial fixes; no performative agreement — state the fix or ask a technical question.
CLAUDE.md for stack-specific gates (JAX, GPU limits, etc.).Deep-read an academic paper and produce a durable, critical research note — not a loose summary. Use when given a paper title, DOI, arXiv ID, publisher/PDF/GitHub URL, or local PDF, or when asked to read closely, summarize, extract contributions, analyze experiments, critique, compare to related work, reproduce results, or maintain a paper-reading repository index. Works across fields (astro/physics, ML, bio, security, …); examples lean astro-ph but the workflow is general.
Remote, slice-level access to FLAMINGO HDF5 files on COSMA via the `hdfstream` Python module — no need to download whole snapshots. Covers install, server connection, navigation, dataset slicing, multi-slice batched reads, and integration with swiftsimio. Use when reading any FLAMINGO data product remotely.
FLAMINGO past-lightcone products: virtual observers, particle lightcones, HEALPix shell maps, integrated_maps, and halo lightcones. Use when building mock surveys, stacking Compton-y or lensing maps, or cross-correlating with observations.
Style and structure for research manuscript text: IMRaD, hourglass narrative, formal tone, topic sentences, reproducible Methods, captions that tell the story. Use when drafting or editing titles, abstracts, sections, captions, or reports.
Iterative VLM review of compiled LaTeX PDFs for layout clashes (text vs figures, tables, long equations). Use after the first compile or any float/equation edit; loop fix-recompile-recheck until no clashes remain.
End-to-end research paper workflow: plan the narrative, draft IMRaD sections, produce figure assets, compile LaTeX to PDF, and debug layout by visually inspecting output (VLM). Use when starting, editing, or submitting a manuscript.