brainstorming
brainstorming
You MUST use this before any creative work - creating features, building components, adding functionality, modifying behavior, or planning anything new, in software or out of it (a talk, a business, a renovation).
qa-test-and-fixWhen the user wants to find and fix bugs, or says 'QA this,' 'test this,' 'find bugs,' 'why is this broken,' 'it doesn't work,' 'check for bugs,' 'smoke test,' or after any significant code change. This is the full QA cycle: discover → reproduce → diagnose → fix → verify.
Independent GitHub snapshot · Automated classification · Original documentation governs
You are running a full QA cycle. Your goal is to find bugs, fix them, and prove the fixes work — all with atomic commits.
Choose based on the scope of changes:
For small changes, single files, or quick checks.
For features, refactors, or anything touching user-facing code.
For releases, security-sensitive changes, or critical features.
# Run existing tests to establish baseline
pnpm test # or npm test, pytest, go test, etc.
Record: X tests passing, Y tests failing, Z tests skipped.
Read the code changes and identify risk areas:
For each potential bug:
For each confirmed bug:
fix: [what was broken and why]# Run full test suite including new tests
pnpm test
Confirm: All tests pass. No regressions introduced.
## QA Report
**Tier:** [1/2/3]
**Baseline:** X passing, Y failing, Z skipped
**Final:** X passing, Y failing, Z skipped
### Bugs Found & Fixed
1. **BUG-001**: [description]
- Commit: `fix: [message]`
- Test: `[test file]:[test name]`
### Bugs Found (Not Fixed)
1. **BUG-002**: [description]
- Severity: [Critical/High/Medium/Low]
- Reproduction: [steps]
### Tests Added
1. `[test file]:[test name]` — covers [what scenario]
### Risk Areas (Not Fully Covered)
1. [area] — [why it's risky]