don-cheli-sdd 1.13.0

package/habilidades/estimacion/HABILIDAD.md

@@ -0,0 +1,48 @@
+---
+nombre: Estimación de Desarrollo
+descripcion: "Estimar esfuerzo de desarrollo con 4 modelos: Puntos de Función, Planning Poker IA, COCOMO, Histórico"
+version: 1.0.0
+autor: Don Cheli
+tags: [planificación, estimación, COCOMO, planning-poker, esfuerzo]
+activacion: "estimar esfuerzo", "cuánto tiempo toma", "planning poker", "estimación"
+---
+
+# Habilidad: Estimación de Desarrollo
+
+**Versión:** 1.0.0
+**Categoría:** Planificación
+**Tipo:** Flexible
+
+## Propósito
+
+Generar estimados de desarrollo profesionales usando múltiples modelos en paralelo.
+
+## Modelos de Estimación
+
+### 1. Puntos de Función
+Evalúa complejidad funcional. Mejor para features nuevas.
+
+### 2. Planning Poker IA
+3 agentes independientes estiman la misma tarea. Fórmula PERT: `(O + 4M + P) / 6`
+
+### 3. COCOMO Simplificado
+Basado en LOC estimadas. Mejor para proyectos grandes.
+
+### 4. Histórico
+Compara con tareas similares completadas. Mejor para equipos maduros.
+
+## Flujo
+
+```
+Input (PRD/Feature/Tarea)
+    │
+    ├─ Desglosar en componentes
+    ├─ Aplicar 4 modelos
+    ├─ Calcular consenso
+    ├─ Identificar riesgos
+    └─ Generar estimado-[fecha].md
+```
+
+## Template de Salida
+
+Ver [`plantillas/estimado-desarrollo.md`](../../plantillas/estimado-desarrollo.md)

package/habilidades/extensiones-presets/HABILIDAD.md

@@ -0,0 +1,133 @@
+---
+nombre: Sistema de Extensiones y Presets
+descripcion: "Cargar configuraciones predefinidas para frameworks específicos (Django, Rails, Next.js, etc.)"
+version: 1.0.0
+autor: Don Cheli
+tags: [extensiones, presets, configuracion, frameworks]
+activacion: "preset", "configuración para Django", "template de framework"
+---
+
+# Habilidad: Sistema de Extensiones y Presets
+
+**Versión:** 1.0.0
+**Categoría:** Configuración
+**Tipo:** Flexible
+
+> Inspirado en el sistema de Extensions & Presets de GitHub Spec Kit.
+
+## Cómo Mejora el Framework
+
+Permite personalizar Don Cheli sin tocar el core. Tres niveles de personalización con resolución por prioridad:
+
+```
+⬆ Más alta prioridad
+█ Overrides del proyecto (.especdev/overrides/)
+█ Presets (.especdev/presets/<preset-id>/)  
+█ Extensiones (.especdev/extensiones/<ext-id>/)
+█ Core de Don Cheli (plantillas/ y comandos/)
+⬇ Más baja prioridad
+```
+
+## Extensiones — Agregar Nuevas Capacidades
+
+Las extensiones agregan nuevos comandos, plantillas, o habilidades:
+
+```
+.especdev/
+└── extensiones/
+    └── django/
+        ├── extension.yml        # Metadata
+        ├── comandos/
+        │   └── django-migrate.md  # Nuevo comando
+        ├── plantillas/
+        │   └── model.py.template  # Template custom
+        └── habilidades/
+            └── django-orm/
+                └── HABILIDAD.md   # Skill de Django
+```
+
+### extension.yml
+
+```yaml
+nombre: "django"
+version: "1.0.0"
+descripcion: "Soporte para Django ORM y migraciones"
+autor: "equipo-backend"
+dependencias:
+  - python >= 3.10
+  - django >= 5.0
+```
+
+### Instalar/Desinstalar
+
+```bash
+# Agregar extensión desde repo
+/especdev:extension agregar @github:usuario/especdev-django
+
+# Agregar extensión local
+/especdev:extension agregar ./mis-extensiones/django/
+
+# Listar extensiones
+/especdev:extension listar
+
+# Remover
+/especdev:extension remover django
+```
+
+## Presets — Personalizar Flujos Existentes
+
+Los presets modifican templates y configuraciones del core sin reemplazarlo:
+
+```
+.especdev/
+└── presets/
+    └── empresa-xyz/
+        ├── preset.yml
+        ├── plantillas/
+        │   └── plan.md.template    # Override del template de plan
+        └── reglas/
+            └── estandares.md       # Reglas adicionales de la empresa
+```
+
+### preset.yml
+
+```yaml
+nombre: "empresa-xyz"
+version: "1.0.0"
+descripcion: "Estándares de Empresa XYZ"
+autor: "equipo-plataforma"
+overrides:
+  persona: "profesional"
+  nivel_madurez: 2
+  hooks_parar:
+    - lint
+    - tests
+    - sonarqube
+```
+
+### Presets Incluidos
+
+| Preset | Descripción |
+|--------|-------------|
+| `startup` | Velocidad sobre formalidad. Specs ligeras, minimal hooks |
+| `enterprise` | Máxima formalidad. Todos los hooks, coverage 90%, ADRs obligatorios |
+| `open-source` | Contributing guide, PR templates, CI público |
+| `solo-dev` | Sin PRs, sin ramas, commits directos, hooks mínimos |
+
+## Overrides del Proyecto
+
+Para ajustes de un solo proyecto sin crear un preset:
+
+```
+.especdev/
+└── overrides/
+    └── plantillas/
+        └── tasks.md.template  # Override solo para este proyecto
+```
+
+## Resolución de Conflictos
+
+Si múltiples presets/extensiones definen el mismo comando:
+1. El de mayor prioridad gana
+2. Al remover, se restaura automáticamente el siguiente en prioridad
+3. Si no hay overrides, se usa el core de Don Cheli

package/habilidades/generador-specs/HABILIDAD.md

@@ -0,0 +1,37 @@
+---
+nombre: Generador de Specs
+descripcion: "Generar especificaciones Gherkin automáticamente desde descripciones de features en lenguaje natural"
+version: 1.0.0
+autor: Don Cheli
+tags: [especificación, gherkin, BDD, features, specs]
+activacion: "generar spec", "escribir gherkin", "crear feature file"
+---
+
+# Habilidad: Generador de Specs (Pipeline Gherkin)
+
+**Versión:** 1.0.0
+**Categoría:** Especificación
+
+## Propósito
+
+Convertir requerimientos en lenguaje natural a especificaciones Gherkin trazables.
+
+## Pipeline
+
+```
+especificar → clarificar → planificar-tecnico → desglosar → bucle → revisar
+```
+
+## Formato Feature
+
+```gherkin
+Feature: [Nombre]
+  Como [rol]
+  Quiero [acción]
+  Para [beneficio]
+
+  Escenario: [nombre]
+    Dado que [precondición]
+    Cuando [acción]
+    Entonces [resultado esperado]
+```

package/habilidades/ingenieria-contexto/HABILIDAD.md

@@ -0,0 +1,34 @@
+---
+nombre: Ingeniería de Contexto
+descripcion: "Gestionar qué información cargar en el context window para maximizar calidad de respuestas"
+version: 1.0.0
+autor: Don Cheli
+tags: [fundamental, contexto, memoria, context-window, sesión]
+activacion: "contexto", "qué archivos cargar", "context window"
+---
+
+# Habilidad: Ingeniería de Contexto
+
+**Versión:** 1.0.0
+**Categoría:** Fundamental
+**Tipo:** Rígida
+
+> **Auto-anuncio:** "Usando habilidad de Ingeniería de Contexto para mantener memoria persistente."
+
+## Propósito
+
+Mantener contexto persistente entre sesiones usando el Patrón de 3 Archivos.
+
+## El Patrón de 3 Archivos
+
+| Archivo | Propósito | Frecuencia |
+|---------|-----------|------------|
+| `estado.md` | ¿Dónde estoy? | Cada hito |
+| `plan.md` | ¿A dónde voy? | Transiciones de fase |
+| `progreso.md` | ¿Qué he hecho? | Continuamente |
+
+## Principio
+
+> "Ventana de Contexto = RAM, Sistema de Archivos = Disco"
+
+Los asistentes de IA olvidan porque el contexto no se persiste. Esta habilidad trata el sistema de archivos como memoria persistente.

package/habilidades/integracion-mcp/HABILIDAD.md

@@ -0,0 +1,59 @@
+---
+nombre: Integración MCP
+descripcion: "Conectar y orquestar servidores MCP para extender las capacidades del agente con herramientas externas"
+version: 1.0.0
+autor: Don Cheli
+tags: [mcp, herramientas, integracion, protocolo]
+activacion: "MCP", "conectar servidor", "herramientas externas", "model context protocol"
+---
+
+# Habilidad: Integración MCP
+
+**Versión:** 1.0.0
+**Categoría:** Herramientas
+**Tipo:** Flexible
+
+> Inspirado en la integración MCP de Gentle-AI.
+
+## Cómo Mejora el Framework
+
+MCP (Model Context Protocol) permite a los agentes de IA conectarse a herramientas y fuentes de datos externas. Sin MCP, el agente solo tiene acceso al codebase local. Con MCP:
+
+- 📚 **Documentación viva** de frameworks/librerías (Context7)
+- 📋 **Gestión de proyectos** (Notion, Jira, Linear)
+- 🔍 **Búsqueda semántica** en repositorios
+- 🗄️ **Acceso a bases de datos** para queries ad-hoc
+
+## Servidores MCP Recomendados
+
+| Servidor | Tipo | Propósito | Prioridad |
+|----------|------|-----------|-----------|
+| **Context7** | Remote HTTP | Documentación viva de librerías | P0 |
+| **Filesystem** | Local | Acceso a archivos del proyecto | P0 |
+| **Git** | Local | Operaciones Git avanzadas | P1 |
+| **Notion** | Remote HTTP | Gestión de proyectos | P1 |
+| **Jira** | Remote HTTP | Issue tracking | P1 |
+| **Sequential Thinking** | Local | Razonamiento paso a paso | P2 |
+
+## Configuración
+
+```yaml
+# .especdev/config.yaml
+mcp:
+  servidores:
+    context7:
+      tipo: "remote"
+      url: "https://context7.com/api"
+      habilitado: true
+    notion:
+      tipo: "remote"
+      url: "https://notion-mcp.example.com"
+      habilitado: false
+      nota: "Requiere auth token — configurar por separado"
+```
+
+## Seguridad MCP
+
+- Los servidores MCP **NUNCA** manejan credenciales del framework
+- Tokens de autenticación se configuran **por separado** por el usuario
+- El framework solo indica las rutas de configuración y documentación

package/habilidades/leyes-hierro/HABILIDAD.md

@@ -0,0 +1,45 @@
+---
+nombre: Leyes de Hierro
+descripcion: "Aplicar las 3 leyes no negociables: TDD obligatorio, causa raíz primero, evidencia siempre"
+version: 1.0.0
+autor: Don Cheli
+tags: [calidad, TDD, debugging, verificación, leyes]
+activacion: "leyes de hierro", "TDD obligatorio", "reglas no negociables"
+---
+
+# Habilidad: Leyes de Hierro
+
+**Versión:** 1.0.0
+**Categoría:** Calidad
+**Tipo:** Rígida (no negociable)
+
+## Las 3 Leyes de Hierro
+
+### 1. Ley TDD
+Todo código de producción REQUIERE tests. Sin excepciones.
+
+```
+RED → GREEN → REFACTOR
+1. Escribir test que falla (RED)
+2. Escribir código mínimo que pasa (GREEN)
+3. Mejorar sin cambiar comportamiento (REFACTOR)
+```
+
+### 2. Ley de Debugging
+Primero la causa raíz, luego la corrección.
+
+```
+1. REPRODUCIR el error
+2. AISLAR la causa
+3. ENTENDER por qué ocurre
+4. CORREGIR la causa raíz
+5. VERIFICAR que no regresa
+```
+
+### 3. Ley de Verificación
+Evidencia antes de afirmaciones. Mostrar, no contar.
+
+```
+✅ "Los tests pasan (screenshot adjunto)"
+❌ "Creo que funciona"
+```

package/habilidades/mapa-arquitectonico/HABILIDAD.md

@@ -0,0 +1,93 @@
+---
+nombre: Mapa Arquitectónico Vivo
+descripcion: "Generar y mantener un mapa visual de la arquitectura del sistema con dependencias y flujos"
+version: 1.0.0
+autor: Don Cheli
+tags: [arquitectura, mapa, diagrama, dependencias]
+activacion: "mapa de arquitectura", "diagrama del sistema", "dependencias", "cómo está estructurado"
+---
+
+# Habilidad: Mapa Arquitectónico Vivo
+
+**Versión:** 1.0.0
+**Categoría:** Arquitectura
+**Tipo:** Flexible
+
+> Adaptado de DevilDev (lak7/devildev) — Architecture Map con componentes, conexiones y propiedad de código.
+
+## Cómo Mejora el Framework
+
+Don Cheli ya tiene specs, planes, y diseños técnicos. Pero le faltaba un **mapa visual de la arquitectura** que se mantiene actualizado automáticamente conforme el código cambia.
+
+## Formato del Mapa
+
+El mapa vive en `.especdev/arquitectura.md` y se actualiza con cada cambio:
+
+```markdown
+# Mapa Arquitectónico: mi-proyecto
+
+Última actualización: 2026-03-21
+
+## Componentes
+
+| ID | Componente | Propósito | Stack | Archivos |
+|----|-----------|-----------|-------|----------|
+| auth | Sistema de Auth | Login, sesiones, permisos | NextAuth, JWT | src/services/auth/ |
+| api | API Gateway | Endpoints REST | Next.js API Routes | src/app/api/ |
+| db | Capa de Datos | Persistencia, queries | Prisma, PostgreSQL | src/db/ |
+| ui | Portal de Usuario | Interfaz web | React 19, Tailwind | src/components/ |
+| pay | Pagos | Cobros, suscripciones | Stripe | src/services/payment/ |
+
+## Conexiones
+
+| De → A | Flujo de Datos | Tipo |
+|--------|---------------|------|
+| ui → api | Requests HTTP | Síncrono |
+| api → auth | Verificar token | Middleware |
+| api → db | Queries SQL | Síncrono |
+| api → pay | Crear cobro | Async |
+| pay → api | Webhook evento | Async |
+
+## Diagrama
+
+```mermaid
+graph TD
+    UI[🖥️ Portal Usuario] --> API[🔌 API Gateway]
+    API --> AUTH[🔐 Auth]
+    API --> DB[(🗄️ PostgreSQL)]
+    API --> PAY[💳 Pagos]
+    PAY -.webhook.-> API
+```
+```
+
+## Propiedad de Código
+
+Cada componente tiene un mapeo de propiedad con niveles de confianza:
+
+| Confianza | Significado | Ejemplo |
+|-----------|------------|---------|
+| 0.8-1.0 | Implementación primaria | `src/services/auth/` para Auth |
+| 0.5-0.79 | Soporte/relacionado | `src/utils/crypto/` para Auth |
+| 0.2-0.49 | Dependencia compartida | `src/db/prisma.ts` para todos |
+
+## Auto-Actualización
+
+El mapa se actualiza cuando:
+1. `/especdev:reversa` se ejecuta manualmente
+2. `/especdev:archivar` completa un cambio
+3. Git push (si `auto_sync: true` en WORKFLOW.md)
+
+### Reglas de Actualización (De DevilDev)
+
+1. **El árbol del repo es la fuente de verdad** — Si un directorio no existe, el componente se elimina
+2. **Archivos eliminados → componente eliminado** — Si toda la implementación primaria se borra, el componente desaparece
+3. **IDs estables** — Componentes sobrevivientes mantienen su ID original
+4. **Conexiones válidas** — No referenciar componentes que ya no existen
+
+## Comandos Relacionados
+
+```
+/especdev:reversa → generar mapa desde cero (para proyectos existentes)
+/especdev:explorar → leer el mapa para entender el proyecto
+/especdev:diseñar → proponer cambios al mapa (ADRs)
+```

package/habilidades/memoria-persistente/HABILIDAD.md

@@ -0,0 +1,97 @@
+---
+nombre: Engram — Memoria Persistente Cross-Sesión
+descripcion: "Almacenar y recuperar información cross-sesión usando archivos Engram en disco"
+version: 1.0.0
+autor: Don Cheli
+tags: [memoria, engram, persistencia, contexto]
+activacion: "recordar esto", "memoria", "guardar para después", "engram"
+---
+
+# Habilidad: Engram — Memoria Persistente Cross-Sesión
+
+**Versión:** 1.0.0
+**Categoría:** Contexto
+**Tipo:** Rígida
+
+> Inspirado en Engram de Gentleman-Programming/gentle-ai
+
+## Cómo Mejora el Framework
+
+Sin Engram, cada sesión de IA empieza de cero. El agente "olvida" decisiones, bugs, convenciones y preferencias. Con Engram:
+
+- ⏳ **Persistencia cross-sesión**: las decisiones y convenciones sobreviven al reinicio
+- 🧠 **Memoria semántica**: "¿De qué hablamos la vez pasada?"
+- 📝 **Contexto acumulativo**: cada sesión BUILD sobre las anteriores
+- 0️⃣ **Zero re-explicación**: no repetir instrucciones que ya se dieron
+
+## Cómo Funciona en Don Cheli
+
+### Archivos de Memoria
+
+```
+.especdev/
+├── memoria/
+│   ├── decisiones.md        # Decisiones arquitectónicas registradas
+│   ├── convenciones.md      # Convenciones del proyecto
+│   ├── errores-conocidos.md # Bugs y soluciones encontradas
+│   ├── preferencias.md      # Preferencias del usuario
+│   └── sesiones/
+│       ├── 2026-03-21.md    # Log de sesión
+│       └── ...
+```
+
+### Auto-Registro
+
+En cada sesión, Don Cheli automáticamente:
+
+1. **Lee** los archivos de memoria al comenzar (`/especdev:continuar`)
+2. **Registra** nuevas decisiones cuando se toman
+3. **Actualiza** convenciones cuando se establecen
+4. **Guarda** log de sesión al completar
+
+### Comandos de Memoria
+
+| Comando | Qué Hace |
+|---------|----------|
+| `/especdev:memorizar <insight>` | Guardar un insight manualmente |
+| `/especdev:continuar` | Cargar memoria y contexto de sesión previa |
+| `/especdev:donde-estoy` | Test rápido de 5 preguntas para verificar contexto |
+| `/especdev:traspaso` | Generar handoff completo de contexto |
+
+### Ejemplo de Uso
+
+```markdown
+# .especdev/memoria/decisiones.md
+
+## Decisiones Arquitectónicas
+
+### 2026-03-21: Usar Repository Pattern
+- **Contexto:** Se necesita abstraer la capa de datos
+- **Decisión:** Repository Pattern con inyección de dependencias
+- **Razón:** Facilita testing y cambio de BD
+- **Registrado por:** /especdev:memorizar
+
+### 2026-03-20: No usar ORM
+- **Contexto:** El equipo prefiere SQL directo
+- **Decisión:** Usar query builder en vez de ORM
+- **Razón:** Más control sobre queries, mejor rendimiento
+```
+
+## Integración con el Pipeline
+
+```
+sesión nueva → leer memoria/ → cargar contexto
+    ↓
+trabajar → registrar decisiones automáticamente
+    ↓
+fin sesión → guardar log en sesiones/ → actualizar memoria
+```
+
+## Diferencia con Engram de Gentle-AI
+
+| Aspecto | Engram (Gentle-AI) | Memoria Don Cheli |
+|---------|-------------------|-----------------|
+| **Implem.** | Binary Go separado (puerto 7437) | Archivos markdown (sistema de archivos) |
+| **Ventaja** | Búsqueda semántica en memoria | Sin dependencias externas, portable |
+| **Datos** | BD vectorial | Markdown legible por humanos |
+| **Cross-agente** | Sí (vía MCP) | Sí (cualquier agente lee markdown) |

package/habilidades/obsidian/HABILIDAD.md

@@ -0,0 +1,93 @@
+---
+nombre: Integración Obsidian
+descripcion: "Exportar conocimiento del proyecto a formato Obsidian con links bidireccionales y grafos"
+version: 1.0.0
+autor: Don Cheli
+tags: [obsidian, documentacion, knowledge-graph, markdown]
+activacion: "obsidian", "exportar a vault", "knowledge graph", "notas conectadas"
+---
+
+# Habilidad: Integración Obsidian
+
+**Versión:** 1.0.0
+**Categoría:** Documentación
+**Tipo:** Flexible
+
+> Adaptado de [obsidian-skills](https://github.com/kepano/obsidian-skills) — Markdown Obsidian-flavored + canvas.
+
+## Propósito
+
+Generar documentación compatible con Obsidian usando wikilinks, propiedades, callouts y canvas para visualización de arquitectura.
+
+## Capacidades
+
+### 1. Markdown Obsidian-Flavored
+
+| Feature | Sintaxis | Uso en Don Cheli |
+|---------|---------|------------------|
+| Wikilinks | `[[archivo]]` | Vincular specs, planes, hallazgos |
+| Embeds | `![[archivo]]` | Incrustar diagramas en docs |
+| Callouts | `> [!tip]` | Destacar decisiones, warnings |
+| Propiedades | YAML frontmatter | Metadata de specs y planes |
+| Tags | `#tag` | Categorizar hallazgos |
+| Block refs | `^block-id` | Referenciar secciones específicas |
+
+### 2. JSON Canvas (Diagramas)
+
+Generar archivos `.canvas` para visualizar:
+- Mapa arquitectónico del proyecto
+- Flujo de datos entre módulos
+- Dependencias entre features
+- Pipeline de desarrollo
+
+```json
+{
+  "nodes": [
+    { "id": "a1b2c3", "type": "text", "text": "API Gateway",
+      "x": 0, "y": 0, "width": 200, "height": 100 }
+  ],
+  "edges": [
+    { "id": "e1f2g3", "fromNode": "a1b2c3", "toNode": "d4e5f6" }
+  ]
+}
+```
+
+### 3. Propiedades (Frontmatter)
+
+```yaml
+---
+titulo: Spec de Autenticación
+tipo: spec
+estado: en-progreso
+prioridad: P1
+tags: [auth, seguridad, api]
+creado: 2026-03-22
+autor: DonCheli
+---
+```
+
+### 4. Callouts para Decisiones
+
+```markdown
+> [!decision] Usar JWT sobre sesiones
+> **Contexto:** API stateless para múltiples clientes
+> **Alternativas:** Sesiones server-side, OAuth tokens
+> **Motivo:** Escalabilidad horizontal sin sticky sessions
+
+> [!warning] Riesgo de seguridad
+> Los tokens JWT no se pueden revocar individualmente.
+> Mitigación: refresh tokens con blacklist en Redis.
+```
+
+## Cuándo Activar
+
+- Si el proyecto usa Obsidian como knowledge base
+- Si se detecta carpeta `.obsidian/` en el vault
+- Si el usuario lo solicita explícitamente
+
+## Guardrails
+
+- Wikilinks solo para archivos internos del vault
+- Links externos con markdown estándar `[texto](url)`
+- Canvas máximo 20 nodos (legibilidad)
+- Propiedades siempre en YAML, nunca inline