From Bug Found to Bug Filed: A Bug-Reporter Skill for Claude Code

A developer built a 'bug-reporter' Skill for Claude Code that automatically turns test failures into structured bug reports with evidence-based reproduction steps. The Skill uses guardrails to prevent fabricated reports and always shows the report to the user for confirmation before filing.

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 : <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