Files
accounted/.claude/skills/loop-vercel-errors/SKILL.md
T
Jakob WennbergandClaude Opus 4.8 f675ae6565 fix(loops): committed playbook path + Sentry-first error source (#851)
* fix(loops): move playbook to committed .claude/loops.md; Sentry-first error source

dev_docs/* is gitignored ('internal reference, not published'), so the loop skills'
'read dev_docs/loops.md first' reference never resolves on main / in a fresh cloud
clone. Relocate the playbook to .claude/loops.md (committed) and repoint all 4 skills.

Rewrite loop-vercel-errors to use the wired Sentry API (the Vercel MCP is not in the
cloud routine tool allowlist) and document the required token scope (event:read,
project:read) + cloud-env secrets.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* fix(loops): Vercel loop is Vercel-native + local (Sentry is not wired up)

Sentry is not integrated in this codebase (no @sentry/* dep, no config, no
instrumentation, zero source refs) — the SENTRY_* names in .env.local and CLAUDE.md
are leftovers. Rewrite loop-vercel-errors to source errors from Vercel (Vercel MCP
locally; Vercel API with VERCEL_TOKEN in cloud) and reclassify it as a LOCAL loop,
since the Vercel MCP is only available locally and there is no error-aggregation
service. The cloud trigger stays disabled. Only GH_TOKEN is needed to provision the
cloud loops (1 & 3).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-02 13:36:12 +02:00

4.0 KiB
Raw Blame History

name, description
name description
loop-vercel-errors Loop that pulls recent production runtime errors from Vercel (via the Vercel MCP locally, or the Vercel API with a token), groups + dedupes them, files well-formed GitHub issues, and opens a fix PR only for clearly trivial/safe cases. Best run LOCALLY (the Vercel MCP is available there). Follows .claude/loops.md.

loop-vercel-errors

Goal: every distinct, real production runtime error is tracked as a GitHub issue (deduped), and the obviously-trivial ones have a proposed fix PR. Never merge. Read .claude/loops.md first.

Vercel project erp-base (prj_zOvCFaOMXS166cUY5VYEGHKke00X, team team_WPj3QZgcSVRWZKcHJQB3wfv8).

No error-aggregation service is wired up (Sentry is NOT used — no @sentry/*, no config, despite leftover SENTRY_* names in .env.local/CLAUDE.md). The only source is Vercel's own runtime logs / observability, which have short retention — this loop sees a recent window, not full history. Run it LOCALLY so the Vercel MCP is available; the cloud routine is disabled (see step 1).

1. Fetch errors from Vercel

  1. Vercel MCP (primary, local runs): mcp__plugin_vercel_vercel__* — authenticate if needed, then list recent production deployments and pull runtime logs / observability / error events. This is the clean path and is only present in a LOCAL session.
  2. Vercel API (if a token exists): with a VERCEL_TOKEN (from vercel.com/account/tokens),
    curl -s -H "Authorization: Bearer $VERCEL_TOKEN" \
      "https://api.vercel.com/v6/deployments?projectId=prj_zOvCFaOMXS166cUY5VYEGHKke00X&teamId=team_WPj3QZgcSVRWZKcHJQB3wfv8&limit=5&target=production"
    # then pull runtime logs for the latest prod deployment id
    
    This is the only path that works in a cloud routine — and only if VERCEL_TOKEN is set as a secret on the cloud env. VERCEL_OIDC_TOKEN in .env.local is short-lived and NOT a usable API token.
  3. Vercel CLI last resort: vercel logs <prod-deployment-url> --json (v48 here; only a live tail).

If no source is reachable, STOP and report exactly which sources you tried and why each failed. Never invent errors.

2. Group into distinct errors

Cluster raw log lines by signature: normalized message + top of stack + route. Drop noise (expected 4xx, aborted requests, health checks). For each cluster capture: signature, first/last seen, count, sample stack, affected route/file.

3. Dedupe (mandatory — see loops.md)

Fingerprint = a stable hash of the normalized signature.

gh issue list --search "<fingerprint> in:body state:all" --json number,state

Open match → comment ("still occurring, N since "). Closed + recurring → reopen. No match → file new. Cap 8 new issues/run; log the rest.

4. File the issue

Title: [prod error] <short normalized message> (<route>)
Labels: loop:auto, loop:vercel, bug
Body:
  **Signature:** …    **Count / window:** …    **First/last seen:** …
  **Route/file:** app/…:line   **Sample stack:** (fenced)   **Vercel:** <deployment/log link if available>
  **Likely cause:** <1–2 lines from reading the referenced code>
  <!-- loop-fingerprint: <hash> -->

Point at the suspected file:line by reading the code the stack references.

5. Trivial fix only (propose-don't-merge) — cap 2 PRs/run

Open a loop/vercel-<hash> fix PR only when the cause is unambiguous and low-risk (missing null guard, unhandled undefined, bad env read with an obvious default, a narrow type fix). Anything touching bookkeeping/money/migrations/auth → issue only, label loop:needs-human. Every fix passes the loop-verify gate. PR body: Closes #<issue>.

6. Report

List: new issues filed, existing issues updated, fix PRs opened, which source worked, anything skipped.


> **Want proper error tracking?** Vercel runtime-log retention is short. For a real errors→tickets loop,
> wire an error sink (Sentry, Vercel Log Drains to a store, etc.) and update step 1 to read from it.