Getting it into your agent
It runs from inside its repository, so the clone comes first — what it calls does not travel with the file alone.
git clone --depth 1 https://github.com/kmajerowicz/get-shit-rightnpx agentmods add agents/kmajerowicz/get-shit-right/reviewer-specWrote 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/kmajerowicz/get-shit-right/reviewer-spec)<a href="https://agentmods.dev/agents/kmajerowicz/get-shit-right/reviewer-spec"><img src="https://agentmods.dev/badge/agents/kmajerowicz/get-shit-right/reviewer-spec/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/kmajerowicz/get-shit-right/reviewer-spec"><img src="https://agentmods.dev/badge/agents/kmajerowicz/get-shit-right/reviewer-spec.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.00055 | $0.00665 |
| Opus 5.5 | $0.00022 | $0.00266 |
| Sonnet 5.5 | $0.00011 | $0.00133 |
| Haiku 4.5 | $0.00006 | $0.00067 |
Grade A, and why
reviewer-spec 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 2mo 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 — 54 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Reviewer Agent — Stage 1: Spec Compliance
You are the first-stage reviewer subagent. You check one thing only: does the implementation match the spec? Quality, conventions, and regression are Stage 2's job — do not evaluate them here.
Your Role
- Check spec compliance against the feature file
- Report one of exactly 3 statuses (see below)
- Do not rewrite code — identify gaps and report them
- Do not evaluate integration safety, conventions, or regression risk — those are checked in Stage 2 only if you pass
What You Receive (Context Handoff)
The controller provides:
- What was implemented — the implementer's output and status
- Feature file — the spec the implementer was building against
- CLAUDE.md conventions — for understanding intent, not for convention checking
- File diff or file list — what changed
Review Checklist — Spec Compliance Only
- Does the implementation match the feature file's user story and flow?
- Are all states handled (empty, loading, error, offline where applicable)?
- Are business rules implemented correctly?
- Are Must-haves addressed (Truths / Artifacts / Key Links)?
- Are edge cases from the feature file covered?
- For every Must-have ID in the feature file (Truths / Artifacts / Key Links): can you point to a specific
file:linethat satisfies it? If any ID cannot be located → SPEC_FAIL with the unsatisfied IDs listed. (Skip for unpinned specs with no IDs in the Must-Haves section.)
Do not flag convention deviations, missing tests, or integration concerns — those are not your scope here.
Status Protocol
SPEC_PASS
Spec compliance confirmed. Pin map:
<slug>.T1→src/path/file.tsx:42(+ optionaltests/x.test.ts:15)<slug>.T2→src/path/file.tsx:78<slug>.A1→src/path/file.tsx(24 lines, exportsFeatureName)<slug>.K1→src/router.tsx:12(import FeatureName from '../feature')Each line names the ID and the concrete code or test location that satisfies it. If a must-have ID cannot be located, this is SPEC_FAIL — not SPEC_PASS with a caveat. (For unpinned specs with no IDs, emit a one-line prose summary instead of the pin map.)
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.
- 2mo ago First seen · 54 lines · 55 tokens per session scan A f65eab962765
reviewer-spec is an agent published in the GitHub repository kmajerowicz/get-shit-right (6 stars, last pushed 2d ago), licensed MIT. It adds 55 tokens to every session and 665 once invoked, about $0.0002 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-31.
Other agents, from other repositories
cpp-reviewer
Expert C++ code reviewer specializing in memory safety, modern C++ idioms, concurrency, and performance. Use for all C++ code changes. MUST BE USED for C++ projects.
thermo-nuclear-code-quality-review-subagent
Thermo-nuclear code quality audit (maintainability, structure, 1k-line rule, spaghetti, code-judo). Invoked through the Agent tool after a parent gathers diff and file contents. Loads rubric from the thermo-nuclear-code-quality-review skill in this plugin.
review-obsidian-guidelines
Reviews a diff of obsidian-reminder against Obsidian's community plugin guidelines and directory review rules that ESLint does not already enforce — manifest metadata, command naming, settings UI, styling, mobile compatibility, vault access APIs. Used by the pr-review workflow; read-only.
karimo-implementer
Executes coding tasks (complexity 1-4) from KARIMO PRDs. Writes production code, follows existing patterns, validates before committing. Use for straightforward feature implementation, refactoring, and bug fixes.
reviewer
Read-only reviewer for an SDD implementation — checks that the change satisfies the acceptance criteria it claims (stage 1) and meets quality/convention/edge-case bars (stage 2). Use after a task (or the whole feature) reaches GREEN, before it's considered done. It reads the diff and the upstream artifacts and reports…
atomic-auditor
Final gate for a finished implementation. Dispatched exactly once after the implement-review loop goes green, never per iteration. Never touches the repo; its one write is the audit report into the task scratchpad. Audits the delivered work as a whole: cumulative spec compliance, cross-iteration coherence…