| name | sentry-setup-releases |
| description | Set up Sentry releases and deploy tracking — tag events with a version and environment, create the release in CI with its commits, and wire up suspect commits and code mappings, so Sentry can show which release introduced an issue, which commit is responsible, and release health. Use when asked to set up releases, track deploys, see what changed, or when issues show an unknown release or no suspect commit. |
| license | Apache-2.0 |
Set Up Sentry Releases
Without a release, an issue tells you what broke but nothing about when it started
or what changed. This skill wires that up end to end: the version tag on events, the
release created in CI with its commits and deploy, and the suspect-commit path that
turns an issue into a culprit PR.
The whole setup fails silently — every piece can be individually correct while
producing nothing visible — so this skill’s real job is to diagnose which piece is
missing before configuring anything.
Wrong skill? If Sentry isn’t installed and capturing events yet, start with
sentry-instrument — releases decorate events you already receive.
If the complaint is minified or unsymbolicated frames, that’s sentry-fix-stack-traces
(readable frames are a prerequisite for suspect commits, so you may come back here
after). If the goal is fixing one specific issue rather than setting up the wiring,
that’s sentry-debug-issue. Note that sentry-get-started and sentry-instrument set
the release tag during setup, using the same references — this skill is the entry
point for the CI half and for a release feature that isn’t working.
Step 1 — Establish which half exists before configuring anything
