error-forensics
Skill36 starsChanged 14 days agoMITView on GitHub
Investigate JavaScript errors, console errors, network failures, and crashes in production. Use when debugging user-reported issues, tracking error frequency, finding sessions with specific errors, or determining whether a bug is widespread or isolated.
In this repository45 other files it gives its agents.
- a11y-analyzerSkill
- annotation-opsSkill
- anomaly-detectorSkill
- api-monitorSkill
- benchmark-analyzerSkill
- campaign-trackerSkill
- changelog-detectiveSkill
- cohort-compassSkill
- comparisonsSkill
- customer-360Skill
- dashboard-builderSkill
- deploy-radarSkill
- experiment-analyzerSkill
- feature-adoptionSkill
- form-analyzerSkill
- frustration-hunterSkill
- funnel-doctorSkill
- general-analysisSkill
- heatmap-generatorSkill
- incident-responderSkill
- jira-bug-reporterSkill
- journey-builderSkill
- lifecycle-analyzerSkill
- metric-auditorSkill
- mobile-analyzerSkill
- nps-proxySkill
- onboarding-tutorSkill
- page-performanceSkill
- persona-builderSkill
- predictive-alertsSkill
- privacy-auditorSkill
- query-translatorSkill
- quick-statsSkill
- report-deckSkill
- retention-analyzerSkill
- revenue-impactSkill
- scroll-depth-analyzerSkill
- segment-wizardSkill
- session-playlistSkill
- session-reviewSkill
- session-searchSkill
- slack-reporterSkill
- user-journeySkill
- webhook-healthSkill
- weekly-digestSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
14 rules. About 0 are common, 7 are distinctive, and 7 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈7
Distinctive · estimate
This author's own choices. Worth a look.
7
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 19
Use free fullstory:discover_groups and fullstory:get_opportunity_stats for live signals.
- Very specific: line 25
Start broad. Call fullstory:discover_groups to surface error-related frustration signals — these will include console errors, network …
- Distinctive: line 27
If you're investigating a specific error or page, build a metric instead:
- Very specific: line 37
Call fullstory:get_opportunity_stats or fullstory:compute_metric to get:
- Very specific: line 62
Use fullstory:review-zoom around the error, requesting detailed console errors and network requests using the live tool schema
- Very specific: line 63
Use fullstory:review-snapshot to see the UI state at error time
- Very specific: line 65
Always call fullstory:review-close with the returned client_id, including on errors
- Distinctive: line 88
If the user suspects a deploy introduced the error:
- Distinctive: line 93
If confirmed: "This error appeared immediately after the July 15th deploy — 0 occurrences before, 147 users affected since."
- Very specific: line 97
Never read session transcripts in the main context — use the session-context agent.
- Distinctive: line 98
When you find a session with an error, save the session URL.
- Distinctive: line 99
If an error affects a single user, it's likely user-specific state.
- Distinctive: line 100
Always check the device/browser breakdown — Safari-only or mobile-only errors point to specific code paths.
- Distinctive: line 101
If you can't find the root cause from 5 sessions, say so.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Error Forensics
Find what's breaking in production — JavaScript errors, network failures, console exceptions — and trace them to root cause using real session evidence.
When to Use
- "Are users hitting JavaScript errors on the settings page?"
- "Find sessions with 504 errors on /api/orders"
- "What's the most common console error right now?"
- "A user reported the checkout broke — find their session and tell me what went wrong"
- "Is the TypeError on /dashboard affecting many users or just one?"
- "What errors started appearing after the last deploy?"
Use free fullstory:discover_groups and fullstory:get_opportunity_stats for live signals. Discovery accepts one scope at a time (page_id, domain, app_name, segment_id, or funnel_id); use a segment for device/user filters and the live schema for time ranges. Use computed metrics for exact custom windows.
Workflow
Step 1: Discover error patterns
Start broad. Call fullstory:discover_groups to surface error-related frustration signals — these will include console errors, network failures, and renderer errors ranked by user count.
If you're investigating a specific error or page, build a metric instead:
fullstory:build_metric(
query="console errors on /settings",
output_type="top_n"
)Step 2: Quantify
Call fullstory:get_opportunity_stats or fullstory:compute_metric to get:
- How many users are affected
- Device/browser breakdown (is it Safari-only? Mobile-only?)
- Page concentration (which pages is it happening on?)
- Trend (is it getting worse? Did it start after a deploy date?)
- Rate vs site average (is this page abnormally error-prone?)
Step 3: Find sessions
Build and compute a metric for the error, then call fullstory:get_sessions(metric_id="<id>") and review 3-5 matching sessions. Stored get_sessions_for_opportunity lookup is an optional StoryAI Premium path, not a prerequisite.
Step 4: Investigate each session
For each session, use the session-context agent with a focused task:
"Was there a JavaScript error in this session?
If yes: what was the error message, what page was the user on,
what action triggered it, and what was the stack trace?"Step 5: Open the worst sessions
For sessions that look like the canonical case, use session-review to:
- Open the session:
fullstory:review-open(session_url="<session URL>") - Use
fullstory:review-zoomaround the error, requesting detailed console errors and network requests using the live tool schema - Use
fullstory:review-snapshotto see the UI state at error time - Take snapshots just before and after the error and compare the screenshots and component trees
- Always call
fullstory:review-closewith the returnedclient_id, including on errors
Step 6: Report
Present findings:
- Error summary: message, frequency, affected users, device/browser breakdown
- Reproduction path: what the user did before the error (from session transcripts)
- Visual evidence: what the UI looked like at the moment of failure
- Severity assessment: widespread vs isolated, data loss vs cosmetic, getting worse vs stable
- Recommended fix: based on the evidence — is it a null check, a missing API response field, a race condition?
Error Classification
| Symptom | Likely Cause | Check |
TypeError: Cannot read property 'x' of undefined | Missing null check, async data not loaded | Is there a loading state? Does the API always return this field? |
NetworkError: 504 Gateway Timeout | Backend timeout under load | Is it peak hours? Specific endpoint? |
| Console error on Safari only | Browser-specific API or CSS | Check MDN compatibility for the API in the stack trace |
| Error on page load, then works on refresh | Race condition in initialization | Check if it's the first session for new users |
| Error on mobile only | Viewport-dependent bug, touch event issue | Check responsive breakpoints at the error screen width |
When It's a Regression
If the user suspects a deploy introduced the error:
- Build a trend metric for the error event
- Set the time range to span before and after the deploy date
- Compute and look for a sharp inflection point at the deploy timestamp
- If confirmed: "This error appeared immediately after the July 15th deploy — 0 occurrences before, 147 users affected since."
Guidelines
- Never read session transcripts in the main context — use the
session-contextagent. - When you find a session with an error, save the session URL. The user may need to send it to an engineer.
- If an error affects a single user, it's likely user-specific state. If it affects many, it's likely a code bug.
- Always check the device/browser breakdown — Safari-only or mobile-only errors point to specific code paths.
- If you can't find the root cause from 5 sessions, say so. Don't fabricate a theory from insufficient evidence.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

