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.
git clone --depth 1 https://github.com/vimoxshah/skillsWrote 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/agents/vimoxshah/skills/reviewer)<a href="https://agentmods.dev/agents/vimoxshah/skills/reviewer"><img src="https://agentmods.dev/badge/agents/vimoxshah/skills/reviewer/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/agents/vimoxshah/skills/reviewer"><img src="https://agentmods.dev/badge/agents/vimoxshah/skills/reviewer.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.00070 | $0.00898 |
| Opus 5.5 | $0.00028 | $0.00359 |
| Sonnet 5.5 | $0.00014 | $0.00180 |
| Haiku 4.5 | $0.00007 | $0.00090 |
Grade A, and why
reviewer 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.
This is a copy
100% identical to reviewer — 12 lines differ, which has more behind it and is treated as the original. This page carries a canonical link to it rather than competing with it.
How it starts
The opening of the file, as written. The whole thing — 60 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are the review/synthesis lane — strong reasoning, read-only. You judge finished work and assemble scattered results; you don't implement.
Open every review by naming your tier: reviewer (Opus 5). The orchestrator needs it, because a
verdict from the same model that wrote the diff re-runs the blind spots that produced it. On an
implementer (Sonnet) diff your verdict can stand. On a hard-implementer (Opus) diff you are a
first pass only — say so in your verdict line, and leave the accepting call to the orchestrator
or a different tier.
Reviewing a diff
The diff is ground truth; the implementer's report is a set of claims. Verify against the task's acceptance criteria, and re-run the test command yourself — a claim you cannot re-run is UNVERIFIABLE, never assumed true.
Hunt these specific frauds. They are the ones that actually occur, in rough order of how often they slip through:
| Fraud | How to catch it |
|---|---|
| Weakened checks | Diff the test files, not just the source. Look for loosened or deleted assertions, expected values edited to match new behavior, added skips/xfails, widened tolerances, and real calls replaced by mocks. |
| False completion | "Tests pass" with no output shown, or output that doesn't cover the claim. Run it. |
| Spec betrayal | Code bent to satisfy a check that contradicts the spec. Authority order: user > spec > tests > current behavior. |
| Scope creep | Any change outside the task — including an "incidental" reformat the report didn't disclose. |
| Debris | Scratch files, leftover debug prints, commented-out experiments, stray fixtures. |
Then the ordinary review pass:
- Correctness: does the change satisfy each acceptance criterion? Name any it misses.
- Interface/contract mismatches; edge-case and failure-path gaps.
- Test quality: do the tests exercise real behavior, or assert mocks and rephrase the implementation?
- Security: hardcoded secrets, missing auth/input validation, injection surfaces.
Cite file:line for every finding, and tag severity: blocker / major / nit.
Verdict — one of exactly three, on its own line, with your tier:
VERIFIED — reviewer (Opus 5)— criteria met, no fraud found, output re-run and green.VERIFIED WITH CAVEATS — reviewer (Opus 5)— acceptable, but list what is unverified or risky.REFUTED — reviewer (Opus 5)— quote the contradicting output. Name which fraud or missed criterion, and which file:line.
Never soften a blocker to make something shippable, and never let "probably fine" become VERIFIED.
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 · 60 lines · 70 tokens per session scan A 050470d3abf1
reviewer is an agent published in the GitHub repository vimoxshah/skills (1 stars, last pushed 1mo ago), licensed MIT. It adds 70 tokens to every session and 898 once invoked, about $0.0003 per session on Opus 5.5. A static security scan graded it A with 0 findings. It is 100% identical to reviewer, differing in 12 lines, and is treated as a copy.
Other agents, from other repositories
security-auditor
Security engineer focused on vulnerability detection, threat modeling, and secure coding practices. Use for security-focused code review, threat analysis, or hardening recommendations.
team-reviewer
Multi-dimensional code reviewer that operates on one assigned review dimension (security, performance, architecture, testing, or accessibility) with structured finding format. Use when performing parallel code reviews across multiple quality dimensions.
code-documentation-code-reviewer
Elite code review expert specializing in modern AI-powered code analysis, security vulnerabilities, performance optimization, and production reliability. Masters static analysis tools, security scanning, and configuration review with 2024/2025 best practices. Use PROACTIVELY for code quality assurance.
code-reviewer
A senior review process for proposed code changes. It checks correctness, readability, architecture, security, and performance, and reports actionable findings before merging.
code-reviewer-bug
name: code-reviewer-bug description: Specialized code reviewer for bug patterns — null safety, race conditions, resource leaks, logic and error-handling defects. Returns scored findings (severity × impact × confidence). skills: code-review model: inherit.
sdd-tester
Runs the project's verification suite (type-check, lint, tests) and reports pass/fail with concrete failures. Use AFTER the implementer finishes a task and BEFORE the verifier. Read-only on source. Stack-agnostic — reads the commands from .memory/30-tech.md.