jaktestowac/reporting-bugs
skills/reporting-bugs/SKILL.md
Transforms rough tester notes, screenshots, console output, or observed behavior into reproducible defect reports with severity, evidence, and follow-up guidance. Use when logging bugs, triaging intermittent issues, or rewriting vague defect notes into developer-ready reports.
$ install --global
skillsauthnpx skillsauth add jaktestowac/awesome-copilot-for-testers reporting-bugsInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: Aug 26, 2026, 2:16 AM59.5s3 files scanned
SKILL.md
- name:
- reporting-bugs
- description:
- Transforms rough tester notes, screenshots, console output, or observed behavior into reproducible defect reports with severity, evidence, and follow-up guidance. Use when logging bugs, triaging intermittent issues, or rewriting vague defect notes into developer-ready reports.
- argument-hint:
- Observed behavior, expected behavior, steps, environment, evidence, and any reproduction notes
- user-invocable:
- true
Reporting Bugs
Use this skill to turn messy observations into bug reports that developers can actually act on. It is optimized for reproducibility, evidence quality, and clean communication rather than speculative root-cause analysis.
When to Use
- write a bug report from rough notes or screenshots
- normalize findings from exploratory testing
- triage an intermittent or hard-to-reproduce issue
- rewrite a vague defect description into a developer-ready report
- capture product, accessibility, or automation defects in a consistent format
Reporting Rules
- Observation first - describe what happened before discussing why it may have happened.
- Reproduction beats opinion - a calm, reproducible report is worth more than a dramatic summary.
- Evidence should travel with the bug - attach logs, screenshots, recordings, payloads, or selectors when available.
- Severity follows impact - grade the issue by user or business impact, not by frustration level.
- Unknowns stay visible - if confidence is low, say so clearly instead of bluffing.
Workflow
Phase 0: Gather the raw material
Collect what exists today:
- short summary of the problem
- environment and build details
- preconditions or setup state
- reproduction steps or triggering actions
- actual result
- expected result
- evidence such as screenshots, traces, logs, payloads, or timestamps
If critical pieces are missing, ask only for what is needed to make the report actionable.
Phase 1: Normalize the reproduction story
Reduce the issue to a clean sequence:
- starting state
- user action or system trigger
- observable result
- expected result
If the issue is intermittent, capture the pattern explicitly:
alwayssometimesseen oncenot reproduced yet
Phase 2: Classify the issue
Give the bug enough metadata to route it correctly.
Suggested dimensions:
- Category - functional, data, auth, performance, accessibility, automation, or integration
- Severity - use
./resources/severity-matrix.md - Confidence - confirmed, likely, or suspected
- Reproducibility - always, intermittent, once, or unknown
Do not write a fake root cause. If the user has a strong suspicion, place it in a separate Notes / Hypothesis section.
Phase 3: Build the report
Use ./resources/bug-report-template.md when possible.
A strong report should include:
- clear title with the broken behavior and surface
- environment block
- preconditions
- numbered steps to reproduce
- actual vs expected result
- severity with short justification
- evidence list
- missing evidence or follow-up questions if the report is still incomplete
Phase 4: Add next-step guidance
When useful, end with one or more of these:
- suggested retest focus after the fix
- related areas that may also be affected
- test coverage that should be added or updated
- evidence still needed to confirm the defect fully
Common Failure Modes
- reporting a symptom without a trigger
- skipping expected behavior and forcing the developer to guess the contract
- writing severity with no business or user impact explanation
- mixing multiple bugs into one ticket
- stating a root cause as fact without evidence
Resource Map
./resources/bug-report-template.md- default structure for the final bug report./resources/severity-matrix.md- impact-based severity rubric
Related Skills
designing-functional-tests- when the defect needs new manual coverage or regression updatesauditing-accessibility- when the report is centered on WCAG or assistive-technology failuresrequirements-test-coverage-mapper- when a bug reveals a larger coverage gap against stated requirements
Definition of Done
This skill is complete when:
- the bug can be understood without extra chat context
- reproduction details are explicit or clearly marked as missing
- severity is justified by impact
- evidence and unknowns are both visible
- the final report is ready to paste into a ticketing system or team channel
Related Skills
jaktestowac/testing-agent-skills
testing
VerifiedTrustedCommunity
Tests the customization assets themselves - skills, prompts, custom agents, instructions - the way a product is tested: activation cases that check an asset fires when it should and stays quiet when it should not, output-contract cases, safety cases, collision cases between assets competing for the same trigger, a weighted rubric scored blind, and a baseline-versus-candidate gate before an edit ships. Use when a skill is edited and nobody knows whether behaviour changed, when two skills fight over the same request, when a description is being tuned for discoverability, when a collection has grown past manual spot-checking, or when the request mentions skill evals, prompt regression, or "does this skill actually work".
113SKILL.mdUpdated Aug 29, 2026
jaktestowac/communicating-quality-findings
development
VerifiedTrustedCommunity
Shapes QA output for the person who has to act on it: result and blocker in the first two lines, one decision per report, findings ordered by what they cost, the long artifact in a file and the decisions in the message, and magnitude stated in units the reader can count. Use when a report is accurate but nobody acts on it, when a finding set is too long to read under time pressure, when the same findings must be retold for a developer, a release manager, and an on-call engineer, or when the request mentions "too long", "make this readable", "just tell me what to do", "so what", or "summarize this for stakeholders". Pairs with unslop-answers, which makes the same report honest.
113SKILL.mdUpdated Aug 29, 2026
jaktestowac/verifying-change-coverage
testing
VerifiedTrustedCommunity
Verifies that the lines and branches a change actually touched are executed by tests, using LCOV or Cobertura diff coverage instead of whole-repo percentages, and escalates uncovered high-risk changes into a blocking finding. Use when a pull request needs a coverage gate that unrelated tests cannot satisfy, when total coverage looks healthy but the diff is untested, when wiring diff coverage into CI, or when someone claims a change is covered because the suite is green.
113SKILL.mdUpdated Aug 26, 2026
jaktestowac/unslop-tests
development
VerifiedTrustedCommunity
Cuts AI tells from test code: tests that pass without proving anything, tautological assertions, mock-only tests, hardcoded waits, coverage theater, vague names, swallowed errors, retries used as fixes. Use whenever test code is written, changed, or reviewed, including tests produced as a side effect of a feature task, and when the request mentions "review these tests", "are these tests any good", "this test always passes", "this suite is flaky", or "clean up these tests". Must always apply to test code.
113SKILL.mdUpdated Aug 26, 2026