nntrivi2001
17d56d0e01
Clean break, no compatibility alias. Renames the product name, the CLI binary (`ccam` -> `agenthub`), the env var prefix (`CCAM_` -> `AGENTHUB_`), the Prometheus metric namespace (`ccam_*` -> `agenthub_*`), the tmux session prefix (`ccam-lane-<id>` -> `agenthub-lane-<id>`), the per-repo runtime profile directory (`.ccam/profile` -> `.agenthub/profile`), the lanes state root (`~/.claude/ccam-lanes` -> `~/.claude/agenthub-lanes`), the bundled plugins (`plugins/ccam*` -> `plugins/agenthub*`) and their slash commands (`/ccam-doctor` -> `/agenthub-doctor`, `/ccam:*` -> `/agenthub:*`). Because there is no alias, an existing install has to be updated by hand: rename its `.ccam/profile` directory and any `CCAM_*` variables, and reinstall the plugin under its new name. Two other name families are deliberately left alone here, since they are not just strings: the `Claude-Code-Monitor` repository/marketplace name, and the `agent-dashboard` npm package plus its `~/.claude/agent-dashboard` runtime directory, which holds the live database and needs a migration rather than a rename. Verified: server 1406/1406, client 459/459, `grep -i ccam` clean across tracked files, `openapi.yaml` regenerated (95 paths, unchanged count).
54 lines
2.5 KiB
Markdown
54 lines
2.5 KiB
Markdown
---
|
||
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.
|