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 yash-gadodia/claude-init --skill reviewgit clone --depth 1 https://github.com/yash-gadodia/claude-initWrote 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/yash-gadodia/claude-init/review)<a href="https://agentmods.dev/skills/yash-gadodia/claude-init/review"><img src="https://agentmods.dev/badge/skills/yash-gadodia/claude-init/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/yash-gadodia/claude-init/review"><img src="https://agentmods.dev/badge/skills/yash-gadodia/claude-init/review.svg" alt="Reviewed on agentmods" width="80" 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.1 | $0.00027 | $0.00994 |
| Opus 5 | $0.00014 | $0.00497 |
| Sonnet 5 | $0.00005 | $0.00199 |
| Haiku 4.5 | $0.00003 | $0.00099 |
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 11d 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 — 123 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Review: Two-Stage Code Review
Review all changes in two passes: first check if the spec is met, then check code quality.
When This Triggers
Automatically after implementing any change. Also useful before committing or creating PRs.
Process
Stage 1: Spec Compliance
Does the code match what was requested?
Change summary (loaded fresh when this skill triggers):
!git diff --stat HEAD 2>/dev/null || git diff --stat
Recent commits on this branch:
!git log --oneline -5 2>/dev/null || echo "(no git history)"
Read the full diff for any file that shows up above before judging it — git diff HEAD -- <file> for unstaged + staged, git diff <base>...HEAD -- <file> when reviewing a PR. Never review from memory.
For each requirement/acceptance criterion from the plan or request:
- Is there code implementing it?
- Is there a test verifying it?
- Does the implementation match the spec (not over-build, not under-build)?
Missing requirement? Flag it. Don't proceed to Stage 2 until spec is met. Extra code not in spec? Flag it. YAGNI — remove unless there's a clear reason.
Stage 2: Code Quality
For each changed file, check:
Correctness:
- Does the logic do what it claims?
- Edge cases handled (null, empty, boundary values)?
- Off-by-one errors?
- Async operations handle errors and race conditions?
Security:
- User input validated and sanitized?
- No SQL injection, XSS, or command injection?
- No credentials or secrets in code?
- Auth checks present where needed?
Conventions:
- Matches existing patterns in the codebase?
- Uses existing utilities instead of reinventing?
- Follows naming conventions?
Tests:
- New functionality has tests that followed TDD (test was written first)?
- Tests assert exact expected values, not ranges?
- Test names describe behavior?
Severity taxonomy
Label every finding — not all feedback is mandatory, and treating nits as blockers erodes trust in the review:
| Severity | Meaning | Action |
|---|---|---|
| Critical | Bug, security hole, data loss, spec violation | Blocks approval |
| Important | Wrong pattern, missing test, latent bug | Should fix before merge |
| Nit | Style, naming, minor cleanup | Author may ignore |
| FYI | Informational, no change requested | No action |
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.
- 11d ago First seen · 123 lines · 27 tokens per session scan A 75077446f4cc
review is a skill published in the GitHub repository yash-gadodia/claude-init (5 stars, last pushed 3d ago), licensed MIT. It adds 27 tokens to every session and 994 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-31.
Other skills, from other repositories
code-review
You are a senior code reviewer. You receive diffs via stdin.
naming-format
Use when reviewing file names, renaming files, fixing naming conventions, or auditing exports. Enforces consistent casing and suffix patterns.
security-review
Adversarial security review of a change (branch diff, PR, or working tree) before merge. Use when the user asks to "review this for security", "security review", "check for vulnerabilities", "is this safe to merge", or before merging anything that touches a trust boundary — auth/authz, input parsing…
design-system
Frontend design conventions for {{ projectname }} -- layout hierarchy, spacing, typography, anti-slop rules. Auto-activates when creating or modifying templates, CSS, or frontend components.
include-test-files-that-assert-on-behavior-being-changed-in-decl
When delegating a task affected by this skill, include.
review
Use when the user wants code assessed rather than changed — "review PR 88", "is this branch ready to merge?", "look over my changes", "any problems with this diff?", "give me a code review", "what do you think of this PR?", "sanity-check this branch", "ship it?". Applies to a pull request or the current branch when…