agentleFS
WST2002WST2002/claude-code-skills/skills/bug-report-writer/SKILL.md

bug-report-writer

Skill4 starsChanged 27 days agoMITView on GitHub

Use when writing or improving a bug report, defect ticket or Jira/GitHub issue from notes, screenshots, logs, a video description or a failed test, so developers can reproduce and fix it quickly.

4 other projects use a version of this.

Adopted by

Most recently taken up by

The file

Files
SKILL.md

Bug Report Writer

Overview

A good bug report lets a developer reproduce the problem on the first try. State exactly what happened, what should have happened, and how to make it happen again, with only the evidence that matters.

Method

  1. Collect facts from what the user provides: steps, screenshots, console or server logs, failing test output, environment.
  2. Reduce the steps to the shortest path that triggers the bug. Remove steps that do not matter.
  3. Separate observation from guesses. Facts go in the report; suspected causes go in a clearly labelled Notes line.
  4. Find missing essentials (environment, build version, account type, data used). Ask for them, or mark them Unknown.
  5. Set severity and priority with the table below.
  6. Write using the format. Keep the title searchable.

Format

Title: <Area>: <what goes wrong> when <condition>
       e.g. "Checkout: total ignores coupon when quantity is changed"

Environment: <app/build version, URL, browser/OS or device, account role, feature flags>
Severity: <Blocker | Critical | Major | Minor | Trivial>   Priority: <P1-P4>

Steps to reproduce:
1. ...
2. ...

Expected result: <what should happen, with the rule or spec reference if known>
Actual result: <what happens, exact error text>
Reproducibility: <Always | Intermittent (3 of 10 tries) | Once>

Evidence: <screenshot or video name, log excerpt (only relevant lines), request/response, test name>
Test data: <account, IDs, input values>
Notes: <suspected cause, workaround, first build where seen> (optional)

Severity guide

SeverityMeaning
BlockerStops testing or a release; no workaround
CriticalCore flow broken, data loss, security or payment issue
MajorFeature works incorrectly; workaround exists
MinorCosmetic or rare edge case with little impact
TrivialTypo or tiny visual issue

Common mistakes

  • Titles like "Bug in app" or "Not working".
  • Steps that start in the middle ("go to the form" — which form, which user?).
  • Pasting 500 lines of logs instead of the relevant 10.
  • Mixing two bugs in one report.
  • Presenting a guessed cause as fact.

Made by Wageesha Tripathi · LinkedIn · Email · More skills

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.