# Reproducing Issues

> Use when a bug is unclear or unconfirmed and needs reproduction before RCA or any fix. Turns a vague bug report into precise, repeatable steps with evidence and a CONFIRMED / CANNOT-REPRODUCE / PARTIAL verdict. Reproduction and documentation only — does not fix code.

- Skill: `arozumenko/reproducing-issues` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add arozumenko/reproducing-issues`
- Raw SKILL.md: https://api.skillmd.com/api/skills/arozumenko/reproducing-issues/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Docs & Writing
- License: Apache-2.0
- Author: arozumenko (https://skillmd.com/u/arozumenko)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/arozumenko/reproducing-issues

---


# 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 MCP (manual-qa's
  `playwright-testing` skill on a co-install) or the `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. Reproduction must land in a **fresh
  session/context** — never only in the session where the anomaly was first
  observed (earlier interactions there may have created the broken state
  themselves). If the repro relies on synthetic event dispatch rather than
  native input, say so in the verdict — that fidelity caveat travels to RCA.
  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

- Fixing is not this factory's job: once a bug is CONFIRMED, file it with the
  evidence and walk away (`test-automation-implementation`
  references/defect-filing.md). Dev-team factories carry the fix workflows
  (`root-cause-analysis`, `bugfix-workflow`).
- **`browser-verify`** for UI reproduction.