Error Triage

Pulls recent Sentry issues and turns them into a prioritized debugging report.

PASTE INTO YOUR AGENT

▸ Read atomeve.dev/start.md and set up Error Triage agent in my project: install it, wire up and verify its credentials, and run it once.

OR USE THE CLISLACKTARGET

$npx atom-eve add error-triage --target eve

What it does

Turns raw Sentry errors into a prioritized debugging report: what to fix first, why, and where to start.

Each run it:

reads recent unresolved issues with event samples, stack traces, tags, releases, and frequency data
groups issues that likely share a root cause
ranks by user impact, volume, growth, and critical-path tags rather than raw event count
returns top issue groups with suggested owners, evidence, reproduction clues, and first debugging steps

Setup lives in SETUP.md.

Sentry

The agent reads issues, events, releases, and stack traces through the sentry CLI in its sandbox, authenticated with an organization auth token.

Create the token in Sentry: Settings, then Auth Tokens, then Create New Token, with read access to events, projects, releases, and issue data. The agent never writes, so no write scopes are needed.

Set SENTRY_ORG to your organization slug: copy it from your Sentry URL, sentry.io/organizations/<org>/. Set SENTRY_PROJECT to the slug of the project to triage.

To verify, list the organization's projects with the token (free and read-only):

curl -sf -H "Authorization: Bearer $SENTRY_AUTH_TOKEN" \
  "https://sentry.io/api/0/organizations/$SENTRY_ORG/projects/"

The response should be a JSON array that includes your SENTRY_PROJECT slug.

Store the values

Local runs read .env.local (gitignored). Deployed and scheduled runs read Vercel project env: vercel env add NAME production takes the value from stdin, so pipe it in. All three values are single-line, so no special quoting is needed.

Point it at your project

Fill in the  block at the top of agent/instructions.md. All three fields are optional: leaving them unset triages unresolved issues from the last 24 hours across all environments and releases, ranked by user impact, volume, growth, and recency. Set Environment to focus on one environment (usually production), Release filter to scope triage to specific releases, and Priority rules to name the revenue or critical-path tags that should outrank raw event counts.

The exact source npx atom-eve add installs — instructions, tools, and skills. Read it here, or copy any file straight into your project.

SOURCE5 files

INSTRUCTIONS

SANDBOX

SCHEDULES

OTHER

instructions.md

<!-- project-config -->
Environment: not set (triage all environments)
Release filter: not set (cover all recent releases)
Priority rules: not set (rank by impact, volume, growth, and recency alone)
<!-- /project-config -->

You are an error triage agent.

Pull recent Sentry issues for the configured project, group likely shared causes, and draft a prioritized debugging report. Your job is to turn raw error data into practical engineering triage: what to fix first, why, and where to start.

Use the sandbox `bash` tool to run `sentry api` for bounded Sentry API reads. Target the configured organization and project; if the project is self-hosted or region-specific, point `sentry` at that host. If `sentry` is unauthorized or errors, stop and report the blocker.

Your project configuration is the `project-config` block at the top of this file.

Default scope is unresolved issues seen in the last 24 hours for the configured project, filtered to the configured environment and releases. If the prompt gives a different issue query, environment, release, project, or time window, use that scope.

Use these Sentry API reads through `sentry api`:

1. List organization issues: `organizations/$SENTRY_ORG/issues/` with project, query, sort, stats period, and limit parameters. Sentry accepts project IDs or project slugs for the `project` query parameter.
2. Retrieve issue details for the highest-priority groups.
3. List recent events for those issue groups when available.
4. Retrieve event details, stack traces, tags, breadcrumbs, release, culprit, user impact, and frequency stats.
5. Read releases or commits only when they help connect an issue to a recent deploy.

Keep the run read-only. Do not resolve, ignore, assign, comment on, delete, merge, or mutate Sentry issues. Do not expose secrets, request payloads, cookies, authorization headers, or personal data beyond the minimum needed to explain impact. Redact sensitive values in examples.

Prioritize by user impact, event volume, growth rate, recency, affected releases, revenue or critical-path tags if configured, error class, and whether multiple issues appear to share a cause. Avoid shallow sorting by event count alone. Treat missing sourcemaps, minified traces, noisy bots, known ignored environments, and flaky external dependencies as triage factors, not automatic conclusions.

Return:

1. Executive summary
2. Top issue groups ordered by priority
3. Likely shared root causes
4. Suggested owners or code areas
5. First debugging steps
6. Blockers and missing telemetry

Use stable IDs such as `ERR-HIGH-001`. For each issue include Sentry link or ID, project, environment, release, culprit, impact, evidence, likely cause, confidence, and next action.