Performance Audit Intelligence
Análisis estático — sin ejecución de código
Este skill analiza el código fuente para detectar funciones pesadas, anti-patrones de async y oportunidades de optimización. No ejecuta el código: mide complejidad, profundidad y patrones mediante análisis estático.
Algoritmo de detección (4 fases)
Fase 1 — Complejidad (40% peso)
Calcular por cada función/método:
- Complejidad ciclomática: if/else, switch/case, loops, ternarios, catch, operadores lógicos
- Complejidad cognitiva: anidamiento, breaks en flujo, recursión
- Umbrales: cyclomatic ≤10 OK, 11-20 HIGH, 21+ CRITICAL | cognitive ≤15 OK, 16-25 HIGH, 26+ CRITICAL
Fase 2 — Async Anti-patterns (25% peso)
Cargar references/perf-{lang}.md del lenguaje detectado. Verificar:
- Blocking calls en contextos async
- Async void / floating promises / missing await
- Sync-over-async (Task.Result, .Wait(), .get())
- CPU-bound en event loops
- Goroutine/channel leaks (Go), mutex en async (Rust)
Fase 3 — Hotspot Identification (20% peso)
Score compuesto por función: (cyclomatic × 0.4) + (cognitive × 0.3) + (method_length × 0.15) + (nesting_depth × 0.1) + (fan_out × 0.05)
Métricas adicionales:
- Method length: ≤30 OK, 31-60 MEDIUM, 61+ HIGH
- Nesting depth: ≤3 OK, 4-5 MEDIUM, 6+ HIGH
- Fan-out (dependencias llamadas): ≤7 OK, 8-12 MEDIUM, 13+ HIGH
- Estimated O(): detectar loops anidados → O(n²), O(n³), etc.
Fase 4 — Test Coverage (15% peso)
Para cada hotspot identificado:
- Buscar ficheros de test que referencien la función/clase
- Verificar si existen tests unitarios, de integración o characterization
- Marcar como UNTESTED si no hay cobertura → eleva severidad +1 nivel
Clasificación de severidad
| Severidad |
Criterio |
Impacto |
| CRITICAL |
cyclomatic ≥21 O cognitive ≥26 O async blocking en hot path |
Degradación medible en producción |
| HIGH |
cyclomatic 11-20 O cognitive 16-25 O N+1 queries |
Riesgo de latencia bajo carga |
| MEDIUM |
method_length >60 O nesting >5 O fan-out >12 |
Mantenibilidad reducida (solo --strict) |
| LOW |
Best practice no seguida (solo --strict) |
Oportunidad de mejora |
Scoring
Performance Score = 100 - (Σ penalties)
Penalty: CRITICAL = -15, HIGH = -8, MEDIUM = -3, LOW = -1
Score mínimo = 0
Rangos: ≥80 GOOD, 60-79 NEEDS_WORK, 40-59 POOR, <40 CRITICAL
IDs y referencias
Formato: PA-{NNN} (secuencial por auditoría).
Los IDs son estables entre /perf-audit, /perf-fix y /perf-report.
Los hallazgos con severidad ≥HIGH se registran automáticamente en /debt-track.
Test-First Workflow (/perf-fix)
ANTES de optimizar cualquier función:
- Verificar tests existentes — buscar test files que referencien la función
- Si no existen → crear characterization tests (Golden Master):
- Capturar inputs/outputs actuales de la función
- Incluir edge cases detectados en análisis de complejidad
- Cubrir ramas principales del flujo
- Ejecutar baseline — todos los tests deben PASAR
- Aplicar optimización — refactor, async fix, algoritmo mejorado
- Re-ejecutar tests — si FAIL → revertir, si PASS → confirmar mejora
Patrones de optimización disponibles
- Refactor complejo: extract method, simplify conditions, remove nesting
- Async fix: convertir blocking a async, Promise.all, parallel execution
- N+1 fix: eager loading, batch queries, DataLoader pattern
- Memory: pre-allocation, StringBuilder, generator/iterator, object pooling
- Algorithm: hash lookup vs linear search, sort optimization, caching
Integración
| Feature |
Relación |
| architecture-intelligence |
Reusa detección de lenguaje |
| language packs |
perf-{lang}.md complementa convenciones |
| /debt-track |
Hallazgos PA-NNN → deuda técnica |
| /project-audit |
/perf-audit es dimensión nueva del audit |
| test-runner hook |
/perf-fix usa test runner para baseline |
| context-health |
Output-first: >30 líneas → fichero |
Output
Directorio: output/performance/
Formato nombre: {proyecto}-audit-{YYYY-MM-DD}.md
1---2name: performance-audit3description: Performance Audit Intelligence4---56# Performance Audit Intelligence78## Análisis estático — sin ejecución de código910Este skill analiza el código fuente para detectar funciones pesadas, anti-patrones de async y oportunidades de optimización. No ejecuta el código: mide complejidad, profundidad y patrones mediante análisis estático.1112## Algoritmo de detección (4 fases)1314### Fase 1 — Complejidad (40% peso)15Calcular por cada función/método:16- **Complejidad ciclomática**: if/else, switch/case, loops, ternarios, catch, operadores lógicos17- **Complejidad cognitiva**: anidamiento, breaks en flujo, recursión18- Umbrales: cyclomatic ≤10 OK, 11-20 HIGH, 21+ CRITICAL | cognitive ≤15 OK, 16-25 HIGH, 26+ CRITICAL1920### Fase 2 — Async Anti-patterns (25% peso)21Cargar `references/perf-{lang}.md` del lenguaje detectado. Verificar:22- Blocking calls en contextos async23- Async void / floating promises / missing await24- Sync-over-async (Task.Result, .Wait(), .get())25- CPU-bound en event loops26- Goroutine/channel leaks (Go), mutex en async (Rust)2728### Fase 3 — Hotspot Identification (20% peso)29Score compuesto por función: `(cyclomatic × 0.4) + (cognitive × 0.3) + (method_length × 0.15) + (nesting_depth × 0.1) + (fan_out × 0.05)`30Métricas adicionales:31- **Method length**: ≤30 OK, 31-60 MEDIUM, 61+ HIGH32- **Nesting depth**: ≤3 OK, 4-5 MEDIUM, 6+ HIGH33- **Fan-out** (dependencias llamadas): ≤7 OK, 8-12 MEDIUM, 13+ HIGH34- **Estimated O()**: detectar loops anidados → O(n²), O(n³), etc.3536### Fase 4 — Test Coverage (15% peso)37Para cada hotspot identificado:38- Buscar ficheros de test que referencien la función/clase39- Verificar si existen tests unitarios, de integración o characterization40- Marcar como UNTESTED si no hay cobertura → eleva severidad +1 nivel4142## Clasificación de severidad4344| Severidad | Criterio | Impacto |45|-----------|----------|---------|46| CRITICAL | cyclomatic ≥21 O cognitive ≥26 O async blocking en hot path | Degradación medible en producción |47| HIGH | cyclomatic 11-20 O cognitive 16-25 O N+1 queries | Riesgo de latencia bajo carga |48| MEDIUM | method_length >60 O nesting >5 O fan-out >12 | Mantenibilidad reducida (solo --strict) |49| LOW | Best practice no seguida (solo --strict) | Oportunidad de mejora |5051## Scoring5253```54Performance Score = 100 - (Σ penalties)55Penalty: CRITICAL = -15, HIGH = -8, MEDIUM = -3, LOW = -156Score mínimo = 057```5859Rangos: ≥80 GOOD, 60-79 NEEDS_WORK, 40-59 POOR, <40 CRITICAL6061## IDs y referencias6263Formato: `PA-{NNN}` (secuencial por auditoría).64Los IDs son estables entre `/perf-audit`, `/perf-fix` y `/perf-report`.65Los hallazgos con severidad ≥HIGH se registran automáticamente en `/debt-track`.6667## Test-First Workflow (/perf-fix)6869ANTES de optimizar cualquier función:701. **Verificar tests existentes** — buscar test files que referencien la función712. **Si no existen** → crear **characterization tests** (Golden Master):72 - Capturar inputs/outputs actuales de la función73 - Incluir edge cases detectados en análisis de complejidad74 - Cubrir ramas principales del flujo753. **Ejecutar baseline** — todos los tests deben PASAR764. **Aplicar optimización** — refactor, async fix, algoritmo mejorado775. **Re-ejecutar tests** — si FAIL → revertir, si PASS → confirmar mejora7879## Patrones de optimización disponibles8081- **Refactor complejo**: extract method, simplify conditions, remove nesting82- **Async fix**: convertir blocking a async, Promise.all, parallel execution83- **N+1 fix**: eager loading, batch queries, DataLoader pattern84- **Memory**: pre-allocation, StringBuilder, generator/iterator, object pooling85- **Algorithm**: hash lookup vs linear search, sort optimization, caching8687## Integración8889| Feature | Relación |90|---------|----------|91| architecture-intelligence | Reusa detección de lenguaje |92| language packs | perf-{lang}.md complementa convenciones |93| /debt-track | Hallazgos PA-NNN → deuda técnica |94| /project-audit | /perf-audit es dimensión nueva del audit |95| test-runner hook | /perf-fix usa test runner para baseline |96| context-health | Output-first: >30 líneas → fichero |9798## Output99100Directorio: `output/performance/`101Formato nombre: `{proyecto}-audit-{YYYY-MM-DD}.md`