Menu
Use when the user asks to inspect Sentry issues or events, summarize recent production errors, or pull basic Sentry health data via the Sentry API; perform read-only queries with the bundled script and require `SENTRY_AUTH_TOKEN`.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Use after neutral discovery and before Scope Ledger drafting when consequential design uncertainty, ownership placement, lifecycle/state responsibility, compatibility, migration, algorithm choice, operability, or reversibility could admit a materially different safe approach. Begin with a lightweight design-space probe when the lead currently sees one obvious design but an alternative may plausibly exist. Run the full comparison when the probe identifies two or more viable approaches or when choosing incorrectly would be materially consequential. Do not trigger when settled constraints clearly force one safe design.
Explain, trace, or deeply review existing code using inspected repository evidence without implementing changes. Use for code-understanding requests unless the user explicitly asks only for a concise, brief, quick, high-level, or initial overview. This skill explicitly owns thorough reviews, comprehensive explanations, audits, diagnosis, correctness analysis, architecture assessment, risk analysis, execution tracing, concurrency analysis, lifecycle analysis, and full subsystem understanding.
Use when actual scientific or model inputs, outputs, semantics, units, boundaries, classifications, calibration, uncertainty, tolerances, or claims change or require authoritative resolution. Independently derive and evaluate the scientifically defensible contract, compare competing interpretations, create independent golden vectors, and make evidence-qualified recommendations while leaving product policy, scope, architecture, and implementation authority with the user and lead. Do not trigger for mechanical work that cannot affect model behavior or claims.
Use before approval when testability or oracle quality could materially affect scope, behavior, architecture, observability, or validation planning, and after approval before implementation when the detailed planned evidence may not falsify a broken design. Apply to unclear parser, protocol, config, lifecycle, retained-state, performance, scientific/model, security, workflow-checker, or other material oracles. Do not trigger when accepted checks directly prove a localized mechanical change.
Use when reviewing or changing Codex workflow authority, approval, validation routing, review rules, templates, repo-managed skills, or enforcing scripts. Select conformance mode when checking implementation against accepted workflow policy. Select effectiveness mode when the user explicitly asks whether the workflow, its rules, or its architecture should be retained, changed, consolidated, replaced, or removed. Do not trigger for ordinary product documentation or runtime work whose workflow contract is unchanged.
Use after current-state discovery when material product, operator, compatibility, failure, classification, default, threshold, ordering, precedence, persistence, or test-oracle semantics still admit more than one plausible interpretation. Compare interpretations and make conditional recommendations, but unresolved material semantics remain user-owned and block concrete design selection and an unconditional Scope Ledger until explicitly resolved by the user, controlling authority, or evidence that eliminates every competing interpretation. Do not trigger merely because requirements are detailed or work is Non-trivial.
| name | sentry |
| description | Use when the user asks to inspect Sentry issues or events, summarize recent production errors, or pull basic Sentry health data via the Sentry API; perform read-only queries with the bundled script and require `SENTRY_AUTH_TOKEN`. |
SENTRY_AUTH_TOKEN (read-only scopes such as project:read, event:read) or to log in and create one before running commands.SENTRY_AUTH_TOKEN as an env var.SENTRY_ORG, SENTRY_PROJECT, SENTRY_BASE_URL.{your-org}/{your-project}, time range 24h, environment prod, limit 20 (max 50).If the token is missing, give the user these steps:
project:read, event:read, and org:read.SENTRY_AUTH_TOKEN as an environment variable in their system.Use scripts/sentry_api.py for deterministic API calls. It handles pagination and retries once on transient errors.
$env:SENTRY_API = (Resolve-Path .\codex-skills\sentry\scripts\sentry_api.py).Path
Use the repo-relative script path so Sentry inspection follows the checked-in skill bundle.
python3 "$SENTRY_API" \
list-issues \
--org {your-org} \
--project {your-project} \
--environment prod \
--time-range 24h \
--limit 20 \
--query "is:unresolved"
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.
python3 "$SENTRY_API" \
issue-detail \
1234567890
python3 "$SENTRY_API" \
issue-events \
1234567890 \
--limit 20
python3 "$SENTRY_API" \
event-detail \
--org {your-org} \
--project {your-project} \
abcdef1234567890
Always use these endpoints (GET only):
/api/0/projects/{org_slug}/{project_slug}/issues//api/0/issues/{issue_id}//api/0/issues/{issue_id}/events//api/0/projects/{org_slug}/{project_slug}/events/{event_id}/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.{your-org}{your-project}{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.