QA Bug Hunt Planner
Turn a fuzzy QA request into evidence-backed findings, audit tracks, fix tickets, and verification gates.
When To Use
Use this when the user asks for QA, bug hunting, reliability review, test planning, impact analysis, mismatch review, or "what else should we audit?"
Do not use this for PR-specific review loops; use pull-request-review-loop. Do not use it for narrow field-level contract drift only; use cross-layer-contract-audit.
Workflow
- Scan the requested area before proposing tracks.
- Recommend 3-8 audit tracks with short reasons.
- Ask which tracks to run unless the user already said to run all.
- Execute selected tracks with source evidence.
- Convert findings into fix-ready tickets, definitions of done, impact gates, and tests.
- Hand off to a spec or implementation workflow only after evidence is clear.
For sample prompts and report shape, see references/examples.md.
For a reusable bug-hunt plan template, see references/qa-hunt-template.md.
Input Signals
Use source files, routes, screens, logs, test folders, issue reports, API schemas, screenshots, metrics, support reports, recent incidents, and known flaky areas. If the scope is broad, start with a bounded scan and recommend tracks before doing deep work.
Output
Return:
- Executive Read: highest-risk area and why.
- Audit Tracks: what to run and why.
- Findings Matrix: severity, finding, evidence, affected surface, proposed ticket, test gap.
- Fix Board: now/next/later ordering.
- Impact Gate: checklist to complete before each fix.
- Follow-Up Tests: automated and manual verification paths.
- Open Questions: product or ownership decisions needed.
Guardrails
- Do not invent bugs without evidence.
- Do not edit implementation code unless the user explicitly approves fixes.
- Do not skip the track recommendation step when the scope is fuzzy.
- Treat destructive actions, auth, payments, admin tools, migrations, and data integrity as high risk.
Avoid
- Do not stop at a generic test plan when the user needs fix-ready tickets.
- Do not bury severity or affected surface in prose.
- Do not recommend a rewrite when a smaller stabilization ticket would prove or reduce the risk.
1---2name: qa-bug-hunt-planner3description: Run source-backed QA discovery, recommend audit tracks, build fix-ready bug-hunt plans, and define verification gates.4---56# QA Bug Hunt Planner78Turn a fuzzy QA request into evidence-backed findings, audit tracks, fix tickets, and verification gates.910## When To Use1112Use this when the user asks for QA, bug hunting, reliability review, test planning, impact analysis, mismatch review, or "what else should we audit?"1314Do not use this for PR-specific review loops; use `pull-request-review-loop`. Do not use it for narrow field-level contract drift only; use `cross-layer-contract-audit`.1516## Workflow17181. Scan the requested area before proposing tracks.192. Recommend 3-8 audit tracks with short reasons.203. Ask which tracks to run unless the user already said to run all.214. Execute selected tracks with source evidence.225. Convert findings into fix-ready tickets, definitions of done, impact gates, and tests.236. Hand off to a spec or implementation workflow only after evidence is clear.2425For sample prompts and report shape, see `references/examples.md`.26For a reusable bug-hunt plan template, see `references/qa-hunt-template.md`.2728## Input Signals2930Use source files, routes, screens, logs, test folders, issue reports, API schemas, screenshots, metrics, support reports, recent incidents, and known flaky areas. If the scope is broad, start with a bounded scan and recommend tracks before doing deep work.3132## Output3334Return:3536- **Executive Read:** highest-risk area and why.37- **Audit Tracks:** what to run and why.38- **Findings Matrix:** severity, finding, evidence, affected surface, proposed ticket, test gap.39- **Fix Board:** now/next/later ordering.40- **Impact Gate:** checklist to complete before each fix.41- **Follow-Up Tests:** automated and manual verification paths.42- **Open Questions:** product or ownership decisions needed.4344## Guardrails4546- Do not invent bugs without evidence.47- Do not edit implementation code unless the user explicitly approves fixes.48- Do not skip the track recommendation step when the scope is fuzzy.49- Treat destructive actions, auth, payments, admin tools, migrations, and data integrity as high risk.5051## Avoid5253- Do not stop at a generic test plan when the user needs fix-ready tickets.54- Do not bury severity or affected surface in prose.55- Do not recommend a rewrite when a smaller stabilization ticket would prove or reduce the risk.
mo-hawary