Concurrency report
Skill hoangsonww/Claude-Code-Agent-Monitor/plugins/ccam-workflows/skills/concurrency-report
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.From its SKILL.md
npx -y skills add hoangsonww/Claude-Code-Agent-Monitor --skill concurrency-reportAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
SKILL.md
2.5 KB, 496 tokens by cl100k_base, as published. Nobody here has run it
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 startfrom the repo root.
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.