Enrich Error

Purpose

Raw error messages are useless to non-developer users. Error: fetch failed (status 401) doesn't tell anyone what to do.

This skill rewrites errors into findings with three properties:

1. What happened — in plain English, no jargon.
2. Why — the underlying cause if you can guess.
3. What to do — the specific next step (link if possible).

Pattern

For each error, produce an inbox_add payload like:

{
  "kind": "routine_error",
  "summary": "<plain English what + actionable next step>",
  "importance": "medium",
  "reasoning": "<technical detail for debugging>",
  "suggestedAction": { "label": "<verb-led link text>", "link": "<dashboard path>" }
}

Common error patterns + rewrites

Severity rules

• high: auth/connector failures (user MUST act for the routine to keep working)
• medium: transient errors that have happened ≥3 fires in a row
• low: one-off transient errors (rate limits, timeouts) — log it but don't pester

When NOT to enrich

If the error is a programming bug (TypeError, ReferenceError, schema mismatch), produce a short routine_error finding tagged for the developer rather than the user, with the raw stack in reasoning. The user can't fix code; the dev can.

Tags to add when relevant: ["dev-bug"] or ["transient"] or ["auth-needed"].