{"slug": "from-bug-found-to-bug-filed-a-bug-reporter-skill-for-claude-code", "title": "From Bug Found to Bug Filed: A Bug-Reporter Skill for Claude Code", "summary": "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.", "body_md": "*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.*\n\nEvery 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.\n\nBefore writing the Skill, it's worth being explicit about the fields a useful bug report has — this becomes the Skill's output template:\n\n```\n---\nname: playwright-bug-reporter\ndescription: \"Turn a test failure or bug found during Playwright testing into\"\n a filed bug report. Use whenever the user says a bug was found, asks to\n file an issue, or wants a test failure written up as a report.\n---\n\n# Playwright bug reporter\n\n## Process\n1. Gather evidence first: the relevant snapshot, trace, or log from the\n failure — never write a report from memory of \"what probably happened.\"\n2. Fill out the report using this exact structure:\n\n **Title**: — , not a vague summary\n\n **Steps to Reproduce**:\n 1. ...\n 2. ...\n 3. ...\n\n **Expected Result**: ...\n\n **Actual Result**: ...\n\n **Evidence**: \n\n **Environment**: \n\n **Suggested Severity**: — flagged as a\n suggestion for the team to confirm, not a final call.\n\n3. Every reproduction step must come from an action that was actually\n taken and observed during testing — not inferred or assumed.\n4. Do not suggest a root cause unless directly asked; a bug report\n documents what happened, not why (that's the flaky-test-debugger\n Skill's job from Part 6).\n```\n\nThis 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:\n\n```\n## Guardrails\n- Never include a reproduction step you did not personally execute and\n observe during this session.\n- If evidence for any field is missing (no trace, no screenshot), say\n so explicitly in that field rather than leaving it blank or guessing.\n- Do not file the issue automatically — always show the report to the\n user for confirmation first, since only they know if it duplicates\n an existing ticket.\n```\n\nThat 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.\n\nHere's the whole loop, start to finish:\n\n```\nThis checkout test is failing intermittently — can you check it and file a bug if it's real?\n```\n\n`playwright-flaky-test-debugger`\n\n(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`\n\nfires next, producing:\n\n```\n**Title**: Checkout — \"Place Order\" clickable before cart total finishes updating\n\n**Steps to Reproduce**:\n1. Add two items to cart on the checkout page.\n2. Immediately click \"Place Order\" without waiting for the total to refresh.\n3. Observe the order is placed with the pre-update total.\n\n**Expected Result**: \"Place Order\" should be disabled until the cart total\nfinishes recalculating.\n\n**Actual Result**: Button remains clickable during the recalculation window,\nallowing an order to be placed with a stale total.\n\n**Evidence**: Trace shows `cart-total` element still has `aria-busy=\"true\"`\nat the moment of the click event (trace timestamp 00:04.211).\n\n**Environment**: Chromium, 1280x720, staging, run #4821\n\n**Suggested Severity**: High — flagged for team confirmation.\n```\n\nThe template above is tracker-agnostic on purpose. To adapt it:\n\n`.github/ISSUE_TEMPLATE/bug_report.md`\n\nstructure, so the Skill's output can be pasted straight in.`## Process`\n\nsection 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.\n\nWould your team's tracker need extra fields beyond this template? Let me know what's missing in the comments!", "url": "https://wpnews.pro/news/from-bug-found-to-bug-filed-a-bug-reporter-skill-for-claude-code", "canonical_source": "https://dev.to/aswani25/from-bug-found-to-bug-filed-a-bug-reporter-skill-for-claude-code-5ih", "published_at": "2026-07-25 16:35:00+00:00", "updated_at": "2026-07-25 17:02:17.101057+00:00", "lang": "en", "topics": ["developer-tools", "artificial-intelligence", "ai-agents"], "entities": ["Claude Code", "Playwright"], "alternates": {"html": "https://wpnews.pro/news/from-bug-found-to-bug-filed-a-bug-reporter-skill-for-claude-code", "markdown": "https://wpnews.pro/news/from-bug-found-to-bug-filed-a-bug-reporter-skill-for-claude-code.md", "text": "https://wpnews.pro/news/from-bug-found-to-bug-filed-a-bug-reporter-skill-for-claude-code.txt", "jsonld": "https://wpnews.pro/news/from-bug-found-to-bug-filed-a-bug-reporter-skill-for-claude-code.jsonld"}}