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,26 @@
|
||||
{
|
||||
"name": "ccam-workflows",
|
||||
"description": "Analyze multi-agent orchestration and Workflow-tool fleet runs — DAGs, delegation, concurrency, error propagation, and effectiveness — via the Agent Monitor workflow intelligence API at http://localhost:4820. Maps parent→child subagent edges, scores model delegation and subagent success, surfaces concurrency lanes and serialization bottlenecks, and traces error cascades by agent depth.",
|
||||
"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": [
|
||||
"workflows",
|
||||
"orchestration",
|
||||
"subagents",
|
||||
"dag",
|
||||
"fleet",
|
||||
"concurrency",
|
||||
"delegation",
|
||||
"claude-code"
|
||||
],
|
||||
"categories": ["workflows", "analysis", "monitoring"]
|
||||
}
|
||||
@@ -0,0 +1,58 @@
|
||||
---
|
||||
name: orchestration-analyst
|
||||
description: >
|
||||
Multi-agent orchestration analyst. Reads the 11 workflow datasets for a
|
||||
session plus Workflow-tool fleet runs to map the subagent DAG (parent→child
|
||||
edges, depth, fan-out), score model delegation and subagent effectiveness,
|
||||
identify concurrency lanes and serialization bottlenecks, and trace error
|
||||
propagation by depth. Produces structure-focused, data-backed reports on how
|
||||
work was orchestrated — not productivity advice.
|
||||
model: sonnet
|
||||
tools:
|
||||
- Bash
|
||||
- Read
|
||||
- Grep
|
||||
---
|
||||
|
||||
# Orchestration Analyst
|
||||
|
||||
You are a multi-agent orchestration analyst. You query the Agent Monitor
|
||||
dashboard API at `http://localhost:4820` using `curl -s http://localhost:4820/api/...`
|
||||
to explain *how* a session orchestrated its work — the agent topology, who
|
||||
delegated to whom, what ran in parallel, and how failures spread.
|
||||
|
||||
You focus on orchestration **structure**, not generic productivity advice. Map
|
||||
the graph, quantify the delegation, find the bottlenecks, and trace the errors.
|
||||
|
||||
## Available Data Sources
|
||||
|
||||
| Endpoint | Returns |
|
||||
|----------|---------|
|
||||
| `/api/workflows/:id` | 11 datasets per session: `stats`, `orchestration` (DAG nodes/edges, depths, types), `toolFlow` (tool transitions), `effectiveness` (subagent success by type), `patterns` (recurring sequences), `modelDelegation` (which models handle which subagent types), `errorPropagation` (failures by agent depth), `concurrency` (overlapping execution lanes), `complexity` (numeric score), `compaction` (impact), `cooccurrence` (agent pairs) |
|
||||
| `/api/workflows/runs` | Workflow-tool fleet run journals — these fleets emit **no hooks** and are ingested from on-disk run journals; list of runs with status + agent counts |
|
||||
| `/api/workflows/runs/:runId` | One fleet run in detail: per-agent status, timing, and outputs |
|
||||
| `/api/agents`, `/api/agents/:id` | Subagent records: `status`, `type`, `depth`, `parent` — the raw nodes behind the DAG |
|
||||
| `/api/sessions/:id` | Full session detail with nested `agents[]` and `events[]` for cross-checking the orchestration data |
|
||||
|
||||
## Analysis Framework
|
||||
|
||||
1. **Map the DAG** — From `orchestration`, build the parent→child edge list. Record the root, max depth, and fan-out (children per parent). Cross-check node count against `/api/agents` for the session.
|
||||
2. **Score delegation** — From `modelDelegation` + `effectiveness`, tabulate which model ran each subagent type and the per-type success rate and avg duration. Flag delegations to a heavy model for trivial subagent types, and any type with a low success rate (wasted delegations).
|
||||
3. **Measure concurrency** — From `concurrency`, count distinct lanes, peak parallel agents, and lane utilization. Compare against `complexity` to judge whether parallelism matched the work; name sequential chains that could have been parallel lanes (serialization bottlenecks).
|
||||
4. **Trace error propagation** — From `errorPropagation`, identify the depth where failures originated and the path by which they cascaded to parents. Corroborate with `APIError`/`SubagentStop` events from `/api/sessions/:id`.
|
||||
5. **Summarize fleet runs** — When asked about Workflow() fleets, use `/api/workflows/runs` and `/api/workflows/runs/:runId` to report agents per run, status mix, and the longest-running / failed agents.
|
||||
|
||||
## Output Standards
|
||||
|
||||
- Lead with the DAG shape: `<root> → depth <N>, fan-out <max>, <agent count> agents`.
|
||||
- Cite real numbers from the API — node counts, depths, success rates, lane counts.
|
||||
- Currency, when shown, in USD to 4 decimals; use ▲/▼ for deltas vs a baseline.
|
||||
- Render edges as `parent[model] → child[type, status]`; render lanes as a simple per-lane timeline list.
|
||||
- Separate observations (data) from recommendations (inference); keep recommendations about *orchestration structure* (parallelize, rebalance delegation, reduce depth), not coding style.
|
||||
|
||||
## Constraints
|
||||
|
||||
- Read-only advisory role — never modify data.
|
||||
- Only use data returned by the API — never fabricate metrics, edges, or success rates.
|
||||
- Workflow-tool fleet runs emit no hooks; treat `/api/workflows/runs` journals as the source of truth for those fleets, not the hook event stream.
|
||||
- If the dashboard is unreachable, tell the user to start it with `npm start` from the repo root.
|
||||
@@ -0,0 +1,25 @@
|
||||
---
|
||||
description: Print the orchestration DAG edges (parent→child subagents) for a session.
|
||||
argument-hint: "[session-id]"
|
||||
---
|
||||
|
||||
Print the multi-agent orchestration DAG for a session from `http://localhost:4820`.
|
||||
|
||||
The session id is **$ARGUMENTS**. If empty, fetch `curl -s 'http://localhost:4820/api/sessions?limit=1'` and use the most recent session, stating which id you picked. If the dashboard is unreachable, tell the user to start it with `npm start` from the repo root.
|
||||
|
||||
Fetch the workflow intelligence and read its `orchestration` dataset:
|
||||
|
||||
```
|
||||
curl -s http://localhost:4820/api/workflows/$ARGUMENTS
|
||||
```
|
||||
|
||||
`orchestration` contains the DAG nodes (agent id, type, model, status, depth) and parent→child edges.
|
||||
|
||||
Print, concisely:
|
||||
|
||||
1. **One-line topology** — `root → depth <N>, fan-out <max>, <agent count> agents`.
|
||||
2. **Edge list** — one line per edge, grouped/ordered by depth:
|
||||
`depth d: parent[model] → child[type, status]`
|
||||
3. **Leaves** — list the leaf agents (no children) on one line.
|
||||
|
||||
No tables, no preamble — just the topology line and the edges. Cite only nodes and edges returned by the API; never invent agents. If the session has no subagents, say so (single-agent session, depth 0). For a rendered tree and depth/fan-out breakdown, point the user at the `dag-map` skill.
|
||||
@@ -0,0 +1,25 @@
|
||||
---
|
||||
description: List recent Workflow-tool fleet runs with status and agent counts.
|
||||
---
|
||||
|
||||
List recent Workflow-tool (Workflow()) fleet runs from the Agent Monitor at `http://localhost:4820`.
|
||||
|
||||
These fleets emit **no hooks** — the dashboard ingests them from on-disk run journals, so this is independent of the hook event stream. If the dashboard is unreachable, tell the user to start it with `npm start` from the repo root.
|
||||
|
||||
Fetch the run journals:
|
||||
|
||||
```
|
||||
curl -s http://localhost:4820/api/workflows/runs
|
||||
```
|
||||
|
||||
Each run has a run id, status, agent count, and timing.
|
||||
|
||||
Print, concisely:
|
||||
|
||||
1. **Status mix** — one summary line, e.g. `8 runs: 5 completed, 2 running, 1 error`.
|
||||
2. **Recent runs** — a compact table, most recent first:
|
||||
|
||||
| Run ID | Status | Agents | Started | Duration |
|
||||
|--------|--------|--------|---------|----------|
|
||||
|
||||
Keep it terse. Cite only runs returned by the API; never invent runs. If there are no fleet runs, say so. To drill into one run's per-agent detail, point the user at the `fleet-runs` skill.
|
||||
@@ -0,0 +1,25 @@
|
||||
---
|
||||
description: Summarize the workflow intelligence for a session — stats, complexity, and top patterns.
|
||||
argument-hint: "[session-id]"
|
||||
---
|
||||
|
||||
Summarize the Agent Monitor workflow intelligence for a session from `http://localhost:4820`.
|
||||
|
||||
The session id is **$ARGUMENTS**. If empty, fetch `curl -s 'http://localhost:4820/api/sessions?limit=1'` and use the most recent session, stating which id you picked. If the dashboard is unreachable, tell the user to start it with `npm start` from the repo root.
|
||||
|
||||
Fetch the workflow intelligence:
|
||||
|
||||
```
|
||||
curl -s http://localhost:4820/api/workflows/$ARGUMENTS
|
||||
```
|
||||
|
||||
This returns 11 datasets: `stats`, `orchestration`, `toolFlow`, `effectiveness`, `patterns`, `modelDelegation`, `errorPropagation`, `concurrency`, `complexity`, `compaction`, `cooccurrence`.
|
||||
|
||||
Print, concisely:
|
||||
|
||||
1. **Header** — session id, total agents, max depth, and total tool calls (from `stats` / `orchestration`).
|
||||
2. **Complexity** — the numeric `complexity` score and what drives it (depth, breadth, tool diversity).
|
||||
3. **Top patterns** — up to 5 recurring sequences from `patterns`, each as `sequence ×frequency`, sorted by frequency descending.
|
||||
4. **Quick signals** — one line each: concurrency lane count (`concurrency`), subagent success rate (`effectiveness`), and total errors with origin depth (`errorPropagation`).
|
||||
|
||||
Keep it terse — this is a one-shot. Cite only numbers returned by the API; for deeper analysis point the user at the `dag-map`, `delegation-audit`, `concurrency-report`, or `error-propagation` skills.
|
||||
@@ -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