Claude Skill

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

LLM Mart · 0 points · 11 0 0

Virus-scanned Reviewed automatically before listing.

Full trust report

Download hoangsonww-claude-code-agent-monitor-plugins_ccam-workflows_skills_concurrency-report-83d4df5.zip · 1 KB

hoangsonww/claude-code-agent-monitor 1014 238 forks MIT Updated 23h ago

Part of hoangsonww/claude-code-agent-monitor — 86 skills

Install

skills CLI

npx skills add https://github.com/hoangsonww/Claude-Code-Agent-Monitor/tree/master/plugins/ccam-workflows/skills/concurrency-report

Claude Code

claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install hoangsonww-claude-code-agent-monitor@llmmart

Git git clone https://github.com/hoangsonww/Claude-Code-Agent-Monitor.git

The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole hoangsonww/claude-code-agent-monitor collection as a plugin from our marketplace. Git is the plain clone.

Skill manifest

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.

Files (claude-code-agent-monitor)

agents

openai.yaml 278 B

interface:
  display_name: "Concurrency Report"
  short_description: "Report concurrency and parallelism for a session — how many..."
  default_prompt: "Use $concurrency-report to inspect CCAM data and complete this workflow safely."
policy:
  allow_implicit_invocation: true

SKILL.md 2.5 KB

---
name: concurrency-report
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.