| name | agent-performance-report |
| model | sonnet |
| description | Produces an aggregated markdown performance report from stored trace data — tool call metrics, token usage, cost, bottlenecks, and numbered recommendations. Use when: "session cost report", "what ran this week", "why did this spike", "end-of-sprint performance review", "budget alert fired". |
| license | proprietary |
| category | system-health |
| triggers | ["session cost report","what ran this week","why did this spike","end-of-sprint performance review","budget alert fired"] |
| tier | 1 |
| agents | ["primary"] |
| tool_dependencies | ["file_system"] |
| inputs | [{"name":"time_period","type":"string","description":"Time period for the report (e.g. this week, this sprint, today)","required":false}] |
| outputs | [{"name":"performance_report","type":"string","description":"Aggregated markdown performance report with tool call metrics, token usage, cost, bottlenecks, and numbered recommendations"}] |
I. Philosophy
A performance report is an accountability artifact. It converts the raw trace
data accumulated during agent operation into a human-readable narrative that
answers three questions: what ran, how well did it run, and what should change.
The value of this report is not comprehensiveness — it is actionability. A
report that surfaces five specific recommendations is more useful than a report
that lists every span in the trace store. Structure the output so a non-technical
reviewer can understand cost trends and a technical reviewer can locate
bottlenecks without scrolling.
II. When to Use
Use this skill:
- At the end of a work session to summarize what the agent did and how much
it cost.
- After an incident or unexpected failure to understand which nodes failed,
in what order, and why.
- As part of a sprint retrospective to analyze token spend against output
quality.
- When tuning agent configuration — use successive reports to measure whether
changes to model selection, tool ordering, or plan structure are improving
efficiency.
- When a budget alert fires — use this skill to identify which operations
triggered the alert and whether the spend was justified.
Do not use this skill for real-time monitoring during an active session. For
live tool call visibility, use tool-intercept-logger. This skill operates on
stored, completed trace data.
III. Workflow
Step 1 — Accept time range and filters.
Accept the following inputs:
time_range: required. ISO 8601 start/end pair (e.g., 2026-04-01T00:00:00Z
to 2026-04-05T23:59:59Z). If only a start is given, end defaults to now.
Convenience shortcuts: "today", "last_7_days", "this_month".agent_filter: optional. Restrict to spans generated by a specific agent ID.user_filter: optional. Restrict to spans for a specific user ID.tool_namespace: optional. Restrict tool-level metrics to a namespace prefix
(e.g., mcp_by_dojo:*).
If no filters are provided, report covers all agents and users for the time
range.
Step 2 — Query stored spans.
Query TraceStorage for all spans within the time range, applying any filters.
Each span contains: SpanID, TraceID, ParentID, Name, StartTime,
, , , , .
