performance-instrumenter

name	performance-instrumenter
description	Use when you need to add lightweight performance instrumentation, capture a baseline, and identify the slowest endpoint or hot path with enough trace detail for planning and optimization.

Performance Instrumenter

Instrument only what is needed to expose the critical path and establish a credible baseline.

The best output is not the most tracing. It is the smallest trace set that clearly explains where latency is going.

Deliverables

• Request-level instrumentation on the target endpoint or workflow
• Child spans around the likely expensive operations
• A repeatable baseline measurement
• One trace-backed summary of the slowest path

Workflow

1. Start from the intake brief. Use the chosen endpoint, run command, and hot files. Do not widen scope unless the evidence forces it.
2. Add narrow instrumentation. Prefer existing OpenTelemetry packages if they are already in the stack. Otherwise add the minimum viable setup around the request path and its expensive dependencies.
3. Trace the likely bottlenecks. Wrap database calls, external HTTP requests, cache misses, serialization, and any expensive loops or transforms.
4. Capture the baseline. Run the target flow enough times to smooth out startup noise. Record latency and the key spans that dominate the request.
5. Hand off evidence, not raw logs. Summarize the endpoint, total latency, top spans, and the likely optimization directions.

Handoff Format

• Target endpoint or workflow
• Baseline latency and measurement command
• Top spans with rough timings
• The files where the latency appears to originate
• Instrumentation notes for anyone re-running the benchmark

Guardrails

• Do not attempt repo-wide tracing.
• Do not spend time wiring a vendor backend unless it already exists.
• Favor readable, removable instrumentation.
• If true OpenTelemetry is too expensive for the time box, still emit a trace-shaped breakdown with explicit naming and timing.