Skills Agentes

Cyclomatic Complexity

Refactoriza para bajar la complejidad ciclomática y dejar el código legible y mantenible a largo plazo, no solo fácil de leer para una IA.

Estrellas
166

en el repo

Actividad
61

0–100, la ruta de este skill

Actualizado
anteayer

último commit aquí

Commits
1

últimos 90 días

Contexto
761 tok

125 tok en reposo

Paquete
1 archivo

3 KB

Instalar

Funciona con cualquier agente que lea SKILL.md

npx -y skills add saurabhkumar8112/cyclomatic-complexity-skill --skill cyclomatic-complexity --agent claude-code

Se instala solo en este repositorio.

Qué hace

  • Mide complejidad ciclomática (puntos de decisión + 1) y refactoriza hotspots para que el código sea mantenible por humanos, no solo por IA.
  • Usa umbrales del linter del proyecto, o 1–5 bien / 6–10 vigilar / 11–15 ahora / 15+ partir.
  • Tácticas en orden: guard clauses, extraer función, lookup table, predicados con nombre, polimorfismo, aplanar bucles.
  • Cierra con una tabla before/after y verificación de comportamiento; no juega con la métrica metiendo ramas en one-liners.

Úsalo cuando

  • El usuario pide refactorizar, simplificar, limpiar o revisar calidad; menciona complejidad, spaghetti o funciones dios.
  • Hay que revisar código generado por IA antes de mergear, o tras escribir una función con mucho branching.

No lo uses cuando

    Qué lo activa

    Di cualquiera de estas frases y el agente debería cargar este skill.

    • Reduce la complejidad ciclomática de esta función
    • Este código es un spaghetti, simplifícalo
    • Revisa este código de IA antes de mergearlo
    • Parte esta god function

    SKILL.md

    En inglés

    Cyclomatic Complexity

    Purpose: AI-written code often works but branches like a jungle. This skill: measure complexity, refactor hotspots, keep code human-maintainable.

    Measure first

    CC = decision points + 1. Decision points: if, else if, case, loops, catch, ternary, &&, || in conditions.

    Project linter config wins. If eslintrc, radon config, sonar config, or similar sets a complexity threshold, use that. No config: use defaults below.

    Thresholds:

    • 1-5: fine, leave alone
    • 6-10: watch, refactor if touching anyway
    • 11-15: refactor now
    • 15+: must split, no debate

    Prefer real tools over eyeballing when environment allows:

    • Python: radon cc -s -a <path>
    • JS/TS: eslint complexity rule
    • Go: gocyclo
    • Polyglot: lizard <path>

    No tool available: count manually, per function, show the count.

    Refactor tactics, in order of preference

    1. Guard clauses. Invert conditions, return early, kill nesting.
    2. Extract function. Each extracted piece gets a name that says what, not how. Names are documentation.
    3. Lookup table / map instead of if-else or switch chains.
    4. Named predicates. if (isEligibleForRefund(order)) beats a 4-clause boolean soup.
    5. Polymorphism / strategy for switch-on-type. Only when the switch appears in 2+ places.
    6. Flatten loops. Extract loop body, use continue instead of nested if.

    Hard rules

    • Preserve behavior. Run tests before and after. No tests: say so, suggest adding, refactor conservatively.
    • Don't game the metric. A dense one-liner hiding 6 branches is worse than the honest if-chain it replaced. Complexity should move into well-named units, not disappear into cleverness.
    • Don't break public APIs or exported signatures without asking.
    • Small functions with clear names > few functions with comments explaining sections.
    • One responsibility per function. If the name needs "and", split.

    Workflow

    1. Measure all touched functions, rank by CC descending.
    2. Report hotspots with numbers before touching anything.
    3. Refactor worst first, one function at a time.
    4. Re-measure. Show before/after table: function, CC before, CC after.
    5. Verify: tests pass, behavior unchanged, diff reviewable.

    Output format

    End every refactor with:

    ## Complexity report
    | Function | Before | After |
    |----------|--------|-------|
    | parseOrder | 14 | 4 |
    
    Extracted: validateHeader, resolveDiscount
    Behavior verified: <how>
    

    Keep prose minimal. Numbers and diffs do the talking.

    Reproducido de saurabhkumar8112/cyclomatic-complexity-skill bajo licencia Apache-2.0. Leer esta página en markdown.

    Archivos

    1 archivo en el paquete. Solo se lee SKILL.md al activarse — las referencias se cargan si el skill decide que las necesita.

    Antes de instalar

    Si el entorno lo permite, usa herramientas reales (`radon`, eslint `complexity`, `gocyclo`, `lizard`); si no, cuenta a mano por función.

    Detalles

    Licencia
    Apache-2.0
    Recursos incluidos
    Solo SKILL.md
    Código fuente
    Ver SKILL.md

    Etiquetas

    Skills relacionados

    Impone la solución más perezosa que funcione: la más simple, corta y mínima. YAGNI antes que código nuevo, stdlib y nativo antes que dependencias. Para cualquier tarea de código; no para pedidos que no son de código.

    Costo de contexto al activarse
    1.7k tok
    Tamaño del paquete
    1 archivo
    Última actualización
    el mes pasado
    herramientas desarrollo

    Auditoría de sobre-ingeniería en todo el repo, no solo un diff: lista rankeada de qué borrar, simplificar o reemplazar por stdlib/nativo. Reporte de una sola vez, no aplica los cambios.

    Costo de contexto al activarse
    413 tok
    Tamaño del paquete
    1 archivo
    Última actualización
    hace 2 meses
    herramientas desarrollo

    Recolecta los comentarios `ponytail:` del repo en un ledger de deuda técnica, para que los atajos y aplazamientos deliberados no se olviden. Reporte de una sola vez, no cambia nada.

    Costo de contexto al activarse
    426 tok
    Tamaño del paquete
    1 archivo
    Última actualización
    hace 2 meses
    herramientas desarrollo