| name | enrich-error |
| description | SessionEnd hook for routines — turns raw error messages into actionable findings (e.g. "Error: 401" → "Gmail token expired — reconnect at /dashboard/connectors"). Routine-only. |
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:
- What happened — in plain English, no jargon.
- Why — the underlying cause if you can guess.
- 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
| Raw error | Plain summary | Suggested action |
|---|
401 Unauthorized from Gmail | "Gmail connection expired" | Reconnect at /dashboard/connectors |
403 Forbidden from Slack | "Slack token doesn't have the scope this routine needs" | Re-authorise in Connectors |
429 Too Many Requests | "Hit rate limit on <service>" | (no action — auto-retries) |
5xx from any service | "<service> is down or having issues" | (no action — wait it out) |
corrupt or unsupported data | "Couldn't process the file" | Check the source file format |
BudgetExceededError | "Daily budget cap reached for this routine" | Raise the cap on the routine detail page |
| Network timeout | "Connection timed out reaching <service>" | (no action — auto-retries) |
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"].
