error-backlog-triage

name	error-backlog-triage
description	Hourly error-backlog grooming sweep for {{sentry_project}}. Groups new and spiking errors, dedupes against existing GitHub issues in {{triage_repo}} by Sentry issue ID, drafts a GitHub issue with the stack trace and impact for the top {{max_issues_per_run}}, and posts a sweep summary to {{alert_channel}}. Never resolves, ignores, mutes, or assigns an error.

Groom the Sentry backlog into a short, deduped, ranked list of GitHub issues — without paging anyone and without deciding anything is fixed. A sweep spawns a fresh, read-only session; this skill turns the current state of {{sentry_project}} into grouped errors, a dedupe check against {{triage_repo}}'s existing issues, drafted issues for the top offenders, and a Slack summary.

This is backlog grooming, not incident response: it never fires on a single alert and never pages a human (that's the oncall-triage template), and it never drafts a postmortem after an incident resolves (that's incident-postmortem). It runs on a fixed cadence over the whole backlog and its only outputs are drafted issues and a summary alert.

Proactive and read-only across Sentry; covers every new-or-spiking error found in a sweep. Nothing carries over between sweeps — dedupe state comes from GitHub's own issue list, not an agent-side ledger. Handle each error as an independent unit: a failure or inconclusive check on one error never blocks the others found in the same sweep.

- The hourly error-backlog sweep fires on its cadence. - A human asks the agent to re-groom the Sentry backlog, or to explain why a specific error wasn't drafted as an issue.

Step 1 — Pull the backlog from Sentry (read-only)

Via the Sentry connector, for {{sentry_project}}:

• Issues that are new (first seen since the last hour).
• Issues that are unresolved and whose event frequency over the last hour is at least {{spike_multiplier}}x their trailing baseline (e.g. the last 14 days' hourly average) — a real spike, not steady background noise.

For each one, pull the full stack trace, exception type, first-seen and last-seen timestamps, total event count, and affected-user count.

Step 2 — Group and rank

Group the pulled issues by Sentry fingerprint so one root cause is one candidate, not several. Rank the groups by impact:

impact_score = event_count * max(affected_users, 1)

Spiking issues rank alongside new ones on the same impact score — a spike in an old, previously-quiet error can matter as much as a brand-new one.

Step 3 — Dedupe against GitHub (read-only)

Before drafting anything, check whether each candidate is already tracked:

gh issue list --repo {{triage_repo}} --state all \
  --search "<sentry-issue-short-id>" \
  --json number,title,url,state

Match on the Sentry issue's short ID or permalink (issues drafted by this skill embed it in the body — see Step 4). If a match exists, mark the candidate as already tracked and skip drafting; note its issue URL for the Step 5 summary instead.

Step 4 — Draft the top offenders

For the top {{max_issues_per_run}} candidates that aren't already tracked, draft one GitHub issue each:

gh issue create --repo {{triage_repo}} \
  --title "[error-triage] <exception type>: <location>" \
  --label "bug,sentry-triage" \
  --body "Detected by the hourly error-triage sweep.

**Sentry issue:** <permalink> (<short-id>)
**First seen:** <timestamp>
**Impact:** <event_count> events / <affected_users> users
**Trend:** <new | spiking Nx trailing baseline>

**Stack trace:**
\`\`\`
<full trace>
\`\`\`

This is a draft for triage — no error state was changed in Sentry, and no
assignee has been set. A human owns prioritization and ownership from here."

Any candidate beyond {{max_issues_per_run}} is left for the next sweep to re-evaluate against the current backlog — it is not queued or remembered.

Step 5 — Post the sweep summary

Post one message to {{alert_channel}}: counts of new vs. spiking errors found, the issues drafted this sweep (title + link), and the candidates skipped because they're already tracked (with the existing issue's link). A sweep with nothing new or spiking posts nothing — silence is the all-clear.

- **Read-only across Sentry, no exceptions.** Never resolve, ignore, mute, merge, or delete a Sentry issue from this skill — reporting only. - **Draft, not decide.** A drafted GitHub issue has no assignee and is never labeled or closed as resolved by this skill. A human owns triage from there. - **Dedupe via GitHub, not a ledger.** Every sweep is a fresh session; the "already tracked" check reads GitHub's current issue list each time, never an agent-side memory of what was drafted before. - **Cap per sweep.** Draft at most {{max_issues_per_run}} issues per run, even if more candidates qualify — avoid flooding the tracker in one sweep. - **Independent per error.** A failure or inconclusive check on one error never blocks grooming the others found in the same sweep. - **Scoped secrets.** The Sentry credential is brokered through the connector and the GitHub token is injected at runtime for the `gh` CLI; neither is ever shown to the model or written to logs. - **One summary per sweep.** Don't re-post or re-draft for an error already handled this same sweep.