---
name: reducir-entropia
description: >
  Skill manual-only para minimizar el tamaño total del codebase. Mide el
  éxito por la cantidad de código final, no por el esfuerzo de escribirlo.
  Sesgo hacia la eliminación: 50 líneas que borran 200 = win neto; 14
  funciones para no escribir 2 = pérdida neta. Cargar SOLO cuando el
  usuario lo pide explícitamente — no se activa por similitud o keyword.
  Adaptación de `reducing-entropy` de agent-toolkit.
version: "1.0.0"
herramientasPermitidas: [Read, Grep, Glob, Bash]
exclusiones:
  - "No cargar automáticamente — solo cuando el usuario lo pide explícitamente con 'reducir entropía', 'minimizar código', 'qué podemos borrar'. La activación automática contradice el propósito."
  - "No cargar para greenfield (proyecto nuevo) donde aún no hay código que reducir."
  - "No cargar contra código en framework con convenciones fuertes (Django, Rails, NestJS) — pelearse con el framework siempre suma código, no resta."
  - "No cargar para código bajo requerimiento regulatorio que mandata cierta estructura (auditoría, compliance, separación de concerns legal)."
evolvable: true
---

# Habilidad: Reducir entropía

Más código engendra más código. La entropía se acumula. Este skill sesga
hacia el codebase más pequeño posible.

**Pregunta central**: "¿Cómo se ve el codebase **después**?"

## Antes de empezar

Verificar que el usuario invocó este skill explícitamente. No activarlo
por keyword similar ("refactor", "limpiar"). Si la invocación es ambigua,
preguntar:

> ¿Quieres que aplique el lente de *reducir-entropia* (sesgo hacia
> borrar) o un refactor estándar (cambia estructura sin reducir
> tamaño)?

Si la respuesta es "refactor", NO cargar este skill — usar
`legacy-code-rescue` o `revisor-codigo-swl`.

## Cuándo cargar

- Usuario pide explícitamente: "reduce entropía", "minimiza este código",
  "¿qué podemos borrar?", "el codebase está gordo".
- Tras un sprint donde se duplicaron utilidades sin consolidar.
- Al cerrar una fase grande para limpiar deuda antes de la siguiente.

## Cuándo NO cargar

Listado en `exclusiones` del frontmatter — incluye activación automática,
greenfield, frameworks opinionados y requerimientos regulatorios.

---

## La meta

La meta es **menos código total en el codebase final** — no menos código
por escribir ahora.

- Escribir 50 líneas que borran 200 = win neto.
- Mantener 14 funciones para no escribir 2 = pérdida neta.
- "Sin churn" no es la meta. Menos código es la meta.

**Medir el estado final, no el esfuerzo.**

## Tres preguntas

### 1. ¿Cuál es el codebase mínimo que resuelve esto?

No "cuál es el cambio mínimo" — cuál es el **resultado** mínimo.

- ¿Podrían ser 2 funciones en lugar de 14?
- ¿Podrían ser 0 funciones (borrar la feature completa)?
- ¿Qué borraríamos si hiciéramos esto?

### 2. ¿El cambio propuesto resulta en menos código total?

Contar líneas antes y después. Si después > antes, rechazar el cambio.

- "Mejor organizado" pero más código = más entropía.
- "Más flexible" pero más código = más entropía.
- "Mejor separación" pero más código = más entropía.

### 3. ¿Qué se puede borrar?

Cada cambio es una oportunidad para borrar. Preguntar:

- ¿Qué vuelve obsoleto este cambio?
- ¿Qué solo existía por lo que estamos reemplazando?
- ¿Cuál es el máximo que podríamos remover?

---

## Red flags (justificaciones que NO compensan más código)

- **"Keep what exists"** — sesgo de status quo. La pregunta es código
  total, no churn.
- **"Esto añade flexibilidad"** — flexibilidad para qué. YAGNI.
- **"Mejor separación de concerns"** — más archivos/funciones = más
  código. La separación no es gratis.
- **"Type safety"** — vale cuántas líneas. A veces runtime checks en
  menos código gana.
- **"Más fácil de entender"** — 14 cosas no son más fáciles que 2 cosas.
- **"Por si acaso lo necesitamos"** — YAGNI. Borrar.

## Cuándo NO aplica (después de cargar el skill)

Aunque el skill se haya cargado, hay casos donde la respuesta correcta
es "no hay nada que reducir":

- El codebase ya es mínimo para lo que hace.
- Estás dentro de un framework con convenciones fuertes (no peles contra
  el framework — más esfuerzo, más bugs, mismo tamaño).
- Hay requerimientos regulatorios o de compliance que mandan estructura
  (auditoría, separación legal, accesibilidad WCAG).
- El código es bibliográficamente pequeño pero **estructuralmente
  necesario** (DI containers, contracts entre módulos, schemas de
  validación legal).

Si alguna de estas aplica, decirlo y NO insistir en borrar.

---

## Reglas obligatorias

1. **Manual-only**: este skill no se carga por matcher ni por keyword
   similar. Solo por invocación explícita. **Por qué**: el sesgo hacia
   borrar es agresivo; aplicarlo cuando el usuario no lo pidió destruye
   trabajo legítimo.

2. **Contar líneas antes/después**: cada propuesta de cambio incluye el
   delta de LOC. **Por qué**: sin números, "reducir" se vuelve subjetivo
   — y subjetivamente, "está mejor" suele significar "más código pero
   organizado".

3. **Borrar > extraer**: ante la duda entre "borrar la feature" y
   "refactorizar la feature", priorizar borrar. **Por qué**: la feature
   no usada cuesta mantenimiento aunque esté "bien organizada".

4. **Red flags requieren justificación cuantitativa**: si alguien
   defiende un cambio con "más flexible", exigir números de cuántas
   variaciones reales se anticipan en los próximos 6 meses. **Por qué**:
   "flexible" sin métrica = optimización para casos imaginarios.

5. **Si el codebase ya es mínimo, decirlo y parar**: no forzar reducciones
   inventadas. **Por qué**: borrar de un codebase ya mínimo introduce
   bugs sin reducir entropía real.

6. **Respetar contratos públicos**: APIs públicas con consumidores no se
   borran sin plan de migración. **Por qué**: la entropía se reduce
   internamente, no rompiendo a terceros.

---

## Relación con otras herramientas SWL

- **`legacy-code-rescue`**: refactoriza código heredado preservando
  comportamiento. Este skill **borra** comportamiento que no se necesita.
  Opuestos por diseño.
- **`revisor-codigo-swl`**: detecta code smells y aplica reglas de
  estilo. Este skill aplica un único lente (tamaño total) — más radical.
- **Regla `estilo-codigo.md § DRY`**: dice "no duplicar conocimiento".
  Este skill dice "borrar si no hace falta". DRY puede generar más
  código (extraer helper); este skill prefiere borrar el caller.
- **Skill `analisis-previo-tareas-grandes`**: si reducir entropía resulta
  en cambios masivos (>10 archivos), aplicar tabla comparativa + 3
  opciones antes de borrar.
- **Regla `arreglar-al-detectar.md`**: prohíbe deuda silenciosa. Si al
  reducir se descubren funcionalidades no documentadas, reportar antes
  de borrar.

---

## Ejemplo de uso

Usuario: *"el módulo `utils/` está gigante, ¿qué podemos borrar?"*.

Agente carga este skill y aplica las tres preguntas:

```
### Análisis de entropía — utils/ (1,847 LOC)

**Inventario**: 23 archivos, 67 funciones exportadas.

**Pregunta 1 — codebase mínimo**: para los casos de uso reales (verificados
con `grep -rn 'from utils'` en backend/ y frontend/), 12 funciones cubren
el 90% de los imports. Las otras 55 funciones tienen 0-2 imports cada una.

**Pregunta 2 — delta neto**: borrar las 55 funciones poco usadas elimina
1,420 LOC. Inlinar los 2-3 imports de cada una añade ~80 LOC en sus
callers. Delta: -1,340 LOC.

**Pregunta 3 — qué se puede borrar**:
- `utils/dateFormatters.js` (8 funciones, 240 LOC) — 6 funciones no
  usadas; 2 usadas, inlinables en el caller único.
- `utils/stringHelpers.js` (12 funciones, 380 LOC) — 9 no usadas; 3
  duplican métodos nativos (`String.prototype.padStart` etc.).
- `utils/legacyAdapter.js` (320 LOC) — 0 imports activos tras migración
  de v3 → v4 en 2025-Q4. Candidato a borrado completo.

**Red flags detectadas en el código actual**:
- "Por si acaso" en 3 helpers que nadie llama.
- "Type safety" en wrappers que solo agregan annotations sin valor.

**Propuesta**:
1. Borrar `legacyAdapter.js` (sin imports). -320 LOC.
2. Borrar las 9 funciones no usadas de `stringHelpers.js`. -270 LOC.
3. Borrar las 6 funciones no usadas de `dateFormatters.js`. -180 LOC.
4. Mantener las 12 funciones core (alta concurrencia).

**Delta total proyectado**: -770 LOC (de 1,847 → 1,077, -42%).

**Lo que NO conviene borrar**:
- `utils/validation/` — schemas de validación legal (compliance).
- `utils/auth/` — contratos con frontend; cambio rompería runtime.

¿Procedo con el plan en 3 commits atómicos?
```

El usuario decide. El agente NO borra antes de aprobación explícita.
