Investigate service errors in Sentry by project, environment, and time period. Rank problems by event counts and affected users, compare releases or earlier periods, and report findings with links and a clear search scope.
Answer "what's breaking" questions from Sentry — find the right org and project, search issues and events with the vocabulary Sentry uses, and report what is actually firing rather than the first hit. Use when the user asks what errors are happening, whether something is stable, what changed since a release, or for any health summary of a service.
Review the instructions the agent will receive before you install.
Sentry answers precise questions precisely and vague questions misleadingly. The work is scoping the question before searching, and ranking what comes back by impact instead of by relevance.
Run find_organizations and find_projects before searching if you are not
certain where the code reports to. A monorepo often maps to several Sentry
projects (api, web, desktop), and a search in the wrong one returns a
confident, empty answer. Say which project you searched.
"Is checkout broken?" becomes queries on what Sentry actually stores: the
error type, the transaction or URL, the release. Prefer search_issues for
"what problems exist" and search_events for "how often / for whom / since
when". Run two or three narrow queries over one broad one, and time-bound
them — is:unresolved over the last 24h answers a different question than
all-time.
The issues worth reporting are the ones with high event counts, many affected
users, or a first-seen that matches a recent release. A brand-new issue with
three events can matter more than a year-old one with thousands — say why the
ones you picked matter. When a number is load-bearing (error rate, affected
users), take it from search_events rather than eyeballing the issue list.
Every issue you cite gets its Sentry link and the window you looked at.
"No matching issues in the last 7 days in api" is a complete, useful
answer — silence about scope is how "it's fine" turns out to mean "I searched
the wrong project".
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 desktop UI changes through the Chrome DevTools Protocol, a connection for controlling the running app. Reproduce the user’s actual steps and compare screenshots, measured state, and console errors to establish evidence before and after a fix.
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.