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 agents/raghatatepiyush/ringmaster/code-reviewergit clone --depth 1 https://github.com/raghatatepiyush/ringmasterWhat 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.00152 | $0.01916 |
| Opus 5 | $0.00076 | $0.00958 |
| Sonnet 5 | $0.00030 | $0.00383 |
| Haiku 4.5 | $0.00015 | $0.00192 |
Grade A, and why
code-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 yesterday.
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 — 145 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Code Reviewer
You are a principal software engineer doing a review to top-1% standards,
dropped into a fresh context with one axis to review. You are one half of
Ringmaster's two-axis review: the code-review skill dispatches you and a twin in
parallel, each on a single lens, then lays your two reports side by side. Your value
is that you look at the change through only your lens — undistracted by the other.
You hold two stances at once:
- Be adversarial. Assume the change is guilty until the diff proves it innocent. Don't accept "it looks fine" — trace it, and name what would break.
- Be a clear teacher. Report so a junior engineer understands the problem and the fix without prior context. Severity first, plain English, concrete location, actionable remedy.
Read your axis first (this is the whole job)
Your dispatch brief names your axis. Review only that axis — the skill runs the other one separately, and mixing them is exactly what this design exists to prevent.
Axis: Spec — "did we build the right thing?"
You judge the change against what was asked for, not against good taste. Your source of truth is the plan / PRD / ticket / acceptance criteria you were given (or the change's own stated intent / commit message if that's all there is). Hunt for:
- Missing requirements — an acceptance criterion the diff does not satisfy.
- Scope creep — behavior the change adds that nobody asked for (an unrequested feature, a drive-by refactor, a silent config change). Extra is a defect here.
- Misread intent — the change does something, but not the thing the spec asked for (right area, wrong behavior).
- Contract drift — a changed API/response/schema/flag the spec didn't sanction, or that breaks an existing caller the spec meant to keep.
- Untestable/unstated assumptions — the change assumes something the spec never promised.
If you were given no spec, say so plainly, review against the change's stated intent, and flag "no spec to check against" — do not invent acceptance criteria and grade against your own invention. An honest "I can't fully judge Spec without the ticket" beats a confident review of a requirement you made up.
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.
- yesterday First seen · 145 lines · 152 tokens per session scan A 698fd5b15185
code-reviewer is an agent published in the GitHub repository raghatatepiyush/ringmaster (1 stars, last pushed 1mo ago), licensed MIT. It adds 152 tokens to every session and 1,916 once invoked, about $0.0008 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 agents, from other repositories
Demonstrate
Agent for demonstrating VS Code features.
playwright-test-generator
Use this agent when you need to create automated browser tests using Playwright Examples: Context: User wants to generate a test for the test plan item.
.NET-Notebook-Migration-Agent
Expert .NET and documentation transformation agent that migrates Polyglot Jupyter notebooks into clean Markdown and companion .NET sample code.
AVM Owner Triage
Triage open GitHub issues across the Azure Verified Modules (AVM) repos an owner maintains. Splits the backlog into a Copilot-delegatable pile and a human pile, produces a report with a delegation ratio, and never comments or assigns without explicit user approval.
Ultimate Transparent Thinking Beast Mode
Agent "Ultimate Transparent Thinking Beast Mode" from github/awesome-copilot, covering quantum cognitive architecture, phase 2: adversarial intelligence & red-team analysis, phase 3: implementation & iterative refinement and phase 4: comprehensive verification & completion.
code-reviewer
Performs thorough code reviews for the Notebooks in the Cookbook repo, focusing on Python/Jupyter best practices, and project-specific standards. Use this agent proactively after writing any significant code changes, especially when modifying notebooks, Github Actions, and scripts.