bug-prospector

# Bug Prospector > **Quick Ref:** Find bugs that pattern-based scanners miss by analyzing *intent*, not syntax. Output: `.agents/research/YYYY-MM-DD-bug-prospector-*.md` **YOU MUST EXECUTE THIS WORKFLOW. Do not just describe it.** **Required output:** Every BUG finding MUST include Urgency, Risk, ROI, and Blast Radius ratings using the Issue Rating Table format. Do not omit these ratings. **Required output:** Every BUG and FRAGILE finding MUST also narrate the **user experience** — what a person hits while the bug is live, and what they get instead once it is fixed. Write it in plain user-facing language: what they see, tap, and feel. Not the mechanism, which the fields above already carry. Two rules keep this honest: - 🛑 **Findings with no visible symptom still get the field.** Say so explicitly and name what the user is protected from — a crash that never happens, data that is not silently lost, a sync that stops diverging. Invisible wins are the ones most often dropped, and they are frequently the most valuable. "No visible change; prevents X" is a complete answer. - 🛑 **Never invent a symptom to fill the field.** If you cannot say what the user would experience, that is a signal the finding may be theoretical — reclassify it or say plainly that the impact is unclear. A plausible-sounding invented symptom is worse than an admitted gap: it inflates the finding's apparent severity and corrupts the triage the ratings exist to support. *Why: ratings say how bad a find...