reproducing-issues

name	reproducing-issues
description	Turn a vague bug report into precise, repeatable steps with evidence and a CONFIRMED / CANNOT-REPRODUCE / PARTIAL verdict. Use when a bug is unclear or unconfirmed and needs reproduction before RCA or any fix. Reproduction and documentation only — does not fix code.
license	Apache-2.0
metadata	{"authors":["Artem Rozumenko <[e-mail]>"],"version":"0.1.0"}

Reproducing Issues

Turn a vague bug report into precise, repeatable reproduction steps backed by evidence, ending in a clear verdict. Reproduction and documentation only — you do NOT fix code.

Platform & systems

Findings go on the tracker ticket — the source of truth — using the tracker scout recorded in .agents/profile.md § Project systems (GitHub Issues, Jira via atlassian-content, GitLab, Azure Boards, Linear). The gh issue … commands below are the GitHub reference; translate per .agents/workflow.md § Git host. In a standalone session with no tracker, report the same content directly to the user.

Methodology — 5 phases

1. Intake

Read the report in full (gh issue view <N> or the tracker equivalent). Assess: clear steps → follow exactly; partial → fill the gaps; none → explore the feature area; intermittent → expect multiple timed attempts. Note that reproduction has started on the ticket.

2. Environment setup

Identify the target URL/endpoint/page, auth (user role, credentials), prerequisite data/state, and client requirements. Reproduction must be repeatable — document the environment.

3. Reproduction attempts

• UI → drive the browser with the playwright-testing or browser-verify skill: navigate, snapshot for refs, follow the reported steps, screenshot the failure, capture console errors and network requests.
• API → reproduce the failing request with curl or a small script; record status code + body.
• Logic → a minimal script calling the function with the edge-case input; print expected vs actual.
• Intermittent → run 5–10×, vary timing and data, document the success/failure rate.

4. Root-cause hints (handoff to RCA)

Gather clues for root-cause-analysis: exact console errors + stack traces; failing requests / unexpected status codes; works-vs-fails patterns; triggering vs safe inputs; timing sensitivity. Post these technical observations on the ticket.

5. Confirmation gate (required)

Assess the result and post a verdict. Do not let work proceed to RCA unless CONFIRMED:

• CONFIRMED — reproduced at least once, repeatable (or intermittent rate documented), failure clearly captured (screenshot / log / response), steps precise enough for anyone to follow. Post: reproduction rate, method, exact steps, expected vs actual, evidence, and RCA hints. → ready for RCA.
• CANNOT REPRODUCE — post what was tried and the specific information needed. → not ready.
• PARTIALLY CONFIRMED — reproducible but inconsistent; post the rate and the conditions under which it fails. → RCA may proceed; flag the intermittency.

Output

Full report on the ticket; a one-line summary to the user/PM, e.g. ✅ #N CONFIRMED — 4/5 attempts, trigger: <one sentence>. Ready for RCA.

You do NOT

Edit source code, create branches/PRs, make architecture decisions, close tickets, skip the confirmation gate, or proceed to RCA when not confirmed.

Related skills

• bugfix-workflow orchestrates reproduce → fix → verify; this is its deep "reproduce" methodology.
• root-cause-analysis is the next step once a bug is CONFIRMED.
• playwright-testing / browser-verify for UI reproduction.