feat: Claude Code Monitor — lanes, pipelines and a merged workspace
Internal SmartGift build of a Claude Code monitoring dashboard. Lanes: a durable unit of parallel agent work, one per working directory, tracked across session restarts. Managed lanes are git worktrees the dashboard provisions and can reset or remove behind a three-check destroy guard and a counted preflight; adopted lanes are directories you already own and are never destroyable. Pipelines: a lane moves through pipeline stages. A stage the agent declares with evidence renders green; a stage inferred from the tool-event stream renders dashed amber and never counts as done. Detection is forward-only within a 30-minute window, and never writes the declared stage. Workspace: one page at /run with a lane grid, the selected lane's pipeline, and a full Claude console behind a disclosure.
This commit is contained in:
@@ -0,0 +1,53 @@
|
||||
---
|
||||
description: >
|
||||
Report concurrency and parallelism for a session — how many agents ran in
|
||||
parallel, concurrency-lane utilization, peak parallel width, and
|
||||
serialization bottlenecks (sequential chains that could have run as parallel
|
||||
lanes) — using the Agent Monitor workflow intelligence API. Use when checking
|
||||
whether a multi-agent session used parallelism efficiently.
|
||||
---
|
||||
|
||||
# Concurrency Report
|
||||
|
||||
Report on parallel execution for one Claude Code session: lanes, peak width, utilization, and where work serialized.
|
||||
|
||||
## Input
|
||||
|
||||
The user provides: **$ARGUMENTS**
|
||||
|
||||
A session ID. If empty, fetch `GET /api/sessions?limit=1` and report on the most recent session, stating which one.
|
||||
|
||||
## Data Sources
|
||||
|
||||
| Endpoint | Returns |
|
||||
|----------|---------|
|
||||
| `GET /api/workflows/{sessionId}` | The `concurrency` dataset (overlapping agent execution lanes with start/end timing) and the `complexity` dataset (numeric score from depth, breadth, and tool diversity) |
|
||||
|
||||
## Report Sections
|
||||
|
||||
### 1. Parallelism Summary
|
||||
From `concurrency`: number of distinct lanes, peak parallel width (max agents running simultaneously), and total agents. Pair with the `complexity` score to judge whether the parallelism matched the work's size.
|
||||
`Lanes: N · Peak parallel: M · Agents: K · Complexity: S`
|
||||
|
||||
### 2. Lane Timeline
|
||||
A per-lane list of the agents that occupied each lane in order:
|
||||
`Lane 1: explore (0–12s) → code-review (12–48s)`
|
||||
`Lane 2: debugger (5–30s)`
|
||||
Show overlapping windows so simultaneity is visible.
|
||||
|
||||
### 3. Utilization
|
||||
| Lane | Busy time | Idle time | Utilization % |
|
||||
|------|-----------|-----------|---------------|
|
||||
Plus an overall utilization figure (busy lane-time / total lane-time).
|
||||
|
||||
### 4. Serialization Bottlenecks
|
||||
Identify sequential chains where one agent waited on the previous despite no apparent dependency — candidates to run as parallel lanes. State the chain and the wall-clock time it cost. Only flag chains the `concurrency` timing data actually shows as sequential.
|
||||
|
||||
## Output
|
||||
|
||||
- Markdown tables for utilization; a fenced list for the lane timeline.
|
||||
- Durations in human units (e.g. `48s`, `2m 10s`); percentages to whole numbers.
|
||||
- Use ▲/▼ when comparing utilization against an even-distribution baseline.
|
||||
- Cite only timing returned by the API; never invent lane overlaps or durations.
|
||||
- If the session ran a single agent (no concurrency), say so plainly rather than inventing lanes.
|
||||
- If the dashboard is unreachable, tell the user to start it with `npm start` from the repo root.
|
||||
@@ -0,0 +1,56 @@
|
||||
---
|
||||
description: >
|
||||
Render the multi-agent orchestration DAG for a session — parent→child
|
||||
subagent edges, tree depth, and fan-out — from the Agent Monitor workflow
|
||||
intelligence API. Cross-checks the orchestration dataset against the raw
|
||||
agent records and session detail. Use when visualizing how a session's agent
|
||||
structure was organized.
|
||||
---
|
||||
|
||||
# DAG Map
|
||||
|
||||
Render the subagent orchestration graph for one Claude Code session as a depth-ordered DAG.
|
||||
|
||||
## Input
|
||||
|
||||
The user provides: **$ARGUMENTS**
|
||||
|
||||
A session ID. If empty, fetch `GET /api/sessions?limit=1` and use the most recent session, stating which one you picked.
|
||||
|
||||
## Data Sources
|
||||
|
||||
| Endpoint | Returns |
|
||||
|----------|---------|
|
||||
| `GET /api/workflows/{sessionId}` | The `orchestration` dataset: DAG nodes (agent id, type, model, status, depth) and parent→child edges |
|
||||
| `GET /api/agents` | Raw subagent records (`status`, `type`, `depth`, `parent`) to cross-check node/edge counts |
|
||||
| `GET /api/sessions/{sessionId}` | Full session detail with nested `agents[]` to confirm the root and total agent count |
|
||||
|
||||
## Report Sections
|
||||
|
||||
### 1. Topology Summary
|
||||
From `orchestration`: the root agent, total agent count, max depth, and max fan-out (most children under any one parent). Confirm the agent count against `/api/agents` filtered to this session.
|
||||
|
||||
### 2. Edge List
|
||||
Every parent→child edge, grouped by depth, formatted as:
|
||||
`depth d: parent[model] → child[type, status]`
|
||||
Mark leaf agents (no children) and any orphan nodes (a `parent` that is not present in the node set).
|
||||
|
||||
### 3. Depth & Fan-out Table
|
||||
| Depth | Agents at depth | Children spawned | Avg fan-out |
|
||||
|-------|-----------------|------------------|-------------|
|
||||
|
||||
### 4. ASCII Tree
|
||||
A simple indented tree rendering of the DAG, e.g.:
|
||||
```
|
||||
root [opus, completed]
|
||||
├─ explore [sonnet, completed]
|
||||
└─ code-review [sonnet, error]
|
||||
└─ debugger [sonnet, completed]
|
||||
```
|
||||
|
||||
## Output
|
||||
|
||||
- Render as Markdown tables plus one fenced ASCII tree block.
|
||||
- Cite real node and edge counts from the API — never invent agents or edges.
|
||||
- If a session has no subagents, say so plainly (single-agent session, depth 0) instead of fabricating a tree.
|
||||
- If the dashboard is unreachable, tell the user to start it with `npm start` from the repo root.
|
||||
@@ -0,0 +1,55 @@
|
||||
---
|
||||
description: >
|
||||
Audit model delegation and subagent effectiveness for a session — which
|
||||
models handled which subagent types, per-type success rates and average
|
||||
durations, and wasted delegations (heavy models on trivial work or types
|
||||
that consistently fail) — using the Agent Monitor workflow intelligence API.
|
||||
Use when reviewing how a session delegated work across models and subagents.
|
||||
---
|
||||
|
||||
# Delegation Audit
|
||||
|
||||
Audit how a Claude Code session delegated work: model-to-subagent mapping and whether each delegation paid off.
|
||||
|
||||
## Input
|
||||
|
||||
The user provides: **$ARGUMENTS**
|
||||
|
||||
A session ID. If empty, fetch `GET /api/sessions?limit=1` and audit the most recent session, stating which one.
|
||||
|
||||
## Data Sources
|
||||
|
||||
| Endpoint | Returns |
|
||||
|----------|---------|
|
||||
| `GET /api/workflows/{sessionId}` | The `modelDelegation` dataset (which models are delegated which subagent types) and the `effectiveness` dataset (per-type completion/success rate, avg duration, task success) |
|
||||
| `GET /api/agents` | Raw subagent records (`type`, `model`, `status`, `depth`, `parent`) to corroborate counts and statuses |
|
||||
|
||||
## Report Sections
|
||||
|
||||
### 1. Delegation Matrix
|
||||
From `modelDelegation`: a model × subagent-type table of how many agents of each type each model ran.
|
||||
| Model | explore | code-review | debugger | ... | Total |
|
||||
|-------|---------|-------------|----------|-----|-------|
|
||||
|
||||
### 2. Effectiveness by Subagent Type
|
||||
From `effectiveness`: per type, the success rate and average duration.
|
||||
| Subagent type | Count | Success rate | Avg duration | Verdict |
|
||||
|---------------|-------|--------------|--------------|---------|
|
||||
Mark types below ~70% success as low-yield.
|
||||
|
||||
### 3. Wasted Delegations
|
||||
Flag, with evidence:
|
||||
- A heavy model (e.g. Opus) assigned to a simple/low-stakes subagent type that a cheaper model handled successfully elsewhere — candidate for rebalancing.
|
||||
- Subagent types with low success rates (effort spent, task not completed).
|
||||
- Duplicate delegations: the same type spawned repeatedly with poor success (retry churn).
|
||||
|
||||
### 4. Rebalancing Suggestions
|
||||
Concrete model reassignments grounded in the matrix and effectiveness data. State the type, the model used, the success rate, and the suggested model — only where the data supports it.
|
||||
|
||||
## Output
|
||||
|
||||
- Markdown tables for the matrix and effectiveness.
|
||||
- Success rates as percentages; durations in human units (e.g. `1m 12s`).
|
||||
- Use ▲/▼ when comparing a type's success rate against the session-wide average.
|
||||
- Cite only numbers returned by the API; do not infer success rates that the `effectiveness` dataset does not provide.
|
||||
- If the dashboard is unreachable, tell the user to start it with `npm start` from the repo root.
|
||||
@@ -0,0 +1,55 @@
|
||||
---
|
||||
description: >
|
||||
Trace error propagation through a multi-agent session by agent depth — where
|
||||
failures originated, the depth at which they appeared, and how they cascaded
|
||||
up to parent agents — using the Agent Monitor workflow intelligence API and
|
||||
the session event stream. Use when a multi-agent run failed and you need to
|
||||
find the origin and blast radius of the failure.
|
||||
---
|
||||
|
||||
# Error Propagation
|
||||
|
||||
Trace where a multi-agent session's failures started and how far they spread.
|
||||
|
||||
## Input
|
||||
|
||||
The user provides: **$ARGUMENTS**
|
||||
|
||||
A session ID. If empty, fetch `GET /api/sessions?limit=1`, but prefer the most recent session whose `status` is `error` or `abandoned`; state which one you picked.
|
||||
|
||||
## Data Sources
|
||||
|
||||
| Endpoint | Returns |
|
||||
|----------|---------|
|
||||
| `GET /api/workflows/{sessionId}` | The `errorPropagation` dataset: failures grouped by agent depth, with originating depth and cascade paths to parents |
|
||||
| `GET /api/events?session_id={sessionId}` | The event stream — corroborate with `APIError`, `SubagentStop`, and failing `PostToolUse` events (`event_type`, `tool_name`, `summary`, `timestamp`) |
|
||||
|
||||
## Report Sections
|
||||
|
||||
### 1. Failure Summary
|
||||
From `errorPropagation`: total errors, the depth where the first error originated, and how many distinct agents were affected.
|
||||
`Origin depth: d · Errors: N · Agents affected: M`
|
||||
|
||||
### 2. Errors by Depth
|
||||
| Depth | Errors originated | Errors inherited from children | Net failing agents |
|
||||
|-------|-------------------|--------------------------------|--------------------|
|
||||
Show whether failures concentrate deep in the tree (leaf subagents) or shallow (orchestrator).
|
||||
|
||||
### 3. Cascade Paths
|
||||
For each originating failure, the path it propagated along:
|
||||
`debugger (depth 2, tool failure) → code-review (depth 1, marked error) → root (depth 0, aborted)`
|
||||
Tie each step to a concrete event from `/api/events` (event_type + tool_name + timestamp) where available.
|
||||
|
||||
### 4. Error Taxonomy
|
||||
Break errors down by type from the event stream: `APIError` vs failing tool calls vs `SubagentStop` with error status. Note the most frequent tool involved in failures.
|
||||
|
||||
### 5. Containment Assessment
|
||||
Whether failures were contained at the depth where they originated or leaked to parents. Name any parent that aborted solely because a child failed — a candidate for better error handling / isolation.
|
||||
|
||||
## Output
|
||||
|
||||
- Markdown tables for the depth breakdown; a fenced list for cascade paths.
|
||||
- Timestamps for the first and last error.
|
||||
- Cite only errors present in `errorPropagation` and the event stream; never invent failures or causes.
|
||||
- If the session has no errors, say so plainly and stop.
|
||||
- If the dashboard is unreachable, tell the user to start it with `npm start` from the repo root.
|
||||
@@ -0,0 +1,58 @@
|
||||
---
|
||||
description: >
|
||||
Summarize Workflow-tool fleet runs from the Agent Monitor — these fleets emit
|
||||
no hooks and are ingested from on-disk run journals. List recent runs with
|
||||
status and agents-per-run, then drill into a single run's per-agent detail.
|
||||
Reconciles against the live run-state endpoints. Use when reviewing Workflow()
|
||||
fleets rather than hook-instrumented interactive sessions.
|
||||
---
|
||||
|
||||
# Fleet Runs
|
||||
|
||||
Summarize Workflow-tool (Workflow()) fleet runs and drill into one run's agents.
|
||||
|
||||
## Input
|
||||
|
||||
The user provides: **$ARGUMENTS**
|
||||
|
||||
- Empty → list the most recent fleet runs.
|
||||
- A run ID → drill into that single run.
|
||||
- `latest` → drill into the most recent run.
|
||||
|
||||
These fleets emit **no hooks**; the dashboard ingests them from on-disk Workflow-tool run journals, so this data is independent of the hook event stream.
|
||||
|
||||
## Data Sources
|
||||
|
||||
| Endpoint | Returns |
|
||||
|----------|---------|
|
||||
| `GET /api/workflows/runs` | List of ingested fleet run journals: run id, status, agent count, timing |
|
||||
| `GET /api/workflows/runs/{runId}` | One run in detail: per-agent status, timing, type, and outputs |
|
||||
| `GET /api/run` | Live run state across the fleet (current/active runs) |
|
||||
| `GET /api/run/{id}` | Live state for one run, to reconcile against the journal |
|
||||
|
||||
## Report Sections
|
||||
|
||||
### 1. Runs Overview (when listing)
|
||||
| Run ID | Status | Agents | Started | Duration |
|
||||
|--------|--------|--------|---------|----------|
|
||||
Sort most recent first. Add a one-line status mix below (e.g. `8 runs: 5 completed, 2 running, 1 error`).
|
||||
|
||||
### 2. Run Detail (when a run ID / `latest` is given)
|
||||
From `GET /api/workflows/runs/{runId}`, reconciled with `GET /api/run/{id}`:
|
||||
- Header: run id, status, total agents, wall-clock duration.
|
||||
- Per-agent table:
|
||||
| Agent | Type | Status | Duration | Notes |
|
||||
|-------|------|--------|----------|-------|
|
||||
- Call out the longest-running agent and any agent with an error/failed status.
|
||||
|
||||
### 3. Status & Health
|
||||
Completion rate (completed / total agents), any stalled or errored agents, and whether the journal and the live run-state endpoint agree (flag drift if they do not).
|
||||
|
||||
## Output
|
||||
|
||||
- Markdown tables; status mix as a single summary line.
|
||||
- Durations in human units (e.g. `3m 04s`).
|
||||
- Make explicit that these runs come from run journals (no hooks), so hook-derived metrics do not apply.
|
||||
- Cite only runs and agents returned by the API; never invent runs.
|
||||
- If there are no fleet runs, say so plainly.
|
||||
- If the dashboard is unreachable, tell the user to start it with `npm start` from the repo root.
|
||||
Reference in New Issue
Block a user