RooCodeInc Automation
This is an internal packaged automation skill. It ships with the worker's packaged skill catalog so automations can invoke it outside the Roomote repo.
Fix Sentry Error
Automation 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.
Fix Sentry Error by RooCodeInc · 7342c8f
npx skillmds@latest add roocodeinc/fix-sentry-error File contents
---name: fix-sentry-errordescription: Automation 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.---# AutomationThis is an internal packaged automation skill. It ships with the worker's packaged skill catalog so automations can invoke it outside the Roomote repo.<role>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.</role><workflow> <overview>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.</overview> <phase name="analysis"> <description>Identify the target issue and verify Sentry MCP access.</description> <steps> <step number="1"> <title>Initialize task tracking</title> <description>Create a focused todo list scoped to one Sentry issue.</description> <actions> <action>Create a todo list covering issue identification, MCP readiness, evidence gathering, root-cause hypothesis, action selection, validation, and delivery or no-op reporting.</action> <action>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.</action> </actions> <validation>The plan addresses one Sentry issue end-to-end.</validation> </step> <step number="2"> <title>Identify the target Sentry issue</title> <description>Resolve the issue ID, URL, fingerprint, or title from the prompt or Slack context.</description> <actions> <action>Prefer an explicit Sentry issue ID or URL. Fall back to a fingerprint or representative title only when no ID is present.</action> <action>If the input is ambiguous, use Sentry MCP search to disambiguate before acting. Do not guess.</action> </actions> <validation>The run targets a single, unambiguous Sentry issue.</validation> </step> <step number="3"> <title>Verify Sentry MCP access</title> <description>Confirm the Sentry MCP is configured before pulling issue evidence.</description> <actions> <action>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.</action> <action>If `mcp__sentry__*` tools are missing or unauthenticated, report the blocker (including `/settings/integrations?highlight=sentry-mcp` when authentication is the issue) and stop.</action> </actions> <validation>The run has Sentry MCP access or an honest blocker.</validation> </step> </steps> </phase> <phase name="investigation"> <description>Build a source-backed hypothesis for the issue's root cause.</description> <steps> <step number="1"> <title>Gather issue evidence</title> <description>Pull enough Sentry evidence to root-cause without leaking sensitive data.</description> <actions> <action>Inspect issue title, ID, URL, first/last seen, event count, user count, affected release, environment, top stack frames, tags, and a representative event timestamp.</action> <action>Do not paste raw request payloads, full stack traces, credentials, or personal data into the report. Summarize.</action> <action>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.</action> </actions> <validation>The investigation has Sentry evidence plus mapped repository context.</validation> </step> <step number="2"> <title>Form a root-cause hypothesis</title> <description>State the most likely cause and the confidence level.</description> <actions> <action>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.</action> <action>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.</action> </actions> <validation>The hypothesis names what the issue is, where in the code it lives, and how confident the run is.</validation> </step> </steps> </phase> <phase name="action"> <description>Pick the smallest useful response: fix, recommend, or no-op.</description> <steps> <step number="1"> <title>Choose the action class</title> <description>Match the action to the hypothesis confidence and impact.</description> <actions> <action>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.</action> <action>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.</action> <action>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.</action> <action>Do not mutate Sentry state (resolve, mute, assign, fingerprint) yourself unless the user explicitly asked for that mutation.</action> </actions> <validation>The action class is named and supported by the hypothesis.</validation> </step> <step number="2"> <title>Implement the chosen action</title> <description>Make repository edits only when the action class is `fix`.</description> <actions> <action>For `fix`, make the smallest correct repository change. Do not bundle unrelated cleanup, refactors, or formatting churn.</action> <action>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.</action> <action>If validation fails, decide once: either tighten the fix or revert this run's edits and downgrade to `recommend`. Do not push broken code.</action> <action>For `recommend` or `no-op`, do not edit repository code.</action> </actions> <validation>Code changes, when present, are scoped and validated; non-code outcomes leave the working tree unchanged.</validation> </step> </steps> </phase> <phase name="reporting"> <description>Deliver the result or report it directly.</description> <steps> <step number="1"> <title>Reach delivery or no-op state</title> <description>Persist code through the right delivery path when a fix shipped.</description> <actions> <action>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.</action> <action>If the final diff is empty, report the recommendation or no-op directly without launching a delivery skill.</action> </actions> <validation>The run delivered fixes through the appropriate child skill or ended as an honest no-op or recommendation.</validation> </step> <step number="2"> <title>Report the outcome</title> <description>Return a compact result naming the issue and action class.</description> <actions> <action>State the Sentry issue ID or URL, action class (`fix`, `recommend`, `no-op`), the recommendation or PR link, and the validation outcome for fixes.</action> <action>Do not claim a Sentry state mutation was made unless the task explicitly asked for it and it succeeded.</action> </actions> <validation>The final response matches the action taken and the diff state.</validation> </step> </steps> </phase><completion_criteria><criterion>The run targeted exactly one Sentry issue and used `mcp__sentry__*` for evidence, or reported an honest MCP blocker.</criterion><criterion>The action class (`fix`, `recommend`, `no-op`) was chosen with stated confidence and source-backed evidence.</criterion><criterion>Code fixes were narrow, validated proportionally to blast radius, and reverted if validation failed.</criterion><criterion>Sentry state was not mutated unless the task explicitly requested that action.</criterion></completion_criteria></workflow><best_practices><guideline priority="high"><rule>One issue, one action.</rule><rationale>Per-issue chores compound value when they stay narrow and are easy to score; broadening into a triage scan dilutes both.</rationale><exceptions>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.</exceptions></guideline><guideline priority="high"><rule>Do not mutate Sentry state implicitly.</rule><rationale>Recommendations are reversible; vendor mutations are not. Leave the mute, fingerprint, or threshold change to a human or to an explicit user request.</rationale><exceptions>Only mutate Sentry state when the user explicitly asks for that action.</exceptions></guideline><guideline priority="high"><rule>Match validation depth to fix scope.</rule><rationale>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.</rationale><exceptions>None.</exceptions></guideline></best_practices><patterns> <pattern name="narrow_fix_with_pr"> <description>Ship a fix when root cause and validation are tight.</description> <template>identify issue -> verify Sentry MCP -> gather evidence -> map to code -> form hypothesis with high confidence -> make smallest correct change -> validate proportionally -> deliver via surrounding policy (default `create-draft-pr`)</template> </pattern> <pattern name="recommend_without_code"> <description>Recommend vendor-side hygiene without code changes.</description> <template>identify issue -> investigate -> conclude that mute, fingerprint, threshold, or instrumentation work is the right move -> report the recommendation clearly -> stop without code edits</template> </pattern> <pattern name="evidence_insufficient_noop"> <description>End the run honestly when the evidence is too weak to act.</description> <template>identify issue -> investigate -> confidence remains low and impact is small -> report no-op with the exact uncertainty -> stop without code edits</template> </pattern></patterns>
roocodeinc/roomote/tree/main/packages/cloud-agents/src/server/workflows/skills/standard/fix-sentry-error commit 7342c8f2c2
Frequently asked questions
Run npx skillmds@latest add roocodeinc/fix-sentry-error in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.
Automation 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. It is listed under DevOps & Infra on SkillMD.
This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.
This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.
Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.
RooCodeInc (@roocodeinc) published this skill. Their other Agent Skills are listed on their SkillMD profile.