Dejé de hacer vibe coding. Este es el framework que construí para reemplazarlo.

El problema que nadie quiere admitir

Llevas meses usando IA para codear. Claude, Copilot, Cursor — lo que sea. Y funciona. Las primeras 2 horas van genial.

Después pasan cosas como estas:

• Le pides que implemente un servicio y te escribe // TODO: implement later
• Le pides tests y los escribe después de ver el código — básicamente confirma lo que ya hizo
• Le preguntas si funciona y te dice "sí, debería funcionar" — sin evidencia, sin tests, sin nada
• Cierras la sesión, vuelves al día siguiente, y Claude no recuerda nada de lo que decidieron juntos

Eso es vibe coding. Y es el enemigo del software de calidad.

La pregunta incómoda

¿Cuándo fue la última vez que tu IA escribió un test que falló primero?

Si la respuesta es "nunca" o "no recuerdo", entonces tus tests no están validando comportamiento. Están confirmando implementación. Es como calificar tu propio examen — siempre vas a pasar.

Lo que construí

Después de meses de frustración, construí Don Cheli — un framework de Desarrollo Dirigido por Especificaciones (SDD) que transforma el caos asistido por IA en ingeniería de software real.

La premisa es simple: no puedes escribir código sin haber escrito el test primero. Y no puedes escribir el test sin haber definido la especificación.

Spec → Test → Code. En ese orden. Sin excepciones.

Las 3 Leyes de Hierro

Llamo "leyes de hierro" a las reglas que el framework no permite saltarse bajo ninguna circunstancia:

1. TDD Obligatorio

No es una recomendación. No es un "best practice" que se ignora cuando hay prisa. Es una restricción dura en el pipeline.

/dc:start "Implementar autenticación JWT"

Se genera spec Gherkin con criterios de aceptación
Se escriben tests DESDE la spec (la IA NO ha visto código aún)
Los tests fallan (RED) ← esto es correcto
Se escribe el código mínimo para pasar (GREEN)
Se refactoriza (REFACTOR)

La diferencia clave: cuando la IA escribe tests después del código, los tests están acoplados a la implementación. Cambias la implementación → los tests se rompen aunque el comportamiento sea correcto. Con spec-first, los tests validan comportamiento, no detalles de implementación.

2. Debugging: causa raíz primero

Nada de "prueba cambiando esto a ver si funciona". El framework fuerza un proceso:

Reproducir → Aislar → Entender → Corregir → Verificar

3. Verificación: evidencia antes de afirmaciones

"Los tests pasan" > "creo que funciona". Si no hay evidencia, no se avanza.

Pre-mortem: anticipar el fracaso antes de codear

Esta es la feature que más me gusta y que ningún otro framework tiene.

/razonar:pre-mortem "Migración de PostgreSQL a MongoDB"

La IA imagina que tu proyecto ya falló. Analiza por qué falló. Y te da un plan para prevenirlo. Todo esto antes de escribir una sola línea de código.

Don Cheli tiene 15 modelos de razonamiento:

Modelo	Para qué
Pre-mortem	Anticipar fracaso
5 Porqués	Encontrar la causa raíz real
Pareto	Enfocarse en el 20% que produce el 80%
Inversión	¿Cómo garantizaríamos el fracaso?
Primeros principios	Descomponer al fundamento
Segundo orden	Consecuencias de las consecuencias
Costo de oportunidad	¿Qué pierdo por NO elegir la otra opción?
Reversibilidad	¿Puedo deshacerlo? Calibrar nivel de compromiso
Minimizar arrepentimiento	¿Qué decisión lamentaré menos en 10 años?
Círculo de competencia	¿Esto lo conozco de verdad o solo creo que lo conozco?
Mapa-territorio	¿Mi modelo refleja la realidad?
Probabilístico	Asignar probabilidades en vez de certezas
RLM (3 modelos)	Razonamiento con sub-LLMs para problemas complejos

Ningún otro framework de IA tiene esto. GSD no lo tiene. BMAD no lo tiene. Spec Kit no lo tiene.

Estimación: nadie más lo hace

/dc:estimate docs/prd.md

4 modelos que se complementan:

Modelo	Técnica
Puntos de Función	Complejidad funcional
Planning Poker IA	3 agentes estiman independientemente
COCOMO	Líneas de código estimadas → esfuerzo
Histórico	Comparación con tareas similares

El resultado es un rango: estimado optimista, esperado y pesimista con desglose por feature. Pregunté a cada framework competidor si pueden estimar esfuerzo. La respuesta: ninguno.

*## Debate adversarial: roles que se enfrentan
*
/dc:debate "¿Monolito o microservicios para el MVP?"

Esto invoca roles senior que deben encontrar problemas con las propuestas de los demás:

• CPO: "El monolito nos deja lanzar 2-3x más rápido"
• Arquitecto: "Pero sin boundaries, la extracción futura será un rewrite"
• QA: "Monolito es más fácil de testear end-to-end"
• Seguridad: "Un solo deploy = una sola superficie de ataque... pero también un solo punto de falla"

La regla: "no tengo objeciones" no es una respuesta válida. Cada rol DEBE encontrar al menos un problema. Esto saca a la luz riesgos que un solo agente nunca genera.

## Mesa técnica: expertos con +15 años

/dc:tech-panel "¿Redis o Memcached para caching de sesiones?"

5 expertos senior debaten tu decisión técnica:

• Tech Lead — Visión holística, impacto en velocity del equipo
• Sr. Backend — Patrones de resiliencia, connection pooling, race conditions
• Sr. Frontend — Core Web Vitals, SSR vs CSR, design systems
• Arquitecto — System design, C4 diagrams, ADRs
• Sr. DevOps/SRE — IaC, SLOs/SLIs, zero-downtime deploys

Cada uno respalda sus argumentos con incidentes reales, benchmarks o post-mortems públicos. Argumentos sin respaldo se marcan como [teórico] y tienen menor peso.

Auditoría OWASP integrada

/dc:security-audit

Escanea las 10 categorías de OWASP:

• A01 Broken Access Control — endpoints sin auth, IDOR, CORS
• A02 Cryptographic Failures — passwords en plaintext, JWT sin expiración
• A03 Injection — SQL, XSS, command injection
• A04-A10 — Configuración, componentes vulnerables, logging

Cada hallazgo incluye: severidad, archivo, línea y fix sugerido. No es un plugin externo — está integrado en el pipeline.

El pipeline: 6 pasos, 6 puertas de calidad

mermaid
flowchart LR
    A["SPECIFY"] -->|Gate 1| B["CLARIFY"]
    B -->|Gates 2+3| C["PLAN"]
    C -->|Gate 4| D["BREAKDOWN"]
    D -->|Gate 5| E["IMPLEMENT"]
    E -->|Gate 6| F["REVIEW"]
    F -->|Fail| E
Cada puerta bloquea el avance si no se cumplen los criterios. No hay atajos.

Pero — y esto es importante — no necesitas memorizar nada de esto. Solo ejecutas:


/dc:start "Implementar autenticación JWT"
El framework detecta la complejidad automáticamente y ejecuta el pipeline apropiado. Para tareas simples, es ligero. Para tareas complejas, es exhaustivo. Se adapta.

Comparación honesta con otros frameworks
BMAD    GSD GSD-2   spec-kit    Don Cheli
Stars   42K 39K 3K  82K Nuevo
Comandos    ~20 ~80 ~40 ~10 72+
Skills  ~15 ~15 ~10 ~6  43
Razonamiento    — — — — 15 modelos
Estimación — — — — 4 modelos
Quality gates   — 1   2   4   6
TDD obligatorio — — — — Ley de hierro
OWASP   — — — — Integrado
i18n    — — — — EN/ES/PT
Multi-plataforma    — — — — Claude, Cursor, Antigravity

**Sí, tenemos menos stars. Somos nuevos. Pero en features, ninguno se acerca.**

Multilenguaje real (no solo READMEs traducidos)
Al instalar, eliges tu idioma. Todo el framework se adapta:

Nombres de carpetas: habilidades/ (ES) → skills/ (EN)
Nombres de comandos: /dc:iniciar (ES) → /dc:init (EN) → /dc:iniciar (PT)
Contenido de reglas: traducido a tu idioma
CLAUDE.md: en tu idioma
.cursorrules: en tu idioma

No es un README traducido con los archivos en otro idioma. Es i18n real, todo para que entiendas la estructura, entiendas los comandos y empieces a codear de verdad sin ninguna limitante de idioma o conocimientos avanzados.

Multi-plataforma
Don Cheli funciona con:

Plataforma  Soporte
Claude Code Completo — 72+ comandos, 43 skills, 7 agentes
Google Antigravity  14 skills + 9 workflows + router a 43 habilidades (Aqui no pudo ampliarlo mas pero es un buen nivel de avance)
Cursor  .cursorrules completo (115 líneas) con todos los comandos
Codex/Otros Instrucciones genéricas vía AGENTS.md

**Instalación en 1 minuto
**

curl -fsSL https://raw.githubusercontent.com/doncheli/don-cheli-sdd/main/scripts/instalar.sh | bash -s -- --global --lang es
O si prefieres verificar antes de ejecutar:


curl -fsSL https://raw.githubusercontent.com/doncheli/don-cheli-sdd/main/scripts/instalar.sh -o instalar.sh
cat instalar.sh  # Revisa antes de ejecutar
bash instalar.sh --global
Después, en cualquier proyecto:


/dc:start "Tu tarea aquí"

**Eso es todo. No necesitas leer documentación de 50 páginas. El framework te guía.**

Open source
Apache 2.0. Gratis. Sin tiers pagos. Sin limitaciones.

GitHub: github.com/doncheli/don-cheli-sdd
npm: npx don-cheli-sdd init
Web: doncheli.tv

72 comandos. 43 habilidades. 15 modelos de razonamiento. 4 de estimación. 6 puertas de calidad. TDD como ley de hierro.

Hecho en Latinoamérica para el mundo, si te gusta apoyame con un Star en Github, para poder expandir el framework a muchas mas personas. 

Deja de adivinar. Empieza a hacer ingeniería.