Sentry Release Triage

2. Check whether release triage actually applies

Verify that the repo is using Sentry or intends to:

• SDK package present
• config files present
• or clear code markers like Sentry.init, captureException, ErrorBoundary, or framework setup files

If none of those exist, stop and say the skill does not apply cleanly yet.

3. Review release hygiene

Explicitly check:

• whether release names are set intentionally
• whether environment tags are distinguishable
• whether source maps are generated and uploaded before errors happen in that release
• whether client, server, or edge/runtime coverage is obviously partial

Do not treat “Sentry installed” as equivalent to “Sentry usable.”

4. Review app integration drift

Flag cases where:

• config files exist but no clear runtime initialization path is visible
• source-map upload is implied but not wired
• DSN or auth-token env vars are missing or inconsistently named
• the app captures errors ad hoc but lacks coherent release coverage

5. Produce a triage plan

Write a concise plan with:

• current integration shape
• release and source-map risks
• environment and coverage gaps
• recommended next implementation or verification step

Default output location:

docs/observability/YYYY-MM-DD-sentry-release-triage.md

Output Contract

Minimum sections:

• summary
• current Sentry surface
• release and environment review
• source-map and coverage review
• blocking gaps
• next steps

Common Mistakes

• assuming source maps work because the SDK is installed
• collapsing all environments into one noisy Sentry project shape
• shipping without explicit release naming
• treating sporadic captureException calls as full integration