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 skills/emdash-cms/emdash/repro-apinpx skills add emdash-cms/emdash --skill repro-apigit 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.00051 | $0.01166 |
| Opus 5 | $0.00026 | $0.00583 |
| Sonnet 5 | $0.00010 | $0.00233 |
| Haiku 4.5 | $0.00005 | $0.00117 |
Grade A, and why
repro-api 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 2d 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 — 57 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Reproduce: API / CLI / Migration / Build
The bug does not need a browser. It lives in a handler, the CLI, the MCP server, a migration, the schema registry, or the build pipeline. Your goal is a deterministic reproduction you can put in the comment as evidence -- ideally a failing vitest test that becomes the regression fixture once fixed.
Environment
- Read and search in the VFS. Use
read_file,ls,grep, andcodeto find the package, read the handler in full, and trace call sites. This is most of the work and none of it needs a container. - Attach a container only to run the project. The harness has already installed dependencies and built the base workspace. Use the container for the focused reproduction command; do not repeat the install or root build.
Do not
- No
git commit,git push, or branch creation. This stage never writes to the remote. - No GitHub writes (no comments, labels, reactions). Read-only API GETs only.
- No network beyond the repo clone, the proxy-signed GitHub API, and the npm registry.
- No
pnpm publish/npm publish. - Touch no issue other than the one being investigated.
Procedure
- Anchor on the issue's exact words. In the isolate, pull the commands, file paths, package names, and stack traces out of the issue body verbatim. Your reproduction matches what the reporter wrote, not a paraphrase. If the body links a repo or gist, fetch it read-only before choosing an approach.
- Find the package (isolate). Use
areaplus file paths in the body. CLI ->packages/core/src/cli/. REST handlers ->packages/core/src/api/handlers/. Migrations ->packages/core/src/database/migrations/. MCP ->packages/core/src/mcp/. Build ->packages/*/tsdown.config.tsor rootpnpm-workspace.yaml. If several packages are plausible,grepbefore guessing. Read the candidate code fully in the isolate before you spend a container on it. - Attach a container. Everything from here needs one.
- Use the prepared toolchain. Do not run
pnpm installor the rootpnpm build. Run a package build only when the reproduction specifically targets compiled output. - Choose an approach, in order of preference:
- Failing vitest test in the package's
tests/tree. UsesetupTestDatabase()/setupForDialect()fromtests/utils/test-db.tsfor anything touching the database; use the dialect wrapper (describeEachDialect) when the bug could be dialect-specific. Mirror source structure (.../src/api/handlers/foo.ts->.../tests/integration/api/handlers/foo.test.ts). Name it for the issue:it("reproduces #<number>: <short description>", ...). Run withpnpm --filter <package> test <path>and confirm it fails for the reason reported, not an unrelated setup error. - Repro script under
/tmp/repro-<issueNumber>/when a test would need too much scaffolding (needs a built binary, needs to spawn children in a specific order). One file when possible; capture stdout, stderr, exit code. pnpm exec emdash ...when the bug is a single CLI invocation whose failure is obvious from the output.
- Failing vitest test in the package's
- Capture evidence. For every attempt record the exact command, the meaningful slice of stdout/stderr (trim -- do not dump thousands of lines), and the exit code. This transcript is the deliverable.
- Confirm the failure mode matches. A crash for a different reason is not a reproduction. If you can only trigger an adjacent failure, say so and lower confidence.
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.
- 2d ago First seen · 57 lines · 51 tokens per session scan A d49b681983ff
repro-api is a skill published in the GitHub repository emdash-cms/emdash (12,159 stars, last pushed today), licensed MIT. It adds 51 tokens to every session and 1,166 once invoked, about $0.0003 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-30.
Other skills, from other repositories
wordpress-plugin-to-emdash
Port a WordPress plugin to EmDash CMS. Use this skill when asked to migrate, convert, or port a WordPress plugin, theme functionality, or custom post type to EmDash. Provides concept mapping and implementation patterns.
emdash-cli
Use the EmDash CLI to manage content, schema, media, and more. Use this skill when you need to interact with a running EmDash instance from the command line — creating content, managing collections, uploading media, generating types, or scripting CMS operations.
building-emdash-site
Build and customize EmDash CMS sites on Astro. Use when creating pages, defining collections, writing seed files, querying content, rendering Portable Text, setting up menus/taxonomies/widgets, configuring deployment, or any task involving an EmDash-powered Astro site. Assumes basic Astro knowledge but provides all…
emdash-github-actions
Sets up GitHub Actions CI/CD workflows for EmDash plugins — TypeScript type-checking, ESLint linting, Vitest testing, npm publishing, and automated releases. ALWAYS use this skill when a user wants to create, add, set up, or configure GitHub Actions, CI/CD, automated checks, or deployment workflows for an EmDash…
adversarial-reviewer
Adversarial code review that assumes bugs exist and hunts for them. Use when asked to review code, find bugs, audit for correctness, stress-test a PR, or when someone says "tear this apart" or "what's wrong with this". Give no benefit of the doubt — every line is guilty until proven innocent.
agent-browser
Browser automation for testing and verification. Use when you need to interact with web UIs, verify visual changes, fill forms, or capture screenshots.