agentleFS
Sign inStart free
mejbaurbaharmejbaurbahar/software-tester-skills/skills/bug-reporting/SKILL.md

bug-reporting

Skill1 starsChanged 53 days agoMITView on GitHub

Use whenever filing a defect found during any kind of testing — applies a standard severity scale, report template, and evidence requirements so bug reports are consistent, reproducible and actionable.

4 other projects use a version of this, 1 of them edited.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

2 rules. 0 are common, 2 are distinctive, and 0 are very specific to this project.

  • 0

    Common

    Most of the 4 edited versions we read keep these.

  • 2

    Distinctive

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Never declare a defect (or a pass) on assumption:

    line 16
  2. Distinctive:

    Check the actual HTTP status, DOM state and persisted data, not just how the page looked.

    line 17

“Common” is measured: kept by at least 6 in 10 of the 4 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Bug Reporting

A good bug report lets a stranger reproduce, understand and prioritize the problem in two minutes. This is the shared format every testing skill files through.

Verify before you file

Never declare a defect (or a pass) on assumption:

  • Check the actual HTTP status, DOM state and persisted data, not just how the page looked.
  • Capture console errors and network request/response evidence.
  • In browser tests wait for a condition (selector/network idle) before asserting; a race-condition false failure wastes everyone's time.
  • Reproduce at least twice and note the rate ("5/5", "2/10"). Try to isolate the minimal steps, and check whether it is a duplicate.
  • Decide whether it is a product bug, test bug, environment issue or requirement gap.

Severity vs priority

Severity (impact on users/system)Meaning
Blocker (S1)Crash, data loss/corruption, core transaction impossible, security breach in progress
Critical (S2)Core feature severely impaired, no workaround (auth broken, checkout broken, cross-tenant data leak)
Major (S3)Non-core feature fails, or a common edge case with a workaround
Minor (S4)Cosmetic, copy, low-impact annoyance
Priority (P0–P3) is the order to fix, set with product/engineering using business context. Severity reflects real-world impact and exploitability, not how the bug was found: a cosmetic issue found during a security audit stays Minor; an unauthenticated data leak is Critical even if it looks like "just a UI thing".

Report template

# [Component] Short, specific symptom (not "X is broken")

- **Severity / Priority**: Critical / P1
- **Environment**: Staging · build 2026.09.21-abc123 · Chrome 128 / macOS 15 (or device/OS)
- **URL / endpoint**: https://…
- **Reproducibility**: 5/5

### Preconditions
Account/role, data state, feature flags.

### Steps to reproduce
1. …
2. …

### Expected result
…
### Actual result
…

### Evidence
- Console: `TypeError: Cannot read properties of undefined (reading 'id')` at cart.js:88
- Network: `POST /api/v1/orders` → 500, response body/`x-request-id: 7f3c…`
- Screenshot/video/HAR/log excerpt (redacted)

### Impact and suspected cause
Who is affected, how many, workaround. Mark theories clearly as hypotheses.

Title formula: [Area] Action → wrong result (condition), e.g. [Checkout] Applying coupon after changing country → total not recalculated.

Filing mechanics

gh issue create --title "[Checkout] Coupon not recalculated after country change" --body-file bug.md --label bug,severity:critical

Attach the smallest useful evidence; link to the failing test, trace or CI run; reference the commit or release that introduced it if known. Group symptoms with one root cause into one report.

Safety and privacy

  • Redact real user PII, tokens, passwords and API keys from screenshots, HARs and logs, even on internal environments.
  • For security findings, use the private disclosure channel (security advisory, restricted tracker, security@ mailbox), include only what is needed to reproduce and verify the fix, and do not publish working exploit chains.

Quality checklist

Title specific · steps numbered and minimal · expected vs actual explicit · environment and build named · evidence attached · severity justified · duplicate checked · no secrets.

Related

manual-testing, exploratory-testing, functional-testing, api-testing, regression-testing, test-metrics-reporting

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.

Check your setup, free