Sentry Operations
Use this skill for live Sentry investigation workflows in the harness.
Before declaring a Sentry data surface unavailable, verify the current CLI help:
- Run
sentry --helpfor top-level command groups. - Run
sentry <command> --helporsentry help <command>before using a command shape from memory. - If a remembered plural command fails, check for the current singular command group before blocking. Prefer canonical forms such as
sentry issue list,sentry org list,sentry log list, andsentry trace list.
Workflow
- Confirm operation and target:
- Determine operation: issue, event, log, trace, org, project, replay/deep-link, Sentry product feature usage, alert/monitor creation, or API query.
- Resolve org from channel config:
jr-rpc config get sentry.org - Resolve project from channel config:
jr-rpc config get sentry.project(optional — many queries span multiple projects). - If org is missing and needed, ask the user.
- If an active repository context exists (cloned repo or configured
github.repo), check the repo root forTELEMETRY.mdbefore forming queries. When present, use its query recipes, org/project mappings, and investigation pivots as repo-specific guidance. Explicit user targets, IDs, URLs, and conversation config still win. If absent, continue normally.
- Execute via CLI:
- Use
sentry <command>for structured queries. - The runtime authenticates Sentry HTTP traffic for this skill. Do not set or print token env vars.
- Read references/cli-commands.md when choosing command shapes, target formats, flags, API fallback, or troubleshooting behavior.
- Read references/sandbox-runtime.md before relying on sandbox credentials.
- Prefer
--jsonwhen parsing or summarizing results. - If no high-level CLI command covers the request, use
sentry api <endpoint>before claiming the workflow is blocked. - Create alerts only when the user explicitly asks. Prefer
sentry alert metricsfor metric-alert list/view/create/edit/delete; before writing, resolve the exact target, check duplicates, run the complete command with--dry-run, then execute once and report the created rule URL. - Use
sentry apionly when live CLI help confirms the first-class command cannot express the requested alert behavior, such as dynamic anomaly detection. - If a Sentry API call returns
401, or clearly says the token is invalid, expired, revoked, or unauthorized, rerun the real Sentry command once and let the runtime trigger a reconnect flow when needed. - If a Sentry API call explicitly says
missing scope,missing scopes, orinsufficient scope, rerun the real Sentry command once and let the runtime trigger a reconnect flow when needed. - If a Sentry API call returns a generic
403,permission denied, or otherwise indicates missing org/project access without naming missing scopes, stop and tell the user the current Sentry connection could not access the requested Sentry data. - Only mention a specific missing scope when the CLI or API error explicitly names that scope. Do not guess scope names from a generic
403.
- Generate deep links:
- For user-scoped or entity-specific views, generate URLs instead of CLI calls.
- Read references/deep-link-patterns.md for URL templates.
- Report result:
- Return issue details, replay links, deep links, or CLI output inline.
- Include Sentry web URLs for easy navigation.
Guardrails
- Default to read-only operations. Only create, edit, or delete alerting resources when the user explicitly requests that exact action and a documented first-class CLI command supports it. Use API fallback only for explicitly requested alert behavior that live CLI help confirms is unsupported.
- Avoid speculative Sentry CLI subcommands. Use bundled references plus live
sentry --helpoutput to verify current commands. - Do not print credential values.
- If org is missing and needed, ask the user.
- Prefer deep links over raw data dumps when linking to Sentry web UI.
- Do not use this skill for repository/source-code/commit/branch/pull-request work, even if the user mentions a Sentry feature or product area.