CtrlK
BlogDocsLog inGet started
Tessl Logo

repro-public

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.

69

Quality

83%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Low

Low-risk findings worth noting

SKILL.md
Quality
Evals
Security

Reproduce: Public Site

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.

Repository
emdash-cms/emdash
Last updated
First committed

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.