Compatibility: This skill is compatible with

sentry-cli

v3 only.

• Preflight validation of sentry-cli installation and auth
• List and filter issues by status, time period, and query
• Categorize issues (Valid, False Positive, Already Resolved, Third Party)
• Resolve, mute, and unresolve issues (individually or in bulk)

• DELETE /issues/{id}/

  - Issue deletion (irreversible)
• Project or release deletion
• Bulk status changes without explicit user confirmation
• Modifying alert rules, notification settings, or project configuration

• Listing and viewing issues (read-only)
• Resolving issues (reversible via unresolve)
• Muting/ignoring issues (reversible via unmute)
• Fetching event details and stack traces

.envrc

export SENTRY_AUTH_TOKEN=sntrys_...
export SENTRY_ORG=<your-org-slug>
export SENTRY_PROJECT=<your-project-slug>

• SENTRY_AUTH_TOKEN

  — Generate at https://sentry.io/settings/account/api/auth-tokens/

• SENTRY_ORG

  — Your organization slug in Sentry

• SENTRY_PROJECT

  — Your project slug in Sentry

These are the native sentry-cli env var names. The CLI reads them automatically, so setting them in

.envrc

(and running

direnv allow

) means you don't need to pass

--org

,

--project

, or

--auth-token

flags.

1. CLI flags (

   --org

   ,

   --project

   ,

   --auth-token

   )
2. Environment variables (

   SENTRY_ORG

   ,

   SENTRY_PROJECT

   ,

   SENTRY_AUTH_TOKEN

   )

3. .sentryclirc

   file (project root or

   ~/.sentryclirc

   )

• Stack trace points to application code (

  src/

  ,

  app/

  ,

  webpack://

  )
• Error originates from application logic, not external code
• Reproducible user-facing issues
• API errors from application endpoints

• Network errors from user connectivity issues (timeouts, DNS failures)
• Browser-specific quirks not affecting functionality
• Expected errors (e.g., 401 for unauthenticated users, 404 for deleted resources)
• Errors from automated bots/crawlers

• Last seen date predates a known fix
• No recent occurrences (check

  lastSeen

  field)
• Related code has been refactored or removed
• Issue matches a closed GitHub issue or merged PR

references/extension-patterns.md

• Stack trace contains extension URLs (

  chrome-extension://

  ,

  moz-extension://

  , etc.)
• Error from injected scripts (

  inpage.js

  ,

  content.js

  ,

  inject.js

  )
• Known extension error messages (

  ResizeObserver loop

  ,

  Extension context invalidated

  )
• Stack trace mentions known extensions (MetaMask, Grammarly, LastPass, etc.)

1. Preflight - Run

   bash scripts/check-sentry.sh -v

   to verify sentry-cli and auth
2. Fetch - Run

   bash scripts/fetch-issues.sh --org=<org> --project=<project>

   to get all unresolved issues
3. Inspect - For each issue, fetch its latest event to examine the stack trace:
   bash

   curl -s -H "Authorization: Bearer $SENTRY_AUTH_TOKEN" \
     "https://sentry.io/api/0/issues/{issue_id}/events/latest/" | jq '.exception.values[0].stacktrace.frames'

   Check

   culprit

   ,

   title

   ,

   metadata

   ,

   lastSeen

   , and event count
4. Categorize - Assign each issue to Valid, False Positive, Already Resolved, or Third Party
5. Present - Summarize in a triage report table:

undefined

• scripts/check-sentry.sh

  - Preflight validation (installation, responsiveness, auth)

• scripts/fetch-issues.sh

  - Fetch unresolved issues with rich JSON

• references/api-fallbacks.md

  - API endpoints for operations sentry-cli can't handle

• references/extension-patterns.md

  - Browser extension error detection patterns

1. Run

   sentry-cli info

   to verify configuration and auth status from any source
2. Pipe API responses through

   jq

   for readable output:

   ... | jq '.[] | {shortId, title, count, lastSeen}'

3. Triage Third Party issues first - they are the easiest to identify and often the most numerous
4. Check

   references/extension-patterns.md

   before categorizing ambiguous stack traces