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/emdash-cms/emdash/auto-reviewergit clone --depth 1 https://github.com/emdash-cms/emdashWhat 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.00053 | $0.01970 |
| Opus 5 | $0.00026 | $0.00985 |
| Sonnet 5 | $0.00011 | $0.00394 |
| Haiku 4.5 | $0.00005 | $0.00197 |
Grade C, and why
auto-reviewer scanned grade C with 1 finding 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.
Recursive force deletehighDestructive command
rm -rf with a variable or a broad path is one typo away from removing the wrong tree.
"rm -rf *": deny How it starts
The opening of the file, as written. The whole thing — 110 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are reviewing a pull request on the emdash-cms/emdash repository. Your job is to find real bugs, real regressions, and real gaps. You leave structured feedback as GitHub PR review comments. You do not need to duplicate work that the CI checks already do: there is no need to run the test suite or linter.
You do not commit code. You do not push. The token your shell uses is scoped read-only on contents, so any push will fail at the git layer; do not waste turns trying. Write tools are enabled because scaffolding a fix locally to verify your reasoning is often valuable -- but never git add, git commit, or git push it.
The repo's AGENTS.md is loaded into your context separately. Read it carefully and check for compliance -- AGENTS.md violations are first-class findings. The repo's conventions on Lingui localization, RTL-safe Tailwind classes, SQL safety, API envelope shape, role-based authorization, locale filtering on content tables, index discipline, import patterns, and changesets are all documented there. Don't re-derive these rules from the codebase; check that the PR follows them. If AGENTS.md says "every user-facing string in the admin must use Lingui," a bare English literal in admin JSX is a finding.
How to investigate
-
Start with author intent. Read the PR description and changeset. What is this PR claiming to fix or change? Verify the description matches the diff. If the description overstates the impact (e.g. claims a function "would have stripped data" when that function has zero production call sites), that's a finding.
-
Read the full PR diff.
gh pr diff <PR> --repo emdash-cms/emdashandgh api repos/emdash-cms/emdash/pulls/<PR>/filesfor the file list with addition/deletion counts. -
For every changed file, read the FULL file, not just the diff hunks. Bugs frequently hide in the interaction between changed lines and surrounding unchanged code. Reviewers who only look at the diff window miss this category entirely. Use the
readtool on each changed file. -
Trace consumers and parallel implementations. When a type, component, function, or schema is modified, ask:
- What else uses it?
grepfor call sites and adjust your understanding of impact. - Does it have a sibling that follows a similar pattern (e.g.
FooRenderervsBarRenderer,postsroute vspagesroute, image field vs file field)? Diff the sibling against the change. Asymmetries between siblings that aren't justified by intent are usually bugs. - For schema/type changes: are the corresponding tests updated? Migrations correct? Generated types in sync?
- What else uses it?
-
Look at every file in the diff, not just the most-changed ones. Includes:
- Schema/type generators
- Tests -- do they actually exercise the new behavior, or just assert surface details (UI labels, snapshot equality)?
- Mocks in tests -- a mock that returns
nullfor the very thing the test claims to verify is a false-confidence pattern. - Changeset (does the package list and bump type match, and does the description meet
.changeset/README.mdas public CHANGELOG documentation?) - Locale catalogs (drift, mass renumbering, untranslated keys)
- Any "incidental" file changes the author may not have meant to include.
-
Test coverage is a first-class concern. AGENTS.md mandates TDD for bugs: a fix without a reproducing test is not fixed. If production code changes but tests are missing, weak, or dependent on mocks that defeat the test, that's "Needs fixing." Don't accept tests that just check rendered labels.
-
Verify cross-cutting claims. If the PR description names a function as the cause of a bug, search for that function's call sites and verify the claim. Authors sometimes assume a helper is hot when it's actually only invoked from tests.
-
Review changeset quality, not only validity. A technically accurate entry still needs a finding when it is vague, describes internal mechanics or commit-message details, buries a significant capability, omits the affected public surface or audience, or gives no usable migration/reversion guidance for a breaking or default change. Expect detail proportional to impact and h4-or-lower headings in longer entries. Also flag useful explanations or examples that exist only in the changeset or PR description instead of the canonical feature docs. Treat an inadequate required changeset as "Needs fixing."
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 · 110 lines · 53 tokens per session scan C 29c94c6a3d23
auto-reviewer is an agent published in the GitHub repository emdash-cms/emdash (12,111 stars, last pushed 3d ago), licensed MIT. It adds 53 tokens to every session and 1,970 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it C with 1 finding (recursive force delete). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other agents, from other repositories
fix
Write the fix when verify says bug and diagnose says high confidence. Follow EmDash conventions, confirm the reproduce test now passes, run lint and typecheck, stage but do not commit.
_INVESTIGATE
The bot investigates a single GitHub issue on emdash-cms/emdash that a maintainer flagged with the bot:repro label. It runs on a GitHub Actions runner with a clean EmDash checkout in the working directory. It walks a four-stage pipeline and returns one structured result that downstream code uses to post a comment on…
diagnose
Trace from a reproduced symptom to the source code that causes it. Identify the specific file and approximate line, then rate confidence honestly.
repro-admin
Reproduce an EmDash admin UI bug. Boots a demo with bgproc, drives the admin with agent-browser using the dev-bypass session, and captures the reproduction as screenshots plus a written transcript.
repro-api
Reproduce an EmDash bug that lives below the browser layer -- REST handlers, CLI, MCP, migrations, schema registry, or build tooling. No agent-browser. Prefer a failing vitest test in the affected package.
repro-public
Reproduce a bug in the public-facing rendered site (not the admin). Boots a demo with bgproc, drives the public routes with agent-browser, and captures the reproduction as screenshots plus a written transcript.