# Repro API > Reproduce an EmDash bug below the browser layer -- REST handlers, CLI, MCP, migrations, schema registry, or build tooling. No browser. Prefer a failing vitest test in the affected package, run in an attached container. - Skill: `emdash-cms/repro-api` (Agent Skill) - Install (CLI): `npx skillmds@latest add emdash-cms/repro-api` - Raw SKILL.md: https://api.skillmd.com/api/skills/emdash-cms/repro-api/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: DevOps & Infra - Author: emdash-cms (https://skillmd.com/u/emdash-cms) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/emdash-cms/repro-api --- # 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`, and `code` to 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 1. **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. 2. **Find the package (isolate).** Use `area` plus 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.ts` or root `pnpm-workspace.yaml`. If several packages are plausible, `grep` before guessing. Read the candidate code fully in the isolate before you spend a container on it. 3. **Attach a container.** Everything from here needs one. 4. **Use the prepared toolchain.** Do not run `pnpm install` or the root `pnpm build`. Run a package build only when the reproduction specifically targets compiled output. 5. **Choose an approach, in order of preference:** - **Failing vitest test** in the package's `tests/` tree. Use `setupTestDatabase()` / `setupForDialect()` from `tests/utils/test-db.ts` for 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 #: ", ...)`. Run with `pnpm --filter test ` and confirm it fails **for the reason reported**, not an unrelated setup error. - **Repro script** under `/tmp/repro-/` 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. 6. **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. 7. **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. ## When to skip Mark skipped, with the reason, when the reproduction genuinely cannot happen here. Do not burn container time fighting these: - Needs a WordPress export, customer dataset, or other artifact the reporter did not attach. - Only manifests on a deployed Cloudflare Worker -- cold starts, eventual consistency, transient D1 errors, isolate eviction. A local run does not reproduce these faithfully. - Needs Postgres at production scale (table sizes, pool exhaustion, planner choices). A handful of rows will not surface the same plan. - Needs real Cloudflare Access, R2 credentials, AI Gateway routing, or other bindings the Workspace does not have. - Timing-dependent heisenbug not reliably reproducible across runs. Note the symptom, leave it for a human. ## Output Return: - Whether you reproduced the bug. - Whether you skipped, and the reason if so. - The approach: `failing-test`, `repro-script`, `pnpm-command`, or `none`. - Notes: the exact command(s), the failure output, and anything diagnose will need. Include the test file path if you wrote one. - An empty screenshots list -- this skill produces none. If you wrote a failing test, leave it in place; do not stage or commit it. A "could not reproduce" result with the full transcript of what you tried is a valid, useful outcome -- return it as one, not as silence.