# From Bug Found to Bug Filed: A Bug-Reporter Skill for Claude Code > Source: > Published: 2026-07-25 16:35:00+00:00 *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. --- # Playwright bug reporter ## 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**: — , not a vague summary **Steps to Reproduce**: 1. ... 2. ... 3. ... **Expected Result**: ... **Actual Result**: ... **Evidence**: **Environment**: **Suggested Severity**: — 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!