Borrowing it
Nothing to install: this file belongs to dinhnguyenngoc/spec-driven-claude-code. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.
curl -O https://raw.githubusercontent.com/dinhnguyenngoc/spec-driven-claude-code/main/.claude/skills/code-review/SKILL.mdgit clone --depth 1 https://github.com/dinhnguyenngoc/spec-driven-claude-codeWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/dinhnguyenngoc/spec-driven-claude-code/code-review)<a href="https://agentmods.dev/skills/dinhnguyenngoc/spec-driven-claude-code/code-review"><img src="https://agentmods.dev/badge/skills/dinhnguyenngoc/spec-driven-claude-code/code-review/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/dinhnguyenngoc/spec-driven-claude-code/code-review"><img src="https://agentmods.dev/badge/skills/dinhnguyenngoc/spec-driven-claude-code/code-review.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector pass
What 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.1 | $0.00011 | $0.01487 |
| Opus 5.5 | $0.00004 | $0.00595 |
| Sonnet 5.5 | $0.00002 | $0.00297 |
| Haiku 4.5 | $0.00001 | $0.00149 |
Grade A, and why
code-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 1mo 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 — 223 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Code Review & Quality Skill
Philosophy
"Approve a change when it definitely improves overall code health, even if it isn't perfect."
Progress over perfection. Continuous incremental improvement.
Five-Axis Review Framework
Canonical detail:
../../references/code-review-checklist.md. This skill lists the axes as an executable pass; the exhaustive per-axis checklist lives there — keep in sync.
Axis 1: Correctness
Questions to ask:
- Does the implementation match the specification?
- Are edge cases handled?
- Are error paths covered?
- Are there potential runtime issues?
- Off-by-one errors
- Race conditions
- Null/undefined access
- Resource leaks
Test adequacy:
- Do tests verify the claimed behavior?
- Are negative cases tested?
- Would a bug slip through?
- Scenario coverage · anti-vacuous · dual-implementation parity — apply the three
Correctness checks canonical in
commands/review.md§Cross-layer conformance (a test that would still pass with the feature removed proves nothing).
Axis 2: Readability & Simplicity
Questions to ask:
- Can another engineer understand this without explanation?
- Are names clear and descriptive?
- Is control flow straightforward?
- Is the code organized logically?
Complexity checks:
- Deep nesting (> 3 levels)?
- Long functions (> 30 lines)?
- Clever tricks that obscure intent?
- Unnecessary abstractions?
Axis 3: Architecture
Questions to ask:
- Does this follow existing patterns in the codebase?
- Are module boundaries respected?
- Is there code duplication that should be extracted?
- Is the abstraction level appropriate?
- Do dependencies flow in the right direction?
Over-engineering checks:
- Is this simpler than it needs to be?
- Are there abstractions "for future use"?
- Would a simpler approach work?
Axis 4: Security
Input validation:
- Is user input validated and sanitized?
- Are queries parameterized?
- Is output properly encoded?
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.
- 1mo ago First seen · 223 lines · 11 tokens per session scan A 8900ccf49099
code-review is a skill published in the GitHub repository dinhnguyenngoc/spec-driven-claude-code (21 stars, last pushed 2mo ago), licensed MIT. It adds 11 tokens to every session and 1,487 once invoked, about $0.0000 per session on Opus 5.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-30.
Other skills, from other repositories
gsd-ns-review
Invoke this Pi skill with /skill:gsd-ns-review.
spec-kitty-mission-review
Review a fully merged Spec Kitty mission post-merge (all WPs done/approved) to verify spec→code fidelity, FR coverage, drift, risks, and security. Triggers: "review the merged mission", "post-merge mission review", "verify the completed mission", "audit the mission implementation", "mission-level acceptance review"…
review
Review code changes for security, performance, bugs, and quality. Reviews staged changes, unstaged changes, specific commits, or PR-ready diffs.
release
Cut a brooks-lint release: set the version in package.json, propagate it across all four plugin manifests and every version-bearing text file (README badges, docs site metadata), write the CHANGELOG entry, validate, then commit, push, tag, and publish the GitHub release. Triggers when the maintainer asks to "release"…
spec-kitty-runtime-review
Review runtime-owned outputs using the Spec Kitty review workflow surface, then direct approval or rejection with structured feedback. Triggers: "review this work package", "check runtime output", "approve this step", "review WP", "is this WP ready to approve", "check this implementation". Does NOT handle: setup-only…
new-skill
Scaffold a new brooks-lint analysis skill so it passes npm run validate and npm run evals on the first try — generates skills/{name}/SKILL.md (with the mandatory "Do NOT trigger for:" clause and a Process section citing guide step ranges) plus skills/{name}/{name}-guide.md (sequentially numbered steps), then appends…