Stats
Actions
Tags
From api-expert
Optimize API performance and scalability. Measures first (pg_stat_statements, OpenTelemetry traces, k6 profile, CPU/memory metrics), identifies top bottlenecks by impact × effort, then applies evidence-backed optimizations — query tuning, indexes, connection pooling (PgBouncer/pgcat), caching (Redis L2 + in-process L1), N+1 elimination (DataLoader), cache stampede prevention (XFetch/single-flight), rate limiting tuning, serialization (protobuf over JSON), HTTP/2-3, CDN edge caching, tail latency reduction (request hedging P80). Triggers on "optimize my api", "api is slow", "reduce latency", "handle more traffic", "scale my api", "reduce 5xx rate", "improve throughput". Produces before/after metrics for every change.
How this skill is triggered — by the user, by Claude, or both
Slash command
/api-expert:optimize-apiThis skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
Dispatches the api-expert agent with a performance-optimization briefing. Measure first, then fix.
Dispatches the api-expert agent with a performance-optimization briefing. Measure first, then fix.
Before dispatching, establish:
| Info | Why |
|---|---|
| Current performance | Baseline |
| Target SLO (p95 latency, error rate) | Goal |
| Traffic level (RPS, concurrent users) | Scale context |
| Worst-performing endpoint / operation | Focus area |
| Bottleneck hypothesis (if any) | Seed for investigation |
| Access to pg_stat_statements / OTel traces / metrics dashboards? | Evidence source |
Agent({
description: "API optimize: <target>",
subagent_type: "api-expert:api-expert",
model: "opus",
prompt: "<see briefing below>"
})
ORIGINAL USER REQUEST: <verbatim>
WORKFLOW: optimize
CURRENT STATE: <baseline metrics>
TARGET SLO: <goal>
TRAFFIC: <current + target RPS>
FOCUS ENDPOINT(S): <list>
EVIDENCE ACCESS: <pg_stat_statements / OTel / dashboards / none>
Read ${CLAUDE_PLUGIN_ROOT}/references/performance-caching.md FIRST, then inter-service.md and observability.md.
MEASURE FIRST — NEVER OPTIMIZE BLIND.
DELIVERABLES:
1. Measurement baseline
2. Top 3-5 bottlenecks by impact x effort
3. Proposed changes (in priority order), each with: change description + code diff, expected impact, effort estimate (S/M/L), verification method
4. Application plan — sequence of changes with measurement between each
5. Rollback plan for each change
6. Long-term recommendations (if any require broader work)
PROCEED.
Present the bottleneck ranking + proposed changes + expected impact. Confirm with user before applying.
Provides CDSS development patterns for drug interaction checking, dose validation, clinical scoring (NEWS2, qSOFA), and alert classification integrated into EMR workflows.
npx claudepluginhub themizeguy/api-expert-public