Fans del Spec Driven Development, van a amar sdd-flow

La semana pasada lancé Redakt, una herramienta open source de cumplimiento GDPR. Seis features para una UI web y una REST API que nos ayudan a manejar mejor los PII (Información de Identificación Personal).

Llevaba meses usando el proceso de spec driven development (SDD) a través de un plugin que construí. Cuando vi que Claude había expandido la ventana de contexto a un millón de tokens, pensé: "¿Por qué no intentar llevar al límite la forma en que desarrollaba software?" Lo que quiero decir es que el proceso SDD fue creado para ayudar con la gestión del contexto. Sigue un ciclo de desarrollo de software tradicional y riguroso, pero era lento en comparación con la velocidad a la que se mueven las cosas en el espacio de la AI. Decidí intentar desarrollar un feature de un solo tiro usando un skill para orquestar las fases de un ciclo de desarrollo, y funcionó sorprendentemente bien.

El skill no fue lo único que optimizó el proceso. El lanzamiento de --permission-mode auto por parte de Anthropic la semana pasada fue el empujón que necesitaba para sacarme los pañales. Estaba ansioso por probarlo. Este modo está limitado por ahora a cuentas de Teams. Al principio era inestable, pero me dio una probada de la fruta prohibida. No quería volver a confirmar cada solicitud. En casa, sabía que había otra opción, una peligrosa, que había evitado hasta ahora: --dangerously-skip-permissions. Después de casi un año usando Claude, y sin haber tenido ningún momento de "oh mierda", decidí quitar todas las barreras y saltarme los permisos. Se sintió como si la gravedad me empujara la cara hacia atrás, como se ve en los videos de pilotos de combate cuando vuelan a varios Machs... y la sensación es adictiva.

SDD, No STD

No STD, como suele escupir mi modelo de voz a texto. El desarrollo guiado por especificaciones le indica a la AI que investigue el codebase y los requerimientos, escriba la especificación y luego implemente contra esa especificación. La spec se convierte en lo que versionas y revisas, mientras que el código es el output.

Me gustó el concepto y adoré los resultados.

Qué hace /sdd-flow

/sdd-flow es un skill de Claude Code, un slash command personalizado que invocas con una tarea:

/sdd-flow Add GDPR-compliant audit logging for all anonymization requests

Luego una pipeline de subagentes toma el control. Conversaciones separadas de Claude, cada una con una ventana de contexto nueva, cada una manejando una fase.

Investigación. El primer subagente investiga el codebase. Para el feature de audit logging de Redakt, mapeó la configuración de logging existente, encontró un bug de handler duplicado que yo no sabía que existía, y marcó que el schema en el código había divergido de la spec original. Produjo un documento de investigación con rutas de archivo, números de línea específicos y puntos de integración.

Revisión adversarial de la investigación. Un segundo subagente destroza la investigación. Para el audit logging, encontró problemas reales: seis brechas críticas, cuatro suposiciones cuestionables, cuatro perspectivas que faltaban.

Especificación. Un subagente de planificación lee la investigación revisada y escribe una spec completa: requerimientos funcionales, casos límite, escenarios de falla, restricciones de seguridad.

Revisión adversarial de la spec. Para el audit logging, esto detectó un problema que, si se hubiera solucionado en la capa de auditoría, habría implicado cambios invasivos en funciones compartidas más arriba.

Implementación, revisión de código, revisión crítica. El código y los tests se escriben contra la spec. Un subagente de revisión de código verifica la alineación mientras un subagente de revisión crítica hace un pase adversarial final. Cada hallazgo, sin importar qué tan grave sea, se resuelve antes de un commit.

Cómo se ve /sdd-flow

Cuando /sdd-flow termina, obtienes un directorio así:

SDD/
├── research/
│   └── RESEARCH-006-audit-logging.md
├── requirements/
│   └── SPEC-006-audit-logging.md
├── prompts/
│   ├── PROMPT-006-audit-logging-2026-03-29.md
│   ├── implementation-complete/
│   │   └── IMPLEMENTATION-SUMMARY-006-...md
│   └── context-management/
│       └── progress.md
└── reviews/
    ├── CRITICAL-SPEC-audit-logging-20260329.md
    └── CRITICAL-IMPL-audit-logging-20260329.md

Un Skill, Dos Modos

El modo supervisado es el predeterminado porque te obliga a tomar decisiones críticas que normalmente no deberían automatizarse. Estas decisiones incluyen revisar la investigación completada y revisar el código antes del commit.

El modo autónomo existe para features donde los requerimientos están claros y tenés confianza. Lo usé para algunos de los features posteriores de Redakt después de que los primeros dos probaron el proceso. Pero hacer pausas para revisar es el predeterminado por una razón: la confianza es con frecuencia sobreconfianza.

Pruébalo

Tanto el skill como el plugin son open source:

• Skill (orquestador): claude-skills
• Plugin (comandos de fase): claude-plugins
• Redakt (construido con él): redakt, revisá el directorio SDD/ para ver el rastro completo de artefactos

Los artefactos en el directorio SDD/ de Redakt son el mejor argumento que puedo hacer. Lee los documentos de investigación, las specs y especialmente las revisiones críticas. Y después dejá que el SDD fluya.