Files
Claude-Code-Monitor/plugins/ccam-quality/skills/regression-alert/SKILL.md
T
nntrivi2001 57dc91585d feat: Claude Code Monitor — lanes, pipelines and a merged workspace
Internal SmartGift build of a Claude Code monitoring dashboard.

Lanes: a durable unit of parallel agent work, one per working directory,
tracked across session restarts. Managed lanes are git worktrees the
dashboard provisions and can reset or remove behind a three-check destroy
guard and a counted preflight; adopted lanes are directories you already
own and are never destroyable.

Pipelines: a lane moves through pipeline stages. A stage the agent declares
with evidence renders green; a stage inferred from the tool-event stream
renders dashed amber and never counts as done. Detection is forward-only
within a 30-minute window, and never writes the declared stage.

Workspace: one page at /run with a lane grid, the selected lane's pipeline,
and a full Claude console behind a disclosure.
2026-07-30 14:39:03 +07:00

64 lines
3.5 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
---
description: >
Compare this period's reliability against the prior period using Agent Monitor
data — error rate (APIError/total) and tool-failure rate (PreToolUse→PostToolUse
gap) — flag any regression where reliability got worse, and optionally wire a
persistent alert rule so the dashboard catches the next regression
automatically. Use when checking whether reliability degraded.
---
# Regression Alert
Detect whether Claude Code reliability is getting worse period-over-period, and
optionally arm an alert so it never has to be checked by hand again. Scope is
reliability/failures only — for cache/cost/compaction drift, use ccam-insights'
`regression-watch` instead.
## Input
The user provides: **$ARGUMENTS**
This may be:
- empty or "all" — check error rate and tool-failure rate (default)
- "errors" — APIError-rate regression only
- "tools" — tool-failure-rate regression only
- a window like "7 vs 7" or "30 vs 30" — recent vs baseline window sizes (default: last 7 days vs the prior 7)
- "arm" — after reporting, also create an alert rule via `POST /api/alerts/rules` (only on explicit request)
## Data Sources
| Endpoint | Returns |
|----------|---------|
| `GET /api/analytics` | `daily_events` (365d), `daily_sessions` (365d), `event_types` — split into recent vs baseline windows to compute per-window failure rates |
| `GET /api/events?session_id=X` | Per-session stream — localize a regression to the sessions driving it |
| `GET /api/alerts/rules` | Existing alert rules — check whether a matching reliability rule already exists before arming a new one |
| `POST /api/alerts/rules` | Create a new alert rule (only when the user says "arm") |
## Report Sections
### 1. Windowing
Split history into a **recent window** (newer) and a **baseline window** (the equal-length period just before it). Default: recent = last 7 days, baseline = the prior 7. Use `daily_events`/`daily_sessions` to bucket counts by day.
### 2. Error-Rate Regression
- Per window: `error rate = APIError count / total events`.
- Compare recent vs baseline. Flag if recent is higher. Report absolute change (pp) and relative change (%), plus the recent sessions contributing the most `APIError` events.
### 3. Tool-Failure-Rate Regression
- Per window: `tool-failure rate = (PreToolUse PostToolUse) / PreToolUse`.
- Compare recent vs baseline. Flag a rising rate as a reliability regression. Name the tools whose gap grew most.
### 4. Verdict
Roll up which rates regressed, rank by relative worsening, and name the most likely driver.
### 5. Optional — Arm an Alert
**Only if the user passed "arm".** First `GET /api/alerts/rules` to avoid duplicates. Then `POST /api/alerts/rules` with a rule that fires when the regressed metric crosses a threshold near the recent value (e.g., error rate > recent rate). Echo the created rule back; do not create webhooks or fire alerts.
## Output
- A Markdown table: metric | baseline | recent | Δ (pp) | Δ (%) | direction (▲ worse / ▼ better) | verdict.
- Tag each metric 🔴 (clear regression), 🟡 (within noise), or 🟢 (improved).
- Rates as percentages to 2 decimals; any currency in USD to 4 decimals.
- List the specific session IDs that contributed most to any regression.
- End with the single highest-priority regression and a concrete next step (and, if armed, the new rule's id/threshold).
- Read-only **except** the explicit "arm" path, which is the only write. Never mutate alert rules otherwise. If `curl` cannot reach `http://localhost:4820`, tell the user to start the dashboard with `npm start` from the repo root.