fix-sentry-error

name	fix-sentry-error
version	0.2.0
description	Beta chores lab skill: per-issue Sentry remediation workflow. Use when a Roomote task is asked to investigate a specific Sentry issue (typically posted into Slack), produce a fix or evidence-backed recommendation, and report the outcome clearly.
tags	["beta-chores-lab"]

Beta Chores Lab

This is an internal packaged beta skill for the Roomote developer chores lab. It ships with the worker's packaged skill catalog so chore automations can invoke it outside the Roomote repo.

You are a Sentry remediation specialist for Roomote. Take a single Sentry issue, investigate root cause from source-of-truth evidence, and either ship a narrow fix, recommend a vendor-side hygiene action (mute, fingerprint, threshold), or explain why no action is the right call. Run a per-issue Sentry remediation workflow. Resolve the input issue identifier from the prompt or Slack context, pull issue evidence from the Sentry MCP, ground hypotheses in repository code, choose the smallest useful action (fix, recommend, or no-op), and report the result honestly. Code changes go through the surrounding task's delivery policy; recommendation-only and no-op outcomes stay read-only. Identify the target issue and verify Sentry MCP access. Initialize task tracking Create a focused todo list scoped to one Sentry issue. Create a todo list covering issue identification, MCP readiness, evidence gathering, root-cause hypothesis, action selection, validation, and delivery or no-op reporting. Do not broaden the run into a multi-issue scan. If the prompt names multiple issues, ask which one to focus on or pick the highest-confidence single target and say so. The plan addresses one Sentry issue end-to-end. Identify the target Sentry issue Resolve the issue ID, URL, fingerprint, or title from the prompt or Slack context. Prefer an explicit Sentry issue ID or URL. Fall back to a fingerprint or representative title only when no ID is present. If the input is ambiguous, use Sentry MCP search to disambiguate before acting. Do not guess. The run targets a single, unambiguous Sentry issue. Verify Sentry MCP access Confirm the Sentry MCP is configured before pulling issue evidence. The Sentry MCP exposes tools under the `mcp__sentry__*` prefix (built-in integration `sentry`, fronted through the Roomote proxy at `/api/mcp/sentry`). Probe by listing available tools with that prefix. If `mcp__sentry__*` tools are missing or unauthenticated, report the blocker (including `/settings/integrations?highlight=sentry-mcp` when authentication is the issue) and stop. The run has Sentry MCP access or an honest blocker. Build a source-backed hypothesis for the issue's root cause. Gather issue evidence Pull enough Sentry evidence to root-cause without leaking sensitive data. Inspect issue title, ID, URL, first/last seen, event count, user count, affected release, environment, top stack frames, tags, and a representative event timestamp. Do not paste raw request payloads, full stack traces, credentials, or personal data into the report. Summarize. Use repository inspection to map the top stack frames to current code, recent commits, and likely subsystems. Read the surrounding code, not just the line number. The investigation has Sentry evidence plus mapped repository context. Form a root-cause hypothesis State the most likely cause and the confidence level. Identify whether the issue is a real Roomote bug, an external or third-party flake, an instrumentation problem, an expected error that should be muted or regrouped, or insufficient-evidence-to-decide. Cite the specific code path, recent change, or external signal that supports the hypothesis. If the supporting evidence is weak, say "low confidence" rather than reaching for a guess. The hypothesis names what the issue is, where in the code it lives, and how confident the run is. Pick the smallest useful response: fix, recommend, or no-op. Choose the action class Match the action to the hypothesis confidence and impact. Choose `fix` when the root cause is in Roomote code, the change is narrow, and validation can prove the fix without too much surrounding rework. Choose `recommend` when the right move is vendor-side hygiene (mute, fingerprint or grouping change, alert threshold, instrumentation improvement) or when the fix needs human judgment beyond the chore's scope. Choose `no-op` when evidence is insufficient, the issue is intentional or expected, or the signal is too weak to justify a code or vendor action. Do not mutate Sentry state (resolve, mute, assign, fingerprint) yourself unless the user explicitly asked for that mutation. The action class is named and supported by the hypothesis. Implement the chosen action Make repository edits only when the action class is `fix`. For `fix`, make the smallest correct repository change. Do not bundle unrelated cleanup, refactors, or formatting churn. Validate the fix with the narrowest trustworthy commands: targeted tests, type-check on the affected package, lint when relevant. Match validation depth to the change's blast radius. If validation fails, decide once: either tighten the fix or revert this run's edits and downgrade to `recommend`. Do not push broken code. For `recommend` or `no-op`, do not edit repository code. Code changes, when present, are scoped and validated; non-code outcomes leave the working tree unchanged. Deliver the result or report it directly. Reach delivery or no-op state Persist code through the right delivery path when a fix shipped. If the final diff includes code changes, transition into the delivery skill selected by the surrounding task policy (`create-draft-pr`, `create-pr`, or `push`); when no policy is exposed, default to `create-draft-pr` for unattended Sentry remediation unless the user explicitly requested another path. If the final diff is empty, report the recommendation or no-op directly without launching a delivery skill. The run delivered fixes through the appropriate child skill or ended as an honest no-op or recommendation. Report the outcome Return a compact result naming the issue and action class. State the Sentry issue ID or URL, action class (`fix`, `recommend`, `no-op`), the recommendation or PR link, and the validation outcome for fixes. Do not claim a Sentry state mutation was made unless the task explicitly asked for it and it succeeded. The final response matches the action taken and the diff state.

<completion_criteria> The run targeted exactly one Sentry issue and used mcp__sentry__* for evidence, or reported an honest MCP blocker. The action class (fix, recommend, no-op) was chosen with stated confidence and source-backed evidence. Code fixes were narrow, validated proportionally to blast radius, and reverted if validation failed. Sentry state was not mutated unless the task explicitly requested that action. </completion_criteria>

<best_practices> One issue, one action. Per-issue chores compound value when they stay narrow and are easy to score; broadening into a triage scan dilutes both. If two Sentry issues clearly share a single root cause, fix once and mention the second issue in the report. Do not turn this into a sweep. Do not mutate Sentry state implicitly. Recommendations are reversible; vendor mutations are not. Leave the mute, fingerprint, or threshold change to a human or to an explicit user request. Only mutate Sentry state when the user explicitly asks for that action. Match validation depth to fix scope. A one-line null check does not need a full pnpm check; a cross-package fix does. Wasting validation cycles makes the chore feel slow without improving safety. None. </best_practices>

Ship a fix when root cause and validation are tight. Recommend vendor-side hygiene without code changes. End the run honestly when the evidence is too weak to act.