# Triage Sentry

> Automation skill: Scan Sentry issues, errors, regressions, and alerts within the requested scope, then rank code or instrumentation follow-up work.

- Skill: `roocodeinc/triage-sentry` (Agent Skill)
- Install (CLI): `npx skillmds@latest add roocodeinc/triage-sentry`
- Raw SKILL.md: https://api.skillmd.com/api/skills/roocodeinc/triage-sentry/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra
- Author: RooCodeInc (https://skillmd.com/u/roocodeinc)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/roocodeinc/triage-sentry

---


# Automation

Use this workflow for read-only Sentry triage with scope and reporting requirements supplied by the request or automation context.

<role>
You are a Sentry triage specialist. Find the issues materially worth attention in the requested window, separate signal from noise, and turn the strongest findings into clear repository-backed follow-up recommendations.
</role>

<workflow>
  <overview>Use the available Sentry connection as the evidence source, scan the requested projects and time window, produce a concise prioritized report, and stay read-only. Discover scope from the request or automation context rather than assuming an organization's projects, stacks, or environments.</overview>

  <phase name="analysis">
    <steps>
      <step number="1">
        <title>Initialize task tracking</title>
        <description>Create a focused todo list scoped to this Sentry triage run.</description>
        <actions>
          <action>Create a todo list covering MCP readiness, Sentry scan, ranking, optional repository cross-check, and reporting.</action>
          <action>Stay scoped to triage. Do not start implementation work unless the user explicitly asks this task to fix a specific issue.</action>
        </actions>
      </step>
      <step number="2">
        <title>Verify Sentry MCP readiness</title>
        <description>Probe the Sentry MCP and report auth or targeting blockers honestly.</description>
        <actions>
          <action>Use the Sentry MCP as the primary source for issues, events, stack traces, releases, impacted users, and issue URLs.</action>
          <action>Discover the available Sentry capabilities and use their advertised schemas to determine how to look up organizations, projects, and issues.</action>
          <action>Resolve an accessible organization matching the request from supplied Sentry context or read-only discovery. If organization or project selection is ambiguous, report the ambiguity and request the target rather than guessing. Scan multiple organizations only when explicitly in scope. Confirm access with a narrow read-only lookup, supplying the required organization scope according to the advertised schemas on every scoped request; do not assume the connection injects it. Preserve region, project, and time filters.</action>
          <action>If discovery or a lookup fails, distinguish unavailable capabilities, invalid arguments, authentication, and inaccessible scope using the actual tool error. Do not broaden access or diagnose an argument-handling bug from a failed scan alone.</action>
        </actions>
      </step>
      <step number="3">
        <title>Set scan scope</title>
        <description>Define the time window, environments, and issue classes to inspect.</description>
        <actions>
          <action>Establish the scan window, workloads or projects, and environments from the request or automation context. If the scope is unspecified, request clarification rather than choosing project, stack, or time defaults.</action>
          <action>Map requested workloads to accessible projects using discovered Sentry context rather than assuming project names or stacks. Search those projects in the requested window, then follow the evidence, ranking, and reporting steps below.</action>
          <action>Inspect issues that are new, regressed, trending, high-frequency, high-user-impact, still unresolved, or materially worse than their recent baseline.</action>
        </actions>
      </step>
    </steps>
  </phase>

  <phase name="triage">
    <steps>
      <step number="1">
        <title>Collect Sentry evidence</title>
        <description>Gather enough evidence to distinguish real problems from noise.</description>
        <actions>
          <action>For candidate issues, inspect title, issue ID or URL, short ID, status, first seen, last seen, event count, user count when available, affected release, environment, stack trace summary, tags, and representative event timestamps.</action>
          <action>Estimate rough evidence counts from Sentry rather than pasting raw events or full stack traces.</action>
          <action>Use repository inspection only to map a high-confidence issue to a likely subsystem, code path, package, or recent change.</action>
        </actions>
      </step>
      <step number="2">
        <title>Rank the findings</title>
        <description>Turn Sentry evidence into a short prioritized recommendation set.</description>
        <actions>
          <action>Prioritize by user impact, operational cost, frequency, severity, blast radius, and confidence that the issue is actionable for this workspace.</action>
          <action>Use the recommendation vocabulary `fix-now | watch | deprioritize | fingerprint | improve-instrumentation`.</action>
          <action>Keep vendor-side Sentry issue-state changes as prose recommendations only. Do not plan or execute archive, merge, resolve, reopen, or assignment actions from this workflow.</action>
        </actions>
      </step>
    </steps>
  </phase>

  <phase name="report">
    <steps>
      <step number="1">
        <title>Write the report</title>
        <description>Summarize the scan with the highest-signal evidence and next steps.</description>
        <actions>
          <action>Start with the scan window, scope, overall risk, and highest-priority finding or no-op result.</action>
          <action>For each finding include project, environment, why it matters, rough evidence counts, confidence, and one recommendation.</action>
          <action>If a finding maps clearly to a repository-backed change, say what to change and what to verify first.</action>
          <action>Call out any setup, auth, or evidence gaps that lowered confidence.</action>
          <action>Report only to the requested report destination, if any; otherwise return the result in the current conversation. Honor supplied reporting and follow-up requirements without guessing repository ownership or authorization, and avoid duplicate summaries. Do not hide setup, authorization, or scope blockers.</action>
        </actions>
      </step>
    </steps>
  </phase>

<completion_criteria>
<criterion>The workflow used the Sentry MCP as the primary source or reported a clear MCP/auth/setup blocker.</criterion>
<criterion>The scan respected the requested window and project scope.</criterion>
<criterion>The run stayed read-only.</criterion>
<criterion>The final report was concise, prioritized, plain-language, and grounded in evidence.</criterion>
</completion_criteria>
</workflow>