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 skills add SylphAI-Inc/atskills --skill code-reviewgit clone --depth 1 https://github.com/SylphAI-Inc/atskillsWrote 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/sylphai-inc/atskills/code-review)<a href="https://agentmods.dev/skills/sylphai-inc/atskills/code-review"><img src="https://agentmods.dev/badge/skills/sylphai-inc/atskills/code-review.svg" alt="Measured on agentmods" 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.00016 | $0.00697 |
| Opus 5 | $0.00008 | $0.00349 |
| Sonnet 5 | $0.00003 | $0.00139 |
| Haiku 4.5 | $0.00002 | $0.00070 |
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 8d 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 — 47 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Code Review Workflow
Review the given diff, pull request, or set of changed files as a careful senior engineer would — looking for correctness, safety, and maintainability issues, not just style nits.
Steps
-
Understand intent first. Read the PR description / commit messages / linked issue before reading the diff line-by-line. Know what problem the change is supposed to solve before judging whether it solves it.
-
Trace the change end-to-end. For each modified function/module, identify every caller and every downstream consumer of its output. A change that looks correct in isolation can still break a caller that assumed the old behavior.
-
Check correctness before style. In priority order:
- Logic errors — off-by-one, incorrect conditionals, wrong operator, inverted boolean logic.
- Error handling — are error/exception paths handled, or silently swallowed? Are edge cases (empty input, null/None, zero, max values) covered?
- Concurrency/state — race conditions, shared mutable state, missing locks/transactions where needed.
- Security — unsanitized input reaching a query/shell/template, secrets in code, missing auth checks on new endpoints.
- Resource handling — unclosed files/connections, unbounded loops/memory growth, missing timeouts.
-
Check test coverage. Does the diff include tests for the new/changed behavior? Do the tests actually exercise the changed logic, or do they just assert trivial properties (tautological tests)? Are edge cases from step 3 covered?
-
Check for duplication and reuse. Does this diff reimplement something that already exists elsewhere in the codebase (a date formatter, a retry helper, an API client)? Prefer reusing/extending existing utilities over introducing parallel implementations.
-
Check the blast radius. Is the change scoped to what the task requires, or does it touch unrelated files/formatting/comments? Flag unrelated changes explicitly — they hide the real diff and increase review risk.
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.
- 8d ago First seen · 47 lines · 16 tokens per session scan A 0bbb2d8d20e8
code-review is a skill published in the GitHub repository SylphAI-Inc/atskills (82 stars, last pushed 16d ago), licensed MIT. It adds 16 tokens to every session and 697 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
quality-gate
Orchestrates the QUALITY pipeline stage for egregore work items, running code review, unbloat, and test updates. Use when running quality checks before a PR.
plugin-review
Review plugin quality with tiered checks and dependency scoping. Use for PR and pre-release audits.
plugin-quality
A review guide for checking Zhin.js plugins before release. It covers plugin structure, feature declarations, resource cleanup, message sending, and security.
code-review
Automated code review with checklist and quality gates.
code-review
Orchestrates code review by detecting the project language and architecture, then routing to the appropriate specialized review skill (code-review-go, code-review-typescript, code-review-python, code-review-php, code-review-architecture). Falls back to the generic checklist when no specific skill applies. Invoked when…
code-review-architecture
Architecture-focused code review covering hexagonal boundary violations, DDD anti-patterns, CQRS misuse, and microservices coupling issues. Applied in addition to the language-specific review skill when architecture markers are detected. Invoked when reviewing hexagonal architectures, DDD patterns, or microservices…