version: "1.0.0" name: performance description: > Use for memory, CPU, latency, and query-performance investigations, plus dependency-upgrade blast-radius analysis. Trigger on leak/OOM/profiling/regression reports or "what breaks if I upgrade X." Route to memory-leak or dependency-blast-radius workflow based on intent.

Nexus Performance

Route to the correct sub-skill and follow it end-to-end.

Compatibility

• Sub-skills: memory-leak.md, dependency-blast-radius.md
• Supporting files: examples/production-scenarios.md, checklists/performance-checklist.md,

heuristics/performance-heuristics.md, anti-patterns/common-mistakes.md, validation/output-validation.md

• Required tools: Read, Bash, Grep
• Hands off to: nexus:debugging for single-service runtime failures
• Hands off to: the roadmap-planner agent after the fix is approved

Routing

Step 1 — Classify the Request

Pick exactly one track:

If the request does not clearly fit one track, ask one question: "Is this about memory/CPU/latency behavior of a running service, or about the risk of upgrading a dependency?"

Step 2 — Read Sub-Skill and Execute

Read the appropriate sub-skill file. Follow its numbered steps in order. Do not skip steps. Read heuristics/performance-heuristics.md for fast pattern-matching before starting investigation.

Step 3 — Validate Output

Before presenting results, check against validation/output-validation.md.

Output Format

Each sub-skill defines its own output format. This router produces no standalone output.

Anti-Patterns

• Never profile a running production process without confirming the profiling overhead is acceptable.
• Never recommend a dependency upgrade without completing the blast radius analysis first.
• Never mix tracks — complete one sub-skill fully before considering another.
• Never skip reading the actual code or configuration — performance issues are almost always specific to the exact version and usage pattern.
• Never recommend "just increase memory/CPU limits" without first identifying the root cause — scaling a leak just delays the next OOM.

Examples

"Memory usage is growing by 50MB per hour and the process gets OOM killed every 12 hours" → route to memory-leak.md

"We want to upgrade SQLAlchemy from 1.4 to 2.0 — what will break?" → route to dependency-blast-radius.md

"Our API latency is 3× higher than yesterday after the last deploy" → route to memory-leak.md if memory metrics are elevated; otherwise route to nexus:debugging

"Which of our services import requests==2.28.0 and would be affected by this CVE patch upgrade?" → route to dependency-blast-radius.md