Part 8 of the "Automating Playwright with Claude Code" series. Our pack from Part 6 catches problems (flaky tests, locator issues); this post adds a Skill that turns a caught problem into a properly filed bug report, using the guardrail patterns from Part 7.
Every Skill we've built so far in this series ends with Claude telling you something's wrong. This post closes that loop: a Skill that takes a failure Claude just found and turns it into a bug report good enough to actually file — with reproduction steps grounded in evidence, not guesswork, thanks to the guardrails from Part 7.
Before writing the Skill, it's worth being explicit about the fields a useful bug report has — this becomes the Skill's output template:
---
name: playwright-bug-reporter
description: "Turn a test failure or bug found during Playwright testing into"
a filed bug report. Use whenever the user says a bug was found, asks to
file an issue, or wants a test failure written up as a report.
---
## Process
1. Gather evidence first: the relevant snapshot, trace, or log from the
failure — never write a report from memory of "what probably happened."
2. Fill out the report using this exact structure:
**Title**: <component/flow> — <specific symptom>, not a vague summary
**Steps to Reproduce**:
1. ...
2. ...
3. ...
**Expected Result**: ...
**Actual Result**: ...
**Evidence**: <snapshot excerpt, trace line, or screenshot reference>
**Environment**: <browser, viewport, env (staging/prod), test run ID>
**Suggested Severity**: <Critical/High/Medium/Low> — flagged as a
suggestion for the team to confirm, not a final call.
3. Every reproduction step must come from an action that was actually
taken and observed during testing — not inferred or assumed.
4. Do not suggest a root cause unless directly asked; a bug report
documents what happened, not why (that's the flaky-test-debugger
Skill's job from Part 6).
This Skill is a perfect candidate for the guardrail patterns from Part 7, since a fabricated bug report is actively harmful — it wastes a developer's time chasing something that isn't real:
## Guardrails
- Never include a reproduction step you did not personally execute and
observe during this session.
- If evidence for any field is missing (no trace, no screenshot), say
so explicitly in that field rather than leaving it blank or guessing.
- Do not file the issue automatically — always show the report to the
user for confirmation first, since only they know if it duplicates
an existing ticket.
That last line matters: filing directly into a tracker is a good candidate for a human-review gate, not full automation — someone still needs to check for duplicates and confirm it's worth filing.
Here's the whole loop, start to finish:
This checkout test is failing intermittently — can you check it and file a bug if it's real?
playwright-flaky-test-debugger
(Part 6) fires first, gathering trace evidence and identifying that the "Place Order" button is being clicked before the cart total finishes updating.playwright-bug-reporter
fires next, producing:
**Title**: Checkout — "Place Order" clickable before cart total finishes updating
**Steps to Reproduce**:
1. Add two items to cart on the checkout page.
2. Immediately click "Place Order" without waiting for the total to refresh.
3. Observe the order is placed with the pre-update total.
**Expected Result**: "Place Order" should be disabled until the cart total
finishes recalculating.
**Actual Result**: Button remains clickable during the recalculation window,
allowing an order to be placed with a stale total.
**Evidence**: Trace shows `cart-total` element still has `aria-busy="true"`
at the moment of the click event (trace timestamp 00:04.211).
**Environment**: Chromium, 1280x720, staging, run #4821
**Suggested Severity**: High — flagged for team confirmation.
The template above is tracker-agnostic on purpose. To adapt it:
.github/ISSUE_TEMPLATE/bug_report.md
structure, so the Skill's output can be pasted straight in.## Process
section so nothing gets skipped.This Skill closes the loop between finding a problem and doing something useful with it — and because it inherits the guardrails from Part 7, the reports it produces are grounded in real evidence rather than a plausible-sounding guess. Combined with Part 6's pack, you now have Skills that catch issues, diagnose them, and write them up in a consistent, reviewable format. Next up, we'll zoom out from individual Skills and map how a set like this covers the full Software Testing Life Cycle.
Would your team's tracker need extra fields beyond this template? Let me know what's missing in the comments!