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.

Project scope. Only operate on
```
organizationSlug=sentry
```
, project slug
```
javascript
```
. If asked to triage a different project, stop and ask the user to confirm.
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.
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.
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").
Never touch issues outside the unresolved queue. Skip anything with
```
status
```
of
```
resolved
```
,
```
ignored
```
, or
```
reprocessing
```
.
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.
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:

Input shape	Meaning
Sentry issue URL ( `https://sentry.sentry.io/issues/JAVASCRIPT-…` )	Triage that single issue.
Issue short ID ( `JAVASCRIPT-…` )	Triage that single issue.
Sentry issue query (contains a colon, e.g. `is:unresolved firstSeen:-24h` )	Use as the search query.
Empty	Use the default triage queue: `is:unresolved is:unassigned firstSeen:-7d` , sort `new` , limit `50` .

$ARGUMENTS

is ambiguous, ask the user to clarify before searching.

Workflow

1. Load the queue

For single-issue input:

Call

get_sentry_resource(url=<issue-url>)

get_sentry_resource(resourceType='issue', organizationSlug='sentry', resourceId=<shortId>)

Confirm
```
Project
```
is the javascript frontend project. If not, stop.

For query/default input:

Call

search_issues(organizationSlug='sentry', projectSlugOrId='javascript', query=<query>, sort='new', limit=50)

Then call
```
get_sentry_resource
```
for each result in parallel to get culprit, substatus, assignee, and stack-frame hints (the search response omits some fields).

Skip immediately if any of these are true on an issue:

```
status
```
is not
```
unresolved
```
(already archived, resolved, or in reprocessing).
```
assignedTo
```
is set to a human (someone is already owning it).
```
assignedTo
```
is set to a team other than
```
frontend
```
/
```
issues
```
and the issue looks team-specific (let the owning team triage).

2. Classify each issue

Read

references/archive-criteria.md

for the category taxonomy with recognition heuristics and examples. For each candidate issue, produce one of:

Decision	Meaning
`archive`	Matches a documented category; include the category name in the reason.
`skip`	Could be a real bug in our code, or insufficient evidence; do not archive.
`needs-human`	Looks like noise but doesn't cleanly fit a category, or volume is unusually high; flag for user review.

When evaluating, weight these signals (in this order):

Top non-Sentry-SDK frame. If the top in-app frame is in
```
node_modules/
```
,
```
chrome-extension://
```
, a third-party host, or
```
<unknown>
```
, this is a strong archive signal.
Title pattern. Many archives are recognizable from the title alone (see criteria reference).
Volume is not a veto. Some high-volume issues (10k+ events, thousands of users) are still archive-worthy if the top frame is third-party. Volume alone never forces archive either.
Recency. Single-event issues older than 30 days with no recurrence are usually noise.
Customer org spread. If events come from one customer subdomain only (check
```
customerDomain.subdomain
```
tag), it is likely customer-environment noise.

3. Build the plan

Output one Markdown table to the user, in this exact shape:

## Triage plan — sentry/javascript (<N> candidates)

| # | Issue | Title | Volume | Decision | Category | Reason |
|---|-------|-------|--------|----------|----------|--------|
| 1 | [JAVASCRIPT-XXXX](url) | TypeError: ... | 12e/3u | archive | browser-api-noise | Browser clipboard permission denied; not actionable. |
| 2 | [JAVASCRIPT-YYYY](url) | <unknown> | 4945e/123u | needs-human | — | High volume, no title — please review before archiving. |
| 3 | [JAVASCRIPT-ZZZZ](url) | ZodError: ... | 360e/132u | skip | — | Schema validation failure in our code; looks actionable. |

Then summarize counts:

N archive / M skip / K needs-human

. End with:

Reply `apply` to archive the N issues marked `archive`, `apply N,M,...` to archive a subset, or `cancel` to take no action.

4. Apply on approval

When the user replies

apply

(or

apply <subset>

For each issue in the approved set, call:

update_issue(
  organizationSlug='sentry',
  issueId=<shortId>,
  status='ignored',
  ignoreMode='untilEscalating',
  reason=<category-tagged reason from the plan>,
)

Run these sequentially (not in parallel). If a call fails, log the failure, continue with the remaining issues, and report the failed IDs in step 5.

If the user replies

cancel

or asks to modify the plan, do NOT call

update_issue

. If they reply with edits ("change row 2 to skip"), rebuild the plan and re-confirm.

5. Report

After applying, output:

## Triage report

- Archived: N
- Skipped: M
- Needs human review: K
- Failures: F (with issue IDs)

<details><summary>Archived issues</summary>

- JAVASCRIPT-XXXX — <reason>
- ...

</details>

Recovery

If
```
update_issue
```
fails on one item, log the failure and continue with the rest. Report failed IDs at the end.
If the user notices a wrong archive, the user can unarchive it themselves in Sentry. The skill never reverses its own actions automatically.
If the user asks "redo the plan with these tweaks" mid-flow, regenerate the plan from scratch — do not assume the previous plan still applies.

Example reasons (use this voice)

Third-party library noise — echarts tooltip; not actionable in our code.

Browser API permission noise — Clipboard writeText denied by user agent.

Customer-environment proxy interference — 200 response treated as error (HTML body from corporate proxy).

Transient backend 5xx — InternalServerError on /api/0/organizations/.../events-meta/; backend transient.

Test/synthetic event — smoke test or security probe, not production traffic.

Wrong project — Prisma/Python error mis-routed to frontend project.

Single-event fluke — 1 event, 1 user, no recurrence in 30+ days.

Browser extension noise — ReferenceError for extension-injected global (DarkReader/WeixinJSBridge).

triage-frontend-issues

NPX Install

Tags

SKILL.md Content