| name | sentry-fix-stack-traces |
| description | Make Sentry stack traces readable — upload source maps for JavaScript/TypeScript, or debug files for native and mobile (dSYM, ProGuard/R8, NDK symbols, Dart obfuscation maps, .NET PDBs). Use when frames in Sentry show minified names, bundled paths, hex addresses, "unknown", or method names with no file/line, instead of your original source. |
| license | Apache-2.0 |
Fix Unreadable Stack Traces
An event whose frames read chunk-4f2a.js:1:28471 or 0x00000001045a2f10 costs you the
thing Sentry is for.
This skill takes an existing unreadable trace and gets the right artifact — source maps,
or debug files — uploaded and matched, then proves it on a new event.
Wrong skill? If Sentry isn’t installed and capturing events yet, start with
sentry-instrument — you can’t diagnose frames you don’t have.
(That skill and sentry-get-started handle this proactively during setup, using the
same references; this skill is the symptom-driven entry point for a trace that’s already
broken.) If frames are readable and the goal is tying them to commits and suspect PRs,
that’s releases, not this.
Step 1 — Read a real event before touching build config
Do not start editing build files. Missing artifacts, mismatched artifacts, and a
partially-covered build all look identical in a trace, and the fixes differ.
Pull the event — via the MCP (search_issues, then get_sentry_resource) or the issue
URL the user gives you — and classify it using the triage table in
references/debug-artifacts/index.md.
Also establish whether the event came from a release build (dev builds are usually
readable already).
