Verify bug reports
Never take bug reports or QA feedback as gospel. Use before fixing anything QA or a user reported, to verify what correct behaviour actually is.From its SKILL.md
npx -y skills add StuMason/skills --skill verify-bug-reportsAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
1.6 KB, as published. Nobody here has run it
Verify Bug Reports
QA describes what they see. They do not define what is correct. A "fix" for a misunderstood requirement is a new bug with a paper trail, so before fixing what is reported, verify the report.
The check
- Reproduce what they saw. If you cannot reproduce it, that is your finding, go back with exactly what you tried.
- Find the source of truth for expected behaviour. The ticket, the spec, an ADR, how the rest of the codebase handles the same pattern. Not the bug report itself, and not vibes.
- Deliver a verdict, one of three:
- The report is right. Behaviour contradicts the source of truth. Fix it.
- The report misunderstands the requirement. The observed behaviour is correct. Explain why, with the source cited. Do not "fix" it. Do not change working code to match a misreading.
- Nobody actually knows what correct is. There is no source of truth to check against. That is not a bug, that is an unwritten requirement: stop and get it decided before touching code (see the ticket-readiness skill).
Why bother
Because "QA said so" is how correct code gets broken politely. The reporter is describing a symptom through their own model of the system, and their model may be wrong. Asking "hang on, is that actually the intended behaviour?" costs nothing. Being the agent who quietly broke checkout because a tester misread the spec costs rather more.