Smartgift-AI/Claude-Code-Monitor
3
0
Fork 0
Code Issues 1 Pull Requests Actions Packages Projects Releases Wiki Activity

feat: Claude Code Monitor — lanes, pipelines and a merged workspace

Browse Source 
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.
This commit is contained in:
nntrivi2001
2026-07-29 17:07:45 +07:00
commit 57dc91585d
783 changed files with 221743 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
plugins/ccam-analytics/.claude-plugin/plugin.json
+24
View File
@@ -0,0 +1,24 @@
{
"name": "ccam-analytics",
"description": "Deep analytics and monitoring for Claude Code sessions — cost tracking, token usage breakdowns, usage trends, and productivity scoring powered by Agent Monitor.",
"version": "1.0.0",
"author": {
"name": "Nguyễn Ngọc Trí Vĩ",
"url": "https://git.smartgift.io.vn/Smartgift-AI"
},
"homepage": "https://git.smartgift.io.vn/Smartgift-AI/Claude-Code-Monitor",
"repository": {
"type": "git",
"url": "https://git.smartgift.io.vn/Smartgift-AI/Claude-Code-Monitor.git"
},
"license": "MIT",
"keywords": [
"analytics",
"monitoring",
"cost-tracking",
"token-usage",
"productivity",
"claude-code"
],
"categories": ["analytics", "monitoring", "productivity"]
}
plugins/ccam-analytics/agents/analytics-advisor.md
+67
View File
@@ -0,0 +1,67 @@
---
name: analytics-advisor
description: >
Analyzes Claude Code session data from the Agent Monitor dashboard — tokens
(total_input/total_output/total_cache_read/total_cache_write with compaction
baselines pre-summed), costs via the pricing engine (pattern-matched model
rules at $/Mtok), workflow intelligence (11 datasets), session metadata
(thinking_blocks, turn_count, turn durations, usage_extras), and event
streams. Provides actionable cost optimization and productivity
recommendations grounded in actual data.
model: sonnet
tools:
- Bash
- Read
- Grep
---
# Analytics Advisor
You are an expert analytics advisor for Claude Code usage. You query the
Agent Monitor dashboard API at `http://localhost:4820` to produce actionable,
data-backed insights.
## Available Data Sources
Query these endpoints using `curl -s http://localhost:4820/api/...`:
| Endpoint | What it returns |
|----------|----------------|
| `/api/stats` | `{ total_sessions, active_sessions, active_agents, total_agents, total_events, events_today, ws_connections, agents_by_status, sessions_by_status }` |
| `/api/analytics` | `{ overview, tokens (total_input, total_output, total_cache_read, total_cache_write — baselines pre-summed), tool_usage (top 20), daily_events (365d), daily_sessions (365d), agent_types, event_types, avg_events_per_session, total_subagents, sessions_by_status, agents_by_status }` |
| `/api/sessions?limit=N` | Session list — each has status, model, cwd, started_at, ended_at, metadata (JSON with thinking_blocks, turn_count, total_turn_duration_ms, usage_extras) |
| `/api/sessions/:id` | Full session detail with nested agents and events |
| `/api/events?session_id=X` | Event stream: event_type (PreToolUse, PostToolUse, Stop, SubagentStop, SessionStart, SessionEnd, Notification, Compaction, APIError, TurnDuration), tool_name, summary, data |
| `/api/pricing/cost` | `{ total_cost, breakdown: [{ model, input_tokens, output_tokens, cache_read_tokens, cache_write_tokens, cost, matched_rule }] }` |
| `/api/pricing/cost/:id` | Same shape, per-session |
| `/api/pricing` | `{ pricing: [{ model_pattern, display_name, input_per_mtok, output_per_mtok, cache_read_per_mtok, cache_write_per_mtok }] }` |
| `/api/workflows/:id` | 11 datasets: stats, orchestration (DAG), toolFlow (transitions), effectiveness (subagent success), patterns (recurring sequences), modelDelegation, errorPropagation (by depth), concurrency (lanes), complexity (score), compaction (impact), cooccurrence (agent pairs) |
## Key Concepts
- **Token totals**: Analytics API returns `total_input`, `total_output`, `total_cache_read`, `total_cache_write` (baselines are pre-summed into totals at the DB level)
- **Cost formula**: `(tokens / 1M) × rate_per_mtok` for each of 4 token types
- **Cache efficiency**: `total_cache_read / (total_cache_read + total_input)` — higher = better prompt caching
- **Event type ratio**: PreToolUse ≈ PostToolUse; gap indicates tool failures
## Analysis Framework
1. **Data Collection**: Fetch from relevant endpoints with curl
2. **Statistical Summary**: Compute averages, medians, trends, distributions
3. **Pattern Recognition**: Use workflow API for deep behavioral analysis
4. **Insight Generation**: Translate patterns into actionable recommendations
5. **Quantification**: Attach dollar/percentage impact to every recommendation
## Output Standards
- Cite specific numbers — never use vague qualifiers
- Format currency as USD to 4 decimal places
- Show percentage changes with ▲/▼ indicators
- Provide confidence levels (high/medium/low)
- Limit recommendations to top 5 by impact × feasibility
## Constraints
- Read-only advisory role — do not modify any data
- Only use data from the API — do not fabricate metrics
- If the dashboard is unreachable, tell the user to start it with `npm start`
plugins/ccam-analytics/agents/token-economist.md
+68
View File
@@ -0,0 +1,68 @@
---
name: token-economist
description: >
Analyzes token economics for Claude Code usage from the Agent Monitor
dashboard — prompt-cache hit rate (total_cache_read / (total_cache_read +
total_input)), output/input ratios, compaction baseline recovery (effective
totals = current + pre-summed baseline), per-model token mix (Opus/Sonnet/
Haiku share of tokens and cost), and concrete token-reduction tactics with
dollar impact. Grounded in /api/analytics token totals, /api/pricing rates,
and /api/pricing/cost breakdowns.
model: sonnet
tools:
- Bash
- Read
- Grep
---
# Token Economist
You are a token-economics analyst for Claude Code usage. You query the
Agent Monitor dashboard API at `http://localhost:4820` using
`curl -s http://localhost:4820/api/...` to turn raw token counts into
actionable, dollar-quantified guidance on how to spend fewer tokens for the
same work.
## Available Data Sources
Query these endpoints using `curl -s http://localhost:4820/api/...`:
| Endpoint | What it returns |
|----------|----------------|
| `/api/analytics` | `{ overview, tokens (total_input, total_output, total_cache_read, total_cache_write — baselines pre-summed), tool_usage, daily_events (365d), daily_sessions (365d), agent_types, event_types, avg_events_per_session, total_subagents, ... }` |
| `/api/pricing` | `{ pricing: [{ model_pattern, display_name, input_per_mtok, output_per_mtok, cache_read_per_mtok, cache_write_per_mtok }] }` — rates per million tokens |
| `/api/pricing/cost` | `{ total_cost, breakdown: [{ model, input_tokens, output_tokens, cache_read_tokens, cache_write_tokens, cost, matched_rule }] }` — fleet-wide cost split per model |
| `/api/sessions?limit=N` | Session list — each has status, model, cwd, started_at, ended_at, inline `cost`, metadata (JSON with thinking_blocks, turn_count, total_turn_duration_ms, usage_extras) |
## Key Concepts
- **Effective totals**: `/api/analytics` `tokens.*` fields are `current + baseline`. Baselines preserve pre-compaction tokens that would otherwise be lost when the transcript JSONL is rewritten — so they already account for recovered context.
- **Cache hit rate**: `total_cache_read / (total_cache_read + total_input)`. Higher means more of your context is being served from cache instead of re-sent as fresh input.
- **Cache reuse ratio**: `total_cache_read / total_cache_write`. Each cache write is paid once; every read after that is the payoff. A ratio below ~1 means you are paying to write cache you barely reuse.
- **Output/input ratio**: `total_output / total_input`. Very low = verbose prompts for terse answers; very high = heavy generation. Use it to spot where prompt bloat or runaway generation dominates spend.
- **Cost formula**: `(tokens / 1M) × rate_per_mtok` for each of the 4 token types; longest `model_pattern` wins on match.
- **Default rates ($/Mtok in/out/cacheRead/cacheWrite)**: Opus $5/$25/$0.50/$6.25, Sonnet $3/$15/$0.30/$3.75, Haiku $1/$5/$0.10/$1.25.
## Analysis Framework
1. **Collect**: Fetch `/api/analytics` for token totals, `/api/pricing` for current rates, `/api/pricing/cost` for the per-model cost split, and `/api/sessions?limit=200` for per-session model and cost detail.
2. **Cache economics**: Compute cache hit rate and reuse ratio. Quantify cache-read spend vs. cache-write spend from the cost breakdown — flag when cache_write cost rivals or exceeds the read savings.
3. **Generation balance**: Compute output/input ratio and per-model output share. Identify where output tokens (the most expensive token type) dominate cost.
4. **Compaction recovery**: Estimate how much of the effective token total comes from recovered baselines and what that context preservation is worth at current rates.
5. **Model mix**: For each model family, compute its share of total tokens vs. share of total cost; surface premium models doing low-complexity work (cross-check session metadata and subagent types).
6. **Token-reduction tactics**: Translate each finding into a concrete action with an estimated dollar/percentage impact.
## Output Standards
- Cite specific numbers from the API — never use vague qualifiers.
- Format currency as USD to 4 decimal places.
- Express token counts with thousands separators; show rates as $/Mtok.
- Show percentage and trend changes with ▲/▼ indicators.
- Rank token-reduction tactics by estimated savings (descending); cap at top 5.
- Attach a confidence level (high/medium/low) to each recommendation.
## Constraints
- Read-only advisory role — never modify any data.
- Only use data returned by the API — never fabricate metrics.
- If the dashboard is unreachable, tell the user to start it with `npm start` from the repo root.
plugins/ccam-analytics/bin/ccam-stats
Executable
+171
View File
@@ -0,0 +1,171 @@
#!/usr/bin/env bash
# ccam-stats — Quick CLI stats from Claude Code Agent Monitor
# Usage: ccam-stats [--json] [--cost] [--sessions] [--all]
set -euo pipefail
DASHBOARD_URL="${CCAM_DASHBOARD_URL:-http://localhost:4820}"
usage() {
cat <<EOF
ccam-stats — Claude Code Agent Monitor Quick Stats
USAGE:
ccam-stats [OPTIONS]
OPTIONS:
--all Show all stats (default)
--sessions Show session summary
--cost Show cost summary
--tokens Show token usage summary
--json Output raw JSON instead of formatted text
--help Show this help
ENVIRONMENT:
CCAM_DASHBOARD_URL Dashboard URL (default: http://localhost:4820)
EXAMPLES:
ccam-stats # Show all stats
ccam-stats --cost # Show cost summary only
ccam-stats --json # Get raw JSON output
EOF
exit 0
}
check_dashboard() {
if ! curl -sf "${DASHBOARD_URL}/api/health" > /dev/null 2>&1; then
echo "✗ Dashboard unreachable at ${DASHBOARD_URL}" >&2
echo " Start it with: cd <agent-monitor-dir> && npm start" >&2
exit 1
fi
}
format_number() {
printf "%'d" "$1" 2>/dev/null || echo "$1"
}
show_sessions() {
local stats
stats=$(curl -sf "${DASHBOARD_URL}/api/stats")
local total active completed errored
total=$(echo "$stats" | jq -r '.total_sessions // 0')
active=$(echo "$stats" | jq -r '.active_sessions // 0')
completed=$(echo "$stats" | jq -r '.sessions_by_status.completed // 0')
errored=$(echo "$stats" | jq -r '.sessions_by_status.error // 0')
echo "╔══════════════════════════════════════╗"
echo "║ SESSION SUMMARY ║"
echo "╠══════════════════════════════════════╣"
printf "║ Total Sessions: %15s ║\n" "$(format_number "$total")"
printf "║ Active: %15s ║\n" "$(format_number "$active")"
printf "║ Completed: %15s ║\n" "$(format_number "$completed")"
printf "║ Errored: %15s ║\n" "$(format_number "$errored")"
echo "╚══════════════════════════════════════╝"
}
show_cost() {
local cost
cost=$(curl -sf "${DASHBOARD_URL}/api/pricing/cost")
local total_cost model_count
total_cost=$(echo "$cost" | jq -r '.total_cost // "0.0000"')
model_count=$(echo "$cost" | jq -r '.breakdown | length // 0')
echo "╔══════════════════════════════════════╗"
echo "║ COST SUMMARY ║"
echo "╠══════════════════════════════════════╣"
printf "║ Total Cost (USD): %15s ║\n" "\$${total_cost}"
printf "║ Models Tracked: %15s ║\n" "${model_count}"
echo "╚══════════════════════════════════════╝"
if [ "$model_count" -gt 0 ] 2>/dev/null; then
echo ""
echo " Per-model breakdown:"
echo "$cost" | jq -r '.breakdown[] | " \(.model): $\(.cost) (\(.matched_rule))"' 2>/dev/null || true
fi
}
show_tokens() {
local analytics
analytics=$(curl -sf "${DASHBOARD_URL}/api/analytics")
local input output cache_read cache_write
input=$(echo "$analytics" | jq -r '.tokens.total_input // 0')
output=$(echo "$analytics" | jq -r '.tokens.total_output // 0')
cache_read=$(echo "$analytics" | jq -r '.tokens.total_cache_read // 0')
cache_write=$(echo "$analytics" | jq -r '.tokens.total_cache_write // 0')
echo "╔══════════════════════════════════════╗"
echo "║ TOKEN USAGE ║"
echo "╠══════════════════════════════════════╣"
printf "║ Input Tokens: %15s ║\n" "$(format_number "$input")"
printf "║ Output Tokens: %15s ║\n" "$(format_number "$output")"
printf "║ Cache Read: %15s ║\n" "$(format_number "$cache_read")"
printf "║ Cache Write: %15s ║\n" "$(format_number "$cache_write")"
echo "╚══════════════════════════════════════╝"
}
show_json() {
local section="${1:-all}"
case "$section" in
sessions) curl -sf "${DASHBOARD_URL}/api/stats" | jq . ;;
cost) curl -sf "${DASHBOARD_URL}/api/pricing/cost" | jq . ;;
tokens) curl -sf "${DASHBOARD_URL}/api/analytics" | jq '.tokens' ;;
all)
echo '{'
echo ' "stats":'
curl -sf "${DASHBOARD_URL}/api/stats" | jq ' .'
echo ','
echo ' "cost":'
curl -sf "${DASHBOARD_URL}/api/pricing/cost" | jq ' .'
echo ','
echo ' "tokens":'
curl -sf "${DASHBOARD_URL}/api/analytics" | jq ' .tokens'
echo '}'
;;
esac
}
# --- Main ---
JSON_MODE=false
SECTION="all"
while [[ $# -gt 0 ]]; do
case "$1" in
--help|-h) usage ;;
--json) JSON_MODE=true; shift ;;
--sessions) SECTION="sessions"; shift ;;
--cost) SECTION="cost"; shift ;;
--tokens) SECTION="tokens"; shift ;;
--all) SECTION="all"; shift ;;
*) echo "Unknown option: $1" >&2; usage ;;
esac
done
check_dashboard
if $JSON_MODE; then
show_json "$SECTION"
exit 0
fi
echo ""
echo " Claude Code Agent Monitor — $(date '+%Y-%m-%d %H:%M')"
echo " Dashboard: ${DASHBOARD_URL}"
echo ""
case "$SECTION" in
sessions) show_sessions ;;
cost) show_cost ;;
tokens) show_tokens ;;
all)
show_sessions
echo ""
show_cost
echo ""
show_tokens
;;
esac
echo ""
plugins/ccam-analytics/commands/burn-rate.md
+28
View File
@@ -0,0 +1,28 @@
---
description: Compute the recent 7-day spend trend (burn rate) from daily sessions and per-session cost.
argument-hint: ""
---
Estimate the recent daily spend trend (burn rate) for Claude Code usage from the Agent Monitor dashboard.
Fetch analytics, which includes the 365-day daily series and token totals:
```
curl -s http://localhost:4820/api/analytics
```
Use `daily_sessions` (365 days of `{ date, count }`) together with per-session cost to estimate daily spend. If `daily_sessions` does not carry cost directly, fetch the session list to map cost to dates:
```
curl -s "http://localhost:4820/api/sessions?limit=200"
```
Then compute and print:
1. **Last 7 days vs. prior 7 days** — total spend in each window, and the change as a percent with ▲ (up) / ▼ (down).
2. **7-day burn rate** — average daily spend over the last 7 days, as USD to 4 decimal places, plus a simple 30-day projection (`avg_daily × 30`).
3. **Per-day mini-trend** — one line per day for the last 7 days: `<date> — $<spend to 4dp>` with a ▲/▼ vs. the prior day.
Currency as USD to 4 decimal places. Keep it to these three blocks — no long analysis.
If session dates and costs cannot be aligned precisely, state the approximation you made in one line rather than fabricating exact daily figures. If the dashboard is unreachable, tell the user to start it with `npm start` from the repo root.
plugins/ccam-analytics/commands/cost-today.md
+26
View File
@@ -0,0 +1,26 @@
---
description: Quick total cost plus a per-model one-liner from the dashboard pricing engine.
argument-hint: "[today|week]"
---
Print a quick cost snapshot from the Agent Monitor dashboard pricing engine.
The user's scope is **$ARGUMENTS** (default `today` if empty; accepts `today` or `week`).
Fetch the fleet-wide cost breakdown:
```
curl -s http://localhost:4820/api/pricing/cost
```
This returns `{ total_cost, breakdown: [{ model, input_tokens, output_tokens, cache_read_tokens, cache_write_tokens, cost, matched_rule }] }`.
Then print, concisely:
1. **Total cost** — `total_cost` as USD to 4 decimal places, labeled with the scope (`$ARGUMENTS`).
2. **Per-model one-liners** — one line per entry in `breakdown`, sorted by `cost` descending:
`<model> — $<cost to 4dp> (in <input_tokens>, out <output_tokens>, cacheR <cache_read_tokens>, cacheW <cache_write_tokens>)`
Keep token counts with thousands separators. No tables, no preamble — just the total and the per-model lines.
Note: the endpoint returns lifetime totals; if the user asked for `today` or `week` and the data is not scoped, say so in one line rather than fabricating a windowed number. If the dashboard is unreachable, tell the user to start it with `npm start` from the repo root.
plugins/ccam-analytics/commands/top-spenders.md
+25
View File
@@ -0,0 +1,25 @@
---
description: List the top N most expensive Claude Code sessions by inline cost.
argument-hint: "[N]"
---
List the most expensive Claude Code sessions from the Agent Monitor dashboard.
`N` = **$ARGUMENTS** (default `10` if empty).
Fetch the session list (each session carries an inline `cost` field from bulk pricing):
```
curl -s "http://localhost:4820/api/sessions?limit=200"
```
Then:
1. Sort sessions by `cost` descending.
2. Print the top `N` as a numbered list, one line each:
`<rank>. $<cost to 4dp> — <model> — <cwd basename or id> — <started_at>`
3. After the list, print the **summed cost of the top N** and what percent that is of the summed cost of all returned sessions.
Currency as USD to 4 decimal places. Skip sessions with no/zero cost only if it would otherwise pad the list past meaningful entries — otherwise include them. Keep it terse, no extra commentary.
If the dashboard is unreachable, tell the user to start it with `npm start` from the repo root.
plugins/ccam-analytics/hooks/hooks.json
+26
View File
@@ -0,0 +1,26 @@
{
"hooks": {
"Stop": [
{
"matcher": "",
"hooks": [
{
"type": "command",
"command": "jq -r '{session_id: .session_id, stop_reason: .stop_reason, timestamp: now | todate}' | curl -s -X POST http://localhost:4820/api/hooks/event -H 'Content-Type: application/json' -d @- > /dev/null 2>&1 || true"
}
]
}
],
"SubagentStop": [
{
"matcher": "",
"hooks": [
{
"type": "command",
"command": "jq -r '{session_id: .session_id, agent_id: .agent_id, stop_reason: .stop_reason, timestamp: now | todate}' | curl -s -X POST http://localhost:4820/api/hooks/event -H 'Content-Type: application/json' -d @- > /dev/null 2>&1 || true"
}
]
}
]
}
}
plugins/ccam-analytics/skills/cache-efficiency/SKILL.md
+65
View File
@@ -0,0 +1,65 @@
---
description: >
Analyze prompt-cache effectiveness for Claude Code usage from the Agent
Monitor dashboard — cache hit rate (total_cache_read / (total_cache_read +
total_input)), cache_write vs cache_read reuse, cache-read vs cache-write
spend, and the sessions with the poorest reuse. Pulls token totals from
/api/analytics, per-session detail from /api/sessions, and dollar splits
from /api/pricing/cost. Use when diagnosing cache spend or deciding whether
prompt caching is paying off.
---
# Cache Efficiency
Diagnose whether prompt caching is actually saving money, and where it is not.
## Input
The user provides: **$ARGUMENTS**
This may be: empty (analyze the whole fleet), "today" / "this week" / a date range, a session ID to scope the analysis, or a target like "hit rate > 80%". When empty, analyze all data from `/api/analytics`.
## Data Sources
| Endpoint | Returns |
|----------|---------|
| `GET /api/analytics` | `tokens.total_input`, `tokens.total_output`, `tokens.total_cache_read`, `tokens.total_cache_write` (baselines pre-summed), plus `daily_sessions` |
| `GET /api/sessions?limit=200` | Session list — each has model, cwd, started_at, ended_at, inline `cost`, metadata (JSON: usage_extras with cache token detail) |
| `GET /api/sessions/{id}` | Full session detail with nested agents and events, for drill-down on a flagged session |
| `GET /api/pricing/cost` | `{ total_cost, breakdown: [{ model, input_tokens, output_tokens, cache_read_tokens, cache_write_tokens, cost, matched_rule }] }` — used to price cache read vs write spend |
### How cache economics work
```
cache_hit_rate = total_cache_read / (total_cache_read + total_input)
cache_reuse = total_cache_read / total_cache_write
cache_read_cost = (cache_read_tokens / 1M) × cache_read_per_mtok
cache_write_cost = (cache_write_tokens / 1M) × cache_write_per_mtok
```
Cache writes cost more per token than cache reads (e.g. Sonnet $3.75 write vs $0.30 read per Mtok), and writes are billed even if the cached block is never reused. The payoff only arrives on subsequent reads — so a healthy fleet shows **cache_read_tokens far exceeding cache_write_tokens**. When `cache_reuse < 1`, you are paying to cache context you barely re-read.
Token counts are **effective totals** = `current + baseline` (baselines preserve pre-compaction tokens).
## Report Sections
### 1. Fleet Cache Hit Rate
From `/api/analytics`: compute `cache_hit_rate × 100`. State raw `total_cache_read` and `total_input`. Benchmark: >70% strong, 40–70% moderate, <40% weak prompt-cache utilization.
### 2. Write vs Read Reuse
Compute `cache_reuse = total_cache_read / total_cache_write`. Show both token counts. Flag if reuse < 1 (writing more cache than is ever read back).
### 3. Cache Spend Split
From `/api/pricing/cost` breakdown, sum `cache_read_cost` and `cache_write_cost` across all models. Show the dollar split and what fraction of total cost is cache-write overhead vs cache-read savings.
### 4. Sessions With Poor Reuse
From `/api/sessions?limit=200`, parse `metadata.usage_extras` for per-session cache read/write where available; rank sessions by lowest read/write reuse (and by cache_write-heavy cost). List the worst 10 with model, cost, and reuse ratio. Use `/api/sessions/{id}` to drill into any single flagged session.
### 5. Recommendations
- Sessions where `cache_write >> cache_read`: short or one-shot sessions rarely recoup cache writes — note them.
- Stable, repeated context (system prompts, large files) should be cached once and reused; high churn defeats caching.
- Estimate the dollar impact of raising the hit rate to the next benchmark tier.
## Output
Structured Markdown with tables. Currency as USD to 4 decimal places; rates as $/Mtok; percentages with ▲/▼ for any trend. Token counts with thousands separators.
plugins/ccam-analytics/skills/cost-breakdown/SKILL.md
+73
View File
@@ -0,0 +1,73 @@
---
description: >
Break down Claude Code costs using the Agent Monitor pricing engine.
Shows per-model costs (input, output, cache_read, cache_write at $/Mtok rates),
per-session costs, daily trends, and compaction baseline token recovery.
Use when analyzing spending, comparing model costs, or planning budgets.
---
# Cost Breakdown
Detailed cost analysis from the Agent Monitor's pricing engine.
## Input
The user provides: **$ARGUMENTS**
This may be: "today", "this week", "last 30 days", a session ID, or "budget $50/week".
## Data Sources
| Endpoint | Returns |
|----------|---------|
| `GET /api/pricing` | `{ pricing: [{ model_pattern, display_name, input_per_mtok, output_per_mtok, cache_read_per_mtok, cache_write_per_mtok }] }` |
| `GET /api/pricing/cost` | Total cost: `{ total_cost, breakdown: [{ model, input_tokens, output_tokens, cache_read_tokens, cache_write_tokens, cost, matched_rule }] }` |
| `GET /api/pricing/cost/{sessionId}` | Per-session cost with same breakdown shape |
| `GET /api/sessions?limit=200` | Sessions list — each includes inline `cost` field (bulk pricing) |
| `GET /api/analytics` | Token totals (total_input, total_output, total_cache_read, total_cache_write — baselines pre-summed), daily trends |
### How costs are calculated
The pricing engine matches model names against `model_pattern` using SQL LIKE (e.g. `claude-sonnet-4-5%` matches `claude-sonnet-4-5-20250514`). **Longest pattern wins** for specificity. Cost per model:
```
cost = (input_tokens / 1M) × input_per_mtok
+ (output_tokens / 1M) × output_per_mtok
+ (cache_read_tokens / 1M) × cache_read_per_mtok
+ (cache_write_tokens / 1M) × cache_write_per_mtok
```
Token counts are **effective totals** = `current + baseline` (baselines preserve pre-compaction tokens that would otherwise be lost when the transcript JSONL is rewritten).
### Default pricing tiers (seeded on first run)
| Family | Input $/Mtok | Output $/Mtok | Cache Read $/Mtok | Cache Write $/Mtok |
|--------|-------------|--------------|-------------------|-------------------|
| Opus 4.5/4.6 | $5 | $25 | $0.50 | $6.25 |
| Sonnet 4/4.5/4.6 | $3 | $15 | $0.30 | $3.75 |
| Haiku 4.5 | $1 | $5 | $0.10 | $1.25 |
## Report Sections
### 1. Cost by Model
Table from `/api/pricing/cost` breakdown — each model with 4 token counts + cost. Highlight which pricing rule matched.
### 2. Cost by Session (Top 10 Most Expensive)
From sessions list with inline `cost` — sort descending. Show session name, model, duration, cost.
### 3. Daily Cost Trend
Cross-reference `daily_sessions` with per-session costs to compute daily spend. Show 7/30-day trend with direction arrows.
### 4. Token Efficiency Analysis
- **Cache hit rate**: `total_cache_read / (total_cache_read + total_input) × 100` — higher = more efficient
- **Compaction baseline recovery**: Tokens preserved via baseline columns (tokens not lost to compaction)
- **Output/input ratio**: Balanced ratio indicates good prompt efficiency
### 5. Cost Optimization Opportunities
- Sessions where cache_write >> cache_read (poor cache reuse)
- Expensive models used for simple tasks (check subagent_type vs model)
- Sessions with many compactions (context overflow = wasted tokens)
## Output
Structured Markdown with tables. Currency as USD to 4 decimal places. Include total and per-model subtotals.
plugins/ccam-analytics/skills/model-mix/SKILL.md
+64
View File
@@ -0,0 +1,64 @@
---
description: >
Break down Claude Code usage by model family (Opus / Sonnet / Haiku) from the
Agent Monitor dashboard — each family's share of tokens, share of cost, and
the spots where an expensive model is doing cheap work. Pulls per-model token
and cost splits from /api/pricing/cost, current rates from /api/pricing, fleet
token totals from /api/analytics, and per-session model assignment from
/api/sessions. Use when deciding model routing or whether to downshift work to
a cheaper tier.
---
# Model Mix
See where your tokens and dollars go by model family, and where to re-route work.
## Input
The user provides: **$ARGUMENTS**
This may be: empty (analyze the whole fleet), "today" / "this week" / a date range, or a focus like "where is Opus overused?". When empty, analyze all data from `/api/pricing/cost` and `/api/sessions`.
## Data Sources
| Endpoint | Returns |
|----------|---------|
| `GET /api/pricing/cost` | `{ total_cost, breakdown: [{ model, input_tokens, output_tokens, cache_read_tokens, cache_write_tokens, cost, matched_rule }] }` — per-model token and cost split |
| `GET /api/pricing` | `{ pricing: [{ model_pattern, display_name, input_per_mtok, output_per_mtok, cache_read_per_mtok, cache_write_per_mtok }] }` — rates per family |
| `GET /api/analytics` | `tokens` totals (total_input, total_output, total_cache_read, total_cache_write — baselines pre-summed), `agent_types` for delegation context |
| `GET /api/sessions?limit=200` | Session list — model, cwd, started_at, ended_at, inline `cost`, metadata (JSON: thinking_blocks, turn_count, total_turn_duration_ms, usage_extras) |
### How families and rates work
Map each `model` in the cost breakdown to a family from its `matched_rule` / `display_name`:
| Family | Input $/Mtok | Output $/Mtok | Cache Read $/Mtok | Cache Write $/Mtok |
|--------|-------------|--------------|-------------------|-------------------|
| Opus 4.5/4.6 | $5 | $25 | $0.50 | $6.25 |
| Sonnet 4/4.5/4.6 | $3 | $15 | $0.30 | $3.75 |
| Haiku 4.5 | $1 | $5 | $0.10 | $1.25 |
`cost = (tokens / 1M) × rate_per_mtok` summed over the 4 token types; longest `model_pattern` wins. Opus output costs ~5× Sonnet and ~5× Haiku per token, so a family's **cost share routinely exceeds its token share** — that gap is the routing signal.
## Report Sections
### 1. Token Share by Family
Aggregate `input + output + cache_read + cache_write` tokens per family from `/api/pricing/cost`. Show each family's tokens and percent of total. Cross-check the grand total against `/api/analytics` token totals.
### 2. Cost Share by Family
Sum `cost` per family. Show each family's dollar total and percent of `total_cost`. Place the cost-share % next to the token-share % so the premium gap is visible.
### 3. Cost-vs-Token Gap
For each family compute `cost_share − token_share`. A large positive gap on Opus/Sonnet signals premium spend concentration. Rank families by gap.
### 4. Expensive Model on Cheap Work
From `/api/sessions?limit=200`, find Opus/Sonnet sessions with signals of low complexity: low `turn_count`, short `total_turn_duration_ms`, few thinking_blocks, or small token footprints. List candidates that could plausibly run on a cheaper tier, with current cost and estimated cost if downshifted.
### 5. Routing Recommendations
- Quantify the savings of moving each candidate workload to the next-cheaper family (recompute cost at that family's rates).
- Note work that genuinely needs Opus (deep reasoning, long context) and should stay.
- Summarize a suggested routing policy (e.g. Haiku for mechanical edits, Sonnet for default dev, Opus for hard reasoning).
## Output
Structured Markdown with tables. Currency as USD to 4 decimal places; rates as $/Mtok; token shares and cost shares as percentages; use ▲/▼ for the cost-vs-token gap and any trend. Token counts with thousands separators.
plugins/ccam-analytics/skills/productivity-score/SKILL.md
+81
View File
@@ -0,0 +1,81 @@
---
description: >
Calculate a productivity score using actual Agent Monitor metrics —
session completion rates, cache efficiency (cache_read vs input),
compaction pressure (baseline tokens), turn velocity (turn_count /
total_turn_duration_ms), tool success ratio (PreToolUse vs PostToolUse),
and the workflow intelligence API's complexity and effectiveness scores.
---
# Productivity Score
Calculate a productivity scorecard from the Agent Monitor's real data.
## Input
The user provides: **$ARGUMENTS**
Options: "today", "this week", "last 30 days", a session ID, or "compare" for period comparison.
## Data Sources
| Endpoint | Returns |
|----------|---------|
| `GET /api/analytics` | Token totals (`total_input`, `total_output`, `total_cache_read`, `total_cache_write` — baselines pre-summed), tool_usage top 20, daily_events/sessions, event_types, sessions_by_status, agents_by_status, avg_events_per_session, total_subagents |
| `GET /api/sessions?limit=100` | Sessions with metadata JSON: `thinking_blocks`, `turn_count`, `total_turn_duration_ms`, `usage_extras` (service_tier, speed, inference_geo) |
| `GET /api/pricing/cost` | Total cost with per-model breakdown |
| `GET /api/workflows/{sessionId}` | 11 workflow datasets: stats, orchestration, toolFlow, effectiveness, patterns, modelDelegation, errorPropagation, concurrency, complexity, compaction, cooccurrence |
## Score Components (each 0–100)
### 1. Completion Rate (20% weight)
From `sessions_by_status`:
- `completed / (completed + error + abandoned) × 100`
- Bonus for high completed-to-active ratio
- Penalty for abandoned sessions (wasted work)
### 2. Token Efficiency (20% weight)
From analytics `tokens` (baselines are pre-summed into totals):
- **Cache hit rate**: `total_cache_read / (total_cache_read + total_input) × 100`
- Above 60% = excellent, below 30% = poor
- **Output concentration**: `total_output / total_input` — 0.3–0.8 is balanced
### 3. Tool Effectiveness (20% weight)
From `event_types`:
- **Success ratio**: Count `PostToolUse` / Count `PreToolUse` — should be ~1.0; gap = tool failures
- **API error rate**: Count `APIError` / total events — should be near 0
- From workflow `effectiveness` data: subagent completion rates, task success per type
### 4. Velocity (20% weight)
From session metadata:
- **Turns per session**: average `turn_count` across sessions
- **Turn speed**: average `total_turn_duration_ms / turn_count` — lower = faster
- **Events per session**: from `avg_events_per_session` in analytics overview
- **Thinking depth**: average `thinking_blocks` — more thinking = more thorough (neutral metric)
### 5. Cost Efficiency (20% weight)
From pricing:
- **Cost per completed session**: `total_cost / completed_sessions`
- **Cost trend**: comparing current period to previous (decreasing = improving)
- **Model optimization**: sessions using expensive models (Opus) for tasks subagents handle with Haiku/Sonnet
## Overall Score
Weighted sum → letter grade:
- **A+** (95-100), **A** (90-94), **B+** (85-89), **B** (80-84), **C+** (75-79), **C** (70-74), **D** (60-69), **F** (<60)
## Output Format
```
═══════════════════════════════════════
PRODUCTIVITY SCORE: 87/100 (B+)
═══════════════════════════════════════
Completion Rate ████████░░ 80/100
Token Efficiency █████████░ 92/100
Tool Effectiveness████████░░ 85/100
Velocity █████████░ 88/100
Cost Efficiency █████████░ 90/100
═══════════════════════════════════════
```
Then: top 3 strengths, top 3 improvement areas with actionable steps, and period comparison if available.
plugins/ccam-analytics/skills/session-report/SKILL.md
+74
View File
@@ -0,0 +1,74 @@
---
description: >
Generate a comprehensive session report with per-model token usage
(input, output, cache_read, cache_write including compaction baselines),
cost breakdown via the pricing engine, tool invocations, agent hierarchy,
compaction events, API errors, turn durations, and thinking block counts.
Use when reviewing a specific session or summarizing activity over a date range.
---
# Session Report
Generate a detailed session report from the Claude Code Agent Monitor.
## Input
The user provides: **$ARGUMENTS**
This may be a session ID, "latest", or a date range like "last 24 hours".
## Data Sources
All data comes from the Agent Monitor API at `http://localhost:4820`:
| Endpoint | What it returns |
|----------|----------------|
| `GET /api/sessions/{id}` | Session with nested `.agents[]` and `.events[]` |
| `GET /api/sessions?limit=50` | Session list with `agent_count`, `last_activity`, and **inline `cost`** per session (bulk pricing applied server-side) |
| `GET /api/pricing/cost/{sessionId}` | `{ total_cost, breakdown: [{ model, input_tokens, output_tokens, cache_read_tokens, cache_write_tokens, cost, matched_rule }] }` |
| `GET /api/events?session_id={id}` | Event stream: each has `event_type`, `tool_name`, `summary`, `data` (JSON), `created_at` |
### Key data points available per session
- **Status**: `active` / `completed` / `error` / `abandoned`
- **Model**: primary model (e.g. `claude-sonnet-4-20250514`)
- **Metadata (JSON)**: `thinking_blocks` count, `turn_count`, `total_turn_duration_ms`, `usage_extras` (service_tier, speed, inference_geo)
- **Token usage per model**: Pricing breakdown reports `input_tokens`, `output_tokens`, `cache_read_tokens`, `cache_write_tokens` per model (baselines are pre-summed into these totals at the DB level)
- **Cost formula**: `(tokens / 1,000,000) × rate_per_mtok` for each of 4 token types, using longest-match pricing rule
- **Agent hierarchy**: recursive parent_agent_id tree, subagent_type (e.g. "task", "explore", "code-review", "compaction")
- **Event types**: `PreToolUse`, `PostToolUse`, `Stop`, `SubagentStop`, `SessionStart`, `SessionEnd`, `Notification`, `Compaction`, `APIError`, `TurnDuration`
## Report Sections
### 1. Session Overview
- ID (first 16 chars), name, status, model, working directory
- Start → end time, total duration
- Turn count and avg turn duration (from metadata)
### 2. Token Usage (per model)
| Model | Input | Output | Cache Read | Cache Write | Total |
Show **effective totals** (current + baseline) since baselines preserve tokens lost during compaction. Calculate cache hit rate: `cache_read / (cache_read + input) × 100`.
### 3. Cost Breakdown
From `/api/pricing/cost/{id}` — show each model's cost with the matched pricing rule. Note rates are per million tokens.
### 4. Agent Hierarchy
Render the agent tree (main → subagents, with nested children). For each agent: name, type, subagent_type, status, task (first 60 chars), duration.
### 5. Tool Activity
Count `PreToolUse` events by `tool_name`. Flag tools that appear in error events. Note subagent spawns (`tool_name = "Agent"`).
### 6. Compaction & Context Health
- Count of `Compaction` events (each = context was compressed)
- Baseline tokens recovered (sum of baseline_* columns)
- Thinking block count from metadata
### 7. API Errors
List any `APIError` events with type (quota, rate_limit, overloaded) and message.
### 8. Timeline
Key lifecycle events: SessionStart → first tool → compactions → errors → Stop → SessionEnd. Include TurnDuration events.
## Output Format
Clean Markdown: executive summary line, structured tables, agent tree, numbered timeline. Bold key metrics.
plugins/ccam-analytics/skills/usage-trends/SKILL.md
+87
View File
@@ -0,0 +1,87 @@
---
description: >
Analyze Claude Code usage trends over time using the Agent Monitor's
analytics API — daily session counts, daily event counts, token volumes
by type, model distribution, tool usage rankings, and agent/event type
distributions across 365-day retention windows.
---
# Usage Trends
Analyze usage patterns and trends from the Agent Monitor analytics data.
## Input
The user provides: **$ARGUMENTS**
Options: "last 7 days", "last 30 days", "last quarter", "peak hours", "tool trends", "model usage".
## Data Sources
| Endpoint | Returns |
|----------|---------|
| `GET /api/analytics` | Comprehensive analytics object (see schema below) |
| `GET /api/stats` | `{ total_sessions, active_sessions, active_agents, total_agents, total_events, events_today, ws_connections, agents_by_status, sessions_by_status }` |
| `GET /api/sessions?limit=200` | Full session records with timestamps and metadata |
### Analytics response schema (`GET /api/analytics`)
```json
{
"overview": { "total_sessions", "active_sessions", "active_agents", "total_agents", "total_events" },
"tokens": {
"total_input": N, "total_output": N,
"total_cache_read": N, "total_cache_write": N
},
"tool_usage": [{ "tool_name": "...", "count": N }], // top 20
"daily_events": [{ "date": "YYYY-MM-DD", "count": N }], // 365 days
"daily_sessions": [{ "date": "YYYY-MM-DD", "count": N }], // 365 days
"agent_types": [{ "subagent_type": "task"|"explore"|null, "count": N }],
"event_types": [{ "event_type": "PreToolUse"|"PostToolUse"|..., "count": N }],
"avg_events_per_session": N,
"total_subagents": N,
"sessions_by_status": { "active": N, "completed": N, "error": N, "abandoned": N },
"agents_by_status": { "working": N, "completed": N, "error": N, ... }
}
```
## Trend Analyses to Produce
### 1. Daily Activity Trend
Plot `daily_sessions` and `daily_events` for the requested period. Compute:
- **Average sessions/day** and **events/day**
- Week-over-week delta (%)
- Peak day and quietest day
### 2. Token Volume Trends
From analytics tokens (baselines are pre-summed into totals at the DB level):
- Total tokens: `total_input`, `total_output`, `total_cache_read`, `total_cache_write`
- **Cache efficiency over time**: `total_cache_read / (total_cache_read + total_input)` — trending up = improving
- **Output intensity**: `total_output / total_input` ratio — high = Claude is verbose
### 3. Tool Usage Ranking
From `tool_usage` (top 20 tools by event count):
- Bar chart data (tool name → count)
- Tool diversity: unique tools used
- Subagent spawns: count of "Agent" tool uses (each = a subagent launched)
### 4. Model Distribution
From `agent_types` + per-session model field:
- Which models are used most frequently
- Subagent type distribution: main (null) vs task vs explore vs code-review
### 5. Session Health Distribution
From `sessions_by_status`:
- Completion rate: `completed / total × 100`
- Error rate: `error / total × 100`
- Abandoned rate: `abandoned / total × 100`
### 6. Event Type Distribution
From `event_types`:
- PreToolUse/PostToolUse ratio (should be ~1:1; gap = tools failing)
- Compaction frequency relative to session count
- APIError count (quota hits, rate limits, overloaded)
## Output
Markdown with tables and ASCII trend indicators (▲▼→). Include period comparison when applicable.
plugins/ccam-config/.claude-plugin/plugin.json
+17
View File
@@ -0,0 +1,17 @@
{
"name": "ccam-config",
"description": "Audit and govern your Claude Code configuration and file-based memory via the Agent Monitor Config Explorer API — skills, subagents, commands, MCP servers, hooks, settings, and the per-project memory store. Surfaces sprawl, duplication, risky hooks, and stale facts, all read through the dashboard at http://localhost:4820.",
"version": "1.0.0",
"author": {
"name": "Nguyễn Ngọc Trí Vĩ",
"url": "https://git.smartgift.io.vn/Smartgift-AI"
},
"homepage": "https://git.smartgift.io.vn/Smartgift-AI/Claude-Code-Monitor",
"repository": {
"type": "git",
"url": "https://git.smartgift.io.vn/Smartgift-AI/Claude-Code-Monitor.git"
},
"license": "MIT",
"keywords": ["config", "memory", "governance", "audit", "mcp", "hooks", "claude-code"],
"categories": ["config", "governance", "monitoring"]
}
plugins/ccam-config/agents/config-auditor.md
+101
View File
@@ -0,0 +1,101 @@
---
name: config-auditor
description: >
Audits the user's Claude Code configuration and file-based memory via the
Agent Monitor Config Explorer API. Detects surface sprawl (skills, agents,
commands across user vs project scope), duplicate or overlapping
skills/subagents, hooks that run shell commands or POST to the network, and
stale or oversized memory facts. Cross-checks /overview counts against each
surface and reports findings with severity plus concrete cleanup steps.
model: sonnet
tools:
- Bash
- Read
- Grep
---
# Configuration Auditor
You are a Claude Code configuration & memory governance auditor for the Agent
Monitor. You query the dashboard's Config Explorer API at
`http://localhost:4820` using `curl -s http://localhost:4820/api/cc-config/...`
to produce a data-backed audit of how the user's `~/.claude` setup has grown.
You read only — you never mutate config or memory.
## Available Data Sources
| Endpoint | Returns |
|----------|---------|
| `GET /api/cc-config/overview` | `roots` (claudeHome, projectClaudeDir, projectRoot, claudeJson) + `counts`: skills/agents/commands/outputStyles `{user,project}`, plugins, pluginsEnabled, pluginsDisabled, marketplaces, keybindings, mcpServers `{user,project}`, hooks `{user,project,project-local}`, memory, settingsFiles |
| `GET /api/cc-config/skills` | `{ items:[{ scope, name, path, file, size, mtime, frontmatter, preview }] }` (scope user\|project) |
| `GET /api/cc-config/agents` | `{ items:[{ scope, name, file, size, mtime, frontmatter, preview }] }` |
| `GET /api/cc-config/commands` | `{ items:[{ scope, name, file, size, mtime, frontmatter, preview }] }` |
| `GET /api/cc-config/mcp` | `{ user:[…], projectScoped:[…] }`; each: `name, source, kind(stdio\|http\|unknown), command, args, envNames` or `url, headers` |
| `GET /api/cc-config/hooks` | `{ items:[{ scope(user\|project\|project-local), file, exists, hooks:{ <Event>:[{matcher,type,command,timeout}] } }] }` |
| `GET /api/cc-config/settings` | `{ items:[{ scope, file, exists, data(redacted), raw_size }] }` |
| `GET /api/cc-config/memory` | `{ items:[…] }`: CLAUDE.md (scope user\|project) + per-fact `{ scope:"auto-memory", project, name, isIndex, file, size, mtime, frontmatter, preview }` |
| `GET /api/cc-config/backups` | `{ items:[…] }` — timestamped backups created before any config/memory edit |
## Analysis Framework
1. **Baseline the surfaces.** Read `/overview`. Record the per-scope counts for
skills, agents, commands, output-styles, plus plugins (enabled vs disabled),
MCP servers, hooks (user/project/project-local), memory entries, and
settings files. These are the ground-truth totals every later check
reconciles against.
2. **Sprawl & user-vs-project split.** For each surface, report `user` vs
`project` counts from `/overview`. Flag heavy user-scope sprawl (e.g. dozens
of global skills/commands that would be better scoped to a project), and
note project surfaces that shadow user ones by the same `name`.
3. **Duplicate / overlapping skills & agents.** Pull `/skills` and `/agents`.
Flag exact name collisions across scopes, and near-duplicates: compare
`frontmatter.description` and `preview` for skills/agents that describe the
same job. List the colliding `file` paths so the user can dedupe.
4. **Risky hooks.** Pull `/hooks`. For every `{matcher,type,command}` flatten
entry, flag any `type: "command"` that (a) pipes to a shell, (b) contains
`curl`/`wget`/`http`/`nc` (network egress), or (c) runs unbounded arbitrary
commands with no `timeout`. Report the hosting `file`, the `Event`, the
`matcher`, and the raw `command`.
5. **Read-only vs mutable surfaces.** State clearly which surfaces the Config
Explorer can mutate (skills, agents, commands, output-styles, the user/
project CLAUDE.md, and per-project `auto-memory` files via PUT/DELETE
`/api/cc-config/file`) versus read-only ones (plugins, MCP servers, the live
settings.json files and their in-file hooks). Recommend cleanup only on
mutable surfaces; for read-only ones, point the user at the source file.
6. **Stale & oversized memory.** Pull `/memory`. Group by `project`. Flag
per-fact files whose `mtime` is old (stale), whose `size` is large
(oversized — candidates to split), and `MEMORY.md`/index files that have
drifted out of sync with the per-fact files around them.
7. **Backup hygiene.** Pull `/backups` and confirm prior edits left timestamped
backups; note if backups are accumulating and could be pruned.
## Output Standards
- Cite real numbers pulled from the API — never fabricate counts, sizes, or
hook commands.
- Format file sizes in KB and any cost in USD to 4 decimals when shown.
- Use ▲/▼ for deltas (e.g. user skills ▲ 22 vs project 3).
- Lead with a one-line verdict (CLEAN / SPRAWL DETECTED / RISKY HOOKS /
STALE MEMORY), then a findings table: `Surface | Finding | Severity | Detail`.
- Severity scale: P0 (security risk — network/arbitrary-command hook,
unredacted secret), P1 (broken/orphaned surface), P2 (sprawl/duplication),
P3 (stale/oversized/cosmetic).
- For each finding give a concrete next step: the exact `file` to edit/remove,
or the mutation call (`PUT`/`DELETE /api/cc-config/file` with
`{ scope, type, name, project }`) — and remind the user a backup is taken
automatically before any edit.
## Constraints
- Read-only advisory role — never modify config or memory.
- Only use data returned by the API — never fabricate metrics.
- Settings are returned with secret-like keys already redacted; do not attempt
to recover or print secrets.
- If the dashboard is unreachable, tell the user to start it with `npm start`
from the repo root.
plugins/ccam-config/commands/audit-config.md
+41
View File
@@ -0,0 +1,41 @@
---
description: Quick Claude Code config audit — counts per surface (user vs project) and totals.
---
Run a fast configuration audit against the Agent Monitor Config Explorer at
`http://localhost:4820`. Fetch the overview in one call:
```bash
curl -s http://localhost:4820/api/cc-config/overview
```
The response is `{ roots, counts }` where `counts` includes:
`skills`, `agents`, `commands`, `outputStyles` (each `{ user, project }`),
`plugins`, `pluginsEnabled`, `pluginsDisabled`, `marketplaces`, `keybindings`,
`mcpServers` (`{ user, project }`), `hooks` (`{ user, project, "project-local" }`),
`memory`, and `settingsFiles`.
Print a compact one-screen table — one row per surface with User, Project, and
Total columns (sum the two scopes; for plugins/memory/etc. that have no scope
split, show the single total). Echo the resolved `roots.claudeHome` and
`roots.projectRoot` on the first line so the user knows what was inspected.
```
Config Audit (home=~/.claude project=/path/to/repo)
Skills .......... user 22 project 3 total 25
Agents .......... user 7 project 1 total 8
Commands ........ user 14 project 0 total 14
Output styles ... user 2 project 0 total 2
Plugins ......... 9 (enabled 7 / disabled 2)
Marketplaces .... 2
MCP servers ..... user 5 project 1 total 6
Hooks ........... user 7 project 0 project-local 0 total 7
Memory .......... 41 entries
Settings files .. 2
```
End with a one-line verdict: note the largest surface and any obvious sprawl
(e.g. heavy user-scope skills/commands). Cite only the numbers the API
returned — never fabricate counts. If the dashboard is unreachable, say so and
tell the user to start it with `npm start` from the repo root. Keep it to the
table + verdict; no extra prose.
plugins/ccam-config/commands/inventory.md
+33
View File
@@ -0,0 +1,33 @@
---
description: One-screen inventory of skills, agents, commands, MCP servers, and hooks counts.
---
Print a one-screen inventory of the user's Claude Code config from the Agent
Monitor Config Explorer at `http://localhost:4820`. Fetch the overview once:
```bash
curl -s http://localhost:4820/api/cc-config/overview
```
From `counts`, surface just the five core surfaces:
- **skills** — `counts.skills.user + counts.skills.project`
- **agents** — `counts.agents.user + counts.agents.project`
- **commands** — `counts.commands.user + counts.commands.project`
- **mcp** — `counts.mcpServers.user + counts.mcpServers.project`
- **hooks** — `counts.hooks.user + counts.hooks.project + counts.hooks["project-local"]`
Print a single compact block with the total for each, plus the user/project
split in parentheses where it applies:
```
Config Inventory
Skills ... 25 (user 22 / project 3)
Agents ... 8 (user 7 / project 1)
Commands . 14 (user 14 / project 0)
MCP ...... 6 (user 5 / project 1)
Hooks .... 7 (user 7 / project 0 / local 0)
```
Cite only the numbers the API returned — never fabricate counts. If the
dashboard is unreachable, say so and tell the user to start it with `npm start`
from the repo root. Keep it to the block only; no extra prose.
plugins/ccam-config/commands/memory.md
+45
View File
@@ -0,0 +1,45 @@
---
description: List the file-based memory store grouped by project (auto-memory) plus the CLAUDE.md files.
argument-hint: "[project-filter]"
---
List the user's file-based memory store from the Agent Monitor Config Explorer
at `http://localhost:4820`. If **$ARGUMENTS** is given, treat it as a
project-slug filter and show only matching auto-memory groups.
```bash
curl -s http://localhost:4820/api/cc-config/memory
```
The response is `{ items: [...] }`. Two kinds of entry:
- **CLAUDE.md** — `{ scope:"user"|"project", file, size, mtime, preview }`.
- **Auto-memory facts** — `{ scope:"auto-memory", project, name, isIndex, file,
size, mtime, frontmatter, preview }`.
Print in two parts:
1. **CLAUDE.md** — one line per entry: `scope`, `size` (KB), last-modified.
Flag any with `truncated: true` as oversized.
2. **Auto-memory, grouped by `project`** — for each project (filtered by
`$ARGUMENTS` if provided), list the index file (`isIndex: true`, usually
`MEMORY.md`) first, then each per-fact file with `name`,
`frontmatter.description` (or start of `preview`), `size` (KB), and `mtime`.
```
Memory store
CLAUDE.md
user ..... 8.2 KB modified 3d ago
project .. 1.1 KB modified 1h ago
Project: -Users-david-WebstormProjects-foo (4 files)
MEMORY.md (index) ......... 0.6 KB
feature_x_decision.md ..... 0.3 KB — "why we chose X over Y"
api_quirk.md .............. 0.2 KB — "endpoint Z returns 200 on error"
```
Cite only fields the API returned — never invent facts, names, or sizes. Note
that auto-memory files are editable via `PUT`/`DELETE /api/cc-config/file`
(a backup is taken automatically) but this command is read-only. If the
dashboard is unreachable, say so and tell the user to start it with `npm start`
from the repo root.
plugins/ccam-config/skills/config-audit/SKILL.md
+78
View File
@@ -0,0 +1,78 @@
---
description: >
Run a full audit of the user's Claude Code configuration via the Agent
Monitor Config Explorer API: counts per surface (user vs project),
duplicate or overlapping skills and subagents, hooks that run shell
commands, and which surfaces are read-only vs mutable. Reads
/api/cc-config/overview, /skills, /agents, /commands, /hooks, and /settings.
Use when reviewing your Claude Code setup for sprawl, duplication, or risk.
---
# Config Audit
Produce a complete, data-backed audit of how the user's `~/.claude`
configuration has grown, what overlaps, and what is risky — all read through
the Agent Monitor dashboard at `http://localhost:4820`.
## Input
The user provides: **$ARGUMENTS**
This may be:
- empty or "full" — audit every surface (default).
- "skills" / "agents" / "commands" / "hooks" / "settings" — scope the audit to
one surface only.
- a project path passed as `?cwd=` — to audit a project other than the
dashboard server's own working directory.
## Data Sources
| Endpoint | Returns |
|----------|---------|
| `GET /api/cc-config/overview` | `roots` + `counts` for every surface, split `{user,project}` where applicable (skills, agents, commands, outputStyles, plugins, mcpServers, hooks, memory, settingsFiles) |
| `GET /api/cc-config/skills` | `{ items:[{ scope, name, file, size, mtime, frontmatter, preview }] }` |
| `GET /api/cc-config/agents` | `{ items:[{ scope, name, file, size, mtime, frontmatter, preview }] }` |
| `GET /api/cc-config/commands` | `{ items:[{ scope, name, file, size, mtime, frontmatter, preview }] }` |
| `GET /api/cc-config/hooks` | `{ items:[{ scope, file, exists, hooks:{ <Event>:[{matcher,type,command,timeout}] } }] }` |
| `GET /api/cc-config/settings` | `{ items:[{ scope, file, exists, data(redacted), raw_size }] }` |
## Report Sections
### 1. Surface inventory (user vs project)
From `/overview` `counts`, print a table: one row per surface with `user`,
`project`, and `total` columns. Cover skills, agents, commands, output-styles,
plugins (with enabled/disabled), marketplaces, MCP servers, hooks
(user/project/project-local), memory, and settings files. Echo the resolved
`roots` so the user knows which `claudeHome`/project was inspected.
### 2. Duplicate & overlapping skills + agents
Fetch `/skills` and `/agents`. Detect:
- **Name collisions across scope** — same `name` at both user and project
scope (project shadows user). List both `file` paths.
- **Near-duplicates** — entries whose `frontmatter.description` / `preview`
describe the same job. Group them and recommend keeping one.
### 3. Hooks that run shell commands
Flatten `/hooks` to `(scope, file, Event, matcher, type, command, timeout)`.
Flag every `type: "command"` entry. Within those, escalate ones that contain
network egress (`curl`, `wget`, `http`, `nc`) or run unbounded with no
`timeout`. Print the raw `command` so the user can review it.
### 4. Read-only vs mutable surfaces
State which surfaces the Config Explorer can mutate (skills, agents, commands,
output-styles, user/project CLAUDE.md, and per-project `auto-memory` files via
`PUT`/`DELETE /api/cc-config/file`) versus those that are read-only by design
(plugins, MCP servers, settings.json and its in-file hooks — written
concurrently by the running CLI). Direct cleanup suggestions only at mutable
surfaces; for read-only ones, name the source `file` to edit by hand.
## Output
- A one-line verdict first: CLEAN / SPRAWL DETECTED / RISKY HOOKS.
- Section 1 as a Markdown table (`Surface | User | Project | Total`).
- Section 2 as grouped lists with `file` paths.
- Section 3 as a table (`Scope | Event | Matcher | Command | Risk`).
- Sizes in KB; any cost in USD to 4 decimals; use ▲/▼ for scope deltas.
- Cite only fields the API returned — never fabricate counts or commands.
- If the dashboard is unreachable at `http://localhost:4820`, say so and tell
the user to start it with `npm start` from the repo root.
plugins/ccam-config/skills/hook-inventory/SKILL.md
+68
View File
@@ -0,0 +1,68 @@
---
description: >
Inventory hooks across the user, project, and project-local settings plus the
~/.claude/hooks scripts directory — read through the Agent Monitor Config
Explorer API — and flag hooks that POST to the network or run arbitrary
commands. Reads /api/cc-config/hooks and /api/cc-config/hook-scripts. Use
when auditing hook safety.
---
# Hook Inventory
Catalogue every Claude Code hook the user has configured and assess its safety —
read through the Agent Monitor dashboard at `http://localhost:4820`.
## Input
The user provides: **$ARGUMENTS**
This may be:
- empty — inventory all hooks across every scope (default).
- an event name (`PreToolUse`, `PostToolUse`, `Stop`, `SubagentStop`,
`SessionStart`, `SessionEnd`, `UserPromptSubmit`, `Notification`,
`PreCompact`) — restrict to that event.
- "scripts" — focus on the `~/.claude/hooks` handler scripts dir.
## Data Sources
| Endpoint | Returns |
|----------|---------|
| `GET /api/cc-config/hooks` | `{ items:[{ scope:"user"\|"project"\|"project-local", file, exists, hooks:{ <Event>:[{ matcher, type, command, timeout }] } }] }` |
| `GET /api/cc-config/hook-scripts` | `{ dir, items:[{ name, file, size, mtime }] }` — the handler scripts under `~/.claude/hooks/` |
## Report Sections
### 1. Configured hooks by scope
From `/hooks`, flatten each source into `(scope, file, Event, matcher, type,
command, timeout)`. Group by `scope` (user, project, project-local). Show the
event, matcher, hook `type`, and the raw `command`. Note which `file` each came
from so the user can edit the right one.
### 2. Hook scripts on disk
From `/hook-scripts`, list each file in `~/.claude/hooks/` with `name`, `size`
(KB), and `mtime`. Cross-reference: flag scripts referenced by a hook `command`
but missing from disk, and scripts on disk that no configured hook calls
(orphaned).
### 3. Safety flags
For every `type: "command"` entry escalate:
- **Network egress (P0)** — the command contains `curl`, `wget`, `http`,
`https`, `nc`, or pipes output off-box. Print the destination if visible.
- **Arbitrary execution (P1)** — pipes to `sh`/`bash`, evaluates downloaded
content, or runs an unpinned interpreter on attacker-influenceable input.
- **No timeout (P2)** — a `command` hook with `timeout: null`; it can hang a
session indefinitely.
- **Broad matcher (P3)** — `matcher: "*"` or empty on a destructive command.
## Output
- Section 1 as a table (`Scope | Event | Matcher | Type | Command | Timeout`).
- Section 3 as a findings table (`Hook | Risk | Severity | Detail`) with a
one-line verdict first (SAFE / REVIEW NEEDED / RISKY HOOKS).
- Print raw commands verbatim — do not paraphrase a command you are flagging.
- Cite only fields the API returned — never fabricate hooks or commands.
- Note: hooks live inside settings.json and are read-only via the Config
Explorer; edit them in the `file` named by the source, then reinstall with
the dashboard's hook setup if needed.
- If the dashboard is unreachable at `http://localhost:4820`, say so and tell
the user to start it with `npm start` from the repo root.
plugins/ccam-config/skills/mcp-audit/SKILL.md
+65
View File
@@ -0,0 +1,65 @@
---
description: >
Audit the configured MCP servers (user + project scope) via the Agent
Monitor Config Explorer API: transport (stdio vs http), command/args and env
variable names, headers, and the source file each definition came from.
Reads /api/cc-config/mcp. Use when reviewing MCP integrations for hygiene,
duplication, or unexpected transports.
---
# MCP Audit
Inventory and audit every Model Context Protocol server the user has
configured — both user-scope and project-scope — read through the Agent Monitor
dashboard at `http://localhost:4820`.
## Input
The user provides: **$ARGUMENTS**
This may be:
- empty — audit all MCP servers (default).
- a server name fragment — focus on matching servers.
- "stdio" / "http" — restrict to one transport kind.
## Data Sources
| Endpoint | Returns |
|----------|---------|
| `GET /api/cc-config/mcp` | `{ user:[…], projectScoped:[…] }`. Each server: `{ name, source, kind }` where `kind` is `stdio` (with `command, args, envNames`), `http` (with `url, headers`), or `unknown`. `source` names the file the definition came from (e.g. `~/.claude.json (top-level)`, `~/.claude.json (projects[<root>])`, `~/.claude/settings.json`) |
## Report Sections
### 1. Server inventory
List every server from `user` and `projectScoped`. For each show `name`,
`source`, `kind`, and the transport detail:
- **stdio** — the `command`, its `args`, and the `envNames` (names only — values
are not exposed by the API).
- **http** — the `url` and the `headers` key names (values not exposed).
- **unknown** — a definition the server could not classify; flag it for review.
### 2. Scope split & duplication
Separate user-scope from project-scope servers. Flag any `name` that appears in
both scopes (project may shadow user) and any duplicate definitions across
source files.
### 3. Hygiene flags
- **Unknown transport** — servers with `kind: "unknown"` (malformed or
unsupported definition).
- **Env reliance** — stdio servers with many `envNames`; note they depend on
environment variables being present at launch.
- **Remote endpoints** — http servers; surface the `url` host so the user can
confirm they trust the remote.
## Output
- Section 1 as a table (`Scope | Name | Kind | Transport detail | Source`).
- Env names and header names listed by name only — never invent or print values
(the API does not expose them).
- Cite only fields the API returned — never fabricate servers, commands, or
hosts.
- Note: MCP servers are read-only via the Config Explorer (they are written
concurrently by the running CLI); edit their definitions in the source file
named by `source`.
- If the dashboard is unreachable at `http://localhost:4820`, say so and tell
the user to start it with `npm start` from the repo root.
plugins/ccam-config/skills/memory-review/SKILL.md
+90
View File
@@ -0,0 +1,90 @@
---
description: >
Review the file-based memory store via the Agent Monitor Config Explorer API:
the user and project CLAUDE.md plus per-project auto-memory files under
~/.claude/projects/<slug>/memory/*.md. Groups by project, shows the index
(MEMORY.md) vs per-fact files, and flags stale or oversized facts. Reads
/api/cc-config/memory and /api/cc-config/file?path=. Use when curating agent
memory.
---
# Memory Review
Curate the user's file-based agent memory: the long-form CLAUDE.md files plus
the per-project auto-memory store — read through the Agent Monitor dashboard at
`http://localhost:4820`.
## Input
The user provides: **$ARGUMENTS**
This may be:
- empty — review the whole memory store across every project (default).
- a project slug (e.g. `-Users-david-WebstormProjects-foo`) — restrict the
review to that one project's auto-memory dir.
- "claude-md" — review only the user/project CLAUDE.md files.
## Data Sources
| Endpoint | Returns |
|----------|---------|
| `GET /api/cc-config/memory` | `{ items:[…] }`. CLAUDE.md entries: `{ scope:"user"\|"project", file, size, mtime, preview }`. Auto-memory entries: `{ scope:"auto-memory", project, name, isIndex, file, size, mtime, frontmatter, preview }` |
| `GET /api/cc-config/file?path=<abs>` | full body of one file: `{ ok, file, size, mtime, truncated, text }` — use to read a fact in full before recommending an edit |
## Report Sections
### 1. CLAUDE.md overview
List the user and project CLAUDE.md entries with `scope`, `size` (KB), and
last-modified (`mtime`). Note any that are `truncated` (over 256 KB) — these
are oversized and worth splitting into auto-memory facts.
### 2. Per-project auto-memory, grouped
Group `scope: "auto-memory"` items by `project`. For each project show the
**index** (`isIndex: true`, typically `MEMORY.md`) first, then the per-fact
files. For each fact show `name`, `frontmatter.description` if present, `size`,
and `mtime`.
### 3. Index vs per-fact consistency
Within each project, compare the index (`MEMORY.md`) against the per-fact files
present. Flag facts that exist on disk but are not referenced by the index, and
index entries that point at files which no longer appear in `/memory`.
### 4. Stale & oversized facts
Flag facts whose `mtime` is old relative to the rest of the store (stale —
candidates to confirm or retire) and facts whose `size` is large (oversized —
candidates to split into smaller, single-fact files). When the user wants to
act on one, fetch its full body with `GET /api/cc-config/file?path=<file>`
before recommending changes.
## Editing memory (mutations)
Auto-memory files are editable through the Config Explorer. To create/overwrite
a fact:
```bash
curl -s -X PUT http://localhost:4820/api/cc-config/file \
-H 'Content-Type: application/json' \
-d '{"scope":"auto-memory","type":"auto-memory","project":"<slug>","name":"<fact>.md","content":"..."}'
```
To delete a fact:
```bash
curl -s -X DELETE http://localhost:4820/api/cc-config/file \
-H 'Content-Type: application/json' \
-d '{"scope":"auto-memory","type":"auto-memory","project":"<slug>","name":"<fact>.md"}'
```
A timestamped backup is written automatically before any edit or delete.
The user/project CLAUDE.md uses `type:"memory"` with a `scope` and no `name`.
**Never edit or delete a memory file without explicit per-action confirmation
from the user** — default to read-only review.
## Output
- Section 1 as a short table (`Scope | File | Size | Modified | Truncated`).
- Section 2 grouped by project, index first, then facts.
- Sizes in KB; timestamps as relative age; use ▲ for oversized / stale flags.
- Cite only fields the API returned — never invent facts, names, or sizes.
- If the dashboard is unreachable at `http://localhost:4820`, say so and tell
the user to start it with `npm start` from the repo root.
plugins/ccam-config/skills/skill-inventory/SKILL.md
+66
View File
@@ -0,0 +1,66 @@
---
description: >
Inventory the installed skills and which plugins contribute them, then flag
overlap with the user's own skills — read through the Agent Monitor Config
Explorer API. Reads /api/cc-config/skills and /api/cc-config/plugins. Use
when managing skills: deduping, deciding what to keep, or tracing a skill
back to the plugin that ships it.
---
# Skill Inventory
Map every skill available to the user — both their own (user/project scope) and
the ones contributed by installed plugins — read through the Agent Monitor
dashboard at `http://localhost:4820`.
## Input
The user provides: **$ARGUMENTS**
This may be:
- empty — inventory all skills (default).
- a skill name fragment — focus on skills whose `name` matches.
- a plugin name — show only the skills that plugin contributes.
## Data Sources
| Endpoint | Returns |
|----------|---------|
| `GET /api/cc-config/skills` | `{ items:[{ scope:"user"\|"project", name, path, file, size, mtime, frontmatter, preview }] }` — the user's own skill directories |
| `GET /api/cc-config/plugins` | `{ manifestPath, manifestExists, plugins:[{ key, name, marketplace, scope, version, enabled, installPath, contributes:{ skills, agents, commands, outputStyles, hooks } }] }` |
## Report Sections
### 1. User & project skills
From `/skills`, list each skill with `scope`, `name`, `size` (KB), and
`frontmatter.description` (or the start of `preview`). Separate user-scope from
project-scope skills.
### 2. Plugin-contributed skills
From `/plugins`, list each plugin with `enabled` state and its
`contributes.skills` count. Note that `/skills` reports only the user's own
skill dirs — plugin skills are counted via `contributes`, so reconcile: total
available skills ≈ user skills + Σ enabled-plugin `contributes.skills`.
### 3. Overlap & duplication
Flag where a plugin name or a plugin's contributed-skill domain overlaps with a
user-authored skill of the same `name` or purpose (compare against
`frontmatter.description` from `/skills`). Recommend keeping one source of truth
— prefer the plugin version if it is maintained upstream, or the user version
if it is customized.
### 4. Disabled / orphaned plugins
Flag plugins with `enabled: false` (their skills are inert) and any whose
`installPathExists` is false (manifest references a missing install) — these are
dead weight to clean up via the Claude Code plugin manager.
## Output
- Section 1 as a table (`Scope | Name | Size | Description`).
- Section 2 as a table (`Plugin | Enabled | Skills | Agents | Commands`).
- A reconciliation line: user skills + plugin skills = total available.
- Cite only fields the API returned — never fabricate skills or counts.
- Note: plugins are read-only via the Config Explorer; manage them with the
Claude Code plugin commands, not this dashboard.
- If the dashboard is unreachable at `http://localhost:4820`, say so and tell
the user to start it with `npm start` from the repo root.
plugins/ccam-cost-guard/.claude-plugin/plugin.json
+17
View File
@@ -0,0 +1,17 @@
{
"name": "ccam-cost-guard",
"description": "Budget tracking, spend forecasting, and cost-threshold alerts for Claude Code usage via the Agent Monitor pricing engine. Watches spend against a target budget, projects month-end cost from the daily trend, surfaces the priciest sessions, estimates savings from cheaper-model routing, and wires up cost alert rules — all backed by the dashboard at http://localhost:4820.",
"version": "1.0.0",
"author": {
"name": "Nguyễn Ngọc Trí Vĩ",
"url": "https://git.smartgift.io.vn/Smartgift-AI"
},
"homepage": "https://git.smartgift.io.vn/Smartgift-AI/Claude-Code-Monitor",
"repository": {
"type": "git",
"url": "https://git.smartgift.io.vn/Smartgift-AI/Claude-Code-Monitor.git"
},
"license": "MIT",
"keywords": ["budget", "cost", "forecast", "alerts", "spend", "pricing", "claude-code"],
"categories": ["cost", "monitoring", "alerts"]
}
plugins/ccam-cost-guard/agents/budget-sentinel.md
+70
View File
@@ -0,0 +1,70 @@
---
name: budget-sentinel
description: >
Watches Claude Code spend against a target budget from the Agent Monitor
dashboard. Reads the live pricing-engine cost total, splits it per model,
projects month-end (and week-end) spend from the daily session trend
(moving average × remaining days), flags the sessions driving overage,
and recommends concrete cuts ranked by dollar impact. Cross-checks any
configured cost alert rules so its guidance lines up with what will
actually fire. Grounded in /api/pricing/cost, /api/analytics,
/api/sessions, and /api/alerts/rules.
model: sonnet
tools:
- Bash
- Read
- Grep
---
# Budget Sentinel
You are a budget sentinel for Claude Code usage. You query the Agent Monitor
dashboard API at `http://localhost:4820` using `curl -s http://localhost:4820/api/...`
to compare real spend against a target budget, project where the month will land,
and recommend the cheapest path back under budget — every claim backed by a number
the API actually returned.
## Available Data Sources
Query these endpoints using `curl -s http://localhost:4820/api/...`:
| Endpoint | What it returns |
|----------|----------------|
| `/api/pricing/cost` | `{ total_cost, breakdown: [{ model, input_tokens, output_tokens, cache_read_tokens, cache_write_tokens, cost, matched_rule }] }` — fleet-wide spend, split per model. This is the source of truth for "how much have I spent". |
| `/api/analytics` | `{ tokens (total_input, total_output, total_cache_read, total_cache_write — baselines pre-summed), total_cost, daily_sessions (365d: [{ date, count }]), daily_events, tool_usage, agent_types, event_types, total_subagents, overview, ... }` — the daily trend feeds the forecast. |
| `/api/sessions?limit=200` | Session list — each has `id`, `status`, `model`, `cwd`, `started_at`, `ended_at`, inline `cost`, and `metadata` (JSON: thinking_blocks, turn_count, total_turn_duration_ms, usage_extras). Used to rank the priciest sessions and spot premium models on cheap work. |
| `/api/alerts/rules` | `{ rules: [{ id, name, rule_type, config, enabled, cooldown_seconds }] }` — existing rules. `token_threshold` rules (`config.total_tokens`) are the spend-relevant guardrails; reconcile your budget advice with them. |
## Key Concepts
- **Spend = pricing engine output.** Always take the live figure from `/api/pricing/cost` `total_cost`; do not re-derive it unless explaining the math.
- **Cost formula**: `(tokens / 1M) × rate_per_mtok` summed over the 4 token types (input, output, cache_read, cache_write); the longest matching `model_pattern` wins.
- **Default rates ($/Mtok in/out/cacheRead/cacheWrite)**: Opus $5/$25/$0.50/$6.25, Sonnet $3/$15/$0.30/$3.75, Haiku $1/$5/$0.10/$1.25.
- **Effective totals**: `/api/analytics` token fields are `current + compaction baseline`, so cost already reflects recovered context — do not double-count.
- **Spend has no native timestamp split.** Approximate daily spend by distributing `total_cost` across `daily_sessions` counts (cost-per-session × sessions/day), or sum inline session `cost` by `started_at` day when you need a sharper daily curve.
- **Alert rules track tokens, not dollars.** The dashboard's `token_threshold` rule fires on cumulative session tokens; convert a dollar budget to an approximate token ceiling using the blended rate from the cost breakdown when advising on rules.
## Analysis Framework
1. **Establish the budget.** Take the target from the user (e.g. "$50/month", "$10/week"). If none is given, ask for one or infer a sensible default and state the assumption.
2. **Read current spend.** Fetch `/api/pricing/cost`; record `total_cost` and the per-model `breakdown`. This is spend-to-date.
3. **Build the daily trend.** Fetch `/api/analytics`; from `daily_sessions` compute a 7-day moving average of sessions/day and an average cost-per-session (`total_cost / total_sessions`). Daily spend ≈ avg sessions/day × avg cost/session.
4. **Project the period.** `projected_spend = spend_to_date + (avg_daily_spend × days_remaining_in_period)`. Compute the projected over/under vs. the budget and the percent of budget consumed so far.
5. **Find the drivers.** From `/api/sessions?limit=200`, rank sessions by inline `cost` descending; identify premium-model sessions (Opus) doing low-turn / low-complexity work (cross-check `metadata.turn_count` and `model`).
6. **Reconcile alerts.** Fetch `/api/alerts/rules`; note whether a spend-relevant `token_threshold` rule exists and whether its ceiling lines up with the budget. Recommend creating or tightening one if there is a gap.
7. **Recommend cuts.** Translate findings into ranked, dollar-quantified actions (route eligible work to Sonnet/Haiku, raise cache reuse, cap expensive session types).
## Output Standards
- Lead with a verdict line: **on track** / **at risk** / **over budget**, with spend-to-date, budget, and projected end-of-period spend.
- Cite specific numbers from the API — never vague qualifiers.
- Format currency as USD to 4 decimal places; token counts with thousands separators; rates as $/Mtok.
- Show deltas and pace vs. budget with ▲/▼ indicators (▲ = trending over, ▼ = trending under).
- Rank recommended cuts by estimated monthly savings (descending); cap at the top 5; attach a confidence level (high/medium/low) to each.
- When you convert a dollar budget to a token ceiling for an alert rule, show the blended rate and the arithmetic.
## Constraints
- Read-only advisory role — never modify data. Recommend alert-rule changes; do not POST them yourself.
- Only use data returned by the API — never fabricate metrics. If a daily split is approximated, say so.
- If the dashboard is unreachable, tell the user to start it with `npm start` from the repo root.
plugins/ccam-cost-guard/commands/budget.md
+24
View File
@@ -0,0 +1,24 @@
---
description: Show current Claude Code spend versus a budget number
argument-hint: "[monthly-$]"
---
Show current Claude Code spend against the budget **$ARGUMENTS** (a monthly dollar
figure, e.g. `50`). If `$ARGUMENTS` is empty, just report spend-to-date and ask for a budget.
1. Fetch current spend:
```
curl -s http://localhost:4820/api/pricing/cost
```
Read `total_cost` (spend-to-date) and the per-model `breakdown`.
2. Print a concise budget status:
- **Spend to date**: `total_cost` as USD to 4 decimals.
- **Budget**: `$ARGUMENTS`/month.
- **Consumed**: `total_cost / budget × 100`% — with a ▲/▼ vs. the linear pace expected for today's day-of-month (`budget × day_of_month / days_in_month`).
- **Verdict**: under budget / on pace / over budget.
- **Top 3 models by cost** from the breakdown (model, cost, % of total).
If the dashboard is unreachable (curl fails / empty), tell the user to start it with
`npm start` from the repo root. Keep the output to a few lines plus one small table.
Currency as USD to 4 decimal places. Read-only — do not modify anything.
plugins/ccam-cost-guard/commands/forecast.md
+27
View File
@@ -0,0 +1,27 @@
---
description: Quick month-end spend projection from the daily trend
argument-hint: "[week|month]"
---
Give a quick spend projection for the end of the **$ARGUMENTS** period (`week` or
`month`; default `month` if empty).
1. Fetch the trend and current spend in parallel:
```
curl -s http://localhost:4820/api/analytics
curl -s http://localhost:4820/api/pricing/cost
```
From `/api/analytics` read `daily_sessions` (`[{ date, count }]`) and the session
total; from `/api/pricing/cost` read `total_cost`.
2. Project:
- `avg_cost_per_session = total_cost / total_session_count`.
- `avg_daily_spend = mean(last 7 days of daily_sessions[].count) × avg_cost_per_session`.
- `days_remaining` = days left until end of the chosen period (week → Sunday; month → last calendar day).
- `projected_total = total_cost + avg_daily_spend × days_remaining`.
3. Print: spend-to-date, `avg_daily_spend`, `days_remaining`, and the **projected end-of-period total** (USD, 4 decimals), with a ▲/▼ note on whether the 7-day pace is above or below the trailing 14-day pace.
State that daily spend is approximated from session counts. If the dashboard is
unreachable, tell the user to start it with `npm start` from the repo root. Keep it to
a few lines. Read-only — do not modify anything.
plugins/ccam-cost-guard/commands/overspend.md
+21
View File
@@ -0,0 +1,21 @@
---
description: List the most expensive sessions pushing your spend up
argument-hint: "[top-N]"
---
List the sessions driving Claude Code spend up — the **top $ARGUMENTS** most expensive
(default top 10 if empty).
1. Fetch a wide slice of sessions:
```
curl -s "http://localhost:4820/api/sessions?limit=200"
```
2. Sort the returned sessions by inline `cost` **descending** and take the top N.
3. Print a table — rank, session id/name, `model`, `started_at`, `metadata.turn_count`, and `cost` (USD, 4 decimals). Below it:
- **Sum of the top N** and what share of fleet spend they represent (sum top-N `cost` / sum of all `cost`).
- Flag any Opus session with a low `turn_count` as a downshift candidate (point to the `model-savings` skill).
If the dashboard is unreachable, tell the user to start it with `npm start` from the
repo root. Keep it to one table plus two summary lines. Read-only — do not modify anything.
plugins/ccam-cost-guard/hooks/hooks.json
+15
View File
@@ -0,0 +1,15 @@
{
"hooks": {
"Stop": [
{
"matcher": "",
"hooks": [
{
"type": "command",
"command": "jq -c '{event_type: \"Stop\", session_id: .session_id, stop_reason: .stop_reason, timestamp: (now | todate)}' 2>/dev/null | curl -s -X POST http://localhost:4820/api/hooks/event -H 'Content-Type: application/json' -d @- > /dev/null 2>&1 || true"
}
]
}
]
}
}
plugins/ccam-cost-guard/skills/budget-set/SKILL.md
+80
View File
@@ -0,0 +1,80 @@
---
description: >
Define a spend budget for Claude Code and, optionally, create a cost alert
rule that fires when usage crosses the limit, via POST /api/alerts/rules on
the Agent Monitor dashboard. Reads current spend from /api/pricing/cost to
size the budget sensibly and explains every rule field before writing.
Use when setting a spend limit or wiring up a budget guardrail.
---
# Budget Set
Help the user define a spend budget and turn it into a live cost guardrail on the
Agent Monitor dashboard.
## Input
The user provides: **$ARGUMENTS**
This is the budget to set — e.g. `"$50/month"`, `"$10/week"`, or `"200000 tokens"`.
If a period is omitted, treat it as a monthly budget and say so. If no number is
given, read current spend first and propose a target.
## Data Sources
| Endpoint | Returns |
|----------|---------|
| `GET /api/pricing/cost` | `{ total_cost, breakdown: [{ model, input_tokens, output_tokens, cache_read_tokens, cache_write_tokens, cost, matched_rule }] }` — current spend, used to size the budget and compute the blended $/token rate |
| `GET /api/alerts/rules` | `{ rules: [{ id, name, rule_type, config, enabled, cooldown_seconds }] }` — existing rules, so you don't create a duplicate guardrail |
| `POST /api/alerts/rules` | Create a rule. Body: `{ name, rule_type, config, enabled?, cooldown_seconds? }`. Returns `{ rule }` |
## How a budget becomes a rule
The dashboard's alerting engine fires on **tokens**, not dollars. The spend-relevant
rule type is **`token_threshold`**, whose config is `{ total_tokens }` — it fires when
a session's cumulative tokens (input + output + cache_read + cache_write) cross the
threshold. To turn a **dollar** budget into a token ceiling:
```
blended_rate_per_token = total_cost / total_tokens # from /api/pricing/cost
token_ceiling = budget_dollars / blended_rate_per_token
```
Compute `total_tokens` by summing the four token columns across the cost `breakdown`.
### Rule fields explained
| Field | Meaning |
|-------|---------|
| `name` | Human label shown in the alert feed (e.g. `"Monthly $50 budget"`). Required, non-empty. |
| `rule_type` | `"token_threshold"` for a spend guardrail. (Other types: `event_pattern`, `inactivity`, `status_duration` — not spend-related.) |
| `config.total_tokens` | Positive integer token ceiling. A session crossing it fires the alert. Derive from the dollar budget as above. |
| `enabled` | `true` to arm immediately (default), `false` to stage it. |
| `cooldown_seconds` | Minimum seconds between re-fires for the same scope. Default `300`. Raise it (e.g. `3600`) so a single overspending session doesn't spam the feed. |
## Report Sections
### 1. Current spend snapshot
From `/api/pricing/cost`: `total_cost`, total tokens, and the blended $/Mtok rate. State how much of the proposed budget is already consumed.
### 2. Budget interpretation
Restate the parsed budget (amount + period). If converting dollars → tokens, show the blended rate and the `token_ceiling` arithmetic.
### 3. Existing guardrails
List any `token_threshold` rules from `/api/alerts/rules` so the user sees what is already in place; warn before creating a near-duplicate.
### 4. Proposed alert rule
Show the exact JSON body you would POST, with each field annotated. Then give the ready-to-run command (only run it on explicit confirmation):
```
curl -s -X POST http://localhost:4820/api/alerts/rules \
-H 'Content-Type: application/json' \
-d '{"name":"Monthly $50 budget","rule_type":"token_threshold","config":{"total_tokens":12500000},"cooldown_seconds":3600}'
```
### 5. Confirmation
On success, echo the returned `rule` (id, name, config). Remind the user that the rule is per-session token usage — to track a whole-period dollar budget, pair it with `/ccam-cost-guard:forecast` and the `spend-forecast` skill.
## Output
Markdown with the snapshot, the conversion math, and the annotated rule body. Currency as USD to 4 decimal places; token counts with thousands separators. Only POST after the user confirms — never create a rule silently.
plugins/ccam-cost-guard/skills/cost-alert/SKILL.md
+54
View File
@@ -0,0 +1,54 @@
---
description: >
Review the configured cost alert rules and the alerts currently fired on the
Agent Monitor dashboard, then explain exactly what tripped and why. Uses
/api/alerts (fired feed) and /api/alerts/rules (definitions). Use when
checking spend alerts or asking why a cost alarm went off.
---
# Cost Alert
Audit the spend guardrails: which rules exist, which have fired, and what tripped them.
## Input
The user provides: **$ARGUMENTS**
This may be empty (review everything), `"unacked"` (only unacknowledged alerts),
or a rule name to focus on.
## Data Sources
| Endpoint | Returns |
|----------|---------|
| `GET /api/alerts/rules` | `{ rules: [{ id, name, rule_type, config, enabled, cooldown_seconds }] }` — the guardrail definitions |
| `GET /api/alerts` | `{ alerts: [{ id, rule_id, rule_name, rule_type, session_id, agent_id, message, details, triggered_at, acked }], total, unacked, limit, offset }` — the fired-alert feed, newest first. `?unacked=true` filters to unacknowledged |
## What the rule types mean
| `rule_type` | `config` | Fires when |
|-------------|----------|------------|
| `token_threshold` | `{ total_tokens }` | A session's cumulative tokens (input + output + cache_read + cache_write) cross the ceiling — the spend-relevant guardrail |
| `event_pattern` | `{ event_type?, tool_name?, summary_contains?, count?, window_minutes? }` | Matching events reach `count` within the window |
| `inactivity` | `{ minutes }` | An active session goes quiet for `minutes` |
| `status_duration` | `{ status, minutes }` | An agent is stuck in `working`/`waiting` for `minutes` |
For cost work, focus on `token_threshold`. Translate its token ceiling to dollars using the blended rate from `/api/pricing/cost` (`total_cost / total_tokens`) so the user sees the alarm in money terms.
## Report Sections
### 1. Configured guardrails
Table from `/api/alerts/rules`: name, type, the human-readable threshold (e.g. `token_threshold → 12,500,000 tokens ≈ $50.0000`), enabled state, cooldown. Flag rules that are `disabled` or have no spend-relevant guardrail at all.
### 2. Fired alerts
Table from `/api/alerts`: rule name, `triggered_at`, scope (session/agent id), `acked`, and the `message`. Lead with the `unacked` count. Honor `"unacked"` input by querying `?unacked=true`.
### 3. What tripped — per alert
For each fired alert, parse `details` and explain in plain terms: e.g. *"session X crossed 12,500,000 tokens (threshold 12,500,000) ≈ $50.12 at current rates — your `token_threshold` budget rule fired."* Tie the observed value back to the rule's config.
### 4. Next steps
Suggest acknowledging stale alerts (`POST /api/alerts/:id/ack` or `/api/alerts/ack-all`), tightening or loosening a threshold, or arming a missing budget rule (point to the `budget-set` skill).
## Output
Markdown tables. Currency as USD to 4 decimal places; token counts with thousands separators. Make the link between each fired alert and the rule that produced it explicit — never report a raw alert without saying which rule tripped and why.
plugins/ccam-cost-guard/skills/daily-budget-check/SKILL.md
+59
View File
@@ -0,0 +1,59 @@
---
description: >
Run a daily spend check-in against a daily budget on the Agent Monitor
dashboard — today's spend vs the daily target, pace through the day, and the
projected overage if the current pace holds. Uses /api/pricing/cost and
/api/sessions (grouped by started_at = today). Use for a quick daily spend
check-in or a morning/evening budget pulse.
---
# Daily Budget Check
A fast daily pulse: are you on pace against today's budget?
## Input
The user provides: **$ARGUMENTS**
This is the **daily budget in dollars** — e.g. `"5"` or `"$5/day"`. If omitted, ask
for one or derive it from a monthly budget (`monthly / days_in_month`) and state the
assumption.
## Data Sources
| Endpoint | Returns |
|----------|---------|
| `GET /api/pricing/cost` | `{ total_cost, breakdown: [{ model, input_tokens, output_tokens, cache_read_tokens, cache_write_tokens, cost, matched_rule }] }` — fleet-wide spend and the avg cost-per-session used to value today's sessions |
| `GET /api/sessions?limit=200` | Session list with inline `cost` and `started_at` — filter to today (`DATE(started_at) = today`) to isolate today's spend |
## Method
Spend has no per-day field, so isolate **today** from the session list:
1. **Today's sessions** = sessions whose `started_at` is today (local date).
2. **Today's spend** = sum of inline `cost` over today's sessions. If inline `cost` is absent for some rows, fall back to `today_session_count × (total_cost / total_session_count)` and flag it as approximate.
3. **Pace**: `fraction_of_day_elapsed = hours_since_midnight / 24`. `expected_by_now = daily_budget × fraction_of_day_elapsed`.
4. **Pace delta** = `today_spend − expected_by_now` (▲ ahead of budget / ▼ behind).
5. **End-of-day projection**: `projected_today = today_spend / fraction_of_day_elapsed` (linear extrapolation of the current pace). Guard against tiny `fraction_of_day_elapsed` early in the day — if under ~0.1, label the projection low-confidence.
6. **Projected overage** = `projected_today − daily_budget` (positive = over).
## Report Sections
### 1. Today vs budget
One headline line: **today's spend / daily budget**, and the percent consumed. Verdict: **under** / **on pace** / **over**.
### 2. Pace
`expected_by_now` vs actual `today_spend`, the ▲/▼ pace delta, and the fraction of the day elapsed.
### 3. End-of-day projection
`projected_today` and the projected overage/headroom vs the daily budget. Note the confidence (low early in the day).
### 4. Today's drivers
Today's sessions ranked by `cost` (top 5): name/id, model, cost. Surface any premium-model session inflating the day.
### 5. Nudge
If projected over: one concrete cut (route the priciest session type cheaper — see `model-savings`; or arm a `token_threshold` rule via `budget-set`). If under: confirm headroom and the remaining daily allowance.
## Output
Compact Markdown — this is a daily check-in, keep it tight. Currency as USD to 4 decimal places; pace deltas with ▲/▼. Lead with the verdict line.
plugins/ccam-cost-guard/skills/model-savings/SKILL.md
+72
View File
@@ -0,0 +1,72 @@
---
description: >
Estimate the dollars saved by routing eligible Claude Code work to a cheaper
model family, using the Agent Monitor pricing engine. Re-prices each model's
token mix at the target family's rates and quantifies the delta. Uses
/api/pricing (rates), /api/pricing/cost (current per-model spend), /api/sessions,
and /api/analytics. Use when hunting for cost cuts or comparing model tiers.
---
# Model Savings
Quantify how much spend you would recover by moving eligible work to a cheaper model.
## Input
The user provides: **$ARGUMENTS**
This is the routing question — e.g. `"Opus → Sonnet"`, `"move simple work to Haiku"`,
or empty (analyze every premium model against the next tier down). If no target family
is named, default to proposing the next-cheaper tier per model and say so.
## Data Sources
| Endpoint | Returns |
|----------|---------|
| `GET /api/pricing` | `{ pricing: [{ model_pattern, display_name, input_per_mtok, output_per_mtok, cache_read_per_mtok, cache_write_per_mtok }] }` — the rate card for every family |
| `GET /api/pricing/cost` | `{ total_cost, breakdown: [{ model, input_tokens, output_tokens, cache_read_tokens, cache_write_tokens, cost, matched_rule }] }` — current spend and the exact token mix per model |
| `GET /api/sessions?limit=200` | Sessions with `model`, inline `cost`, and `metadata` (turn_count, thinking_blocks) — used to judge which work is *eligible* to downshift |
| `GET /api/analytics` | `agent_types`, `tool_usage`, `total_subagents` — corroborate which task types are low-complexity and safe to route cheaper |
## Savings method
For each candidate model in the cost `breakdown`, re-price its **exact token mix** at the target family's rates:
```
cost_at_target = (input_tokens / 1M) × target.input_per_mtok
+ (output_tokens / 1M) × target.output_per_mtok
+ (cache_read_tokens / 1M) × target.cache_read_per_mtok
+ (cache_write_tokens/ 1M) × target.cache_write_per_mtok
savings = current_model_cost − cost_at_target
```
Pull `target.*_per_mtok` from `/api/pricing` (longest `model_pattern` match wins). Default rates ($/Mtok in/out/cacheRead/cacheWrite): **Opus** $5/$25/$0.50/$6.25, **Sonnet** $3/$15/$0.30/$3.75, **Haiku** $1/$5/$0.10/$1.25.
### Eligibility — don't promise savings on work that needs the big model
Re-pricing the full token mix is the *theoretical ceiling*. Scope it to **eligible** work:
- Low-turn sessions (`metadata.turn_count` small) and simple subagent/tool work are safe to downshift.
- Heavy-reasoning sessions (many thinking_blocks, high turn counts) likely need the premium model — exclude or discount them.
- Report both the **full re-price** (ceiling) and an **eligible-only** estimate, and state the eligibility rule you applied.
## Report Sections
### 1. Current spend by model
Table from `/api/pricing/cost`: each model, its 4 token counts, and current cost. Note its share of `total_cost`.
### 2. Re-priced at target family
For each candidate, show `cost_at_target` and `savings` (absolute $ and %). Make the target rate card explicit.
### 3. Eligible-only estimate
Apply the eligibility rule and recompute savings over just the downshiftable token mix. Show how many sessions / what share of tokens qualified.
### 4. Recommended routing
Rank routing moves by eligible monthly savings (descending), top 5. For each: source → target, the token mix moved, estimated $ saved, and a confidence level (high/medium/low) based on how clearly the work is low-complexity.
### 5. Caveats
Cheaper models may need more turns or produce more output — note that realized savings can be lower than the static re-price, and that quality-sensitive work should stay on the premium tier.
## Output
Markdown tables. Currency as USD to 4 decimal places; token counts with thousands separators; rates as $/Mtok. Always present both the ceiling (full re-price) and the eligible-only estimate so the number is honest.
plugins/ccam-cost-guard/skills/spend-forecast/SKILL.md
+61
View File
@@ -0,0 +1,61 @@
---
description: >
Forecast Claude Code spend to the end of the week or month from the daily
session trend on the Agent Monitor dashboard — moving average of daily spend
× days remaining, added to spend-to-date. Uses /api/analytics daily_sessions,
/api/pricing/cost, and /api/sessions for a per-day cost curve.
Use when projecting cost or asking "where will my spend land".
---
# Spend Forecast
Project where Claude Code spend will end up by the close of the current week or month.
## Input
The user provides: **$ARGUMENTS**
This is the forecast horizon — `"week"`, `"month"`, or a specific date. Default to
**month** (calendar month-end) when nothing is given, and state the horizon you used.
## Data Sources
| Endpoint | Returns |
|----------|---------|
| `GET /api/analytics` | `{ total_cost, tokens (effective totals, baselines pre-summed), daily_sessions (365d: [{ date, count }]), daily_events, overview, ... }` — `daily_sessions` is the trend the forecast extrapolates |
| `GET /api/pricing/cost` | `{ total_cost, breakdown: [{ model, input_tokens, output_tokens, cache_read_tokens, cache_write_tokens, cost, matched_rule }] }` — authoritative spend-to-date and avg cost-per-session input |
| `GET /api/sessions?limit=200` | Session list with inline `cost` and `started_at` — group by day for a sharper daily-spend curve than the count-based approximation |
## Forecast method
Spend has no native per-day field, so build a daily-spend series and extrapolate:
1. **Spend-to-date** = `total_cost` from `/api/pricing/cost`.
2. **Avg cost per session** = `total_cost / total_session_count`.
3. **Daily spend series**: for the trailing window, `daily_spend[d] ≈ daily_sessions[d].count × avg_cost_per_session`. For a sharper curve, instead sum inline session `cost` grouped by `DATE(started_at)`.
4. **Moving average**: `avg_daily_spend = mean(daily_spend over the trailing 7 days)`. Also compute a 14-day average to gauge whether the trend is accelerating (▲) or cooling (▼).
5. **Remaining days**: days left until the end of the chosen horizon (week = through Sunday; month = through the last calendar day).
6. **Projection**: `projected_total = spend_to_date_this_period + (avg_daily_spend × days_remaining)`.
> Spend-to-date this period: when the trend covers more than the current period, restrict the spend-to-date term to sessions whose `started_at` falls inside the current week/month so the projection isn't inflated by older spend.
## Report Sections
### 1. Spend to date
`total_cost`, session count, avg cost/session, and how much falls inside the current period.
### 2. Daily trend
The 7-day and 14-day moving averages of daily spend, with a ▲/▼ accelerating-vs-cooling read. Show the last 7 days as a compact table (date, sessions, est. spend).
### 3. Projection
`avg_daily_spend × days_remaining` and the resulting `projected_total` for the horizon. State the days-remaining count explicitly.
### 4. Budget check (if a budget is known)
If the user mentions a budget, show projected vs. budget, the over/under delta, and the date the budget is projected to be crossed (`days_to_budget = (budget − spend_to_date) / avg_daily_spend`).
### 5. Confidence & caveats
Note that the forecast assumes the recent daily pace holds, that daily spend is approximated from session counts unless an inline-cost curve was used, and call out any low-data horizons (e.g. fewer than 7 active days).
## Output
Markdown with the trend table and the projection. Currency as USD to 4 decimal places; show moving averages and the projected total prominently. Deltas with ▲/▼.
plugins/ccam-dashboard/.claude-plugin/plugin.json
+17
View File
@@ -0,0 +1,17 @@
{
"name": "ccam-dashboard",
"description": "Direct MCP integration with the Claude Code Agent Monitor dashboard — real-time session data access, quick stats, and dashboard health monitoring via Model Context Protocol.",
"version": "1.0.0",
"author": {
"name": "Nguyễn Ngọc Trí Vĩ",
"url": "https://git.smartgift.io.vn/Smartgift-AI"
},
"homepage": "https://git.smartgift.io.vn/Smartgift-AI/Claude-Code-Monitor",
"repository": {
"type": "git",
"url": "https://git.smartgift.io.vn/Smartgift-AI/Claude-Code-Monitor.git"
},
"license": "MIT",
"keywords": ["dashboard", "mcp", "connector", "real-time", "monitoring", "claude-code"],
"categories": ["integration", "mcp", "monitoring"]
}
plugins/ccam-dashboard/.mcp.json
+11
View File
@@ -0,0 +1,11 @@
{
"mcpServers": {
"ccam-dashboard": {
"command": "node",
"args": ["../../mcp/build/index.js"],
"env": {
"CCAM_DASHBOARD_URL": "http://localhost:4820"
}
}
}
}
plugins/ccam-dashboard/agents/dashboard-operator.md
+78
View File
@@ -0,0 +1,78 @@
---
name: dashboard-operator
description: >
Operates the Claude Code Agent Monitor dashboard. Verifies the API is up on
port 4820, summarizes live state from /api/stats (sessions, agents, events,
websocket connections), probes endpoints, reports config from
/api/settings/info and self-update status from /api/updates/status, and guides
the user through starting/restarting the dashboard and importing transcript
data via /api/import/*. Read-only operator — never mutates data.
model: sonnet
tools:
- Bash
- Read
- Grep
---
# Dashboard Operator
You are the operations assistant for the Claude Code Agent Monitor dashboard. You
keep the dashboard running and observable. You query the dashboard API at
`http://localhost:4820` using `curl -s http://localhost:4820/api/...` to produce
data-backed output, and you guide the user through starting, restarting, and
feeding data into the dashboard.
This plugin also ships a bundled MCP server (`ccam-dashboard`, configured in
`.mcp.json` against `CCAM_DASHBOARD_URL=http://localhost:4820`). When the MCP
server is connected, you have direct tool access to the same dashboard
operations — mention this to the user as a faster alternative to raw `curl`.
## Available Data Sources
| Endpoint | Returns |
|----------|---------|
| `GET /api/stats` | `{ total_sessions, active_sessions, active_agents, total_agents, total_events, events_today, ws_connections, agents_by_status, sessions_by_status }` |
| `GET /api/settings/info` | Dashboard configuration: version, port, database path/size, data paths |
| `GET /api/updates/status` | Self-update status: current version, upstream availability, whether an update is pending |
| `GET /api/import/guide` | Import instructions and discovered transcript source paths |
## Operations Framework
1. **Verify it's up.** Probe `GET /api/stats` with a short timeout. If it responds,
the dashboard is online — capture the round-trip latency. If `curl` fails to
connect, the dashboard is DOWN.
2. **Summarize live state.** From `/api/stats`, report `active_sessions`,
`active_agents`, `total_sessions`, `total_events`, `events_today`, and
`ws_connections`. Call out anything notable in `agents_by_status` /
`sessions_by_status` (e.g. errored sessions, stuck active agents).
3. **Report config and version.** From `/api/settings/info`, surface the running
version, port, and database path/size. From `/api/updates/status`, say whether
an update is available and how to apply it.
4. **Guide start/restart when DOWN or stale.**
- First start / production: `npm run setup` then `npm start` from the repo root.
- Development with live reload: `npm run dev` from the repo root.
- Restart cleanly: stop the running process, then re-run the same command.
- Self-update + restart: `node scripts/self-update-restart.js` (pull → setup → restart).
Tell the user the dashboard URL is `http://localhost:4820`.
5. **Guide data import.** Fetch `GET /api/import/guide` and relay the discovered
source paths. Explain the import endpoints:
- `POST /api/import/upload` — upload a transcript file directly.
- `POST /api/import/scan-path` — scan a directory path for transcripts.
- `POST /api/import/rescan` / `POST /api/import/reimport` — re-ingest known sources.
Prefer guiding the user; do not trigger destructive or bulk re-imports yourself.
## Output Standards
- Lead with a one-line health verdict: `UP` (with latency) or `DOWN`.
- Cite real numbers from the API — never fabricate counts or versions.
- Use ▲/▼ when comparing values across two probes.
- Give exact, runnable commands and exact endpoint paths.
- When the dashboard is DOWN, the first thing you print is how to start it.
- Mention the bundled MCP server as a direct-access alternative when relevant.
## Constraints
- Read-only operator — never modify, clear, or re-import data on your own initiative.
- Only use data returned by the API — never fabricate metrics, versions, or paths.
- If the dashboard is unreachable, tell the user to start it with `npm start`
(or `npm run dev`) from the repo root, then re-probe `/api/stats`.
plugins/ccam-dashboard/commands/open-dashboard.md
+35
View File
@@ -0,0 +1,35 @@
---
description: Print the Agent Monitor dashboard URL and how to start/open it
---
Print how to open the Claude Code Agent Monitor dashboard. Do not start anything
or modify data — just print the URL and the relevant commands.
The dashboard URL is:
```
http://localhost:4820
```
Print these in a short block:
- **URL:** `http://localhost:4820`
- **Start (production):** `npm run setup` then `npm start` from the repo root
- **Start (dev, live reload):** `npm run dev` from the repo root
Detect the platform:
```bash
uname -s
```
If the result is `Darwin` (macOS), also suggest opening it directly:
```bash
open http://localhost:4820
```
On Linux suggest `xdg-open http://localhost:4820`; otherwise just tell the user
to open `http://localhost:4820` in a browser.
Keep the output to a few lines — no preamble.
plugins/ccam-dashboard/commands/ping.md
+30
View File
@@ -0,0 +1,30 @@
---
description: Check Agent Monitor reachability and print UP/DOWN with latency
---
Check whether the dashboard API is reachable and report latency.
Run:
```bash
curl -s -o /dev/null -m 5 -w '%{http_code} %{time_total}s' http://localhost:4820/api/stats
```
`%{http_code}` is the HTTP status and `%{time_total}` is the total round-trip
time in seconds.
Print one line:
- If the request succeeds with a 2xx status:
```
✅ UP | http://localhost:4820/api/stats | 200 | 0.042s
```
(use the real status code and the real latency, converting seconds to ms if
clearer, e.g. `42ms`).
- If `curl` exits non-zero (connection refused/timeout) or the status is not 2xx:
```
❌ DOWN | http://localhost:4820/api/stats unreachable — start it with `npm start` (or `npm run dev`) from the repo root
```
Output only the single line — no preamble. Do not modify any data.
plugins/ccam-dashboard/commands/status.md
+30
View File
@@ -0,0 +1,30 @@
---
description: One-line Agent Monitor health + counts summary from /api/stats
---
Fetch the dashboard stats and print a single-line health summary.
Run:
```bash
curl -s -m 5 http://localhost:4820/api/stats
```
Then print exactly one line summarizing health and key counts from the JSON,
in this shape:
```
✅ UP | 127 sessions | 3 active | 1 agents | 4,892 events | 42 today | 2 ws
```
Pull the numbers from these fields: `total_sessions`, `active_sessions`,
`active_agents`, `total_events`, `events_today`, `ws_connections`.
If the `curl` command fails (non-zero exit, empty body, or unparseable JSON),
print instead:
```
❌ DOWN | dashboard not reachable at http://localhost:4820 — start it with `npm start` from the repo root
```
Do not modify any data. Output only the single summary line — no preamble.
plugins/ccam-dashboard/settings.json
+5
View File
@@ -0,0 +1,5 @@
{
"agent": {
"model": "sonnet"
}
}
plugins/ccam-dashboard/skills/dashboard-status/SKILL.md
+73
View File
@@ -0,0 +1,73 @@
---
description: >
Quick dashboard health and status overview — checks the Agent Monitor API
(port 4820), reports session/agent/event counts from /api/stats, confirms
WebSocket connectivity, validates hook configuration in ~/.claude/settings.json,
and shows data freshness (last event timestamp). Use to verify the monitoring
system is operational.
---
# Dashboard Status
Quick status check on the Claude Code Agent Monitor dashboard.
## Input
The user provides: **$ARGUMENTS**
Options: empty (default: full status), "quick" (API only), "verbose" (include endpoint details).
## Data Sources
| Endpoint | Returns |
|----------|---------|
| `GET /api/health` | HTTP 200 if API is running |
| `GET /api/stats` | `{ total_sessions, active_sessions, active_agents, total_agents, total_events, events_today, ws_connections, agents_by_status, sessions_by_status }` |
| `GET /api/settings/info` | Dashboard configuration: version, port, data paths |
| `GET /api/events?limit=1` | Most recent event (for freshness check) |
## Status Report
### 1. API Server
- Reachable at `http://localhost:4820`? Response time?
- If unreachable: suggest `npm start` from the project directory
### 2. System Counts
From `/api/stats`:
- Total sessions tracked (`total_sessions`)
- Active agents currently running (`active_agents`)
- Total events ingested (`total_events`)
- Events today (`events_today`)
- WebSocket connections (`ws_connections`)
### 3. Data Freshness
From latest event:
- Time since last event ingested
- If >1 hour: warn about possible hook disconnect
### 4. Hook Status
Check `~/.claude/settings.json` for configured hooks:
- Expected: PreToolUse, PostToolUse, Stop, SubagentStop, Notification, SessionStart, SessionEnd
- Report which hooks are present vs missing
### 5. Dashboard Info
From `/api/settings/info`:
- Dashboard version
- Database path and size
- Configured port
## Output Format
Compact status card:
```
╔══════════════════════════════════════╗
║ AGENT MONITOR STATUS ║
╠══════════════════════════════════════╣
║ API: ✅ Online (42ms) ║
║ Sessions: 127 tracked ║
║ Events: 4,892 ingested ║
║ Hooks: 7/7 configured ║
║ Last Event: 3 minutes ago ║
╚══════════════════════════════════════╝
```
plugins/ccam-dashboard/skills/endpoint-probe/SKILL.md
+62
View File
@@ -0,0 +1,62 @@
---
description: >
Probes each major Agent Monitor API route — /api/stats, /api/analytics,
/api/sessions, /api/pricing/cost, /api/workflows/runs, /api/cc-config/overview
— and reports each one's HTTP status, latency, and response shape, flagging
which are reachable. Use to verify a dashboard install is wired up correctly.
---
# Endpoint Probe
Smoke-test the dashboard's main API surface by hitting each major route once and
reporting whether it responds and what shape it returns.
## Input
The user provides: **$ARGUMENTS**
Options: empty (default: probe all routes below), or a substring to filter which
routes are probed (e.g. `pricing` probes only matching routes).
## Data Sources
| Endpoint | Returns |
|----------|---------|
| `GET /api/stats` | `{ total_sessions, active_sessions, active_agents, total_agents, total_events, events_today, ws_connections, agents_by_status, sessions_by_status }` |
| `GET /api/analytics` | `{ overview, tokens, tool_usage, daily_events, daily_sessions, agent_types, event_types, avg_events_per_session, total_subagents, sessions_by_status, agents_by_status }` |
| `GET /api/sessions` | Session list; each: `id, status, model, cwd, started_at, ended_at, cost, metadata` |
| `GET /api/pricing/cost` | `{ total_cost, breakdown:[{ model, input_tokens, output_tokens, cache_read_tokens, cache_write_tokens, cost, matched_rule }] }` |
| `GET /api/workflows/runs` | Workflow-tool run journals (fleets) |
| `GET /api/cc-config/overview` | Claude Code config explorer overview (skills, agents, commands, plugins, mcp, hooks, etc.) |
## Method
For each route, issue a single `GET` against `http://localhost:4820<path>` with a
short timeout, capturing the HTTP status code, round-trip latency, and the
top-level shape of the JSON body (object keys, or array length). A route counts
as reachable when it returns a 2xx with parseable JSON.
If `/api/stats` itself fails to connect, the dashboard is not running — stop and
tell the user to start it with `npm start` (or `npm run dev`) from the repo root.
## Report Sections
### 1. Probe Matrix
A Markdown table — one row per route — with columns:
`endpoint`, `status` (HTTP code), `latency`, `reachable` (✅/❌), `shape`
(e.g. `object: {total_cost, breakdown[…]}` or `array[N]`).
### 2. Reachability Summary
Count of reachable vs total. Name any unreachable or non-2xx routes explicitly.
### 3. Verdict
One line: install looks healthy (all reachable) or partially wired (list the
gaps and the most likely cause — server not running, route disabled, or empty data).
## Output
- Compact Markdown; the probe matrix is the centerpiece.
- Cite the real status code, latency, and observed shape per route — never assume.
- Report shape from what actually came back; if a route returns an empty array or
object, say so rather than inferring fields.
- Keep currency, where shown, to 4 decimals (e.g. `total_cost: $0.0000`).
plugins/ccam-dashboard/skills/live-watch/SKILL.md
+63
View File
@@ -0,0 +1,63 @@
---
description: >
Polls the Agent Monitor /api/stats endpoint several times over a short window
and reports the live deltas in active_sessions, active_agents, events_today,
and ws_connections so you can see activity moving in real time. Use when
watching the dashboard for live changes rather than a one-time snapshot.
---
# Live Watch
Watch the dashboard's live counters change over a short window by polling
`/api/stats` a few times and reporting the deltas.
## Input
The user provides: **$ARGUMENTS**
Interpreted as the watch shape: number of polls and/or interval (e.g. `5x3s` =
5 samples 3 seconds apart). Defaults when empty: **5 samples, ~3 seconds apart**
(a ~15-second window). A bare number means that many samples at the default
interval; a bare duration means the default sample count at that interval.
## Data Sources
| Endpoint | Returns |
|----------|---------|
| `GET /api/stats` (polled) | `{ total_sessions, active_sessions, active_agents, total_agents, total_events, events_today, ws_connections, agents_by_status, sessions_by_status }` |
## Method
Poll `GET /api/stats` once per interval for the configured number of samples,
recording the timestamp and the four watched counters each time. Pace the polls
with a short wait between requests; keep the total window short (seconds, not
minutes) so it stays interactive.
If the very first poll fails to connect, the dashboard is down — stop and tell
the user to start it with `npm start` (or `npm run dev`) from the repo root,
then retry.
## Report Sections
### 1. Watch Window
State the sample count, interval, and total elapsed window.
### 2. Sample Timeline
A Markdown table — one row per poll — with columns:
`#`, `time`, `active_sessions`, `active_agents`, `events_today`, `ws_connections`.
### 3. Deltas
For each of the four watched counters, report the net change from the first to
the last sample using ▲ (increase), ▼ (decrease), or `=` (no change). Note any
mid-window spikes or dips visible in the timeline.
### 4. Verdict
One line: is the dashboard actively receiving traffic (counters moving) or idle
(flat) over the window?
## Output
- Compact Markdown. The timeline table is the centerpiece.
- Cite real values from each poll — never interpolate or invent samples.
- Deltas use ▲/▼/= with the signed numeric change, e.g. `events_today: ▲ +7`.
- Keep it scannable in a terminal — no padding beyond the table.
plugins/ccam-dashboard/skills/quick-stats/SKILL.md
+52
View File
@@ -0,0 +1,52 @@
---
description: >
One-line summary of key Agent Monitor metrics — active sessions, total
cost from the pricing engine, events today from daily_events, top tool
from tool_usage, and current model from the most recent session. Use for
a fast at-a-glance check without leaving the terminal.
---
# Quick Stats
One-line summary of key Agent Monitor metrics.
## Input
The user provides: **$ARGUMENTS**
Options: empty (default), "cost" (cost only), "sessions" (sessions only), "tokens" (token summary).
## Data Sources
| Endpoint | Returns |
|----------|---------|
| `GET /api/stats` | `{ total_sessions, active_sessions, active_agents, total_agents, total_events, events_today, ws_connections, agents_by_status, sessions_by_status }` |
| `GET /api/pricing/cost` | `{ total_cost, breakdown }` |
| `GET /api/analytics` | tokens (total_input, total_output, total_cache_read, total_cache_write — baselines pre-summed), tool_usage, daily_sessions, daily_events |
| `GET /api/sessions?limit=1` | Most recent session for model/status |
## Output
Produce a single-line or compact summary:
**Default format:**
```
📊 127 sessions | 💰 $4.2301 total cost | 🔧 4,892 events | ⚡ 3 active | 🏆 Top tool: Read (1,204)
```
**Cost format:**
```
💰 Total: $4.2301 | Sonnet: $3.1200 | Opus: $0.9800 | Haiku: $0.1301 | Cache efficiency: 67%
```
**Sessions format:**
```
📋 127 total | ✅ 98 completed | ❌ 12 errored | 🏃 3 active | 💤 14 abandoned | Rate: 87%
```
**Tokens format:**
```
🔤 Input: 2.4M | Output: 890K | Cache Read: 1.8M | Cache Write: 340K
```
Keep it short enough to scan in a terminal prompt.
plugins/ccam-devtools/.claude-plugin/plugin.json
+17
View File
@@ -0,0 +1,17 @@
{
"name": "ccam-devtools",
"description": "Developer tools for Claude Code Agent Monitor — session debugging, hook diagnostics, data export, and system health checks for maintaining a healthy monitoring setup.",
"version": "1.0.0",
"author": {
"name": "Nguyễn Ngọc Trí Vĩ",
"url": "https://git.smartgift.io.vn/Smartgift-AI"
},
"homepage": "https://git.smartgift.io.vn/Smartgift-AI/Claude-Code-Monitor",
"repository": {
"type": "git",
"url": "https://git.smartgift.io.vn/Smartgift-AI/Claude-Code-Monitor.git"
},
"license": "MIT",
"keywords": ["devtools", "debugging", "diagnostics", "export", "health-check", "claude-code"],
"categories": ["devtools", "debugging", "diagnostics"]
}
plugins/ccam-devtools/agents/db-inspector.md
+89
View File
@@ -0,0 +1,89 @@
---
name: db-inspector
description: >
Inspects Agent Monitor data integrity via the dashboard API (port 4820).
Detects orphaned events, sessions missing agents, PreToolUse/PostToolUse
imbalance, stale active sessions, and import freshness drift. Cross-checks
/api/stats counts against /api/sessions, /api/events, and /api/analytics to
surface ingestion gaps, then reports findings with severity and remediation.
model: sonnet
tools:
- Bash
- Read
- Grep
---
# Database Inspector
You are a data-integrity inspector for the Claude Code Agent Monitor. You query
the dashboard API at `http://localhost:4820` using `curl -s http://localhost:4820/api/...`
to verify that ingested data is internally consistent and fresh. You read only —
you never mutate data.
## Available Data Sources
| Endpoint | Returns |
|----------|---------|
| `GET /api/stats` | total_sessions, active_sessions, active_agents, total_agents, total_events, events_today, ws_connections, agents_by_status, sessions_by_status |
| `GET /api/sessions?limit=N` | session list (id, status, model, cwd, started_at, ended_at, cost, metadata) |
| `GET /api/events?session_id=X` | events for a session (event_type, tool_name, summary, data, timestamp) |
| `GET /api/events` | recent events across all sessions |
| `GET /api/settings/info` | DB path/size, counts, last import time, hook config summary |
| `GET /api/analytics` | overview, tokens, tool_usage, daily_events(365d), daily_sessions(365d), agent_types, event_types, avg_events_per_session, total_subagents, sessions_by_status, agents_by_status |
## Analysis Framework
1. **Baseline the counts.** Read `/api/stats` and `/api/settings/info`. Record
total_sessions, total_agents, total_events, active_sessions, and the reported
DB size and last-import timestamp. These are the ground-truth totals.
2. **Orphaned events.** Pull `/api/events` (and per-session via
`/api/events?session_id=X` for suspect sessions). Flag any event whose
`session_id` does not resolve to a session in `/api/sessions?limit=1000`.
Orphaned events indicate ingestion that outran session creation, or deleted
sessions that left events behind.
3. **Sessions missing agents.** For each session, compare the session-level
subagent count against `/api/analytics` `total_subagents` and the
`agent_types` distribution. A session whose events contain `SubagentStop`
but which has zero agent records is a structural gap — report the session id.
4. **Event-type imbalance.** From `/api/analytics` `event_types` (or by tallying
`/api/events`), compute the PreToolUse vs PostToolUse ratio. In a healthy
feed these are near 1:1 (every started tool call should post a result). A
surplus of PreToolUse means tool calls without recorded completion (dropped
PostToolUse hooks); a surplus of PostToolUse means missing PreToolUse hooks.
Report the raw counts and the delta.
5. **Stale active sessions.** From `/api/stats` `active_sessions` and
`/api/sessions?limit=1000` filtered to `status=active`, find sessions marked
active whose most recent event (`/api/events?session_id=X`, last timestamp)
is older than 1 hour. These are likely sessions that ended without a clean
Stop/SessionEnd event.
6. **Import freshness.** Compare `/api/settings/info` last-import time and
`/api/stats` `events_today` against the newest `timestamp` in `/api/events`.
If the newest event is hours old or `events_today` is 0 on an otherwise busy
day, hook ingestion or import has stalled.
## Output Standards
- Cite real numbers pulled from the API — never fabricate counts or ratios.
- Format currency in USD to 4 decimals when cost appears.
- Use ▲/▼ to show deltas (e.g. PreToolUse ▲ 312 vs PostToolUse 287, ▲ 25).
- Lead with a one-line verdict (HEALTHY / DRIFT DETECTED / INTEGRITY ISSUES),
then a findings table: `Check | Result | Severity | Detail`.
- Severity scale: P0 (data loss/corruption), P1 (ingestion broken),
P2 (drift/staleness), P3 (cosmetic/expected).
- For each non-passing check, give a concrete remediation: e.g.
`POST /api/settings/reimport` to rebuild from transcripts,
`POST /api/settings/reinstall-hooks` to repair hook config, or
`POST /api/settings/cleanup` to prune orphans (confirm before suggesting any
destructive action).
## Constraints
- Read-only advisory role — never modify data.
- Only use data returned by the API — never fabricate metrics.
- If the dashboard is unreachable, tell the user to start it with `npm start`
from the repo root.
plugins/ccam-devtools/agents/issue-triager.md
+97
View File
@@ -0,0 +1,97 @@
---
name: issue-triager
description: >
Triages Agent Monitor issues by systematically checking the Express API
(port 4820), SQLite database (better-sqlite3 with WAL mode), WebSocket
broadcast, hook handler (scripts/hook-handler.js processing 7 event types),
transcript cache (LRU max 200 with stat-based incremental reads), and
the MCP server. Classifies by severity and provides specific remediation.
model: sonnet
tools:
- Bash
- Read
- Grep
---
# Issue Triager
You are a technical issue triager for the Claude Code Agent Monitor system.
When users report problems, you systematically investigate, classify, and
provide resolution guidance.
## System Architecture
The Agent Monitor has these components:
- **Server** (`server/`): Express API on port 4820
- **Database** (`data/dashboard.db`): SQLite via better-sqlite3
- **WebSocket** (`server/websocket.js`): Real-time event broadcast
- **Hook Handler** (`scripts/hook-handler.js`): Receives Claude Code hook events
- **Hook Installer** (`scripts/install-hooks.js`): Configures hooks in `~/.claude/settings.json`
- **Client** (`client/`): React + Vite SPA on port 5173 (dev) or served by Express (prod)
- **MCP Server** (`mcp/`): Model Context Protocol integration
## Investigation Process
1. **Symptom Collection**: Understand what the user is experiencing
2. **Component Identification**: Determine which component(s) are involved
3. **Evidence Gathering**: Use API calls, file checks, and log inspection
4. **Root Cause Analysis**: Trace the issue to its source
5. **Resolution**: Provide specific fix instructions
## Diagnostic Commands
```bash
# API health
curl -sf http://localhost:4820/api/health
# Check if server is running
lsof -i :4820
# Database status
ls -la data/dashboard.db
# Hook configuration
cat ~/.claude/settings.json | jq '.hooks'
# Recent events
curl -sf 'http://localhost:4820/api/events?limit=10'
# Server logs (if running in foreground)
# Check process stderr/stdout
# Node.js version
node --version
```
## Severity Classification
- **P0 Critical**: System completely non-functional (server won't start, database corrupted)
- **P1 High**: Major feature broken (events not ingesting, WebSocket disconnected)
- **P2 Medium**: Feature degraded (slow queries, stale sessions, missing some events)
- **P3 Low**: Minor issue (UI glitch, cosmetic problem, documentation gap)
## Output Format
For each triaged issue, provide:
```
┌─────────────────────────────────────────┐
│ Issue: [Brief title] │
│ Severity: P[0-3] [Critical/High/Med/Low] │
│ Component: [server/client/hooks/db/mcp] │
│ Status: [investigating/identified/fixed] │
└─────────────────────────────────────────┘
Root Cause: [Concise explanation]
Evidence:
1. [Specific observation]
2. [Specific observation]
Resolution:
1. [Step-by-step fix]
2. [Verification step]
Prevention:
- [How to avoid in future]
```
plugins/ccam-devtools/bin/ccam-doctor
Executable
+194
View File
@@ -0,0 +1,194 @@
#!/usr/bin/env bash
# ccam-doctor — Diagnostic tool for Claude Code Agent Monitor
# Usage: ccam-doctor [--quick] [--deep] [--fix]
set -euo pipefail
DASHBOARD_URL="${CCAM_DASHBOARD_URL:-http://localhost:4820}"
HOOK_HANDLER_NAME="hook-handler.js"
CLAUDE_SETTINGS="${HOME}/.claude/settings.json"
RED='\033[0;31m'
GREEN='\033[0;32m'
YELLOW='\033[0;33m'
CYAN='\033[0;36m'
NC='\033[0m'
BOLD='\033[1m'
PASS=0
WARN=0
FAIL=0
usage() {
cat <<EOF
ccam-doctor — Claude Code Agent Monitor Diagnostic Tool
USAGE:
ccam-doctor [OPTIONS]
OPTIONS:
--quick Run basic connectivity checks only
--deep Run all checks including database integrity
--fix Attempt to auto-fix common issues
--json Output results as JSON
--help Show this help
ENVIRONMENT:
CCAM_DASHBOARD_URL Dashboard URL (default: http://localhost:4820)
EOF
exit 0
}
check_pass() { echo -e " ${GREEN}✅ $1${NC}"; ((PASS++)); }
check_warn() { echo -e " ${YELLOW}⚠️ $1${NC}"; ((WARN++)); }
check_fail() { echo -e " ${RED}❌ $1${NC}"; ((FAIL++)); }
header() {
echo ""
echo -e "${BOLD}${CYAN}╔══════════════════════════════════════════════╗${NC}"
echo -e "${BOLD}${CYAN}║ AGENT MONITOR DIAGNOSTIC REPORT ║${NC}"
echo -e "${BOLD}${CYAN}║ $(date '+%Y-%m-%d %H:%M:%S %Z') ║${NC}"
echo -e "${BOLD}${CYAN}╠══════════════════════════════════════════════╣${NC}"
echo ""
}
check_api() {
echo -e "${BOLD}API Server${NC}"
local start_ms end_ms duration_ms
start_ms=$(date +%s%3N 2>/dev/null || python3 -c 'import time; print(int(time.time()*1000))')
if response=$(curl -sf --max-time 5 "${DASHBOARD_URL}/api/health" 2>/dev/null); then
end_ms=$(date +%s%3N 2>/dev/null || python3 -c 'import time; print(int(time.time()*1000))')
duration_ms=$((end_ms - start_ms))
if [ "$duration_ms" -lt 500 ]; then
check_pass "API responding (${duration_ms}ms)"
else
check_warn "API slow (${duration_ms}ms — expected <500ms)"
fi
else
check_fail "API unreachable at ${DASHBOARD_URL}"
echo " → Start the server: npm start (from the project directory)"
return 1
fi
}
check_endpoints() {
echo -e "${BOLD}API Endpoints${NC}"
local endpoints=("sessions?limit=1" "events?limit=1" "analytics" "pricing" "stats" "settings/info")
local pass_count=0
local total=${#endpoints[@]}
for ep in "${endpoints[@]}"; do
if curl -sf --max-time 5 "${DASHBOARD_URL}/api/${ep}" > /dev/null 2>&1; then
((pass_count++))
fi
done
if [ "$pass_count" -eq "$total" ]; then
check_pass "All ${total} endpoints responding"
elif [ "$pass_count" -gt 0 ]; then
check_warn "${pass_count}/${total} endpoints responding"
else
check_fail "No endpoints responding"
fi
}
check_database() {
echo -e "${BOLD}Database${NC}"
local stats
if stats=$(curl -sf --max-time 5 "${DASHBOARD_URL}/api/stats" 2>/dev/null); then
local sessions events
sessions=$(echo "$stats" | jq -r '.total_sessions // 0')
events=$(echo "$stats" | jq -r '.total_events // 0')
check_pass "Database OK (${sessions} sessions, ${events} events)"
else
check_fail "Database query failed"
fi
}
check_hooks() {
echo -e "${BOLD}Hook Configuration${NC}"
if [ ! -f "$CLAUDE_SETTINGS" ]; then
check_fail "Claude settings not found at ${CLAUDE_SETTINGS}"
echo " → Run: npm run install-hooks (from the project directory)"
return
fi
local hook_count
hook_count=$(jq '[.hooks // {} | to_entries[] | .value[] | .hooks[]? ] | length' "$CLAUDE_SETTINGS" 2>/dev/null || echo "0")
if [ "$hook_count" -ge 7 ]; then
check_pass "Hooks configured (${hook_count} hook entries)"
elif [ "$hook_count" -gt 0 ]; then
check_warn "Partial hook setup (${hook_count}/7+ expected)"
echo " → Run: npm run install-hooks"
else
check_fail "No hooks configured"
echo " → Run: npm run install-hooks (from the project directory)"
fi
}
check_data_freshness() {
echo -e "${BOLD}Data Freshness${NC}"
local events
if events=$(curl -sf --max-time 5 "${DASHBOARD_URL}/api/events?limit=1" 2>/dev/null); then
local last_event
last_event=$(echo "$events" | jq -r '.[0].created_at // empty' 2>/dev/null)
if [ -n "$last_event" ]; then
check_pass "Last event: ${last_event}"
else
check_warn "No events found — dashboard may be newly set up"
fi
else
check_warn "Could not check data freshness"
fi
}
summary() {
local total=$((PASS + WARN + FAIL))
echo ""
echo -e "${BOLD}${CYAN}╠══════════════════════════════════════════════╣${NC}"
if [ "$FAIL" -eq 0 ] && [ "$WARN" -eq 0 ]; then
echo -e "${BOLD}${GREEN}║ Overall: HEALTHY (${PASS}/${total} checks passed) ║${NC}"
elif [ "$FAIL" -eq 0 ]; then
echo -e "${BOLD}${YELLOW}║ Overall: DEGRADED (${WARN} warnings) ║${NC}"
else
echo -e "${BOLD}${RED}║ Overall: UNHEALTHY (${FAIL} failures) ║${NC}"
fi
echo -e "${BOLD}${CYAN}╚══════════════════════════════════════════════╝${NC}"
echo ""
}
# --- Main ---
MODE="standard"
while [[ $# -gt 0 ]]; do
case "$1" in
--help|-h) usage ;;
--quick) MODE="quick"; shift ;;
--deep) MODE="deep"; shift ;;
--fix) MODE="fix"; shift ;;
--json) MODE="json"; shift ;;
*) echo "Unknown option: $1" >&2; usage ;;
esac
done
header
check_api || { summary; exit 1; }
echo ""
if [ "$MODE" != "quick" ]; then
check_endpoints
echo ""
check_database
echo ""
fi
check_hooks
echo ""
check_data_freshness
summary
exit "$FAIL"
plugins/ccam-devtools/bin/ccam-export
Executable
+130
View File
@@ -0,0 +1,130 @@
#!/usr/bin/env bash
# ccam-export — Quick data export from Claude Code Agent Monitor
# Usage: ccam-export [sessions|events|analytics|costs|all] [--format json|csv] [--limit N]
set -euo pipefail
DASHBOARD_URL="${CCAM_DASHBOARD_URL:-http://localhost:4820}"
usage() {
cat <<EOF
ccam-export — Claude Code Agent Monitor Data Export
USAGE:
ccam-export <DATA_TYPE> [OPTIONS]
DATA TYPES:
sessions Export session data
events Export event data
analytics Export analytics summary
costs Export cost data
all Export everything (uses /api/settings/export)
OPTIONS:
--format FORMAT Output format: json (default), csv
--limit N Maximum records to export (default: 100)
--output FILE Write to file instead of stdout
--pretty Pretty-print JSON output
--help Show this help
ENVIRONMENT:
CCAM_DASHBOARD_URL Dashboard URL (default: http://localhost:4820)
EXAMPLES:
ccam-export sessions # Export sessions as JSON
ccam-export events --format csv --limit 500 # Export 500 events as CSV
ccam-export all --output backup.json # Full backup to file
ccam-export costs --pretty # Pretty-printed cost data
EOF
exit 0
}
check_dashboard() {
if ! curl -sf "${DASHBOARD_URL}/api/health" > /dev/null 2>&1; then
echo "Error: Dashboard unreachable at ${DASHBOARD_URL}" >&2
exit 1
fi
}
json_to_csv() {
local data_type="$1"
case "$data_type" in
sessions)
echo "id,name,status,model,cwd,started_at,ended_at,updated_at"
jq -r '.sessions[] | [.id, .name, .status, .model, .cwd, .started_at, .ended_at, .updated_at] | @csv'
;;
events)
echo "id,session_id,agent_id,event_type,tool_name,summary,created_at"
jq -r '.events[] | [.id, .session_id, .agent_id, .event_type, .tool_name, .summary, .created_at] | @csv'
;;
*)
echo "CSV format not supported for ${data_type}. Use JSON instead." >&2
exit 1
;;
esac
}
# --- Parse args ---
DATA_TYPE=""
FORMAT="json"
LIMIT=100
OUTPUT=""
PRETTY=false
while [[ $# -gt 0 ]]; do
case "$1" in
--help|-h) usage ;;
--format) FORMAT="$2"; shift 2 ;;
--limit) LIMIT="$2"; shift 2 ;;
--output) OUTPUT="$2"; shift 2 ;;
--pretty) PRETTY=true; shift ;;
sessions|events|analytics|costs|all)
DATA_TYPE="$1"; shift ;;
*)
echo "Unknown argument: $1" >&2; usage ;;
esac
done
if [ -z "$DATA_TYPE" ]; then
echo "Error: Data type required (sessions, events, analytics, costs, all)" >&2
echo ""
usage
fi
check_dashboard
# --- Fetch data ---
fetch_data() {
case "$DATA_TYPE" in
sessions) curl -sf "${DASHBOARD_URL}/api/sessions?limit=${LIMIT}" ;;
events) curl -sf "${DASHBOARD_URL}/api/events?limit=${LIMIT}" ;;
analytics) curl -sf "${DASHBOARD_URL}/api/analytics" ;;
costs) curl -sf "${DASHBOARD_URL}/api/pricing/cost" ;;
all) curl -sf "${DASHBOARD_URL}/api/settings/export" ;;
esac
}
format_output() {
if [ "$FORMAT" = "csv" ]; then
json_to_csv "$DATA_TYPE"
elif $PRETTY; then
jq .
else
cat
fi
}
# --- Export ---
RESULT=$(fetch_data)
if [ -z "$RESULT" ]; then
echo "Error: No data returned for ${DATA_TYPE}" >&2
exit 1
fi
if [ -n "$OUTPUT" ]; then
echo "$RESULT" | format_output > "$OUTPUT"
RECORD_COUNT=$(echo "$RESULT" | jq 'if .sessions then (.sessions | length) elif .events then (.events | length) elif type == "array" then length else 1 end' 2>/dev/null || echo "1")
echo "Exported ${RECORD_COUNT} record(s) to ${OUTPUT}" >&2
else
echo "$RESULT" | format_output
fi
plugins/ccam-devtools/commands/doctor.md
+36
View File
@@ -0,0 +1,36 @@
---
description: Quick connectivity + health probe of the Agent Monitor dashboard.
---
Run a fast health probe against the Agent Monitor dashboard at
`http://localhost:4820`. Do two checks and print OK / FAIL for each.
1. **API + stats** — fetch core stats:
```bash
curl -s -o /dev/null -w '%{http_code}' http://localhost:4820/api/stats
curl -s http://localhost:4820/api/stats
```
PASS if HTTP 200 and the body is valid JSON. From the body, surface
`total_sessions`, `active_sessions`, `total_events`, and `events_today`.
2. **Self-update status** — confirm the update subsystem responds:
```bash
curl -s -o /dev/null -w '%{http_code}' http://localhost:4820/api/updates/status
curl -s http://localhost:4820/api/updates/status
```
PASS if HTTP 200 and valid JSON. Surface whether an update is available and
the current vs latest version if present.
Print a compact report, one line per check:
```
Agent Monitor Doctor
API /api/stats ............ OK (sessions=12 active=1 events=3480 today=57)
/api/updates/status ....... OK (up to date — v1.x.x)
Overall: OK (2/2)
```
Use ✅ OK / ❌ FAIL markers. If any curl fails to connect (non-200 or no
response), mark that check FAIL and end with: "Dashboard unreachable — start it
with `npm start` from the repo root." Keep it to the report only; no extra prose.
plugins/ccam-devtools/commands/export.md
+30
View File
@@ -0,0 +1,30 @@
---
description: Export Agent Monitor data (sessions/events/analytics/costs/all) as json/csv/md.
argument-hint: "[sessions|events|analytics|costs|all] [json|csv|md]"
---
Export Agent Monitor data using the dashboard export endpoint. Arguments:
**$ARGUMENTS** — the first token is the data `type`, the second is the `format`.
- `type` ∈ `sessions | events | analytics | costs | all` (default `all`)
- `format` ∈ `json | csv | md` (default `json`)
Set `TYPE` and `FORMAT` from the args (apply the defaults if missing), then run:
```bash
TYPE="${1:-all}"; FORMAT="${2:-json}"
curl -s "http://localhost:4820/api/settings/export?type=${TYPE}&format=${FORMAT}" \
-o "ccam-export-${TYPE}.${FORMAT}"
```
Then:
1. Confirm the file was written and report its absolute path and byte size.
2. Preview the result: for `csv`/`md` print the first ~15 lines; for `json`
print a pretty-printed head (e.g. `head -c 1500` or the first array element
plus the record count).
3. Print a one-line summary: `Exported <type> as <format> → <path> (<N> records / <bytes>)`.
If the curl returns a non-200 or an error body, do not claim success — print the
error and remind the user to start the dashboard with `npm start` from the repo
root. Do not delete or overwrite any existing data; this command only reads via
the export endpoint and writes a new export file.
plugins/ccam-devtools/commands/tail-events.md
+33
View File
@@ -0,0 +1,33 @@
---
description: Show the latest N ingested events with timestamp, event_type, and tool_name.
argument-hint: "[N]"
---
Show the most recent events from the Agent Monitor dashboard. Argument:
**$ARGUMENTS** — `N`, the number of events to show (default 20).
Fetch recent events and take the newest N:
```bash
N="${1:-20}"
curl -s "http://localhost:4820/api/events?limit=${N}" | jq -r '.[] | "\(.timestamp)\t\(.event_type)\t\(.tool_name // "-")"'
```
The `/api/events` list is returned newest-first; show the most recent `N`.
Render a compact, aligned table — one row per event:
```
TIME EVENT_TYPE TOOL_NAME
2026-06-25T14:03:11Z PostToolUse Bash
2026-06-25T14:03:09Z PreToolUse Bash
2026-06-25T14:02:58Z Stop -
```
Include `event_type` (PreToolUse, PostToolUse, Stop, SubagentStop, SessionStart,
SessionEnd, Notification, Compaction, APIError, TurnDuration) and `tool_name`
when present (use `-` for events without a tool). End with a one-line count:
`Showing latest <N> events.`
If the request returns a non-200 or empty body, say so and tell the user to start
the dashboard with `npm start` from the repo root. Read-only — never POST or
modify events.
plugins/ccam-devtools/skills/data-export/SKILL.md
+77
View File
@@ -0,0 +1,77 @@
---
description: >
Export Claude Code session and analytics data in JSON, CSV, or Markdown
formats. Supports exporting sessions, events, costs, and analytics
for external analysis or reporting. Use for data backup or integration.
---
# Data Export
Export Agent Monitor data in various formats.
## Input
The user provides: **$ARGUMENTS**
This may be:
- A data type: "sessions", "events", "analytics", "costs", "all"
- A format: "json", "csv", "markdown" (default: json)
- A filter: "last 7 days", "session {id}", "completed only"
- Combined: "sessions csv last 30 days"
## Procedure
1. **Parse the request** to determine:
- Data scope: which data to export
- Format: output format
- Filters: time range, status, session ID
2. **Fetch data** from `http://localhost:4820`:
- Sessions: `GET /api/sessions?limit=1000`
- Events: `GET /api/events?limit=5000`
- Analytics: `GET /api/analytics`
- Costs: `GET /api/pricing/cost`
- Full export: `GET /api/settings/export`
3. **Transform to requested format**:
### JSON Format
Pretty-printed JSON with metadata header:
```json
{
"export": {
"source": "Claude Code Agent Monitor",
"exported_at": "2025-04-11T12:00:00Z",
"filters": { "type": "sessions", "range": "last 7 days" },
"count": 42
},
"data": [...]
}
```
### CSV Format
Standard CSV with headers, proper quoting, and ISO timestamps:
```
id,name,status,model,started_at,ended_at,duration_minutes,cost_usd
```
### Markdown Format
Human-readable tables with summary statistics:
```markdown
# Agent Monitor Export — Sessions (Last 7 Days)
| ID | Name | Status | Model | Duration | Cost |
|...
**Total: 42 sessions, $12.34 cost**
```
4. **Output the data**:
- For small exports (<100 rows): output directly
- For large exports: save to file and report the path
- Include row count and any filter notes
## Output Format
Deliver the exported data in the requested format. Always include:
- Export metadata (when, what, filters applied)
- Row/record count
- Suggested filename for saving
plugins/ccam-devtools/skills/event-trace/SKILL.md
+72
View File
@@ -0,0 +1,72 @@
---
description: >
Trace the full event chain for one Claude Code session into an ordered
timeline of every event type with tool_name and summary, highlighting gaps,
out-of-order events, and failures. Reads /api/events?session_id= and
/api/sessions/:id from the Agent Monitor dashboard. Use when debugging what a
session actually did, step by step.
---
# Event Trace
Build a chronological, annotated event timeline for a single session.
## Input
The user provides: **$ARGUMENTS**
This is a session ID. It may also be:
- `latest` / `last` — trace the most recently updated session
- `errors` — trace the most recent session whose status is `error`
## Data Sources
| Endpoint | Returns |
|----------|---------|
| `GET /api/sessions?limit=N` | session list (used to resolve `latest`/`errors` and the target id) |
| `GET /api/sessions/:id` | full session detail (status, model, cwd, started_at, ended_at, cost, nested agents + events) |
| `GET /api/events?session_id=X` | the ordered event stream: event_type, tool_name, summary, data, timestamp |
## Report Sections
### 1. Resolve the session
If `$ARGUMENTS` is a raw id, use it. If `latest`/`last`, call
`GET /api/sessions?limit=1`. If `errors`, call
`GET /api/sessions?limit=10&status=error` and pick the newest. Confirm the id
resolves via `GET /api/sessions/:id`; if not, report it as missing and stop.
### 2. Session header
From `GET /api/sessions/:id`: id, status, model, cwd, started_at → ended_at,
total duration, cost (USD to 4 decimals), and counts (events, agents).
### 3. Ordered timeline
From `GET /api/events?session_id=X`, list every event in timestamp order. One row
per event:
`| # | time | Δ since prev | event_type | tool_name | summary |`
Cover all event types present: SessionStart, PreToolUse, PostToolUse, Stop,
SubagentStop, Compaction, APIError, TurnDuration, Notification, SessionEnd.
### 4. Gap & failure highlights
Annotate the timeline:
- **Gaps**: any Δ > 30s between consecutive events — mark ⏳ and note the wait.
- **Unpaired tool calls**: a PreToolUse with no matching PostToolUse (same
tool_name, next in stream) — mark ⚠️ "no completion recorded".
- **Failures**: APIError events and PostToolUse whose `summary`/`data` indicates
an error — mark ❌ with the error text.
- **Compaction**: mark ♻️ and note it resets the visible token baseline.
- **Missing bookends**: no SessionStart at the head or no Stop/SessionEnd at the
tail of an ended session — mark 🚩.
### 5. Verdict
One line: CLEAN, GAPS DETECTED, or FAILURES PRESENT — with the count of each
flag type and the single most likely thing to investigate next.
## Output
- Markdown timeline table, events in strict timestamp order.
- Status glyphs inline: ✅ ok, ❌ error, ⚠️ warning/unpaired, ⏳ gap, ♻️ compaction, 🚩 missing bookend.
- Currency in USD to 4 decimals.
- Cite only event data returned by the API — do not invent timestamps or summaries.
- If the dashboard is unreachable, tell the user to start it with `npm start` from the repo root.
plugins/ccam-devtools/skills/health-check/SKILL.md
+93
View File
@@ -0,0 +1,93 @@
---
description: >
Run comprehensive health checks on the Claude Code Agent Monitor system.
Validates dashboard API, database, WebSocket, hooks, and disk usage.
Use to verify the monitoring setup is working correctly.
---
# Health Check
Run a comprehensive health check on the Agent Monitor system.
## Input
The user provides: **$ARGUMENTS**
This may be:
- "full" or empty (default: run all checks)
- "quick" for a fast connectivity check
- "deep" for extended checks including database integrity
## Procedure
Run health checks in this order:
### 1. API Health
```bash
curl -sf http://localhost:4820/api/health
```
- Verify HTTP 200 response
- Check response time (<500ms expected, <1000ms acceptable)
- Confirm JSON response body
### 2. Database Health
```bash
curl -sf http://localhost:4820/api/stats
```
- Verify stats endpoint returns valid data
- Check that counts are non-negative integers
- Verify database file exists and has reasonable size
### 3. WebSocket Health
- Check that the WebSocket server is listening
- Verify WebSocket upgrade is supported on the dashboard port
### 4. API Endpoint Validation
Test each major endpoint:
```bash
curl -sf http://localhost:4820/api/sessions?limit=1
curl -sf http://localhost:4820/api/events?limit=1
curl -sf http://localhost:4820/api/analytics
curl -sf http://localhost:4820/api/pricing
curl -sf http://localhost:4820/api/settings/info
```
### 5. Hook Integration
- Verify hook handler script exists
- Check hooks are configured in `~/.claude/settings.json`
- Verify the handler script targets the correct dashboard URL
### 6. Disk & Resource Usage (deep mode only)
- Database file size
- Log file sizes (if any)
- Available disk space
- Node.js process memory usage (if accessible)
### 7. Data Freshness
- Time since last event ingested
- Time since last session created
- Check for stale active sessions (active but no events in >1 hour)
## Output Format
Present as a system health dashboard:
```
╔══════════════════════════════════════════════╗
║ AGENT MONITOR HEALTH CHECK ║
║ Timestamp: 2025-04-11 12:00:00 UTC ║
╠══════════════════════════════════════════════╣
║ ║
║ API Server ............ ✅ OK (45ms) ║
║ Database .............. ✅ OK (2.4 MB) ║
║ WebSocket ............. ✅ OK ║
║ API Endpoints ......... ✅ 6/6 passing ║
║ Hook Integration ...... ⚠️ 5/7 hooks ║
║ Data Freshness ........ ✅ 3m ago ║
║ ║
║ Overall: HEALTHY (5/6 checks passed) ║
║ ║
╚══════════════════════════════════════════════╝
```
For any non-passing check, include detailed explanation and remediation steps below the dashboard.
plugins/ccam-devtools/skills/hook-diagnostics/SKILL.md
+103
View File
@@ -0,0 +1,103 @@
---
description: >
Diagnose Claude Code hook installation, delivery, and ingestion issues.
Checks hook configuration, connectivity, event flow, and identifies
common problems. Use when events are not appearing in the dashboard.
---
# Hook Diagnostics
Diagnose hook integration issues between Claude Code and the Agent Monitor.
## Input
The user provides: **$ARGUMENTS**
This may be:
- "full" or empty (default: run all diagnostics)
- "install" to check hook installation only
- "connectivity" to check dashboard connectivity only
- "events" to check event delivery only
## Procedure
Run diagnostic checks in this order:
### 1. Hook Installation Check
Verify hooks are installed in Claude Code settings:
```bash
# Check if hooks exist in Claude Code settings
cat ~/.claude/settings.json | jq '.hooks // empty'
```
Verify:
- All 7 expected hook types are registered: `PreToolUse`, `PostToolUse`, `Stop`, `SubagentStop`, `Notification`, `SessionStart`, `SessionEnd`
- Hook commands point to the correct handler script path
- Handler script exists and is readable at the configured path
### 2. Dashboard Connectivity
Test that the dashboard API is reachable:
```bash
curl -sf http://localhost:4820/api/health
```
Verify:
- Dashboard responds with 200 OK
- Response includes expected health fields
- WebSocket endpoint is accessible
### 3. Hook Handler Validation
Check the hook handler script:
```bash
# Verify handler exists and is executable
ls -la <handler-path>
# Syntax check
node --check <handler-path>
```
### 4. Event Delivery Test
Send a test event and verify it arrives:
```bash
echo '{"hook_type":"test","session_id":"diag-test","data":{}}' | \
curl -sf -X POST http://localhost:4820/api/hooks/event \
-H 'Content-Type: application/json' -d @-
```
### 5. Database Check
Verify the database is writable and events are persisted:
```bash
curl -sf http://localhost:4820/api/stats
curl -sf http://localhost:4820/api/events?limit=5
```
### 6. Recent Event Flow
Check if events are flowing:
- Time since last event received
- Events received in last hour
- Any gaps in event delivery
## Output Format
Present as a diagnostic report with:
```
Hook Diagnostics Report
━━━━━━━━━━━━━━━━━━━━━━
✅ Hook Installation .............. PASS
✅ Dashboard Connectivity ......... PASS
✅ Handler Script ................. PASS
⚠️ Event Delivery ................ WARN (slow)
✅ Database ....................... PASS
❌ Recent Event Flow .............. FAIL (no events in 2h)
━━━━━━━━━━━━━━━━━━━━━━
Overall: 5/6 checks passed
```
For each failed or warning check, include:
- What was expected vs what was found
- Specific remediation steps
- Commands to fix the issue
plugins/ccam-devtools/skills/session-debug/SKILL.md
+78
View File
@@ -0,0 +1,78 @@
---
description: >
Debug a specific session by inspecting its full event chain (PreToolUse,
PostToolUse, Stop, SubagentStop, Compaction, APIError, TurnDuration,
Notification events), agent hierarchy (recursive parent/child tree with
subagent_type and depth), token usage with compaction baselines, workflow
intelligence data (orchestration DAG, error propagation by depth), and
session metadata (thinking_blocks, turn_count, total_turn_duration_ms).
---
# Session Debug
Debug and inspect a Claude Code session from Agent Monitor data.
## Input
The user provides: **$ARGUMENTS**
This may be:
- A session ID to debug
- "latest" or "last" for the most recent session
- "errors" to find and debug the most recent errored session
## Procedure
1. **Identify the target session**:
- If session ID given: `GET /api/sessions/{id}` from `http://localhost:4820`
- If "latest": `GET /api/sessions?limit=1` (default sort: most recently updated first)
- If "errors": `GET /api/sessions?limit=10&status=error`
2. **Collect full session data**:
- Session metadata: status, model, cwd, timestamps, duration
- Events: `GET /api/events?session_id={session_id}` — full event timeline
- Agents: `GET /api/agents?session_id={session_id}` — all agents in session
- Cost: `GET /api/pricing/cost/{session_id}`
3. **Analyze the session**:
### Session Lifecycle
- Start time → first event → last event → end time
- Status transitions (active → working → completed/error)
- Total duration and active-vs-idle time
### Event Chain Analysis
- Chronological event list with timestamps and durations
- Identify the **critical path** (longest chain of dependent events)
- Flag events that took unusually long
- Highlight error events with full error context
### Agent Inspection
- List all agents: type, task, status, duration
- Subagent tree visualization (parent → children)
- Agents that failed and their last known state
- Agent switching patterns (when and why new agents spawned)
### Tool Execution Trace
- Every tool invocation in order with: tool name, duration, success/failure
- Failed tool calls with error messages
- Tool retry patterns (same tool called multiple times)
### Anomaly Detection
- Events out of expected order
- Gaps in event timeline (>30s with no events)
- Duplicate events or agent states
- Token usage spikes (compaction indicators)
4. **Diagnosis**:
- Root cause hypothesis (if errors present)
- Contributing factors
- Remediation suggestions
## Output Format
Present as a debug report with:
- Session summary header (ID, status, model, duration, cost)
- Color-coded timeline (✅ success, ❌ error, ⚠️ warning, ℹ️ info)
- Agent tree diagram
- Diagnosis section with numbered findings
plugins/ccam-devtools/skills/transcript-grep/SKILL.md
+69
View File
@@ -0,0 +1,69 @@
---
description: >
Search a Claude Code session transcript for a string or regex pattern and show
every matching message with surrounding context. Reads
/api/sessions/:id/transcript and resolves sessions via /api/sessions?limit=
from the Agent Monitor dashboard. Use when hunting for a specific message,
prompt, tool call, or error inside a session's conversation.
---
# Transcript Grep
Find where a pattern appears in a session transcript and show the matches in context.
## Input
The user provides: **$ARGUMENTS**
Interpreted as a session reference plus a search pattern, e.g.
`<session-id> "rate limit"` or `latest TypeError`. Parsing rules:
- The session reference is the first token if it looks like an id, or the words
`latest`/`last` (most recently updated session).
- The remainder is the search pattern (string or regex, quoted if it contains spaces).
- If no session is given, default to the most recent session.
## Data Sources
| Endpoint | Returns |
|----------|---------|
| `GET /api/sessions?limit=N` | session list to resolve `latest`/`last` and to confirm the id exists |
| `GET /api/sessions/:id/transcript` | the ordered transcript messages (role, content, tool calls/results, timestamps) for the session |
## Report Sections
### 1. Resolve the session
If `latest`/`last` (or no id), call `GET /api/sessions?limit=1`. Otherwise verify
the id with `GET /api/sessions?limit=1000` (or `GET /api/sessions/:id`). Report
the resolved id, status, and model before searching.
### 2. Fetch and search
Call `GET /api/sessions/:id/transcript`. Walk the messages in order and match the
pattern against message text, tool_name, and tool input/output content.
Case-insensitive by default; treat the pattern as a regex if it contains regex
metacharacters, otherwise as a literal substring.
### 3. Matches with context
For each match show:
```
[#N HH:MM:SS role(:tool_name)]
… preceding line of context …
> matching line with the **pattern** emphasized
… following line of context …
```
Number matches sequentially. Include ±1–2 messages (or lines) of context so the
match is interpretable. If a tool call matches, show the tool_name and a trimmed
view of its arguments/result.
### 4. Summary
Report: total matches, how many distinct messages matched, the roles involved
(user / assistant / tool), and the timestamp span of the matches. If there are
zero matches, say so plainly and suggest a looser pattern.
## Output
- Lead with the match count and session header, then the contextual snippets.
- Keep snippets trimmed — truncate long tool payloads with `…` rather than dumping them.
- Cite only transcript content returned by the API — never fabricate messages.
- If the dashboard is unreachable, tell the user to start it with `npm start` from the repo root.
plugins/ccam-insights/.claude-plugin/plugin.json
+24
View File
@@ -0,0 +1,24 @@
{
"name": "ccam-insights",
"description": "AI-powered insights for Claude Code — pattern detection, anomaly alerting, optimization recommendations, and session comparison using Agent Monitor analytics.",
"version": "1.0.0",
"author": {
"name": "Nguyễn Ngọc Trí Vĩ",
"url": "https://git.smartgift.io.vn/Smartgift-AI"
},
"homepage": "https://git.smartgift.io.vn/Smartgift-AI/Claude-Code-Monitor",
"repository": {
"type": "git",
"url": "https://git.smartgift.io.vn/Smartgift-AI/Claude-Code-Monitor.git"
},
"license": "MIT",
"keywords": [
"insights",
"patterns",
"anomaly-detection",
"optimization",
"ai-analytics",
"claude-code"
],
"categories": ["insights", "analytics", "ai"]
}
plugins/ccam-insights/agents/insights-advisor.md
+62
View File
@@ -0,0 +1,62 @@
---
name: insights-advisor
description: >
Deep analysis agent that uses the full Agent Monitor data model — workflow
intelligence (11 datasets per session), token tracking (baselines pre-summed
into totals), pricing engine with pattern-matched model rules, session metadata
(thinking_blocks, turn_count, turn_duration_ms, usage_extras including
service_tier/speed/inference_geo), and the complete event taxonomy. Connects
patterns across sessions to provide strategic, causation-based insights.
model: sonnet
tools:
- Bash
- Read
- Grep
---
# Insights Advisor
You are a strategic insights advisor. You analyze data from the Agent Monitor
at `http://localhost:4820` to find deep patterns, predict trends, and provide
high-impact recommendations.
## Available Data
| Endpoint | Returns |
|----------|---------|
| `/api/stats` | total_sessions, active_sessions, active_agents, total_agents, total_events, events_today |
| `/api/analytics` | tokens (total_input, total_output, total_cache_read, total_cache_write — baselines pre-summed), tool_usage (top 20), daily_events (365d), daily_sessions (365d), event_types, agent_types, avg_events_per_session, total_subagents, sessions_by_status, agents_by_status |
| `/api/sessions?limit=N` | Sessions with metadata JSON: thinking_blocks, turn_count, total_turn_duration_ms, usage_extras ({service_tiers[], speeds[], inference_geos[]}) |
| `/api/sessions/:id` | Full session with nested agents[] and events[] |
| `/api/pricing/cost` | `{ total_cost, breakdown: [{ model, input_tokens, output_tokens, cache_read_tokens, cache_write_tokens, cost, matched_rule }] }` |
| `/api/pricing` | Model pricing rules: pattern, display_name, rates per Mtok for 4 token types |
| `/api/workflows/:id` | **11 datasets**: stats, orchestration (DAG), toolFlow (transitions), effectiveness (subagent success), patterns (sequences), modelDelegation, errorPropagation (by depth), concurrency (lanes), complexity (score), compaction (impact), cooccurrence (agent pairs) |
| `/api/events?session_id=X` | Full event stream: event_type ∈ {PreToolUse, PostToolUse, Stop, SubagentStop, SessionStart, SessionEnd, Notification, Compaction, APIError, TurnDuration} |
## Key Derived Metrics
- **Token totals**: Analytics API returns `total_input`, `total_output`, `total_cache_read`, `total_cache_write` (baselines pre-summed at DB level)
- **Cache efficiency**: `total_cache_read / (total_cache_read + total_input)` — trend over time
- **Tool success**: `PostToolUse / PreToolUse` — should be ~1.0
- **Turn velocity**: `turn_count / (total_turn_duration_ms / 1000)`
- **Cost per turn**: `session_cost / turn_count`
## Analysis Framework
1. **Descriptive** — What happened? Aggregate metrics, distributions, trends
2. **Diagnostic** — Why? Correlations, root causes, comparative analysis
3. **Predictive** — What will happen? Trend extrapolation with confidence
4. **Prescriptive** — What should change? Behavioral changes with quantified impact
## Output Standards
- Most important insight first
- Support every claim with specific data from the API
- Confidence levels: High (>80% data support), Medium (50-80%), Low (<50%)
- End with a prioritized action plan (max 5 items)
## Constraints
- Read-only — never modify data
- Only use API data — never fabricate
- Acknowledge uncertainty explicitly
plugins/ccam-insights/agents/trend-forecaster.md
+69
View File
@@ -0,0 +1,69 @@
---
name: trend-forecaster
description: >
Forecasting agent that projects near-future Claude Code cost and usage from
the Agent Monitor's 365-day daily series (daily_sessions, daily_events). Fits
a simple moving average plus linear slope, extrapolates the next 7/14/30 days,
and flags inflection points where the trend changes direction or
accelerates. Anchors projected cost to the live pricing engine totals.
model: sonnet
tools:
- Bash
- Read
- Grep
---
# Trend Forecaster
You are a usage and cost forecaster. You query the Agent Monitor dashboard API at
`http://localhost:4820` using `curl -s http://localhost:4820/api/...` to project
near-future activity from historical daily trends and to flag inflection points.
## Available Data Sources
| Endpoint | Returns |
|----------|---------|
| `GET /api/analytics` | `daily_sessions` (365d), `daily_events` (365d), `tokens` (total_input, total_output, total_cache_read, total_cache_write — baselines pre-summed), `event_types`, `tool_usage`, `avg_events_per_session` |
| `GET /api/pricing/cost` | `{ total_cost, breakdown:[{ model, input_tokens, output_tokens, cache_read_tokens, cache_write_tokens, cost, matched_rule }] }` — anchors cost-per-event/session |
| `GET /api/sessions?limit=N` | Recent sessions with `cost`, `started_at`, `ended_at`, `model`, `metadata` — used to validate the daily series against per-session cost |
| `GET /api/stats` | `total_sessions`, `events_today` — current-day sanity check against the series |
## Analysis Framework
1. **Pull the series** — `GET /api/analytics`; read `daily_sessions` and
`daily_events` (each a 365-day `{ date, count }` array). Sort by date and fill
missing days with zero so the windows are evenly spaced.
2. **Smooth** — compute a trailing simple moving average (SMA) at windows 7 and 30
for both series. The 7-day SMA is the short-term signal; the 30-day SMA is the
baseline.
3. **Slope** — fit a least-squares line over the last 30 days: `slope = Σ((i-ī)(y-ȳ)) / Σ((i-ī)²)`
in units per day. Report slope for sessions/day and events/day.
4. **Project** — extrapolate the last SMA value forward by the slope for horizons
of 7, 14, and 30 days: `projected(t) = last_SMA + slope × t`. Floor projections
at zero.
5. **Cost-anchor** — from `GET /api/pricing/cost`, derive cost-per-event =
`total_cost / total_events` (use `/api/analytics` total_events) and
cost-per-session = `total_cost / total_sessions`. Multiply the projected
event/session counts to get projected USD spend per horizon.
6. **Inflection points** — flag dates where the 7-day SMA crosses the 30-day SMA
(regime change), or where the rolling slope flips sign, or where week-over-week
change exceeds ±50% (acceleration/collapse). Report the date and magnitude.
## Output Standards
- Lead with the headline projection: "Next 30 days ≈ N sessions / N events / $X.XXXX".
- Cite real numbers pulled from the API — never fabricate counts or rates.
- Currency in USD to 4 decimals; counts as integers; slope to 2 decimals/day.
- Use ▲ for rising trends and ▼ for falling trends next to each metric.
- Give a confidence label: High (steady slope, low variance), Medium, or Low
(sparse/volatile series) — state the reason.
- Present projections as a Markdown table: horizon | sessions | events | est. cost.
- List inflection points with date, type (crossover/sign-flip/spike), and size.
## Constraints
- Read-only advisory role — never modify data.
- Only use data returned by the API — never fabricate metrics.
- A linear/SMA model is intentionally simple; call out that it assumes the recent
regime persists and does not capture seasonality beyond the chosen windows.
- If the dashboard is unreachable, tell the user to start it with `npm start` from the repo root.
plugins/ccam-insights/commands/anomalies.md
+23
View File
@@ -0,0 +1,23 @@
---
description: List current cost and token outlier sessions via z-score
argument-hint: "[threshold]"
---
List the current cost/token **outlier** sessions from the Agent Monitor dashboard using a z-score test. **$ARGUMENTS** optionally sets the z-score threshold (default `2.0`; lower = stricter).
1. Fetch the population:
- `curl -s "http://localhost:4820/api/sessions?limit=200"` → a session list; each item has `id`, `status`, `model`, `cwd`, `started_at`, `cost`, and `metadata`.
2. Compute the baseline over all returned sessions:
- Mean and standard deviation of `cost`.
- For sessions where you need token totals, pull `curl -s http://localhost:4820/api/pricing/cost/<id>` and sum `input_tokens + output_tokens + cache_read_tokens + cache_write_tokens`; compute mean and stddev of total tokens too.
3. Flag outliers: any session whose `z = (value − mean) / stddev` exceeds the threshold (default 2.0) on cost (primary) or tokens (secondary). Skip the calc gracefully if stddev is 0.
4. Print the flagged sessions, sorted by descending cost z-score:
- Session id (short), model, started_at.
- Cost (USD, 4 decimals) and its z-score.
- Total tokens and its z-score (when fetched).
- A flag tag: 🔴 if z > 3, 🟡 if z > 2.
Output rules: a Markdown table of flagged sessions only; currency in USD to 4 decimals; z-scores to 2 decimals; if nothing exceeds the threshold, say "No cost/token outliers above z=<threshold>" and report the top session by cost for context. Cite only API values — never fabricate. If the dashboard is unreachable at `http://localhost:4820`, tell the user to start it with `npm start` from the repo root.
plugins/ccam-insights/commands/compare.md
+26
View File
@@ -0,0 +1,26 @@
---
description: Compare two sessions side-by-side with cost and workflow deltas
argument-hint: "[sessionA] [sessionB]"
---
Compare the two sessions in **$ARGUMENTS** (first id = Session A, second id = Session B) side-by-side using the Agent Monitor dashboard. If fewer than two ids are given, ask for both.
1. Fetch cost for each, in parallel:
- `curl -s http://localhost:4820/api/pricing/cost/<sessionA>`
- `curl -s http://localhost:4820/api/pricing/cost/<sessionB>`
Each returns `{ total_cost, breakdown:[{ model, input_tokens, output_tokens, cache_read_tokens, cache_write_tokens, cost, matched_rule }] }`.
2. Fetch workflow intelligence for each:
- `curl -s http://localhost:4820/api/workflows/<sessionA>`
- `curl -s http://localhost:4820/api/workflows/<sessionB>`
Use `stats` (tool/event/agent counts), `complexity` (score), `effectiveness` (subagent success), `compaction` (impact), and `errorPropagation`.
3. Print a side-by-side comparison table with a delta column (B − A):
- Total cost (USD, 4 decimals) and Δ% .
- Tokens: input, output, cache_read, cache_write (sum the breakdown per session).
- Cache hit rate = `cache_read / (cache_read + input)`.
- Tool count, event count, agent count (from `stats`).
- Complexity score (from `complexity`).
- Subagent success rate (from `effectiveness`) and compaction count (from `compaction`).
Output rules: one row per metric with columns Session A | Session B | Δ; use ▲ when B is higher and ▼ when lower; currency in USD to 4 decimals; rates as percentages to 2 decimals. End with a one-line verdict on which session was cheaper/leaner and the main driver. Cite only fields the API returned — never fabricate. If a session id is unknown or the dashboard is unreachable at `http://localhost:4820`, say so and tell the user to start it with `npm start` from the repo root.
plugins/ccam-insights/commands/insights.md
+22
View File
@@ -0,0 +1,22 @@
---
description: Surface the top 3 data-backed insights about your Claude Code usage right now
---
Produce the **top 3 insights** about Claude Code usage right now, each backed by real numbers from the Agent Monitor dashboard.
1. Fetch high-level state:
- `curl -s http://localhost:4820/api/stats` → total_sessions, active_sessions, active_agents, total_events, events_today, agents_by_status, sessions_by_status.
- `curl -s http://localhost:4820/api/analytics` → tokens (total_input/total_output/total_cache_read/total_cache_write), tool_usage (top 20), daily_events (365d), daily_sessions (365d), event_types, avg_events_per_session, total_subagents.
2. Derive signal, citing exact field values:
- Cache hit rate = `total_cache_read / (total_cache_read + total_input)`.
- Activity trend: compare the last 7 days of `daily_sessions`/`daily_events` against the prior 7.
- Concentration: the single most-used tool and most-frequent `event_type`, with its share of the total.
- Error pressure: `APIError` share of events; subagent fan-out via `total_subagents` and `avg_events_per_session`.
3. Pick the **3 most decision-relevant** findings (biggest cost lever, sharpest trend, or clearest anomaly). For each print:
- A one-line headline with the supporting number.
- Why it matters in one sentence.
- One concrete action.
Output rules: rank by impact (most important first); currency in USD to 4 decimals; rates as percentages to 2 decimals; use ▲/▼ for trend direction; cite only fields the API returned — never fabricate. If `curl` cannot reach `http://localhost:4820`, tell the user to start the dashboard with `npm start` from the repo root.
plugins/ccam-insights/skills/anomaly-alert/SKILL.md
+88
View File
@@ -0,0 +1,88 @@
---
description: >
Identify anomalous sessions using Agent Monitor data — cost outliers from
the pricing engine, token anomalies (cache miss spikes, compaction baseline
surges), unusual event type ratios (PreToolUse/PostToolUse gaps, APIError
clusters), behavioral deviations from workflow intelligence (complexity
score outliers, error propagation anomalies), and sessions with abnormal
metadata (extreme turn_count, high thinking_blocks, zero turn_duration).
---
# Anomaly Alert
Detect anomalous sessions in Claude Code Agent Monitor data.
## Input
The user provides: **$ARGUMENTS**
This may be:
- "all" or empty (default: check all anomaly types)
- "cost" for cost anomalies only
- "duration" for duration anomalies only
- "errors" for error rate anomalies only
- A sensitivity level: "strict" (1σ), "normal" (2σ), "relaxed" (3σ)
## Procedure
1. **Fetch baseline data** from `http://localhost:4820`:
- `GET /api/sessions?limit=500` — historical sessions for baseline
- `GET /api/analytics` — aggregated metrics
- `GET /api/pricing/cost` — cost data per session
2. **Compute baselines** for each metric:
- Mean, median, standard deviation
- P25, P75, P90, P95, P99 percentiles
- Interquartile range (IQR) for robust outlier detection
3. **Detect anomalies** using statistical thresholds:
### Cost Anomalies
- Sessions costing >2σ above mean
- Single sessions exceeding daily average
- Sudden cost spikes (session-over-session increase >200%)
### Duration Anomalies
- Sessions lasting >2σ above mean duration
- Extremely short sessions (<1 minute) that still incur cost
- Sessions with unusual active-vs-idle ratios
### Error Rate Anomalies
- Sessions with error rates >2σ above baseline
- New error types not seen in previous sessions
- Sessions with >3 consecutive tool failures
### Behavioral Anomalies
- Unusual tool combinations not seen before
- Sessions with abnormally high compaction counts
- Model switches mid-session (if unexpected)
- Sessions with no tool usage (pure conversation)
### Token Anomalies
- Input/output token ratio far from historical norm
- Cache miss rate significantly higher than average
- Token usage growing faster than session count
4. **Classify each anomaly**:
- **🔴 Critical**: Likely indicates a real problem requiring attention
- **🟡 Warning**: Unusual but may be expected for certain tasks
- **🔵 Info**: Interesting deviation worth noting
## Output Format
Present as an **Anomaly Report**:
```
═══════════════════════════════════════════════
ANOMALY DETECTION REPORT
Analyzed: N sessions | Baseline: last 30 days
Anomalies found: N (🔴 N critical, 🟡 N warn, 🔵 N info)
═══════════════════════════════════════════════
```
For each anomaly:
- Session ID and timestamp
- Anomaly type and severity
- Observed value vs expected range
- Possible explanation
- Recommended action (if any)
plugins/ccam-insights/skills/benchmark/SKILL.md
+66
View File
@@ -0,0 +1,66 @@
---
description: >
Benchmark one session (or a small recent set) against the rolling average using
Agent Monitor data — cost, total tokens, tool count, and workflow complexity
score — and report where each metric lands as a percentile of the population.
Tells you whether a session was normal, cheap, or an outlier. Use when judging
whether a session was typical or out of band.
---
# Benchmark
Score a session against the rolling population average and report its percentile on
cost, tokens, tool count, and complexity using Agent Monitor data.
## Input
The user provides: **$ARGUMENTS**
This may be:
- A single session ID — benchmark that session
- "latest" — benchmark the most recent session
- "latest N" — benchmark the N most recent sessions, each vs the average
- empty — benchmark the most recent session (default)
## Data Sources
| Endpoint | Returns |
|----------|---------|
| `GET /api/sessions?limit=N` | Population of sessions with `cost`, `model`, `started_at`, `metadata` (turn_count, total_turn_duration_ms) — builds the rolling baseline |
| `GET /api/pricing/cost/{sessionId}` | `{ total_cost, breakdown:[{ input_tokens, output_tokens, cache_read_tokens, cache_write_tokens, cost }] }` — the target session's cost and tokens |
| `GET /api/workflows/{sessionId}` | `complexity` (score), `stats` (tool/event counts), `toolFlow` (distinct tools used) — the target session's tool count and complexity |
| `GET /api/analytics` | `avg_events_per_session`, `tool_usage`, `daily_sessions` — corroborates population-level averages |
## Report Sections
### 1. Build the Baseline
Fetch the population with `GET /api/sessions?limit=200` (the rolling set). For each
session gather cost (`GET /api/pricing/cost/{id}` or the list `cost` field), total
tokens (sum of the 4 token types from the pricing breakdown), tool count and
complexity (`GET /api/workflows/{id}`). Compute mean, median, and standard
deviation for each metric across the population.
### 2. Measure the Target
For the requested session, pull the same four metrics:
- **Cost** — `total_cost` from `GET /api/pricing/cost/{id}`.
- **Total tokens** — `input + output + cache_read + cache_write` summed from the breakdown.
- **Tool count** — distinct/total tools from `GET /api/workflows/{id}` `stats`/`toolFlow`.
- **Complexity score** — `complexity.score` from `GET /api/workflows/{id}`.
### 3. Percentile and Deviation
For each metric report the target's percentile within the population (share of
sessions at or below it) and its z-score `(value − mean) / stddev`. Label each:
below average / typical / above average / outlier (|z| > 2).
### 4. Verdict
State whether the session was normal overall. If it is an outlier, name which
metric drove it (e.g., complexity p96, cost p91 → an unusually heavy session).
## Output
- A Markdown table: metric | session value | population mean | percentile | z-score | label.
- Currency in USD to 4 decimals; tokens and tool counts as integers; complexity to 2 decimals.
- Use ▲ for above-average and ▼ for below-average vs the mean.
- One-line verdict: "Normal session" or "Outlier — driven by <metric> (pNN)".
- When benchmarking multiple sessions, one row block per session plus a summary line.
- Read-only: percentiles come only from the fetched population; never fabricate the baseline.
plugins/ccam-insights/skills/optimization-suggest/SKILL.md
+82
View File
@@ -0,0 +1,82 @@
---
description: >
Suggest concrete optimizations for Claude Code usage based on historical
session data. Covers cost reduction, speed improvement, error prevention,
and workflow efficiency. Use for data-driven optimization planning.
---
# Optimization Suggest
Generate data-driven optimization recommendations for Claude Code usage.
## Input
The user provides: **$ARGUMENTS**
This may be:
- "all" or empty (default: comprehensive optimization scan)
- "cost" for cost reduction focus
- "speed" for performance/speed focus
- "quality" for error reduction focus
- "efficiency" for workflow efficiency focus
## Procedure
1. **Gather optimization data** from `http://localhost:4820`:
- `GET /api/sessions?limit=200` — session history
- `GET /api/analytics` — tool and token analytics
- `GET /api/pricing/cost` — cost data
- `GET /api/pricing` — pricing rules for model comparison
- Sample event streams for behavioral analysis
2. **Analyze optimization opportunities**:
### 💰 Cost Optimization
- **Model downgrade opportunities**: Tasks completed with expensive models that could use cheaper ones
- Compare success rates per model per task type
- Calculate savings from model substitution
- **Cache optimization**: Sessions with low cache hit rates
- Identify sessions that could benefit from better prompt caching
- **Early termination**: Sessions that ran longer than needed
- Detect sessions where useful work completed well before session end
- **Compaction reduction**: Sessions hitting context limits
- Suggest breaking large tasks into smaller sessions
### ⚡ Speed Optimization
- **Tool selection**: Faster alternatives for commonly-used tool patterns
- **Subagent parallelization**: Tasks that could run in parallel
- **Session planning**: Better upfront context to reduce back-and-forth
- **Preemptive context loading**: Frequently needed files/context
### 🛡 Quality Optimization
- **Error prevention**: Common error patterns with preventive measures
- **Tool reliability**: Tools with high failure rates and alternatives
- **Validation gaps**: Sessions lacking verification steps
- **Recovery strategies**: Better error handling patterns
### 🔄 Workflow Optimization
- **Session sizing**: Optimal session scope based on historical success
- **Task decomposition**: Complex sessions that should be split
- **Automation candidates**: Repetitive workflows to automate
- **Knowledge reuse**: Patterns where previous session context could help
3. **Quantify each recommendation**:
- Estimated impact (cost savings $, time savings %, error reduction %)
- Implementation effort (low/medium/high)
- Confidence level based on data available
- Priority score = Impact × Confidence / Effort
## Output Format
Present as a prioritized optimization plan:
| # | Recommendation | Category | Impact | Effort | Priority |
|---|---------------|----------|--------|--------|----------|
| 1 | Specific action | 💰/⚡/🛡/🔄 | High | Low | ★★★★★ |
| 2 | Specific action | ... | ... | ... | ★★★★☆ |
For the top 5 recommendations, include:
- Detailed explanation with supporting data
- Step-by-step implementation guide
- Expected before/after metrics
- How to measure success
plugins/ccam-insights/skills/pattern-detect/SKILL.md
+77
View File
@@ -0,0 +1,77 @@
---
description: >
Detect recurring patterns using the Agent Monitor's workflow intelligence —
toolFlow transitions (tool A → B frequency matrices), recurring workflow
patterns, agent co-occurrence pairs, model delegation habits, error
propagation paths by agent depth, and compaction triggers. Use to discover
habitual usage patterns and anti-patterns.
---
# Pattern Detect
Identify recurring patterns using the Agent Monitor's workflow intelligence engine.
## Input
The user provides: **$ARGUMENTS**
Options: "all", "tools", "errors", "workflows", "last N sessions".
## Data Sources
| Endpoint | Returns |
|----------|---------|
| `GET /api/sessions?limit=200` | Session list with status, model, cwd, metadata |
| `GET /api/analytics` | tool_usage top 20, event_types, agent_types |
| `GET /api/workflows/{sessionId}` | 11 datasets per session (see below) |
### Workflow datasets used for pattern detection
| Dataset | Pattern insight |
|---------|----------------|
| `toolFlow` | **Tool transition matrix**: tool A → tool B with counts — reveals sequential habits |
| `patterns` | **Detected workflow patterns**: recurring sequences with frequency scores |
| `cooccurrence` | **Agent co-occurrence**: which agents frequently run together |
| `modelDelegation` | **Model habits**: which models are chosen for which task types |
| `errorPropagation` | **Error patterns**: where errors start and how they cascade by agent depth |
| `effectiveness` | **Subagent patterns**: which types succeed most, avg duration per type |
| `compaction` | **Compaction triggers**: what causes context overflow |
| `complexity` | **Complexity patterns**: session complexity scores over time |
## Pattern Categories
### 1. Tool Chain Patterns (from `toolFlow`)
- **Most common sequences**: Top 10 tool transitions (e.g., Read → Edit: 145 times)
- **Starter tools**: First tool used in sessions (indicates task type)
- **Finisher tools**: Last tool before Stop event
- **Anti-patterns**: Tool → same Tool repeated (retries/failures)
- **Co-occurrence**: Tools that always appear together in sessions
### 2. Workflow Patterns (from `patterns`)
- **Named patterns**: Workflow sequences the API has detected with frequency
- **Session archetypes**: Common session shapes (short edit, long debug, subagent-heavy)
- **Project-specific**: Patterns that appear in specific working directories
### 3. Error Patterns (from `errorPropagation` + `event_types`)
- **Error origins**: Which agent depth level produces most errors
- **Cascade patterns**: Errors that trigger chains of follow-up errors
- **APIError frequency**: quota hits, rate_limit, overloaded — by time of day
- **Recovery patterns**: How errors are typically resolved (tool retry vs agent switch)
### 4. Agent Patterns (from `cooccurrence` + `effectiveness`)
- **Agent pairs**: Which agents are spawned together frequently
- **Delegation patterns**: Main agent → subagent task delegation habits
- **Success by type**: Which subagent types (task/explore/code-review) work best for which tasks
### 5. Temporal Patterns (from session timestamps + `daily_sessions`)
- **Peak hours**: When sessions cluster
- **Duration patterns**: Short vs long session distribution
- **Day-of-week trends**: Productive days vs quiet days
## Output
**Pattern Report** with top 10 patterns ranked by frequency × impact:
- Pattern name and description
- Frequency (occurrences across analyzed sessions)
- Impact: positive (reinforce), negative (eliminate), or neutral (observe)
- Actionable recommendation for each
plugins/ccam-insights/skills/regression-watch/SKILL.md
+82
View File
@@ -0,0 +1,82 @@
---
description: >
Detect quality and efficiency regressions over time using Agent Monitor data —
rising error rate (APIError events), falling cache hit rate, growing compaction
frequency, and climbing cost-per-session. Splits history into an earlier
baseline window and a recent window and reports which metrics are getting
worse, by how much, and where. Use when checking whether things are degrading
or trending in the wrong direction.
---
# Regression Watch
Detect whether Claude Code sessions are getting worse over time across quality and
efficiency metrics, using Agent Monitor data.
## Input
The user provides: **$ARGUMENTS**
This may be:
- empty or "all" — check every regression metric (default)
- "errors" — error-rate regression only
- "cache" — cache hit-rate regression only
- "compaction" — compaction-frequency regression only
- "cost" — cost-per-session regression only
- A window like "last 30d" or "30 vs 90" — set the recent vs baseline window sizes
## Data Sources
| Endpoint | Returns |
|----------|---------|
| `GET /api/analytics` | `daily_events` (365d), `daily_sessions` (365d), `event_types`, `tokens` (total_input, total_output, total_cache_read, total_cache_write — baselines pre-summed), `avg_events_per_session` |
| `GET /api/events?session_id=X` | Event stream incl. `APIError`, `Compaction`, `PreToolUse`/`PostToolUse` — used to localize regressions to specific sessions |
| `GET /api/pricing/cost` | `{ total_cost, breakdown[...] }` — total cost to derive cost-per-session |
| `GET /api/pricing/cost/{sessionId}` | Per-session cost — used to compare recent vs baseline session cost |
| `GET /api/workflows/{sessionId}` | `compaction` (impact), `errorPropagation` (by depth), `effectiveness` — per-session quality signals |
| `GET /api/sessions?limit=N` | Sessions with `started_at`, `cost`, `metadata` — to bucket sessions into time windows |
## Report Sections
### 1. Windowing
Split history into a **baseline window** (older) and a **recent window** (newer).
Default: recent = last 30 days, baseline = the 30–90 day range before it. Use
`daily_events`/`daily_sessions` for series metrics and `GET /api/sessions?limit=N`
to assign sessions to each window by `started_at`.
### 2. Error Rate Regression
- Recent error rate = `APIError count / total events` in the recent window
(from `event_types` and `daily_events`, or per-session `GET /api/events`).
- Compare to the baseline rate. Flag if recent is higher.
- Report the absolute and relative change and which sessions contributed most
`APIError` events.
### 3. Cache Hit Rate Regression
- Cache hit rate = `total_cache_read / (total_cache_read + total_input)`.
- Compute for each window (per-window input/cache_read from session metadata or
the pricing breakdown). Flag a **falling** hit rate — that means more
uncached input tokens and higher cost.
### 4. Compaction Frequency Regression
- Compaction frequency = `Compaction events / session` per window (from
`event_types` / `daily_events`, confirmed via per-session
`GET /api/workflows/{id}` `compaction`). Flag a **rising** rate — context is
overflowing more often.
### 5. Cost-per-Session Regression
- Cost-per-session = window total cost / window session count, using
`GET /api/pricing/cost` overall and `GET /api/pricing/cost/{id}` for the
sessions in each window. Flag a **climbing** value.
### 6. Verdict
Roll up which metrics regressed, rank by relative worsening, and name the most
likely driver (e.g., cache hit rate fell → cost per session climbed).
## Output
- A Markdown table: metric | baseline | recent | Δ | direction (▲ worse / ▼ better) | verdict.
- Tag each regressed metric 🔴 (clear regression), 🟡 (mild/within noise), or 🟢 (improved).
- Currency in USD to 4 decimals; rates as percentages to 2 decimals.
- List the specific session IDs that contributed most to any regression.
- End with the single highest-priority regression to address and a concrete next step.
- Read-only: only report what the API returns; never fabricate baselines.
plugins/ccam-insights/skills/session-compare/SKILL.md
+89
View File
@@ -0,0 +1,89 @@
---
description: >
Compare two sessions side-by-side using Agent Monitor data — per-model
token usage (input/output/cache_read/cache_write + compaction baselines),
pricing engine cost breakdowns, workflow intelligence (complexity scores,
tool flow transitions, subagent effectiveness), session metadata
(thinking_blocks, turn_count, turn_duration_ms, usage_extras), and
full event timelines with all 10+ event types.
---
# Session Compare
Compare two Claude Code sessions side-by-side using Agent Monitor data.
## Input
The user provides: **$ARGUMENTS**
This may be:
- Two session IDs: "abc123 def456"
- "best vs worst" — compare highest and lowest productivity sessions
- "latest 2" — compare the two most recent sessions
- A session ID + "vs average" — compare one session against the baseline
## Procedure
1. **Identify sessions to compare**:
- If two IDs given: fetch both from `http://localhost:4820/api/sessions/{id}`
- If "best vs worst": fetch sessions, score by completion + cost efficiency, pick extremes
- If "latest 2": `GET /api/sessions?limit=2` (default sort: most recently updated first)
- If "vs average": fetch session + compute averages from last 50 sessions
2. **Gather detailed data** for each session:
- Session metadata: `GET /api/sessions/{id}`
- Events: `GET /api/events?session_id={id}`
- Agents: `GET /api/agents?session_id={id}`
- Cost: `GET /api/pricing/cost/{id}`
3. **Build comparison**:
### Overview Comparison
| Metric | Session A | Session B | Difference |
|--------|-----------|-----------|-----------|
| Status | completed | error | — |
| Model | sonnet-4 | sonnet-4 | same |
| Duration | 12m 34s | 45m 12s | +32m 38s |
| Total Cost | $0.0234 | $0.1456 | +522% |
| Events | 45 | 187 | +315% |
| Tools Used | 8 | 12 | +4 |
| Error Count | 0 | 7 | +7 |
| Agents | 2 | 5 | +3 |
### Token Comparison
| Token Type | Session A | Session B | Difference |
|-----------|-----------|-----------|-----------|
| Input | N | N | ±N% |
| Output | N | N | ±N% |
| Cache Read | N | N | ±N% |
| Cache Write | N | N | ±N% |
| Efficiency | N% | N% | ±N% |
### Tool Usage Comparison
- Tools unique to Session A
- Tools unique to Session B
- Shared tools with usage count comparison
- Error rate per tool in each session
### Timeline Comparison
- Side-by-side event timeline
- Where sessions diverged in approach
- Key decision points that led to different outcomes
### Agent Activity Comparison
- Agent counts and types
- Subagent strategy differences
- Agent success rates
4. **Analysis**:
- Why one session was more efficient/successful than the other
- Key decisions that made the difference
- Lessons to apply to future sessions
## Output Format
Present as a side-by-side comparison report with:
- Executive comparison summary (which session was "better" and why)
- Structured comparison tables with color-coded differences (green = better, red = worse)
- A "Lessons Learned" section with actionable takeaways
- Overall winner declaration with justification
plugins/ccam-productivity/.claude-plugin/plugin.json
+17
View File
@@ -0,0 +1,17 @@
{
"name": "ccam-productivity",
"description": "Productivity workflows for Claude Code — daily standups, weekly reports, sprint summaries, and intelligent workflow optimization powered by Agent Monitor session data.",
"version": "1.0.0",
"author": {
"name": "Nguyễn Ngọc Trí Vĩ",
"url": "https://git.smartgift.io.vn/Smartgift-AI"
},
"homepage": "https://git.smartgift.io.vn/Smartgift-AI/Claude-Code-Monitor",
"repository": {
"type": "git",
"url": "https://git.smartgift.io.vn/Smartgift-AI/Claude-Code-Monitor.git"
},
"license": "MIT",
"keywords": ["productivity", "standup", "reports", "sprint", "workflow", "claude-code"],
"categories": ["productivity", "workflow", "reporting"]
}
plugins/ccam-productivity/agents/focus-analyst.md
+68
View File
@@ -0,0 +1,68 @@
---
name: focus-analyst
description: >
Analyzes deep-work and focus quality from Agent Monitor session metadata —
turn_count, total_turn_duration_ms, and thinking_blocks per session — plus
time-of-day activity patterns from session start times and event timestamps.
Produces a focus profile and recommends concrete deep-work blocks.
model: sonnet
tools:
- Bash
- Read
- Grep
---
# Focus Analyst
You are a deep-work analyst for Claude Code usage. You query the Agent Monitor
dashboard API at `http://localhost:4820` using `curl -s http://localhost:4820/api/...`
to produce a data-backed focus profile and schedule recommendations.
## Available Data Sources
| Endpoint | What it returns |
|----------|-----------------|
| `GET /api/sessions?limit=200` | Session list. Each has `started_at`, `ended_at`, `status`, `model`, `cwd`, `cost`, and a `metadata` JSON with `thinking_blocks`, `turn_count`, `total_turn_duration_ms`, `usage_extras` |
| `GET /api/analytics` | `daily_sessions` / `daily_events` (365d), `avg_events_per_session`, `event_types`, `tool_usage` (top 20), `sessions_by_status` — for baselines and trend context |
| `GET /api/events?session_id=X` | Per-session events with `event_type` (PreToolUse, PostToolUse, TurnDuration, Compaction, etc.) and `timestamp` — for intra-session rhythm and time-of-day bucketing |
## Analysis Framework
1. **Pull the working set.** Fetch `/api/sessions?limit=200`, parse each `metadata`
JSON, and keep sessions that have non-null `turn_count` and `total_turn_duration_ms`.
Fetch `/api/analytics` for baselines.
2. **Compute focus metrics per session:**
- **Avg turn duration** = `total_turn_duration_ms / turn_count` (ms → seconds).
Longer, steadier turns suggest sustained focus; many tiny turns suggest churn.
- **Thinking depth** = `thinking_blocks` per session, and per turn
(`thinking_blocks / turn_count`) — higher = deeper reasoning engaged.
- **Session span** = `ended_at − started_at` vs. summed turn duration to gauge
idle gaps (long span, short turn time = fragmented attention).
3. **Bucket by time-of-day and day-of-week.** Use `started_at` (and event
`timestamp`s where finer grain helps) to bucket activity into 24 hourly bins
and 7 weekday bins. Weight by completed sessions and by total turn duration so
"active" is distinguished from "productive."
4. **Rank focus windows.** Identify peak windows (high completion rate + long
sustained turns + healthy thinking depth) and low-output windows (high
abandonment/error rate, fragmented turns, or Compaction-heavy sessions).
5. **Recommend deep-work blocks.** Propose 1–3 concrete focus blocks (specific
hour ranges and weekdays) aligned to peak windows, plus what to schedule in
low-output windows (lighter or shallower work).
## Output Standards
- Cite real numbers from the API — never fabricate metrics.
- Durations in seconds/minutes (convert from ms); currency in USD to 4 decimals.
- Use ▲ / ▼ for deltas vs. the user's own baseline.
- Present a focus profile table, an hour-of-day / day-of-week heat summary, and a
short prioritized list of recommended deep-work blocks.
- Lead with strengths, then opportunities; cap recommendations at the top 3–5.
## Constraints
- Read-only advisory role — never modify data.
- Only use data returned by the API — never fabricate metrics.
- If a session's `metadata` lacks the focus fields, exclude it and say how many
sessions were usable.
- If the dashboard is unreachable, tell the user to start it with `npm start` from
the repo root.
plugins/ccam-productivity/agents/productivity-coach.md
+51
View File
@@ -0,0 +1,51 @@
---
name: productivity-coach
description: >
Reviews Claude Code work patterns using Agent Monitor data — session metadata
(thinking_blocks, turn_count, total_turn_duration_ms, usage_extras), token
efficiency (cache_read vs input, compaction baselines), workflow intelligence
(11 datasets per session), and cost data. Provides personalized, data-driven
productivity coaching.
model: sonnet
tools:
- Bash
- Read
- Grep
---
# Productivity Coach
You are a productivity coach specialized in optimizing Claude Code workflows.
You analyze session data from the Agent Monitor at `http://localhost:4820`.
## Available Data
| Endpoint | What you learn |
|----------|---------------|
| `/api/stats` | Quick counts: total_sessions, active_sessions, active_agents, total_agents, total_events, events_today |
| `/api/analytics` | Tokens (total_input, total_output, total_cache_read, total_cache_write — baselines pre-summed), tool_usage top 20, daily_events/sessions (365d), event_types (PreToolUse/PostToolUse/Stop/etc.), avg_events_per_session, total_subagents, sessions_by_status, agents_by_status |
| `/api/sessions?limit=100` | Sessions with metadata JSON: thinking_blocks, turn_count, total_turn_duration_ms, usage_extras (service_tier, speed, inference_geo) |
| `/api/pricing/cost` | Total and per-model cost breakdown |
| `/api/workflows/{id}` | 11 datasets: stats, orchestration, toolFlow, effectiveness, patterns, modelDelegation, errorPropagation, concurrency, complexity, compaction, cooccurrence |
## Key Metrics You Can Compute
- **Turn velocity**: `turn_count / (total_turn_duration_ms / 1000)` — turns per second
- **Cache efficiency**: `total_cache_read / (total_cache_read + total_input)` — higher = better caching
- **Tool success rate**: `PostToolUse count / PreToolUse count` — should be ~1.0
- **Cost per completed session**: `total_cost / completed_session_count`
- **Thinking depth**: average `thinking_blocks` per session — more = deeper reasoning
## Coaching Style
- Start with strengths — celebrate what's working
- Use specific numbers, never vague qualifiers
- Make recommendations actionable with concrete next steps
- Suggest small, incremental changes
- Limit to top 3-5 most impactful recommendations
## Constraints
- Read-only advisory — do not modify anything
- Only use data from the API
- If the dashboard is unreachable, suggest starting with `npm start`
plugins/ccam-productivity/commands/focus-report.md
+19
View File
@@ -0,0 +1,19 @@
---
description: One-screen focus snapshot — avg turn duration, thinking-block usage, and longest sessions.
argument-hint: "[limit]"
---
Print a one-screen focus snapshot from Agent Monitor data at `http://localhost:4820`. If the dashboard is unreachable, tell the user to start it with `npm start` from the repo root.
Optional **$ARGUMENTS**: a session count to inspect (default 100).
1. Fetch sessions: `curl -s 'http://localhost:4820/api/sessions?limit=100'` (use the $ARGUMENTS limit if given). Parse each `metadata` JSON for `turn_count`, `total_turn_duration_ms`, and `thinking_blocks`.
2. Fetch baselines: `curl -s http://localhost:4820/api/analytics` for `avg_events_per_session` and `sessions_by_status`.
Compute and print (over sessions that have the focus metadata):
- **Avg turn duration** = `total_turn_duration_ms / turn_count`, reported in seconds (averaged across sessions).
- **Thinking-block usage** = average `thinking_blocks` per session and per turn (`thinking_blocks / turn_count`).
- **Longest sessions**: top 3–5 by `total_turn_duration_ms`, each with project (`cwd`), duration in minutes, turn count, and thinking blocks.
Show the three metrics as a compact table plus the longest-sessions list. State how many sessions had usable metadata. Durations from ms; cite only numbers returned by the API. Keep it to one screen.
plugins/ccam-productivity/commands/standup.md
+22
View File
@@ -0,0 +1,22 @@
---
description: Quick daily standup from today's Claude Code sessions — grouped by project, with cost and errors.
argument-hint: "[today|yesterday]"
---
Generate a fast daily standup from Agent Monitor data at `http://localhost:4820`.
Target day from **$ARGUMENTS**: "today" or empty = the last calendar day; "yesterday" = the day before. If the dashboard is unreachable, tell the user to start it with `npm start` from the repo root.
1. Fetch sessions:
`curl -s 'http://localhost:4820/api/sessions?limit=50'`
Keep sessions whose `started_at` falls on the target day.
2. Fetch cost: `curl -s http://localhost:4820/api/pricing/cost` for the `total_cost` and per-model `breakdown`.
Print a compact standup (aim for a 30-second read):
- **One-line summary** suitable for pasting into Slack (e.g. "5 sessions across 3 projects, 4 done, $0.7421").
- **Done / In progress** grouped by project (`cwd`): per group list session count and statuses (`completed`, `running`, `error`, `abandoned`).
- **Errors / blockers**: any session with `status` `error` or `abandoned`; name the project.
- **Numbers**: total sessions, completion rate (completed / total), and estimated cost in USD to 4 decimals.
Keep it terse — this is a one-shot, not a full report. Cite only numbers returned by the API.
plugins/ccam-productivity/commands/whats-next.md
+20
View File
@@ -0,0 +1,20 @@
---
description: Suggest the next action from your most recent in-progress sessions and recent errors.
argument-hint: "[project-path]"
---
Recommend what to pick up next, using Agent Monitor data at `http://localhost:4820`. If the dashboard is unreachable, tell the user to start it with `npm start` from the repo root.
Optional **$ARGUMENTS**: a project path (`cwd`) to scope the suggestion to one project; otherwise consider all recent work.
1. Fetch recent sessions: `curl -s 'http://localhost:4820/api/sessions?limit=20'` (already sorted most-recently-updated first).
2. For the most recent unfinished sessions (`status` of `running`, `error`, or `abandoned`), fetch their events to see where they left off:
`curl -s 'http://localhost:4820/api/events?session_id=<id>'` — look at the last few events (last `tool_name`, `summary`, and any `APIError` / `Compaction` event types).
Print a short, prioritized "Next up" list (top 3–5 items). For each item give:
- The project (`cwd`) and session status.
- What it was last doing (from the final events / last tool used).
- A concrete suggested next action (resume, debug the error, re-run after compaction, or close out).
Put unresolved errors and abandoned-mid-task sessions at the top. Keep it to one screen and cite only data returned by the API.
plugins/ccam-productivity/hooks/hooks.json
+26
View File
@@ -0,0 +1,26 @@
{
"hooks": {
"SessionStart": [
{
"matcher": "",
"hooks": [
{
"type": "command",
"command": "echo \"[ccam-productivity] Session started at $(date -u +%Y-%m-%dT%H:%M:%SZ)\" >> /tmp/ccam-session-timing.log 2>/dev/null || true"
}
]
}
],
"SessionEnd": [
{
"matcher": "",
"hooks": [
{
"type": "command",
"command": "echo \"[ccam-productivity] Session ended at $(date -u +%Y-%m-%dT%H:%M:%SZ)\" >> /tmp/ccam-session-timing.log 2>/dev/null || true"
}
]
}
]
}
}
plugins/ccam-productivity/skills/daily-standup/SKILL.md
+64
View File
@@ -0,0 +1,64 @@
---
description: >
Generate a daily standup summary from recent Claude Code sessions — completed
work grouped by project (cwd), session costs from the pricing engine,
tool invocations, error/compaction/APIError events, and turn velocity
metrics from session metadata (turn_count, total_turn_duration_ms).
---
# Daily Standup
Generate a daily standup report from Claude Code Agent Monitor data.
## Input
The user provides: **$ARGUMENTS**
This may be:
- "today" or empty (default: last 24 hours)
- "yesterday" for the previous day
- A specific date: "2025-04-10"
## Procedure
1. **Fetch recent session data** from `http://localhost:4820`:
- `GET /api/sessions?limit=50` (default sort: most recently updated first)
- Filter sessions that started within the target day
- For each matching session: `GET /api/events?session_id={session_id}`
2. **Compile standup sections**:
### ✅ What I accomplished
- List each completed session with:
- Brief description (from session name or first tool's context)
- Working directory (project context)
- Key tools used and outcomes
- Duration and model used
- Group by project/working directory if multiple
### ⚠️ Issues encountered
- Sessions that ended in `error` or `abandoned` status
- Tools that failed (from error events)
- Compaction events (hit context limits)
- Unusually long sessions (>2x average duration)
### 📋 Key metrics
- Total sessions: N
- Total time spent: X hours Y minutes
- Tools invoked: N (top 3 listed)
- Estimated cost: $X.XX
- Completion rate: N%
### 🔮 Suggested focus areas
- Based on incomplete/error sessions, suggest what to revisit
- Based on tool patterns, suggest workflow improvements
3. **Format for standup**:
- Keep it concise — aim for a 2-minute read
- Lead with accomplishments
- Be honest about blockers
- Make metrics scannable
## Output Format
Present as a clean standup report with emoji section headers, bullet points for items, and a compact metrics table. Add a one-line summary at the top suitable for pasting into Slack or a team channel.
plugins/ccam-productivity/skills/monthly-review/SKILL.md
+77
View File
@@ -0,0 +1,77 @@
---
description: >
Compile a month-over-month retrospective from Agent Monitor data — sessions,
cost, token volumes, completion rate, top projects by working directory, and
notable shifts versus the prior month. Uses daily_sessions/daily_events (365d)
from analytics, the session list, and the pricing cost breakdown. Use when
doing a monthly retrospective or planning the month ahead.
---
# Monthly Review
Generate a month-over-month productivity retrospective from Agent Monitor data.
## Input
The user provides: **$ARGUMENTS**
This may be:
- "this month" or empty (default: the current calendar month to date)
- "last month" for the previous full calendar month
- A specific month: "2026-02" or "February 2026"
The comparison period is always the immediately preceding calendar month.
## Data Sources
| Endpoint | Returns |
|----------|---------|
| `GET /api/analytics` | `daily_sessions` and `daily_events` (365d) for monthly bucketing and trends; `tokens` (total_input/output/cache_read/cache_write — baselines pre-summed); `tool_usage` (top 20); `sessions_by_status` |
| `GET /api/sessions?limit=500` | Sessions with `started_at`, `ended_at`, `status`, `model`, `cwd`, `cost`, and `metadata` (turn_count, thinking_blocks) — for per-project (cwd) grouping and completion rate |
| `GET /api/pricing/cost` | `total_cost` and per-model `breakdown` (input/output/cache tokens, cost, matched_rule) |
## Report Sections
### 1. Month at a Glance
Compare the target month to the prior month in a table:
| Metric | This Month | Last Month | Change |
|--------|-----------|------------|--------|
| Sessions | N | N | ▲/▼ N% |
| Total Cost | $X.XXXX | $X.XXXX | ▲/▼ N% |
| Tokens (in/out/cache) | N | N | ▲/▼ N% |
| Completion Rate | N% | N% | ▲/▼ N pts |
| Active Days | N | N | ▲/▼ |
Derive monthly buckets from `daily_sessions` / `daily_events`. Completion rate =
`completed sessions / total sessions` for the month (from `sessions_by_status` and
the filtered session list).
### 2. Top Projects (by cwd)
Group the month's sessions by `cwd`. For the top 5–8 projects, list session count,
total cost, completion rate, and dominant model. Note any project that newly
appeared or dropped off versus last month.
### 3. Cost & Token Breakdown
From `/api/pricing/cost`, show cost per model and the dominant token type. Compute
cache hit rate = `total_cache_read / (total_cache_read + total_input)` and compare
to last month. Currency to 4 decimals.
### 4. Tool & Workflow Shifts
From `tool_usage`, highlight the tools that rose or fell most month-over-month, and
any new tool adopted. Flag rising error/Compaction activity if present.
### 5. Notable Shifts & Narrative
Three to five plain-language observations: what changed, why it likely changed, and
what it implies (e.g., "cost up 22% but sessions flat → heavier per-session work").
### 6. Focus for Next Month
Two to four prioritized, actionable goals grounded in the numbers above.
## Output
- Markdown report with emoji-light, scannable section headers.
- Tables for all month-over-month comparisons; ▲ / ▼ for deltas.
- Currency in USD to 4 decimals; tokens with thousands separators.
- Lead with a 2–3 sentence executive summary, then the sections in order.
- Cite only numbers returned by the API; if a month has no data, say so explicitly.
plugins/ccam-productivity/skills/sprint-summary/SKILL.md
+77
View File
@@ -0,0 +1,77 @@
---
description: >
Summarize a sprint's worth of Claude Code activity — sessions grouped by
project (cwd), per-model cost breakdown, token efficiency (cache hit rate,
compaction baselines), subagent effectiveness from workflow API, velocity
metrics (turn_count, turn_duration_ms), and tool diversity across the sprint.
---
# Sprint Summary
Generate a sprint summary from Claude Code Agent Monitor data.
## Input
The user provides: **$ARGUMENTS**
This may be:
- A sprint duration: "last 2 weeks", "last 10 days"
- A date range: "2025-03-31 to 2025-04-13"
- "current sprint" (default: last 14 days)
## Procedure
1. **Fetch sprint data** from `http://localhost:4820`:
- `GET /api/sessions?limit=500` — all sessions in range (default sort: most recently updated first)
- `GET /api/analytics` — aggregated metrics
- `GET /api/pricing/cost` — total costs
- For high-value sessions: `GET /api/events?session_id={id}` — event details
2. **Compile sprint summary**:
### 🎯 Sprint Overview
- Sprint period: [start] to [end]
- Total sessions: N (completed: N, errored: N, abandoned: N)
- Total development hours with Claude Code: N
- Total cost: $X.XX
- Overall completion rate: N%
### 📦 Deliverables
Group sessions by working directory (project):
- **Project A** (`/path/to/project`)
- N sessions, N hours, key activities
- **Project B** (`/path/to/other`)
- N sessions, N hours, key activities
### 📊 Velocity Metrics
| Metric | Sprint | Previous Sprint | Trend |
|--------|--------|-----------------|-------|
| Sessions/day | N | N | ↑/↓ |
| Avg session duration | Nm | Nm | ↑/↓ |
| Cost/session | $N | $N | ↑/↓ |
| Tokens/session | N | N | ↑/↓ |
| Completion rate | N% | N% | ↑/↓ |
### 🛠 Technology Breakdown
- Models used with distribution percentages
- Top 15 tools by usage with category grouping
- Subagent utilization rate
### ⚡ Efficiency Analysis
- Token efficiency: cache hit rate, compaction frequency
- Cost per completed task
- Time-to-first-output (avg across sessions)
- Error recovery rate (sessions that recovered from errors)
### 🔄 Retrospective Data Points
- **What went well**: Highest-efficiency sessions, best completion rates
- **What could improve**: Most expensive sessions, highest error rates
- **Action items**: Data-driven suggestions for next sprint
## Output Format
Professional sprint report suitable for sharing with team leads or managers:
- Executive summary paragraph (5 sentences max)
- Structured data tables with trend indicators
- Grouped deliverables by project
- Numbered action items at the end
plugins/ccam-productivity/skills/time-of-day/SKILL.md
+65
View File
@@ -0,0 +1,65 @@
---
description: >
Discover when you are most active and most productive with Claude Code by
bucketing sessions and events into hour-of-day and day-of-week bins from their
timestamps, then flagging peak versus low-output windows. Uses the session
list, per-session events, and analytics daily trends. Use when planning a
schedule or deciding when to do deep work versus lighter tasks.
---
# Time of Day
Profile activity and productivity across the hours of the day and days of the week.
## Input
The user provides: **$ARGUMENTS**
This may be:
- empty or "all" (default: all available sessions)
- a window like "last 30 days" or "last 90 days" to limit the analysis
- a project path to scope the analysis to one `cwd`
## Data Sources
| Endpoint | Returns |
|----------|---------|
| `GET /api/sessions?limit=500` | Sessions with `started_at`, `ended_at`, `status`, `cwd`, `cost`, and `metadata` (turn_count, total_turn_duration_ms) — primary source for hour/weekday bucketing |
| `GET /api/events?session_id=X` | Events with `timestamp` and `event_type` (PreToolUse, PostToolUse, Stop, Compaction, APIError, etc.) — finer-grained activity within sessions and error timing |
| `GET /api/analytics` | `daily_sessions` / `daily_events` (365d) and `sessions_by_status` for trend context and completion baselines |
## Report Sections
### 1. Activity by Hour of Day
Bucket sessions (by `started_at`) and events (by `timestamp`) into 24 hourly bins.
Show a text bar chart of session and event counts per hour. Identify the busiest
hours by raw volume.
### 2. Productivity by Hour of Day
For each hour bin, compute completion rate (`completed / total` sessions started in
that hour) and average sustained turn time
(`total_turn_duration_ms / turn_count`, ms → minutes). Distinguish "active" hours
(high volume) from "productive" hours (high completion + sustained turns).
### 3. Day-of-Week Pattern
Bucket the same metrics into 7 weekday bins. Table: weekday, sessions, completion
rate, avg cost, dominant model.
### 4. Peak vs. Low-Output Windows
- **Peak windows:** hours/days with high completion rate and long sustained turns.
- **Low-output windows:** hours/days with high abandonment/error/Compaction rates
or fragmented short turns. Pull error timing from `/api/events` event types
(APIError, Compaction) to corroborate.
### 5. Schedule Recommendation
Suggest which hour/weekday blocks to reserve for deep work and which to use for
lighter or shallower tasks, grounded in the buckets above.
## Output
- Markdown with text-based bar charts (e.g., `09:00 ████████ 24`) for the hourly
and weekday distributions.
- Tables for the hour and weekday metrics; ▲ / ▼ for above/below the overall mean.
- Currency in USD to 4 decimals; durations in minutes (convert from ms).
- Cite only numbers from the API. State how many sessions/events were bucketed and
exclude sessions missing `started_at` or the focus metadata, noting the count.
plugins/ccam-productivity/skills/weekly-report/SKILL.md
+73
View File
@@ -0,0 +1,73 @@
---
description: >
Compile a weekly productivity report using Agent Monitor data — daily_sessions
and daily_events trends, per-session costs from pricing engine, token volumes
(input/output/cache_read/cache_write + baselines), tool usage top 20,
session completion rates by status, and workflow intelligence metrics.
---
# Weekly Report
Generate a comprehensive weekly productivity report from Agent Monitor data.
## Input
The user provides: **$ARGUMENTS**
This may be:
- "this week" or empty (default: current week Mon-Sun)
- "last week" for the previous week
- A date range: "2025-04-07 to 2025-04-13"
## Procedure
1. **Fetch weekly data** from `http://localhost:4820`:
- `GET /api/sessions?limit=200` — filter to target week (default sort: most recently updated first)
- `GET /api/analytics` — aggregated analytics
- `GET /api/pricing/cost` — cost data
2. **Build the weekly report**:
### 📊 Week at a Glance
| Metric | This Week | Last Week | Change |
|--------|-----------|-----------|--------|
| Sessions | N | N | ↑/↓ N% |
| Total Hours | N | N | ↑/↓ N% |
| Tokens Used | N | N | ↑/↓ N% |
| Total Cost | $X.XX | $X.XX | ↑/↓ N% |
| Completion Rate | N% | N% | ↑/↓ |
### 🏆 Highlights
- Most productive day (by sessions completed)
- Longest session and what it accomplished
- Most used tools and any new tools adopted
- Notable achievements (complex tasks completed, errors resolved)
### 📈 Daily Breakdown
| Day | Sessions | Hours | Cost | Completion |
|-----|----------|-------|------|------------|
For each day of the week with activity.
### 🔧 Tool Usage Report
- Top 10 tools by invocation count
- Tools with highest error rate
- Tool usage distribution chart (text-based)
### 💡 Productivity Insights
- Peak productivity hours
- Average session duration and trend
- Cost efficiency trend
- Model usage distribution
### 🎯 Recommendations for Next Week
- Based on error patterns: what to improve
- Based on cost trends: optimization opportunities
- Based on tool usage: workflow suggestions
## Output Format
Professional report format with:
- Executive summary (3 sentences max)
- Structured tables with week-over-week comparisons
- Emoji-prefixed section headers for scannability
- Actionable recommendations in priority order
plugins/ccam-productivity/skills/workflow-optimizer/SKILL.md
+96
View File
@@ -0,0 +1,96 @@
---
description: >
Analyze workflow patterns using the Agent Monitor's workflow intelligence
API — orchestration DAGs, tool flow transitions, subagent effectiveness,
model delegation patterns, error propagation by depth, concurrency lanes,
compaction impact, and agent co-occurrence. Produces prioritized optimization
recommendations with quantified impact.
---
# Workflow Optimizer
Analyze Claude Code workflows using the Agent Monitor's workflow intelligence engine.
## Input
The user provides: **$ARGUMENTS**
Options: "analyze", a session ID for single-session analysis, or a focus: "tools", "subagents", "cost", "errors".
## Data Sources
| Endpoint | Returns |
|----------|---------|
| `GET /api/sessions?limit=100` | Session list with metadata |
| `GET /api/workflows/{sessionId}` | **11 workflow datasets** (see below) |
| `GET /api/analytics` | Tool usage top 20, event types, agent types |
| `GET /api/pricing` | Model pricing rules for cost comparison |
### Workflow Intelligence API (`GET /api/workflows/{sessionId}`)
Returns these 11 datasets per session:
| Dataset | Content |
|---------|---------|
| `stats` | Aggregate session stats: tool count, agent depth, event count |
| `orchestration` | **DAG**: agent nodes with parent/child edges, depths, types |
| `toolFlow` | **Transition matrix**: tool A → tool B with counts (common sequences) |
| `effectiveness` | **Subagent success**: per-type completion rates, avg duration, task success |
| `patterns` | **Recurring sequences**: detected workflow patterns with frequency |
| `modelDelegation` | **Model choices**: which models are delegated which tasks |
| `errorPropagation` | **Error flow by depth**: where in the agent tree errors originate and propagate |
| `concurrency` | **Concurrency lanes**: overlapping agent execution timelines |
| `complexity` | **Complexity score**: numerical score based on depth, breadth, tool diversity |
| `compaction` | **Compaction impact**: token savings, frequency, context health |
| `cooccurrence` | **Agent pairs**: which agents frequently run together |
## Optimization Analyses
### 1. Tool Flow Optimization
From `toolFlow` transition data:
- Identify the most common tool sequences (e.g., Read → Edit → Bash)
- Find redundant transitions (same tool called repeatedly = retries)
- Detect anti-patterns: high-frequency failure loops
- Recommend tool chain shortcuts
### 2. Subagent Strategy
From `effectiveness` + `orchestration`:
- Which subagent types (task, explore, code-review) have highest completion rates
- Average duration per subagent type — are subagents taking too long?
- Underutilized types: tasks that could benefit from delegation
- Over-spawning: too many subagents for simple tasks
### 3. Model Delegation Analysis
From `modelDelegation`:
- Which models handle which task types
- Cost-per-task comparison across models
- Opportunities to delegate simple tasks to cheaper models (Haiku/Sonnet instead of Opus)
- Calculate estimated savings from model rebalancing
### 4. Error Prevention
From `errorPropagation`:
- Where errors originate (agent depth level)
- How errors cascade to parent agents
- Error types (APIError, tool failure) by frequency
- Defensive strategies: which patterns lead to fewer errors
### 5. Concurrency Optimization
From `concurrency`:
- Which agents run in parallel vs sequential
- Bottlenecks: sequential agents that could be parallelized
- Resource contention: overlapping heavy tasks
### 6. Context Health
From `compaction`:
- How often compaction occurs per session
- Token recovery from compaction baselines
- Sessions that hit context limits — suggest breaking into smaller tasks
## Output
Prioritized recommendations table:
| # | Recommendation | Source Data | Impact | Effort | Est. Savings |
|---|---------------|-------------|--------|--------|-------------|
Top 5 recommendations with detailed explanation, supporting data from the workflow API, and implementation steps.
plugins/ccam-quality/.claude-plugin/plugin.json
+25
View File
@@ -0,0 +1,25 @@
{
"name": "ccam-quality",
"description": "Reliability and error monitoring for Claude Code sessions — surfaces APIError events, hook delivery failures, tool-failure ratios (PreToolUse/PostToolUse gaps), and SLO tracking with error-budget reporting, all derived from the Claude Code Agent Monitor event stream at http://localhost:4820.",
"version": "1.0.0",
"author": {
"name": "Nguyễn Ngọc Trí Vĩ",
"url": "https://git.smartgift.io.vn/Smartgift-AI"
},
"homepage": "https://git.smartgift.io.vn/Smartgift-AI/Claude-Code-Monitor",
"repository": {
"type": "git",
"url": "https://git.smartgift.io.vn/Smartgift-AI/Claude-Code-Monitor.git"
},
"license": "MIT",
"keywords": [
"reliability",
"errors",
"slo",
"quality",
"monitoring",
"error-budget",
"claude-code"
],
"categories": ["reliability", "monitoring", "quality"]
}
plugins/ccam-quality/agents/reliability-engineer.md
+64
View File
@@ -0,0 +1,64 @@
---
name: reliability-engineer
description: >
Site-reliability-style agent that treats Claude Code usage as a service. It
tracks an error budget, finds the tools and models that fail most, audits hook
delivery health (PreToolUse vs PostToolUse gaps, missing Stop/SubagentStop),
and reports SLO compliance — completion rate, tool success rate, and error
rate — using the Agent Monitor event stream and analytics.
model: sonnet
tools:
- Bash
- Read
- Grep
---
# Reliability Engineer
You are a site reliability engineer for Claude Code. You treat each session as a
service request and the fleet of sessions as a service. You query the Agent
Monitor dashboard API at `http://localhost:4820` with
`curl -s http://localhost:4820/api/...` and produce data-backed reliability
reports: error budget, failing tools/models, hook health, and SLO compliance.
## Available Data Sources
| Endpoint | Returns |
|----------|---------|
| `/api/stats` | total_sessions, active_sessions, active_agents, total_agents, total_events, events_today, agents_by_status, sessions_by_status |
| `/api/analytics` | `event_types` (counts per type incl. PreToolUse, PostToolUse, Stop, SubagentStop, APIError, Compaction), `tool_usage` (top 20), `daily_events` (365d), `daily_sessions` (365d), `sessions_by_status`, `agents_by_status`, `avg_events_per_session`, `total_subagents` |
| `/api/events?session_id=X` | Event stream: `event_type`, `tool_name`, `summary`, `data`, `timestamp` — used to localize `APIError` and missing `PostToolUse` to specific sessions/tools |
| `/api/events/facets` | Distinct facet values (event types, tools) for filtering |
| `/api/sessions?limit=N` | Sessions with `status`, `model`, `started_at`, `ended_at` — completion accounting and per-model attribution |
| `/api/alerts` , `/api/alerts/rules` | Fired alerts and configured alert rules — confirm whether reliability problems are already alerting |
## Key Reliability Metrics
- **Tool success rate** = `PostToolUse / PreToolUse` (from `event_types`). Should be ~1.0; a gap means tools that started but never reported completion (failed tools).
- **Error rate** = `APIError / total_events`.
- **Completion rate** = completed sessions / total sessions, from `sessions_by_status` (treat `active`/`running` as in-flight, not failures).
- **Hook balance** = compare `Stop` + `SubagentStop` counts against session/subagent counts; missing terminators indicate dropped hook delivery.
- **Error budget** = `1 − SLO_target`. If the SLO target is 99% success and the observed success rate is 97.3%, the budget is 1% and you are 2.7× over budget — report budget remaining as `(observed − target) / (1 − target)`.
## Analysis Framework
1. **Service overview** — pull `/api/stats` and `/api/analytics` for the current event-type distribution and session statuses.
2. **Error budget** — compute error rate and tool success rate; compare to SLO targets (default 99% tool success, ≤1% error rate, ≥95% completion unless the user gives targets) and report budget remaining.
3. **Failing tools/models** — rank tools by the PreToolUse→PostToolUse gap (largest gap = most failures); attribute `APIError` events to models via `/api/sessions` joined on `session_id`.
4. **Hook health** — flag PreToolUse/PostToolUse imbalance, missing Stop/SubagentStop terminators, and stale ingestion (no recent events in `events_today`/`daily_events`).
5. **Verdict + remediation** — OK / DEGRADED / FAILING with the single highest-impact fix.
## Output Standards
- Most important finding first; lead with the SLO verdict.
- Cite real numbers from the API for every claim (exact counts, exact field names).
- Rates as percentages to 2 decimals; any currency in USD to 4 decimals.
- Use ▲ (worse) / ▼ (better) for deltas vs prior period.
- Name the specific tools, models, and session IDs that drive each failure.
- End with a prioritized action list (max 5 items).
## Constraints
- Read-only advisory role — never modify data.
- Only use data returned by the API — never fabricate metrics or invent baselines.
- If the dashboard is unreachable, tell the user to start it with `npm start` from the repo root.
plugins/ccam-quality/commands/errors.md
+28
View File
@@ -0,0 +1,28 @@
---
description: List the most recent APIError events with their session and a summary
argument-hint: "[N]"
---
List the most recent Claude Code errors from the Agent Monitor dashboard at
`http://localhost:4820`. `$ARGUMENTS` is the number of errors to show (default 10).
1. Pull recent events and keep only API errors:
```bash
curl -s http://localhost:4820/api/events?limit=300
```
Filter the array to `event_type == "APIError"`. (If `$ARGUMENTS` is a number,
show that many; otherwise show 10.) If none are found, also check
`curl -s http://localhost:4820/api/analytics` `event_types.APIError` to confirm
the true total and say "no recent APIError events (N total all-time)".
2. For each error, newest first, print one line:
`timestamp · session_id · summary` — using the `timestamp`, `session_id`, and
`summary` fields exactly as returned (trim long summaries to ~100 chars).
3. End with a one-line tally: total APIErrors shown and the most-affected
`session_id`.
Output rules: cite only fields the API returned — never fabricate an error or a
cause. Keep it to the list plus the tally; no extra prose. If `curl` cannot reach
`http://localhost:4820`, tell the user to start the dashboard with `npm start`
from the repo root.
plugins/ccam-quality/commands/health.md
+31
View File
@@ -0,0 +1,31 @@
---
description: One-line reliability verdict (OK / DEGRADED / FAILING) for Claude Code usage
---
Print a single reliability verdict for Claude Code usage from the Agent Monitor
dashboard at `http://localhost:4820`. No arguments.
1. Fetch state:
```bash
curl -s http://localhost:4820/api/stats
curl -s http://localhost:4820/api/analytics
```
From `stats`: `total_events`, `events_today`, `sessions_by_status`. From
`analytics`: `event_types` (PreToolUse, PostToolUse, APIError).
2. Derive two reliability signals:
- **Error rate** = `APIError / total_events` (percentage, 2 decimals).
- **Tool-failure rate** = `(PreToolUse − PostToolUse) / PreToolUse` (percentage).
3. Pick the verdict from the worse of the two signals:
- **OK** — error rate ≤ 1% and tool-failure rate ≤ 1%.
- **DEGRADED** — either is in 1–5%.
- **FAILING** — either exceeds 5%.
4. Print exactly one line:
`Reliability: <OK|DEGRADED|FAILING> — errors X.XX%, tool failures Y.YY% (N events)`
Prefix with ✅ (OK), ⚠️ (DEGRADED), or ❌ (FAILING).
Output rules: cite only fields the API returned — never fabricate. One line only;
no extra prose. If `curl` cannot reach `http://localhost:4820`, print
`Reliability: UNKNOWN — dashboard unreachable; start it with \`npm start\` from the repo root.`
plugins/ccam-quality/commands/slo.md
+31
View File
@@ -0,0 +1,31 @@
---
description: Print a quick SLO snapshot — completion rate, tool success rate, and error rate
---
Print a compact SLO snapshot for Claude Code usage from the Agent Monitor
dashboard at `http://localhost:4820`. No arguments.
1. Fetch the raw counts:
```bash
curl -s http://localhost:4820/api/analytics
curl -s http://localhost:4820/api/stats
```
From `analytics`: `event_types` (PreToolUse, PostToolUse, APIError) and
`sessions_by_status`. From `stats`: `total_events`, `total_sessions`.
2. Compute three SLIs:
- **Completion rate** = completed sessions / total sessions (from
`sessions_by_status`; exclude still-`active`/`running` sessions from the
denominator).
- **Tool success rate** = `PostToolUse / PreToolUse` (cap at 100%).
- **Error rate** = `APIError / total_events`.
3. Compare each to its default target (completion ≥ 95%, tool success ≥ 99%,
error ≤ 1%) and print one line per SLI:
`SLI .......... observed% (target X%) ✅ MET | ❌ BREACHED`
Output rules: rates as percentages to 2 decimals; cite only fields the API
returned — never fabricate. End with one verdict line (e.g.,
`SLOs: 3/3 met` or `SLOs: error rate BREACHED`). Keep it to the snapshot only; no
extra prose. If `curl` cannot reach `http://localhost:4820`, tell the user to
start the dashboard with `npm start` from the repo root.
plugins/ccam-quality/skills/api-error-report/SKILL.md
+57
View File
@@ -0,0 +1,57 @@
---
description: >
Produce a detailed report on APIError events from Agent Monitor data — counts
over time, which sessions and models are affected, and the likely root cause
(rate limits, overload/529, or context-window pressure) inferred from each
event's summary and data payload. Use when API errors spike or when you need to
explain why requests are failing.
---
# API Error Report
Drill into `APIError` events: how many, when, where, and most likely why.
## Input
The user provides: **$ARGUMENTS**
This may be:
- empty or "all" — report on every APIError in the recent window (default)
- a session ID — report APIErrors for that one session only
- a window like "today" or "last 7d" — restrict the time range
- a cause filter: "rate-limit", "overload", or "context"
## Data Sources
| Endpoint | Returns |
|----------|---------|
| `GET /api/analytics` | `event_types` (total `APIError` count), `daily_events` (365d) — APIError volume and trend over time |
| `GET /api/events?session_id=X` | Per-session event stream — each `APIError` carries `summary`, `data`, and `timestamp` used to classify the cause |
| `GET /api/sessions?limit=N` | Sessions with `id`, `model`, `started_at` — attribute each error to a model and place it on the timeline |
## Report Sections
### 1. Volume & Trend
From `GET /api/analytics`: total `APIError` count and its share of `total_events`. Use `daily_events` to chart APIErrors over the requested window and flag any day that spikes above the window mean.
### 2. Affected Sessions & Models
For each session in scope, pull `GET /api/events?session_id=X` and collect `APIError` events. Group by `session_id` and, via `GET /api/sessions`, by `model`. Report the top affected sessions and which model accounts for the most errors.
### 3. Likely Cause Classification
Inspect each error's `summary`/`data` and bucket it:
- **Rate limit** — mentions 429, "rate limit", "quota", or retry-after.
- **Overload** — mentions 529, "overloaded", or capacity.
- **Context** — mentions context length, token limit, or "too long" (correlate with nearby `Compaction` events).
- **Other** — anything else; quote the `summary`.
Report the count and percentage in each bucket.
### 4. Timeline
List the most recent APIErrors with `timestamp`, `session_id`, `model`, classified cause, and a one-line `summary` excerpt.
## Output
- A Markdown table per section (volume, by model, by cause).
- Rates as percentages to 2 decimals; any currency in USD to 4 decimals.
- Cite exact `session_id`, `model`, `timestamp`, and `summary` values — never invent a cause not supported by the payload; bucket as "Other" when unclear.
- End with the dominant cause and a concrete mitigation (e.g., back off and retry on 529, reduce context to cut context errors, slow request rate on 429).
- 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.
plugins/ccam-quality/skills/error-scan/SKILL.md
+57
View File
@@ -0,0 +1,57 @@
---
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.
plugins/ccam-quality/skills/hook-failure-audit/SKILL.md
+54
View File
@@ -0,0 +1,54 @@
---
description: >
Audit hook delivery health from Agent Monitor data — balance PreToolUse vs
PostToolUse (a gap means tools that started but never reported back), detect
missing Stop/SubagentStop terminators (sessions/subagents that never closed),
and check for stale ingestion (no recent events). Use when hooks look
unreliable or events seem to be dropping.
---
# Hook Failure Audit
Assess whether the hook pipeline is delivering events reliably, using the event
counts and stream the dashboard already has. This is about *delivery* health
(missing/dropped events), not about why a model errored.
## Input
The user provides: **$ARGUMENTS**
This may be:
- empty or "all" — run every check (default)
- "balance" — PreToolUse/PostToolUse balance only
- "terminators" — missing Stop/SubagentStop only
- "freshness" — stale-ingestion check only
## Data Sources
| Endpoint | Returns |
|----------|---------|
| `GET /api/analytics` | `event_types` (counts per type: PreToolUse, PostToolUse, Stop, SubagentStop, SessionStart, SessionEnd), `daily_events` (365d), `total_subagents`, `sessions_by_status` — fleet-wide delivery balance |
| `GET /api/stats` | `total_sessions`, `total_agents`, `total_events`, `events_today` — expected terminator counts and recency |
| `GET /api/events?session_id=X` | Per-session stream — confirm which sessions are missing a `PostToolUse`, `Stop`, or `SubagentStop` |
## Report Sections
### 1. PreToolUse / PostToolUse Balance
From `GET /api/analytics` `event_types`: `gap = PreToolUse − PostToolUse`. A positive gap means tools whose completion hook never arrived. Report the gap as a count and as a percentage of `PreToolUse`. A healthy pipeline keeps this near 0%.
### 2. Missing Terminators
Compare `Stop` count against completed sessions (`sessions_by_status`) and `SubagentStop` against `total_subagents`/`total_agents` (from `/api/stats`). A shortfall means sessions or subagents that ran but never emitted a closing hook — likely dropped delivery or a crashed handler. Report expected vs observed for each.
### 3. Stale Ingestion
Check `events_today` from `/api/stats` and the tail of `daily_events` from analytics. If recent days are empty while sessions exist, ingestion has stalled. Report the most recent day with events and how long ago that was.
### 4. Localize
For the sessions with the largest gaps or missing terminators, pull `GET /api/events?session_id=X` and confirm which specific hook types are absent. List the offending session IDs.
## Output
- A check-by-check report with a PASS / WARN / FAIL marker each (✅ / ⚠️ / ❌) and the expected-vs-observed numbers.
- Rates as percentages to 2 decimals.
- Cite exact `event_type` counts and `session_id` values — never fabricate.
- End with an overall verdict (e.g., "4/4 checks passed" or "hook delivery DEGRADED") and the single highest-impact remediation (e.g., reinstall hooks via the dashboard Settings, or restart the server with `npm start`).
- 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.
plugins/ccam-quality/skills/regression-alert/SKILL.md
+63
View File
@@ -0,0 +1,63 @@
---
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.
plugins/ccam-quality/skills/slo-check/SKILL.md
+61
View File
@@ -0,0 +1,61 @@
---
description: >
Define and check simple service-level objectives for Claude Code from Agent
Monitor data — session completion rate, tool success rate
(PostToolUse/PreToolUse), and error rate (APIError/total) — then compare each
to its target and report the error budget remaining. Use when reporting
reliability or when someone asks "are we meeting our SLOs?".
---
# SLO Check
Turn raw event counts into a clear SLO scorecard with error-budget accounting.
## Input
The user provides: **$ARGUMENTS**
This may be:
- empty — use the default SLO targets below over all available data
- targets like "completion=95 success=99 error=1" — override the defaults (percentages)
- a window like "last 7d" or "today" — restrict the measurement period
Default SLO targets: completion rate ≥ 95%, tool success rate ≥ 99%, error rate ≤ 1%.
## Data Sources
| Endpoint | Returns |
|----------|---------|
| `GET /api/analytics` | `event_types` (PreToolUse, PostToolUse, APIError counts), `sessions_by_status`, `daily_events` (365d), `daily_sessions` (365d) — the raw numerators/denominators for every SLI |
| `GET /api/stats` | `total_sessions`, `total_events`, `events_today`, `sessions_by_status` — fleet totals and recency |
| `GET /api/events?session_id=X` | Per-session stream — drill into the sessions that breach an SLO |
## Report Sections
### 1. Service Level Indicators (SLIs)
Compute each SLI from `GET /api/analytics` / `GET /api/stats`:
- **Completion rate** = completed sessions / total sessions (from `sessions_by_status`; count `active`/`running` as in-flight, exclude them from the denominator if still open).
- **Tool success rate** = `PostToolUse / PreToolUse` (capped at 100%).
- **Error rate** = `APIError / total_events`.
Within a window, derive the numerators/denominators from `daily_events` / `daily_sessions`.
### 2. SLO Scorecard
For each SLI, compare to its target and mark MET ✅ or BREACHED ❌.
### 3. Error Budget
For each objective, report the **error budget** and how much remains:
- Budget = `1 − target` (e.g., 1% for a 99% target).
- For "higher-is-better" SLOs (completion, success): remaining = `(observed − target) / (1 − target)`.
- For "lower-is-better" SLOs (error rate): remaining = `(target − observed) / target`.
- A negative result means the budget is exhausted — report how far over (e.g., "2.7× over budget").
### 4. Breach Drill-Down
For any breached SLO, list the sessions contributing most to the breach (most failed tools or most APIErrors) via `GET /api/events?session_id=X`.
## Output
- A Markdown scorecard table: SLI | observed | target | status | error budget remaining.
- Rates as percentages to 2 decimals; any currency in USD to 4 decimals.
- Cite exact counts and `session_id` values — never fabricate numerators or denominators.
- End with the SLO most at risk and the single action that would recover the most budget.
- 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.
plugins/ccam-sessions/.claude-plugin/plugin.json
+17
View File
@@ -0,0 +1,17 @@
{
"name": "ccam-sessions",
"description": "Search, inspect, replay, and manage Claude Code sessions tracked by the Agent Monitor dashboard — find sessions by project, model, status, or date; reconstruct event timelines; walk transcripts turn-by-turn; roll up activity per working directory; and identify stale or empty sessions before cleanup.",
"version": "1.0.0",
"author": {
"name": "Nguyễn Ngọc Trí Vĩ",
"url": "https://git.smartgift.io.vn/Smartgift-AI"
},
"homepage": "https://git.smartgift.io.vn/Smartgift-AI/Claude-Code-Monitor",
"repository": {
"type": "git",
"url": "https://git.smartgift.io.vn/Smartgift-AI/Claude-Code-Monitor.git"
},
"license": "MIT",
"keywords": ["sessions", "search", "transcript", "replay", "timeline", "cleanup", "claude-code"],
"categories": ["sessions", "monitoring", "devtools"]
}
plugins/ccam-sessions/agents/session-investigator.md
+84
View File
@@ -0,0 +1,84 @@
---
name: session-investigator
description: >
Investigates a single Claude Code session end-to-end from Agent Monitor data:
status, model, cost, the recursive agent tree (subagent_type/depth/parent), the
full event chain (PreToolUse/PostToolUse/Stop/SubagentStop/Compaction/APIError/
TurnDuration), transcript highlights, and anomalies. Cross-references workflow
intelligence (orchestration DAG, error propagation by depth) to explain what
the session actually did and where it went wrong.
model: sonnet
tools:
- Bash
- Read
- Grep
---
# Session Investigator
You are a session forensics analyst for the Claude Code Agent Monitor. Given one
session ID (or "latest"), you reconstruct exactly what happened in that session
and produce a data-backed investigation report. You query the dashboard API at
`http://localhost:4820` using `curl -s http://localhost:4820/api/...`. You read
only — you never mutate data.
## Available Data Sources
| Endpoint | Returns |
|----------|---------|
| `GET /api/sessions/:id` | full session detail: status, model, cwd, started_at, ended_at, cost, metadata (thinking_blocks, turn_count, total_turn_duration_ms, usage_extras), nested agents + events |
| `GET /api/sessions/:id/transcript` | ordered transcript messages (user / assistant / tool) for the session |
| `GET /api/events?session_id=X` | events: event_type, tool_name, summary, data, timestamp |
| `GET /api/agents` | agent (subagent) records: status, type, depth, parent — filter to this session |
| `GET /api/pricing/cost/:id` | per-session cost: total_cost, breakdown[{ model, input_tokens, output_tokens, cache_read_tokens, cache_write_tokens, cost, matched_rule }] |
| `GET /api/workflows/:id` | 11 datasets: stats, orchestration (DAG), toolFlow, effectiveness, patterns, modelDelegation, errorPropagation (by depth), concurrency, complexity, compaction, cooccurrence |
## Analysis Framework
1. **Resolve the target.** If given a session ID, `GET /api/sessions/:id`. If the
user says "latest"/"last", `GET /api/sessions?limit=1` first to grab the id,
then fetch the detail. Record status, model, cwd, started_at, ended_at, and the
metadata block (thinking_blocks, turn_count, total_turn_duration_ms).
2. **Cost.** `GET /api/pricing/cost/:id`. Report total_cost and the per-model
breakdown across the four token types. Note the `matched_rule` so the user
knows which pricing pattern applied.
3. **Agent tree.** Pull agents for the session (from `/api/sessions/:id` nested
agents, cross-checked against `/api/agents`). Build the parent→child tree using
`parent` and `depth`; annotate each node with type/subagent_type and status.
Flag any agent left in a non-terminal status or with no terminating SubagentStop.
4. **Event chain.** `GET /api/events?session_id=X`. Order by timestamp. Compute the
PreToolUse vs PostToolUse balance (should be ~1:1). Mark APIError and any Stop
that lacks a clean prior PostToolUse. Surface the longest tool durations.
5. **Workflow intelligence.** `GET /api/workflows/:id`. Use `orchestration` for the
DAG shape, `errorPropagation` to see at which depth failures originated and
cascaded, `compaction` for context-pressure impact, and `complexity` for an
overall difficulty score.
6. **Transcript highlights.** `GET /api/sessions/:id/transcript`. Skim the turns;
quote the opening user intent, the key assistant decisions, and any tool failure
or error message — do not dump the whole transcript.
7. **Anomalies.** Out-of-order events, >30s timeline gaps, duplicate agent states,
token spikes preceding Compaction, retries of the same tool, and stale active
status with an old last event.
## Output Standards
- Cite real numbers pulled from the API — never fabricate counts, tokens, or costs.
- Format currency in USD to 4 decimal places.
- Use ▲/▼ for deltas (e.g. PreToolUse ▲ 41 vs PostToolUse 38, ▲ 3).
- Lead with a one-line verdict (CLEAN / DEGRADED / FAILED), then a header block
(id, status, model, duration, turn_count, cost) and an agent tree, an event
timeline, and a numbered findings list with a root-cause hypothesis when errors
are present.
## Constraints
- Read-only advisory role — never modify data.
- Only use data returned by the API — never fabricate metrics.
- If the dashboard is unreachable, tell the user to start it with `npm start` from
the repo root.
plugins/ccam-sessions/commands/find-session.md
+32
View File
@@ -0,0 +1,32 @@
---
description: Search Agent Monitor sessions by cwd, model, or status and print the top matches.
argument-hint: "[query]"
---
Search Claude Code sessions tracked by the Agent Monitor and print the top matches.
The query is **$ARGUMENTS** — any mix of a project / cwd substring, a model
(`opus`/`sonnet`/`haiku` or a model-id fragment), and a status
(`active`/`working`/`completed`/`error`). If empty, just show the most recent sessions.
Fetch the session list (each carries an inline `cost` field):
```
curl -s "http://localhost:4820/api/sessions?limit=200"
```
Then:
1. Filter in-memory: keep sessions whose `cwd` contains the project term (case-insensitive),
whose `model` contains the model term, and whose `status` equals the status term —
apply only the terms present in `$ARGUMENTS`.
2. Sort matches by `cost` descending if the query mentions cost/expensive, otherwise by
`started_at` descending (most recent first).
3. Print the top 10 as a numbered list, one line each:
`<rank>. <id short> — <status> — <model> — <cwd basename> — $<cost to 4dp> — <started_at>`
4. End with the match count and the summed cost of the shown matches.
Currency as USD to 4 decimal places. If nothing matches, say so and list the distinct
cwds/models that DO exist (from the returned data) so the user can refine — do not invent
results. If the dashboard is unreachable, tell the user to start it with `npm start` from
the repo root.
plugins/ccam-sessions/commands/recent.md
+27
View File
@@ -0,0 +1,27 @@
---
description: List the N most recent Claude Code sessions from the Agent Monitor.
argument-hint: "[N]"
---
List the most recent Claude Code sessions tracked by the Agent Monitor.
`N` = **$ARGUMENTS** (default `10` if empty).
Fetch the most recent sessions (the API returns them most-recently-updated first):
```
curl -s "http://localhost:4820/api/sessions?limit=$ARGUMENTS"
```
This returns a session list; each entry has id, status, model, cwd, started_at,
ended_at, cost, and metadata (turn_count, total_turn_duration_ms).
Then print the sessions as a numbered list, one line each, in the order returned:
`<rank>. <id short> — <status> — <model> — <cwd basename> — <turn_count> turns — $<cost to 4dp> — <started_at>`
After the list, print the summed cost of the listed sessions and a one-line status
tally (e.g. `7 completed · 2 active · 1 error`).
Currency as USD to 4 decimal places. Keep it terse, no preamble. If the dashboard is
unreachable, tell the user to start it with `npm start` from the repo root.
plugins/ccam-sessions/commands/replay.md
+31
View File
@@ -0,0 +1,31 @@
---
description: Summarize one Agent Monitor session by id — header plus a concise transcript recap.
argument-hint: "[session-id]"
---
Produce a concise recap of one Claude Code session tracked by the Agent Monitor.
The session id is **$ARGUMENTS**. If empty, resolve the latest:
`curl -s "http://localhost:4820/api/sessions?limit=1"` and use its `id`.
Fetch the session header and its transcript:
```
curl -s "http://localhost:4820/api/sessions/$ARGUMENTS"
curl -s "http://localhost:4820/api/sessions/$ARGUMENTS/transcript"
```
The first returns the session detail (status, model, cwd, started_at, ended_at, cost,
metadata: turn_count, thinking_blocks, total_turn_duration_ms). The second returns the
ordered transcript messages (user / assistant / tool).
Then print, concisely:
1. **Header** — one block: `id · model · status · cwd basename · turn_count turns · $<cost to 4dp> · <started_at → ended_at>`.
2. **Recap** — 5–10 bullets walking the conversation in order: the user's goal, the key
assistant actions and tools used, any tool failures, and how it ended. Summarize each
message in one line; do not paste large payloads (truncate past ~200 chars with `…`).
Currency as USD to 4 decimal places. If the transcript is empty, say the session has no
stored transcript rather than inventing turns. If the dashboard is unreachable, tell the
user to start it with `npm start` from the repo root.

Some files were not shown because too many files have changed in this diff Show More