Reproduce: Public Site
SkillWeb & browsingLets your agent reproduce bugs on a public site and capture screenshots plus a replayable transcript.
Available today. Use it from your connected AI after setup.
No other account needed.
Connect ahel once, and every AI you use reads what you have installed.
Then ask your AI: use the Reproduce: Public Site skill
About this capability
Reproduce a bug in the public-facing rendered site (not the admin). Attach a container, start the demo dev server, drive public routes with agent-browser, and capture the reproduction as screenshots plus a replayable transcript.
What this skill tells your AI
The instructions your AI receives, as published by emdash-cms/emdash in infra/emdash-bot/.flue/skills/repro-public/SKILL.md and read by ahel’s review.
The bug is in the rendered public site -- Astro pages outside /_emdash, the SSR output a visitor sees, public routing, sitemap, RSS, image rendering, or query patterns anonymous readers hit. No admin session needed. Reproduce and confirm entirely through agent-browser: the durable artifacts are your screenshots, a captured DOM slice, and a precise, replayable transcript. Do not write Playwright or any other browser test -- you cannot run one reliably here. The regression test belongs to whoever lands the fix.
Environment
The dev server, agent-browser, and any CLI seeding run in an attached container (node + browser; neither exists in the isolate). Read the issue and grep the source in the isolate first, then attach the container for the reproduction.
Do not
- No
git commit,git push, or branch creation. - No GitHub writes. Read-only API GETs only.
- No network beyond
localhost(the demo) and the proxy-signed GitHub API. - Touch no issue other than the one being investigated.
Procedure
- Re-read the issue (isolate). Note the exact URL or route pattern, expected-vs-actual output, and any headers or query strings that mattered. Public-site bugs often hinge on the locale, the requested format (HTML vs RSS), or specific content rows -- be precise.
- Pick a demo.
demos/simpleis the default. For a locale-specific bug, pick a demo with multiple locales seeded; for a collection-specific bug, one that already has that collection. - Seed content only if necessary. If the repro needs a content item the seed lacks, create it with the CLI in the container:
pnpm exec emdash content create <collection> --data '...'(see theemdash-cliskill for exact flags). Prefer ephemeral CLI-created content over editing seed files -- it disappears with the Workspace. - Attach a container and start the demo dev server. Astro 7 backgrounds dev servers natively -- from the demo directory run
astro dev --background(e.g.pnpm --filter ./demos/simple exec astro dev --background). It detaches, enables JSON logging, and returns once the server is up, so you do not poll or improvise process management. Read the URL/port/PID and readiness from the.astro/dev.jsonlock file orastro dev status; Astro serves onlocalhost:4321. Tail output withastro dev logs --follow. If the server never comes up, captureastro dev logsand treat it as a setup failure. Stop it withastro dev stopwhen done (or leave it -- it dies with the container). - Open the affected route.
agent-browser open "http://localhost:4321/<path>"with the exact path from the issue. Include any query string orAcceptheader the issue calls out. - Inspect the rendered output.
agent-browser snapshot -i -cfor the accessibility tree;agent-browser get text @e<n>to extract a region. For RSS or other non-HTML output, fetch it through the browser's network panel rather thancurl-- the browser follows the demo's Astro routing the way a visitor does. - Check for runtime errors.
agent-browser consolefor hydration warnings, missing data, or 404 sub-requests;agent-browser errorsfor exceptions thrown during render or hydration. - Screenshot at meaningful states. Save to
.bot-artifacts/step-<n>.png: one of the page as loaded, one of the broken element if visible. - Confirm the failure mode matches. Public-site bugs are easy to misidentify -- rendering differences can come from missing seed data, a stale build artifact, or an unrelated route. If you cannot produce exactly the reported symptom, say so. Write the exact replayable steps (URL, any query string or
Acceptheader, observed-vs-expected) so a maintainer can follow without you.
When to skip
Mark skipped, with the reason, when:
- The bug needs a specific crawler user-agent, OG-card validator, or third-party fetcher you cannot impersonate from
localhost. - The bug needs production-scale content (pagination edge cases, sitemap chunking) the demo cannot realistically produce in run time.
- The bug only manifests on a deployed Worker -- CF edge cache headers, geographic routing, image transformation through the production R2 binding.
- The bug needs a specific source dataset (e.g. a WordPress import) the reporter did not attach.
Output
Return:
- Whether you reproduced the bug.
- Whether you skipped, and the reason if so.
- The approach:
agent-browser-onlyornone. - Notes: the demo used, the exact URL, the interaction sequence in plain prose, and any console or runtime errors.
- A list of screenshots, each with its
.bot-artifacts/filename and a one-line description.
A "could not reproduce" result backed by the transcript and screenshots is a valid, useful outcome -- return it as one.
Signals
- GitHub stars
- 12k
- Forks
- 1k
- Last commit
- Sep 2026
Advanced
- Catalog kind
- skill
- Gateway key
repro-public- Source
- github.com/emdash-cms/emdash