Investigate production errors using Sentry stack traces, which show the code execution path, and events leading up to the failure. Identify likely causes, triggering conditions, affected users, and releases before changing code.
Root-cause a production error with Sentry's evidence before touching code — pull the issue, read the stack trace and breadcrumbs, and separate the crash from its trigger. Use when the user pastes a Sentry link or issue ID, reports a production error, or asks why something is crashing for users.
Run score Not tested
See how to installdebug-with-sentry investigates production errors recorded in Sentry and organizes what failed, why it may have failed, and who was affected. It retrieves issue details and follows the stack trace, the record of the code execution path, to the first frame belonging to the project’s code. It also checks preceding user actions, distributions across browsers, organizations, and releases, as well as when the issue first appeared and how often it occurred. This helps separate the crash location from the condition that triggered it.
Use it when someone shares a Sentry link or issue ID, reports a production error, or asks why the app is crashing. It can help distinguish issues with the same error message but different execution paths, and check whether an error is concentrated in a particular environment or release.
Sentry integration is required. Production line numbers may differ from those in the current working code, so the skill checks the release when comparing them. If it uses Seer analysis, it verifies the suggested cause against the execution trace. Resolving an issue should take into account whether a fix has shipped.
This overview was written by AI (OpenAI Codex) from the public SKILL.md. Check the original below for the exact behavior.
AI checked the SKILL.md for operations that need care and for setup requirements. The score comes only from actually running the skill (hands-on test).
Not counted in the score. Rated by AI (OpenAI Codex) as of Oct 29, 2026. Treat it as a guide and read the original before installing.
Review the instructions the agent will receive before you install.
A Sentry issue is a claim about what broke. The job is to turn it into a claim about why it broke, backed by the event data, before anyone edits code.
A pasted URL or short ID (PROJECT-123) goes straight to get_issue_details.
A described error ("users can't check out") goes through search_issues first,
but treat the results as candidates: match on the error type and the affected
code path, not on title similarity. If two issues share a message but differ in
stack trace, they are two bugs.
Fetch the newest event's stack trace. The top frame is where it crashed, not
where it broke — walk down until you leave library code and hit the first
frame owned by this repo. That frame and its local variables are the starting
point. Cross-check the file against the working tree: production runs a
release, and the line numbers may belong to code that has since changed.
find_releases tells you which version the events come from.
Before proposing a cause, check what the events have in common:
get_issue_tag_values): one browser, one endpoint, one tenant, one
release? A bug scoped to a dimension names its own trigger.Seer (analyze_issue_with_seer) is worth running for a second opinion, but
verify its suggested cause against the frames yourself before repeating it.
The finding is three sentences: what fails, why, and who it hits (volume,
affected users, releases). Link the issue. If the user asks for a fix, fix the
frame you identified — and only then consider update_issue to assign or
resolve, never as a way to make the dashboard quiet.
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Review how you use Superset and identify unused features that fit your workflow. Get a short list of suggestions, learn about each option, and set up selected features such as scheduled agents, parallel workspaces, or shared tasks.
Set up recurring tasks in Superset with an agent prompt, a schedule or event trigger, and a chosen execution workspace. After explicit confirmation, create the automation, check its saved settings, and review a real first run.
Browse pages, click controls, fill fields, and inspect screenshots or console messages through Superset's browser pane. Use it to preview a running web app, check interface behavior, and work through browser tasks in a visible session.
Build Stripe payments, subscriptions, and invoicing using verified documentation and API parameter definitions. The skill guides product selection, sandbox testing, and webhook handling, where server notifications determine payment and subscription state.
Verify a UI change or reproduce a bug in the running desktop app using the Chrome DevTools Protocol (CDP), a browser debugging interface. Follow the real user journey and compare screenshots with measurements such as route, scroll position, and persisted state.
Diagnose failed GitHub Actions runs by finding the first meaningful error, separating code problems from infrastructure issues and intermittent failures, and comparing the base branch. Get a focused report explaining the PR’s involvement and recommended next steps.