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/dinhnguyenngoc/spec-driven-claude-code/code-reviewnpx skills add dinhnguyenngoc/spec-driven-claude-code --skill code-reviewgit 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.svg" alt="Measured on agentmods" height="20"></a>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 | $0.00011 | $0.01487 |
| Opus 5 | $0.00005 | $0.00744 |
| Sonnet 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 4d 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.
- 4d 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 (20 stars, last pushed 5d ago), licensed MIT. It adds 11 tokens to every session and 1,487 once invoked, about $0.0001 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-30.
Other skills, from other repositories
specx-component-architecture
Design or review specx core scope boundaries in Python services. Use when deciding where code belongs across packaged scoped foundation bases, optional local foundation extensions, core/, capabilities, delivery, infrastructure, shared/, and ioc; when adding guardrails or splitting use cases, services, DTOs, schemas…
specx-project-structure
Create or reshape a Python FastAPI service repo into the specx clean core/delivery architecture using packaged scoped foundation bases. Use when starting an API backend, adding the first src package, or establishing AGENTS.md, core/, optional local foundation/, delivery/, infrastructure, ioc/, migrations, and tests.
specx-tests
Add or refine tests for specx Python services. Use when creating unit tests for use cases/services, integration tests for FastAPI controllers or infrastructure adapters, e2e smoke tests, architecture import guardrails, DI override tests, pytest fixtures, or coverage and boundary checks.
specx-diwire-composition
Wire dependency injection for a specx Python service with diwire. Use when adding ioc/container.py, explicit dependency registrations for capabilities, repositories, gateways, UoW managers, clients, settings, or factories, Injected[...] constructor fields, FastAPI app factory/lifecycle composition, test overrides, or…
specx-add-core-use-case
Add or refactor a specx core scope use case. Use when implementing an externally meaningful application action under a core scope usecases package, adding same-file command/query inputs, result DTOs, coordinating services, opening a unit-of-work transaction, or moving behavior out of delivery or infrastructure into…
specx-add-infrastructure-adapter
Add technical infrastructure adapters for specx core scopes. Use when implementing SQLAlchemy repositories and Alembic-backed persistence, Redis stores, HTTP/network clients, file or queue adapters, unit-of-work implementations, gateway implementations for external APIs or SDKs such as OpenAI, or explicit diwire…