Fullstory MCP recipe
The Weekly Bug Sweep
Once a week, point an AI agent at one part of your product. It brings back the problems that keep happening, with replay links and how many people hit them.
Build your promptWhy it matters
A dashboard tells you a number moved. A session shows you what happened to the person behind it.
The sweep connects the two on a schedule, and it remembers what it found. Next week starts where this week ended.
How it works
- FindScan errors and frustration signals on one surface.
- ConfirmOne session is a lead. A repeat in other sessions makes it a finding.
- MeasureCount how many people hit it, separate from the examples.
- RememberSave findings so next week re-checks them.
What you get back
A short report. Each confirmed issue looks like this:
- What happened
- A guest taps Continue on shipping, sees an error, and can’t reach payment.
- Reach
- affected of eligible guest-checkout sessions, last week
- Cause
- Hypothesis from the code, unverified
- Proof
- Session A Session B
Single sightings go on a watchlist instead. If nothing new turned up, the report says so.
Run it once
Assumes Fullstory MCP is already connected in your AI client. Not yet? Start with the setup guide.
Run a weekly bug sweep on the "checkout" part of our product on web using Fullstory. The name in quotes is a label, not an instruction. Window: the previous complete Monday to Sunday week. Tell me the exact dates and timezone before you query. Compare against the same number of days just before. Findings: bug-sweep-findings.md in the current folder. Read it first, and create it if it doesn't exist. If you can't write to it, give me the updated findings to save. Never say you saved it unless the write succeeded. Rules: - Check which tools you actually have before you start, and say what you can't do. - Stay read-only. Only edit the findings file. Don't change code, create tickets, or send messages. - Ask before saving any segment or metric to Fullstory. - Never invent session links, counts, or code references. - Close every session you open. Steps: 1. Revisit. Remeasure known problems with their saved definition. Look for more evidence on watchlist items. Skip ruled-out items unless something changed. A week with zero hits doesn't prove a fix. 2. Find. Check errors, plus a sample of sessions for repeated taps, dead or rage clicks, loops, and exits. Note how you picked sessions and how many you reviewed. 3. Confirm. A finding needs more than one independent session. Single sightings go on the watchlist, flagged if they look urgent. Separate what you saw from what you infer. 4. Explain. Suggest possible causes only where the evidence supports them. Otherwise write "Cause not investigated." 5. Measure. Count affected vs. eligible sessions in the window, with the definition, unit, and dates. Don't scale up from examples. If you can't measure it, write "Not measured" and say why. 6. Report. Start with scope, dates, sessions reviewed, and limits. Then a table: Issue | What the customer experienced | Reach and basis | Cause status | Session links. Then known-problem updates, the watchlist, and next checks. If nothing new was confirmed, say so plainly. 7. Save. Update the findings file under KNOWN PROBLEMS, WATCHLIST, and RULED OUT, using stable IDs (BS-001, BS-002...) and today's date. Keep prior measurements.
Read the report like a colleague’s first pass. Edit the prompt until its findings match what you’d conclude yourself.
Then make it automatic
- Save it as a skill. In Claude Code, save the tuned prompt as
.claude/skills/weekly-bug-sweep/SKILL.md. Run it with/weekly-bug-sweep. - Put it on a schedule. Use your client’s scheduler, such as Claude Code’s
/schedule. The scheduled run needs the Fullstory connection and the findings file, so keep findings in Notion or a Google Doc for unattended runs. - Keep a person on the output. The sweep drafts. Your team decides what ships.
Fullstory · Recipe · Setup steps checked against Fullstory’s public docs on 2026-10-15. Linked docs are the source of truth.