/sentry

name: sentry
description: Inspect Sentry issues, summarize production errors, and pull health data via the Sentry API (read-only). Use when user says "check Sentry", "what errors in production?", "summarize Sentry issues", "recent crashes", or "production error report". Requires SENTRY_AUTH_TOKEN. Do NOT use for setting up Sentry SDK, configuring alerts, or non-Sentry error monitoring.
metadata:
  author: github.com/openai/skills
  version: '1.0.0'

Sentry (Read-only Observability)

Quick start

• If not already authenticated, ask the user to provide a valid `SENTRY_AUTH_TOKEN` (read-only scopes such as `project:read`, `event:read`) or to log in and create one before running commands.
• Set `SENTRY_AUTH_TOKEN` as an env var.
• Optional defaults: `SENTRY_ORG`, `SENTRY_PROJECT`, `SENTRY_BASE_URL`.
• Defaults: org/project `{your-org}`/`{your-project}`, time range `24h`, environment `prod`, limit 20 (max 50).
• Always call the Sentry API (no heuristics, no caching).

If the token is missing, give the user these steps:

1. Create a Sentry auth token: <https://sentry.io/settings/account/api/auth-tokens/> 2. Create a token with read-only scopes such as `project:read`, `event:read`, and `org:read`. 3. Set `SENTRY_AUTH_TOKEN` as an environment variable in their system. 4. Offer to guide them through setting the environment variable for their OS/shell if needed.

• Never ask the user to paste the full token in chat. Ask them to set it locally and confirm when ready.

Core tasks (use bundled script)

Use `scripts/sentry_api.py` for deterministic API calls. It handles pagination and retries once on transient errors.

Skill path (set once)

export AGENT_SKILLS_HOME="${AGENT_SKILLS_HOME:-$HOME/.agent-skills}"
export SENTRY_API="$AGENT_SKILLS_HOME/skills/sentry/scripts/sentry_api.py"

User-scoped skills install under `$AGENT_SKILLS_HOME/skills` (default: `~/.agent-skills/skills`).

1) List issues (ordered by most recent)

python3 "$SENTRY_API" \
  list-issues \
  --org {your-org} \
  --project {your-project} \
  --environment prod \
  --time-range 24h \
  --limit 20 \
  --query "is:unresolved"

2) Resolve an issue short ID to issue ID

python3 "$SENTRY_API" \
  list-issues \
  --org {your-org} \
  --project {your-project} \
  --query "ABC-123" \
  --limit 1

Use the returned `id` for issue detail or events.

3) Issue detail

python3 "$SENTRY_API" \
  issue-detail \
  1234567890

4) Issue events

python3 "$SENTRY_API" \
  issue-events \
  1234567890 \
  --limit 20

5) Event detail (no stack traces by default)

python3 "$SENTRY_API" \
  event-detail \
  --org {your-org} \
  --project {your-project} \
  abcdef1234567890

API requirements

Always use these endpoints (GET only):

• List issues: `/api/0/projects/{org_slug}/{project_slug}/issues/`
• Issue detail: `/api/0/issues/{issue_id}/`
• Events for issue: `/api/0/issues/{issue_id}/events/`
• Event detail: `/api/0/projects/{org_slug}/{project_slug}/events/{event_id}/`

Inputs and defaults

• `org_slug`, `project_slug`: default to `{your-org}`/`{your-project}` (avoid non-prod orgs).
• `time_range`: default `24h` (pass as `statsPeriod`).
• `environment`: default `prod`.
• `limit`: default 20, max 50 (paginate until limit reached).
• `search_query`: optional `query` parameter.
• `issue_short_id`: resolve via list-issues query first.

Output formatting rules

• Issue list: show title, short_id, status, first_seen, last_seen, count, environments, top_tags; order by most recent.
• Event detail: include culprit, timestamp, environment, release, url.
• If no results, state explicitly.
• Redact PII in output (emails, IPs). Do not print raw stack traces.
• Never echo auth tokens.

Golden test inputs

• Org: `{your-org}`
• Project: `{your-project}`
• Issue short ID: `{ABC-123}`

Example prompt: “List the top 10 open issues for prod in the last 24h.” Expected: ordered list with titles, short IDs, counts, last seen.