Triage Frontend Issues

Archive non-actionable noise from the sentry/javascript issue queue: only archive, always untilEscalating, always with a stated reason. Issues that look actionable in our code, or that you cannot confidently classify, must be skipped.

Hard Rules

These rules override anything else. Do not relax them.

1. Project scope. Only operate on organizationSlug=sentry, project slug javascript. If asked to triage a different project, stop and ask the user to confirm.
2. Archive only. The only status mutation permitted is status=ignored. Never resolve, never unresolve, never assign, never delete, never bulk-update fields other than status.
3. Always untilEscalating. Use ignoreMode=untilEscalating. Never use forever, forDuration, untilOccurrenceCount, or untilUserCount. If the user asks for a different mode, stop and have them archive that issue manually, this skill does not perform non-escalating archives.
4. Always include a reason. The reason must be a short, factual sentence naming the category from references/archive-criteria.md (e.g., "Third-party library noise, echarts internals; not actionable in our code").
5. Never touch issues outside the unresolved queue. Skip anything with status of resolved, ignored, or reprocessing.
6. Never archive without confirmation. Build a full plan, show it to the user, wait for explicit approval before calling update_issue. A single approval covers the displayed plan only; new batches need new approval.
7. When in doubt, skip. If an issue could plausibly be a real bug in our code, do not archive it. Surface it as needs-human in the plan with a one-line note.

Prerequisites

• Sentry MCP authenticated via mcp.sentry.dev. Required tools: search_issues, get_sentry_resource, update_issue.
• If update_issue is not available, stop and ask the user to authenticate the Sentry MCP server.

Inputs

$ARGUMENTS is one of: