error-scan — Claude Code skill: error checks and installation
Scans recent Claude Code sessions for API errors and unfinished tool calls, then ranks failures by tool and model. Useful when you need to see what is breaking.
npx skills add hoangsonww/Claude-Code-Agent-Monitor --skill error-scan -a claude-codeWhat error-scan does
The skill checks Agent Monitor data for APIError events and PreToolUse events without a matching PostToolUse. It groups failures by tool and model, then sorts them by frequency. You can scan all failure signals, focus on API errors or tool failures, set a limit on recent sessions, or target one session ID.
The report covers the sessions scanned, overall failure counts, and breakdowns by tool and model. It also names the tool, model, and session with the most failures. The skill only reads data from the Agent Monitor API. If curl cannot reach http://localhost:4820, start the dashboard from the repository root with npm start; the scan depends on that server being reachable.
What it helps with
- find API errors across recent sessions
- spot tool calls that never completed
- rank failures by tool
- compare error counts across models
- identify the session with the most failures
Example prompts for the agent
- Scan all sessions and group the failures.
- Show API errors only:
api. - Check tool failures across the most recent 10 sessions:
tools 10.
How to install error-scan
1Skills CLI (Vercel)
npx skills add hoangsonww/Claude-Code-Agent-Monitor --skill error-scan -a claude-code2Manually: put the files in place
~/.claude/skills/error-scan/SKILL.mdCopy the whole skill folder; for one project use .claude/skills/error-scan/
1Skills CLI (Vercel)
npx skills add hoangsonww/Claude-Code-Agent-Monitor --skill error-scan -a codex2Manually: put the files in place
.agents/skills/error-scan/SKILL.mdFor all projects use ~/.agents/skills/
1Skills CLI (Vercel)
npx skills add hoangsonww/Claude-Code-Agent-Monitor --skill error-scan -a cursor2Manually: put the files in place
.cursor/skills/error-scan/SKILL.mdCursor also reads .agents/skills/ and .claude/skills/
1GitHub CLI
gh skill install hoangsonww/Claude-Code-Agent-Monitor error-scan2Manually: put the files in place
.github/skills/error-scan/SKILL.md1Skills CLI (Vercel)
npx skills add hoangsonww/Claude-Code-Agent-Monitor --skill error-scan -a gemini-cli2Platform CLI
gemini skills install https://github.com/hoangsonww/Claude-Code-Agent-Monitor --path plugins/ccam-quality/skills/error-scanManually: put the files in place
.devin/skills/error-scan/SKILL.mdThe legacy .windsurf/skills/ path still works
Skills CLI (Vercel)
npx skills add hoangsonww/Claude-Code-Agent-Monitor --skill error-scan -a opencodeClaude.ai
Zip the folder and upload it in Settings → Capabilities → Skills
Step by step, with commands for each platform: How to install skills in Claude Code: five ways
Questions about error-scan
How do I install error-scan in Claude Code?
Run npx skills add hoangsonww/Claude-Code-Agent-Monitor --skill error-scan -a claude-code. The skill file is at ~/.claude/skills/error-scan/SKILL.md.
What does error-scan do?
It checks Agent Monitor events for API errors and tool calls that lack a completion event, then ranks failures by tool and model.
What arguments can I use with error-scan?
Use api to check API errors or tools to check unfinished tool calls. A number limits the scan to recent sessions; a session ID targets one session.
Source text
SKILL.md · MIT
--- name: error-scan description: > Scan recent Claude Code activity for errors and failure signals across all sessions using Agent Monitor data — APIError events and PreToolUse→PostToolUse gaps (tools that started but never completed) — then group failures by tool and model and rank them by frequency. Use when checking for errors or asking "what's failing right now". --- # Error Scan Sweep recent events across sessions for error and failure signals, then rank them by how often they occur and which tool or model produced them. ## Input The user provides: **$ARGUMENTS** This may be: - empty or "all" — scan every failure signal (default) - "api" — APIError events only - "tools" — tool-failure gaps only - a number N — limit the scan to the most recent N sessions - a session ID — scan a single session ## Data Sources | Endpoint | Returns | |----------|---------| | `GET /api/analytics` | `event_types` (counts per type incl. PreToolUse, PostToolUse, APIError), `tool_usage` (top 20), `daily_events` (365d) — fleet-wide failure baseline | | `GET /api/events?session_id=X` | Per-session event stream: `event_type`, `tool_name`, `summary`, `data`, `timestamp` — locate `APIError` and unmatched `PreToolUse` | | `GET /api/sessions?limit=N` | Sessions with `id`, `status`, `model`, `started_at` — pick the recent window and attribute failures to a model | ## Report Sections ### 1. Scope Resolve `$ARGUMENTS` to a session set: pull `GET /api/sessions?limit=N` (default 50, ordered by `started_at`). Report how many sessions and what time span are covered. ### 2. Fleet Failure Counts From `GET /api/analytics` `event_types`, report total `APIError` count and the PreToolUse→PostToolUse gap: `gap = PreToolUse − PostToolUse` (unmatched tool starts = likely failures). State both as raw counts and as a share of `total_events`. ### 3. Group by Tool For each session in scope, pull `GET /api/events?session_id=X`. Match each `PreToolUse` to its following `PostToolUse` by `tool_name`; unmatched starts are failures. Aggregate failures and `APIError` events per `tool_name`. Rank tools by failure frequency (descending). ### 4. Group by Model Join failures to the owning session's `model` (from `GET /api/sessions`). Rank models by APIError count and tool-failure count. ### 5. Top Offenders List the single most failure-prone tool, the most error-prone model, and the session with the most failures, each with its exact count and one-line `summary` excerpt from a representative event. ## Output - A ranked Markdown table: tool/model | APIError count | tool-failure (gap) count | total failures | share of events. - Rates as percentages to 2 decimals. - Cite exact `event_type`, `tool_name`, and `session_id` values — never fabricate counts. - End with the one failure pattern most worth investigating and a concrete next step. - Read-only: only report what the API returns. If `curl` cannot reach `http://localhost:4820`, tell the user to start the dashboard with `npm start` from the repo root.
© hoangsonww · MIT · hoangsonww/Claude-Code-Agent-Monitor