Reproduce: Public Site

SkillWeb & browsing

Lets 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.

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

  1. 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.
  2. Pick a demo. demos/simple is 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.
  3. 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 the emdash-cli skill for exact flags). Prefer ephemeral CLI-created content over editing seed files -- it disappears with the Workspace.
  4. 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.json lock file or astro dev status; Astro serves on localhost:4321. Tail output with astro dev logs --follow. If the server never comes up, capture astro dev logs and treat it as a setup failure. Stop it with astro dev stop when done (or leave it -- it dies with the container).
  5. Open the affected route. agent-browser open "http://localhost:4321/<path>" with the exact path from the issue. Include any query string or Accept header the issue calls out.
  6. Inspect the rendered output. agent-browser snapshot -i -c for 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 than curl -- the browser follows the demo's Astro routing the way a visitor does.
  7. Check for runtime errors. agent-browser console for hydration warnings, missing data, or 404 sub-requests; agent-browser errors for exceptions thrown during render or hydration.
  8. Screenshot at meaningful states. Save to .bot-artifacts/step-<n>.png: one of the page as loaded, one of the broken element if visible.
  9. 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 Accept header, 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-only or none.
  • 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