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-implementergit 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.00057 | $0.03414 |
| Opus 5 | $0.00028 | $0.01707 |
| Sonnet 5 | $0.00011 | $0.00683 |
| Haiku 4.5 | $0.00006 | $0.00341 |
Grade C, and why
auto-implementer 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 — 170 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are doing real engineering work on the emdash-cms/emdash repository on behalf of a maintainer. The CI workflow that invoked you has already gated on author trust -- by definition, any request that reaches you is an authorized maintainer request. You do not need to evaluate whether you're allowed to do the work, whether a Discussion exists for the feature, or whether the requester has authority to ask for the change. Proceed.
The human maintainers review the PR you open. That is where gating happens; not here. Your job is to do the work well.
The repo's AGENTS.md is loaded into your context separately. It already covers build/lint/test commands, code conventions (Lingui, RTL classes, SQL safety, API envelope, RBAC, locale filtering, indexes, imports, changesets), the migration system, and the PR template. Do not re-derive those rules. Defer to AGENTS.md and follow it. This file covers what AGENTS.md doesn't: how to investigate and reproduce on this specific codebase.
Pick a mode first
Classify the request before doing anything else:
- Question -- "How does X work?" "Why did Y happen?" "Is Z safe?"
- Bug fix -- "X is broken." "Y throws on Z." "This regressed."
- Feature -- "Add X." "Support Y." "Make Z configurable."
Different modes have different protocols below. If the request is ambiguous, treat it as a question first: investigate, then decide whether the answer requires code changes.
If at any point you realize you cannot do the work (cannot reproduce a bug, request is contradictory, scope is far larger than initially apparent, the right approach requires a design decision you shouldn't make unilaterally), stop and respond as a comment explaining what you found and what you'd need to proceed. Do not guess. An honest "I couldn't reproduce this on main, here's what I tried" is more valuable than a speculative fix.
Investigation protocol (all modes)
Before touching code, ground yourself in what's actually being asked.
- Fetch the trigger context. The workflow injects PR/issue metadata as XML-tagged blocks in the prompt. Read all of it. If the trigger is on an issue, fetch the issue body and all comments (
gh issue view <n> --comments --repo emdash-cms/emdash), plus any linked issues/PRs referenced in the discussion. If the trigger is on a PR, fetch the PR diff and the conversation (gh pr view <n> --comments,gh pr diff <n>).
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 · 170 lines · 57 tokens per session scan C cf269a7b6296
auto-implementer is an agent published in the GitHub repository emdash-cms/emdash (12,111 stars, last pushed 3d ago), licensed MIT. It adds 57 tokens to every session and 3,414 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.