Skills-curated openai-sentry

Use when the user asks to inspect Sentry issues or events, summarize recent production errors,

install

source · Clone the upstream repo

git clone https://github.com/trailofbits/skills-curated

Claude Code · Install into ~/.claude/skills/

T=$(mktemp -d) && git clone --depth=1 https://github.com/trailofbits/skills-curated "$T" && mkdir -p ~/.claude/skills && cp -r "$T/plugins/openai-sentry/skills/openai-sentry" ~/.claude/skills/trailofbits-skills-curated-openai-sentry && rm -rf "$T"

manifest: plugins/openai-sentry/skills/openai-sentry/SKILL.md

source content

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:

Create a Sentry auth token: https://sentry.io/settings/account/api/auth-tokens/
Create a token with read-only scopes such as
```
project:read
```
,
```
event:read
```
, and
```
org:read
```
.
Set
```
SENTRY_AUTH_TOKEN
```
as an environment variable in their system.
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.

Scripts and references are located under

{baseDir}/

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.

When to Use

When NOT to Use