agentleFS
reatlatreatlat/fullstory-claude-plugin/skills/error-forensics/SKILL.md

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.

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
  1. Very specific:

    Use free fullstory:discover_groups and fullstory:get_opportunity_stats for live signals.

    line 19
  2. Very specific:

    Start broad. Call fullstory:discover_groups to surface error-related frustration signals — these will include console errors, network …

    line 25
  3. Distinctive:

    If you're investigating a specific error or page, build a metric instead:

    line 27
  4. Very specific:

    Call fullstory:get_opportunity_stats or fullstory:compute_metric to get:

    line 37
  5. Very specific:

    Use fullstory:review-zoom around the error, requesting detailed console errors and network requests using the live tool schema

    line 62
  6. Very specific:

    Use fullstory:review-snapshot to see the UI state at error time

    line 63
  7. Very specific:

    Always call fullstory:review-close with the returned client_id, including on errors

    line 65
  8. Distinctive:

    If the user suspects a deploy introduced the error:

    line 88
  9. Distinctive:

    If confirmed: "This error appeared immediately after the July 15th deploy — 0 occurrences before, 147 users affected since."

    line 93
  10. Very specific:

    Never read session transcripts in the main context — use the session-context agent.

    line 97
  11. Distinctive:

    When you find a session with an error, save the session URL.

    line 98
  12. Distinctive:

    If an error affects a single user, it's likely user-specific state.

    line 99
  13. Distinctive:

    Always check the device/browser breakdown — Safari-only or mobile-only errors point to specific code paths.

    line 100
  14. Distinctive:

    If you can't find the root cause from 5 sessions, say so.

    line 101

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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-zoom around the error, requesting detailed console errors and network requests using the live tool schema
  • Use fullstory:review-snapshot to 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-close with the returned client_id, including on errors

Step 6: Report

Present findings:

  1. Error summary: message, frequency, affected users, device/browser breakdown
  2. Reproduction path: what the user did before the error (from session transcripts)
  3. Visual evidence: what the UI looked like at the moment of failure
  4. Severity assessment: widespread vs isolated, data loss vs cosmetic, getting worse vs stable
  5. Recommended fix: based on the evidence — is it a null check, a missing API response field, a race condition?

Error Classification

SymptomLikely CauseCheck
TypeError: Cannot read property 'x' of undefinedMissing null check, async data not loadedIs there a loading state? Does the API always return this field?
NetworkError: 504 Gateway TimeoutBackend timeout under loadIs it peak hours? Specific endpoint?
Console error on Safari onlyBrowser-specific API or CSSCheck MDN compatibility for the API in the stack trace
Error on page load, then works on refreshRace condition in initializationCheck if it's the first session for new users
Error on mobile onlyViewport-dependent bug, touch event issueCheck responsive breakpoints at the error screen width

When It's a Regression

If the user suspects a deploy introduced the error:

  1. Build a trend metric for the error event
  2. Set the time range to span before and after the deploy date
  3. Compute and look for a sharp inflection point at the deploy timestamp
  4. 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-context agent.
  • 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.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.