don-cheli-sdd 1.13.0

package/habilidades/arnes-agente/HABILIDAD.md

@@ -0,0 +1,164 @@
+---
+nombre: Arnés del Agente
+descripcion: "Configurar y ejecutar agentes especializados con restricciones, timeouts y recuperación de errores"
+version: 1.0.0
+autor: Don Cheli
+tags: [configuración, agente, harness, arnés]
+activacion: "configurar agente", "arnés", "harness", "ejecutar agente"
+---
+
+# Habilidad: Arnés del Agente (Agent Harness)
+
+**Versión:** 1.0.0
+**Categoría:** Configuración
+**Tipo:** Rígida
+
+> Basado en las prácticas de MELI para 20,000 developers y GitHub Spec Kit.
+
+## Cómo Mejora el Framework
+
+El "arnés del agente" es el conjunto de configuraciones que controla el comportamiento de la IA. Sin un arnés bien diseñado, el agente pierde efectividad a medida que el contexto crece.
+
+### El Problema: Context Rot
+
+> La precisión del agente cae cuando la ventana de contexto supera ~60% de utilización.
+> — Julian de Angelis, MELI
+
+Un CLAUDE.md monolítico de 2,000 líneas **contamina** el contexto. La solución de MELI: **reglas modulares**.
+
+## Las 4 Palancas del Arnés
+
+### 1. Reglas Modulares (Custom Rules)
+
+En vez de un archivo gigante, divide las reglas por concern:
+
+```
+.especdev/
+├── reglas/
+│   ├── arquitectura.md     # Patrones, capas, inyección de deps
+│   ├── testing.md          # Cobertura, mocking, fixtures
+│   ├── seguridad.md        # .env, secrets, OWASP
+│   ├── ui.md               # Componentes, estilos, accesibilidad
+│   ├── bd.md               # Queries, migraciones, transacciones
+│   └── api.md              # REST, versionado, paginación
+```
+
+**Regla de oro:** Cada archivo de reglas < **500 líneas**.
+
+El framework carga SOLO las reglas relevantes para la tarea actual:
+- Si trabajas en UI → carga `ui.md` + `testing.md`
+- Si trabajas en BD → carga `bd.md` + `seguridad.md`
+- Si trabajas en API → carga `api.md` + `testing.md` + `seguridad.md`
+
+### 2. Servidores MCP
+
+Puente entre conocimiento organizacional y el agente:
+- Schemas de BD → via MCP, no pegados en el prompt
+- Docs internos → via MCP, no copy-paste
+- APIs internas → contratos via MCP
+
+### 3. Skills Bajo Demanda
+
+Habilidades que se cargan SOLO cuando son relevantes:
+- No cargar TODAS las habilidades al inicio
+- Usar subagentes aislados para tareas pesadas
+- El contexto principal se mantiene limpio
+
+### 4. Stop Hooks (Verificaciones de Parada)
+
+Puertas de validación automáticas que DEBEN pasar antes de que el agente pueda marcar una tarea como "completa":
+
+```yaml
+# .especdev/hooks/parar.yml
+hooks_parar:
+  - nombre: "Lint"
+    comando: "npm run lint"
+    obligatorio: true
+    
+  - nombre: "Type Check"
+    comando: "npx tsc --noEmit"
+    obligatorio: true
+    
+  - nombre: "Tests"
+    comando: "npm test"
+    obligatorio: true
+    
+  - nombre: "Coverage"
+    comando: "npm run coverage"
+    umbral: 85
+    obligatorio: false
+    
+  - nombre: "Build"
+    comando: "npm run build"
+    obligatorio: true
+```
+
+**Flujo:**
+```
+Implementar → ¿Todos los stop hooks pasan?
+├── ✅ SÍ → Tarea marcada como completa
+└── ❌ NO → Tarea BLOQUEADA, mostrar qué falló
+```
+
+## Niveles de Madurez de Specs
+
+MELI define 3 niveles de madurez en el uso de specs:
+
+### Nivel 1: Spec-First (Básico)
+- La spec se escribe como input
+- Se descarta después de implementar
+- El código es la única fuente de verdad
+- **⚠️ Problema:** La spec se desincroniza
+
+### Nivel 2: Spec-Anchored (Intermedio) ← **Recomendado**
+- La spec vive en el repositorio
+- Se actualiza cuando el código cambia
+- Es documentación viva
+- **✅ Beneficio:** Spec y código siempre alineados
+
+### Nivel 3: Spec-as-Source (Avanzado)
+- La spec ES la fuente primaria
+- Editar la spec regenera el código
+- La spec es ejecutable
+- **🚀 Beneficio:** Cambios desde la spec, no el código
+
+### Cómo Alcanzar Cada Nivel en Don Cheli
+
+| Nivel | Comando | Acción |
+|-------|---------|--------|
+| 1 | `/especdev:especificar` → `/especdev:implementar` | Spec → código (spec se archiva) |
+| 2 | Agregar regla en hooks/parar.yml | Verificar que spec se actualiza con cada cambio |
+| 3 | `/especdev:implementar --desde-spec` | Re-generar código desde spec actualizada |
+
+## Prevención de Context Rot
+
+### Regla del 60%
+
+> Si la ventana de contexto está >60% llena, la precisión cae significativamente.
+
+**Estrategias de prevención:**
+
+1. **Cargar reglas bajo demanda** — No todo de golpe
+2. **Subagentes para tareas pesadas** — Mantener contexto principal limpio
+3. **System prompts < 500 tokens** — Conciso y enfocado
+4. **Outputs estructurados** — JSON/tablas desde el inicio
+5. **No re-leer archivos en contexto** — Referenciar, no duplicar
+
+## Integración con Don Cheli
+
+```yaml
+# .especdev/config.yaml
+arnes:
+  reglas_modulares: true
+  max_lineas_por_regla: 500
+  hooks_parar:
+    - lint
+    - tests
+    - types
+    - build
+  nivel_madurez: 2  # spec-anchored
+  prevencion_context_rot:
+    umbral_contexto: 60
+    subagentes_para_tareas_pesadas: true
+    carga_bajo_demanda: true
+```

package/habilidades/auto-correccion/HABILIDAD.md

@@ -0,0 +1,114 @@
+---
+nombre: Auto-Corrección
+descripcion: "Detectar y corregir errores automáticamente sin intervención humana según las reglas de desviación"
+version: 1.0.0
+autor: Don Cheli
+tags: [auto-corrección, aprendizaje, errores, reglas]
+activacion: "auto-fix", "corregir automáticamente", "auto-corrección"
+---
+
+# Habilidad: Bucle de Auto-Corrección
+
+**Versión:** 1.0.0
+**Categoría:** Aprendizaje
+**Tipo:** Rígida
+
+> Adaptado de `learn-rule` de Pro-Workflow — "Las correcciones se acumulan."
+
+## Cómo Mejora el Framework
+
+> "Después de 50 sesiones, el agente casi no necesita corrección."
+> — Pro-Workflow
+
+Cada error del agente se convierte en una **regla persistente** que previene futuros errores. Las correcciones se acumulan multiplicativamente.
+
+## El Concepto
+
+```
+Sesión 1: Agente comete 10 errores
+Sesión 2: 8 errores (2 ya son reglas)
+Sesión 5: 4 errores
+Sesión 10: 2 errores
+Sesión 50: ~0 errores — el agente aprendió
+```
+
+## Formato de Regla
+
+```
+[APRENDER] Categoría: Regla de una línea
+Error: Qué salió mal
+Corrección: Cómo se corrigió
+```
+
+### Ejemplo Real
+
+```
+[APRENDER] Navegación: Confirmar ruta completa cuando hay archivos con nombre igual.
+Error: Editó src/utils.ts en vez de src/auth/utils.ts
+Corrección: Siempre verificar la ruta absoluta antes de editar
+```
+
+## Categorías
+
+| Categoría | Ejemplos |
+|-----------|----------|
+| **Navegación** | Rutas incorrectas, archivo equivocado |
+| **Edición** | Enfoque erróneo, patrón incorrecto |
+| **Testing** | Cobertura faltante, tests frágiles |
+| **Git** | Commits, branches, conflictos |
+| **Calidad** | Lint, tipos, estilo |
+| **Contexto** | Requisitos faltantes, ambigüedad |
+| **Arquitectura** | Abstracción incorrecta, acoplamiento |
+| **Performance** | O(n²), memoria, queries N+1 |
+
+## Activación
+
+El agente detecta automáticamente cuándo aprender:
+- Usuario dice "recuerda esto", "no hagas eso", "aprende de esto"
+- Se identifica un error y su corrección
+- El wrap-up captura learnings
+
+### Flujo
+
+```
+1. Detectar error o corrección
+2. Formatear como regla de una línea
+3. PROPONER al usuario (nunca auto-guardar)
+4. Si aprueba → persistir en memoria
+5. Próxima sesión → cargar reglas
+```
+
+## Almacenamiento
+
+Las reglas se guardan en `.especdev/memoria/aprendizajes.md`:
+
+```markdown
+# Aprendizajes Acumulados
+
+## Navegación (3 reglas)
+- Confirmar ruta completa cuando hay archivos con nombre igual
+- Usar `find` antes de editar archivos en monorepos
+- Las rutas de tests siguen la misma estructura que src/
+
+## Testing (2 reglas)
+- Siempre mockear servicios externos en unit tests
+- No usar `any` en mocks — define tipos parciales
+
+## Arquitectura (1 regla)
+- Servicios de pago van en su propio módulo, no en utils/
+```
+
+## Búsqueda de Reglas
+
+```
+/especdev:buscar-regla testing           # Reglas de testing
+/especdev:buscar-regla "rutas archivos"  # Búsqueda exacta
+/especdev:buscar-regla --todas           # Listar todas
+```
+
+## Guardrails
+
+- **Siempre esperar aprobación** — No auto-guardar
+- **Una línea, específica y accionable** — No "escribir buen código"
+- **Incluir contexto del error** — Para que la regla tenga sentido después
+- **Evitar duplicados** — Verificar si ya existe una regla similar

package/habilidades/brainstorming/HABILIDAD.md

@@ -0,0 +1,88 @@
+---
+nombre: Brainstorming Estructurado
+descripcion: "Sesiones de brainstorming estructurado con técnicas como SCAMPER, mapas mentales y 6 sombreros"
+version: 1.0.0
+autor: Don Cheli
+tags: [brainstorming, ideacion, descubrimiento, creatividad]
+activacion: "brainstorming", "lluvia de ideas", "generar opciones", "explorar alternativas"
+---
+
+# Habilidad: Brainstorming Estructurado
+
+**Versión:** 1.0.0
+**Categoría:** Descubrimiento
+**Tipo:** Flexible
+
+> Adaptado de [superpowers](https://github.com/obra/superpowers) — Ideación visual con companion.
+
+## Propósito
+
+Sesión de ideación estructurada con descubrimiento visual. En vez de preguntas abstractas, se muestran opciones concretas para que el usuario elija.
+
+## Principio
+
+> "Show, don't tell" — Mostrar 3 opciones concretas en vez de hacer preguntas abiertas.
+
+## Flujo (4 fases)
+
+### Fase 1: Encuadre (2 min)
+
+```
+¿Qué problema resolvemos?
+¿Para quién?
+¿Qué restricciones existen?
+```
+
+### Fase 2: Divergencia (10 min)
+
+Generar ideas sin filtrar:
+- Mínimo 5 ideas por ronda
+- Sin juicio ni evaluación
+- Combinar ideas libremente
+- Provocar con inversión ("¿qué pasa si hacemos lo contrario?")
+
+### Fase 3: Convergencia (5 min)
+
+Evaluar cada idea en 3 dimensiones:
+
+| Dimensión | Pregunta |
+|-----------|----------|
+| **Viabilidad** | ¿Se puede construir con los recursos actuales? |
+| **Impacto** | ¿Resuelve el problema central? |
+| **Riesgo** | ¿Qué puede salir mal? |
+
+### Fase 4: Decisión (3 min)
+
+Presentar las top 3 ideas con:
+- Nombre descriptivo
+- 1 oración de resumen
+- Pro/contra principal
+- Siguiente paso concreto
+
+## Output
+
+```markdown
+## Sesión de Brainstorming: [tema]
+**Fecha:** YYYY-MM-DD
+**Participantes:** [usuario + agentes]
+
+### Problema
+[definición]
+
+### Ideas Generadas (N)
+1. [idea] — viabilidad: alta/media/baja
+2. ...
+
+### Top 3 Seleccionadas
+1. **[nombre]** — [resumen]. Pro: [x]. Contra: [y].
+
+### Decisión
+[idea elegida] → Siguiente paso: [acción]
+```
+
+## Guardrails
+
+- Nunca evaluar durante divergencia
+- Mínimo 5 ideas antes de converger
+- Siempre cerrar con acción concreta
+- Registrar en `.especdev/hallazgos.md`

package/habilidades/cambio-carpeta/HABILIDAD.md

@@ -0,0 +1,100 @@
+---
+nombre: Cambio como Carpeta (Change-as-Folder)
+descripcion: "Gestionar cambios de directorio de trabajo del agente de forma segura con validación de contexto"
+version: 1.0.0
+autor: Don Cheli
+tags: [cambio, carpeta, directorio, organizacion]
+activacion: "cambiar carpeta", "ir a directorio", "cambiar proyecto"
+---
+
+# Habilidad: Cambio como Carpeta (Change-as-Folder)
+
+**Versión:** 1.0.0
+**Categoría:** Organización
+**Tipo:** Rígida
+
+> Adaptado de OpenSpec (Fission-AI/OpenSpec) — sistema de cambios como carpetas.
+
+## Cómo Mejora el Framework
+
+Cada cambio (feature, bugfix, refactor) se empaqueta como una **carpeta autocontenida** con todo lo necesario para entenderlo e implementarlo.
+
+## Estructura
+
+```
+.especdev/
+└── cambios/
+    ├── agregar-oauth/                    # Cambio activo
+    │   ├── propuesta.md                  # POR QUÉ este cambio
+    │   ├── specs/                        # QUÉ cambia (delta specs)
+    │   │   └── auth-oauth.delta.md
+    │   ├── diseño.md                     # CÓMO se construye
+    │   └── tareas.md                     # Plan de implementación
+    │
+    ├── corregir-timeout-login/           # Otro cambio activo
+    │   ├── propuesta.md
+    │   ├── specs/
+    │   └── tareas.md                     # (sin diseño — era simple)
+    │
+    └── archivo/                          # Cambios completados
+        └── 2026-03-21-agregar-logout/
+            ├── propuesta.md
+            ├── specs/
+            ├── diseño.md
+            ├── tareas.md
+            └── metadata.json
+```
+
+## Ventajas
+
+| Sin carpetas | Con carpetas |
+|-------------|-------------|
+| Artefactos sueltos por todo el repo | Todo agrupado por cambio |
+| No se sabe qué pertenece a qué | Cada cambio es autocontenido |
+| Difícil trabajar en paralelo | Múltiples cambios activos |
+| No se puede "pausar" un cambio | Context switching natural |
+
+## Cambios Paralelos
+
+Puedes tener múltiples cambios activos simultáneamente:
+
+```
+.especdev/cambios/
+├── agregar-oauth/      ← en progreso (70%)
+├── corregir-timeout/   ← listo para implementar
+└── mejorar-performance/ ← en exploración
+```
+
+### Context Switching
+
+```bash
+# Trabajando en oauth...
+/especdev:aplicar agregar-oauth
+
+# Interrupción urgente
+/especdev:aplicar corregir-timeout
+
+# Volver a oauth
+/especdev:aplicar agregar-oauth
+# → Retoma donde se quedó (tarea 3/5)
+```
+
+## Archivado Masivo
+
+Cuando tienes múltiples cambios completados:
+
+```bash
+/especdev:archivar --masivo
+
+# Detecta conflictos si múltiples cambios tocan las mismas specs
+# Resuelve en orden cronológico
+```
+
+## Ciclo de Vida
+
+```
+PROPUESTO → EN PROGRESO → IMPLEMENTADO → ARCHIVADO
+    │            │              │              │
+propuesta.md  diseño.md    código listo   metadata.json
+  specs/      tareas.md    tests pasan    → archivo/
+```