spec-driven-development
por addyosmanispec-driven-development es una skill de flujo de trabajo para escribir especificaciones antes del código y luego avanzar por planificación, tareas e implementación con revisión humana en cada fase.
Esta skill obtiene 74/100, así que es una candidata sólida, pero no de primer nivel. Para los usuarios del directorio, eso significa que resulta realmente útil para agentes que necesitan un flujo de trabajo centrado en especificaciones, con suficiente estructura para reducir la improvisación, aunque todavía le faltan archivos de apoyo y guía empaquetada que harían su adopción más sencilla.
- Orientación de uso muy clara: conviene al iniciar un proyecto nuevo, una función o un cambio ambiguo, y no para correcciones triviales.
- Flujo operativo sólido: cuatro fases con control (Specify → Plan → Tasks → Implement) y revisión humana en cada paso.
- Buen nivel de detalle práctico: contenido amplio en SKILL.md con varios encabezados, restricciones y ejemplos de código, lo que facilita que un agente siga el proceso.
- No incluye archivos de apoyo ni comando de instalación: la adopción depende casi por completo de las instrucciones de SKILL.md.
- Entrega en un solo archivo: no hay scripts, referencias ni recursos que refuercen el flujo de trabajo o resuelvan casos límite.
Descripción general de la habilidad spec-driven-development
spec-driven-development es una habilidad de flujo de trabajo para escribir primero una especificación clara y después usarla para guiar la planificación, las tareas y la implementación. Es la mejor opción para la habilidad spec-driven-development cuando vas a empezar una funcionalidad nueva, cambiar la arquitectura o trabajar a partir de requisitos vagos y necesitas reducir al mínimo las suposiciones en el resultado final.
Para qué sirve esta habilidad
Usa esta guía de spec-driven-development cuando el riesgo principal sea construir algo equivocado, no solo construirlo mal. Te ayuda a convertir una idea aproximada en una fuente de verdad compartida que define alcance, comportamiento, restricciones y criterios de aceptación antes de comprometerte con la implementación.
Casos de adopción que encajan mejor
Esta habilidad encaja con equipos y desarrolladores en solitario que buscan una alineación más sólida con una persona revisora, sobre todo cuando una tarea cruza varios archivos, depende de decisiones de producto o es lo bastante grande como para que “solo programa esto” genere retrabajo. También es útil para spec-driven-development en Skill Authoring cuando quieres que la propia habilidad produzca resultados disciplinados y revisables.
En qué se diferencia
Su valor está en el flujo con puertas de control: especificar, luego planificar, luego dividir en tareas y después implementar, con revisión humana en cada paso. Eso la hace más sólida que un prompt genérico, porque reduce las suposiciones ocultas y obliga a tomar decisiones antes, cuando los cambios salen más baratos.
Cómo usar la habilidad spec-driven-development
Instálala y carga el contexto
Para instalar spec-driven-development, añade la habilidad a la configuración de skills de tu agente y abre primero el archivo de la habilidad:
npx skills add addyosmani/agent-skills --skill spec-driven-development
Después lee SKILL.md antes que cualquier otra cosa. Este repositorio no incluye carpetas de apoyo como rules/, references/ o scripts/, así que el contexto de la habilidad vive casi por completo en el archivo principal.
Dale a la habilidad un punto de partida concreto
El patrón de uso de spec-driven-development funciona mejor cuando aportas un objetivo, restricciones y desconocidos ya identificados. Una entrada débil sería “construye un dashboard”. Una entrada sólida sería:
“Crea una especificación para un dashboard que muestre la salud de las suscripciones, admita acceso basado en roles y deba funcionar con nuestra API REST existente. Haz preguntas de aclaración antes de redactar la especificación. No propongas todavía detalles de implementación.”
Eso le da a la habilidad suficiente contexto para sacar a la luz las suposiciones y evitar un diseño prematuro.
Sigue el flujo con puertas de control
La habilidad está diseñada para detenerse en cada fase hasta que se valide. En la práctica, eso significa:
- Especificar el problema y las suposiciones.
- Planificar el enfoque después de aprobar la especificación.
- Dividir el plan en tareas.
- Implementar solo después de revisar las tareas.
Si te saltas los puntos de revisión, pierdes la principal ventaja de la habilidad: menos retrabajo por suposiciones que nadie había comprobado.
Lee primero y usa después
Empieza por SKILL.md y luego usa las secciones de descripción general, cuándo usarla y el flujo con puertas de control como reglas de trabajo. Si vas a adaptarla a tu propio flujo de agente, conserva los puntos de revisión y el comportamiento de “preguntar hasta concretar”, porque son las partes que más probablemente mejoren la calidad del resultado.
Preguntas frecuentes sobre la habilidad spec-driven-development
¿spec-driven-development es mejor que un prompt normal?
Normalmente sí cuando la tarea es ambigua, afecta a varias partes del sistema o sería cara de rehacer. Un prompt normal puede generar código rápido, pero spec-driven-development funciona mejor cuando necesitas acordar qué construir antes de que alguien empiece a programar.
¿Cuándo no debería usarla?
No uses la habilidad spec-driven-development para cambios triviales, correcciones obvias de errores o modificaciones aisladas sin verdadera ambigüedad de producto. En esos casos, la sobrecarga de un ciclo completo de especificación puede llevar más tiempo que el propio trabajo.
¿Es adecuada para principiantes?
Sí, si estás dispuesto a responder preguntas de aclaración y revisar borradores. La habilidad es más fácil de usar que inventar tu propio proceso porque indica al agente que haga una pausa, saque a la luz las suposiciones y avance por fases en orden.
¿Encaja con flujos de trabajo de Skill Authoring?
Sí, especialmente para spec-driven-development en Skill Authoring cuando quieres un proceso repetible para escribir una habilidad nueva o mejorar una existente. Es especialmente útil cuando la tarea de autoría necesita un alcance claro, puntos de revisión y una especificación que pueda validarse antes de implementar.
Cómo mejorar la habilidad spec-driven-development
Da entradas más precisas desde el principio
Los mejores resultados llegan cuando indicas el usuario objetivo, el resultado deseado, las restricciones y lo que aún no se sabe. Por ejemplo: “Migra el flujo de checkout sin cambiar la API pública, conserva los eventos de analítica existentes e identifica cualquier riesgo de dependencias antes de planificar”.
Obliga a la habilidad a nombrar las suposiciones
Un modo de fallo habitual son las especificaciones vagas que parecen completas, pero esconden decisiones críticas. Pide al modelo que enumere las suposiciones antes de redactar la especificación y luego revisa esas suposiciones con la persona ingeniera antes de pasar a la planificación. Ahí es donde spec-driven-development suele ahorrar más tiempo.
Itera sobre la especificación, no sobre el código
Si la primera versión no encaja, corrige el alcance, los criterios de aceptación o las restricciones antes de pedir la implementación. El flujo funciona mejor cuando cada revisión afina el contrato, porque las fases posteriores dependen de la precisión de la especificación.
Úsala cuando las revisiones sean costosas
La habilidad aporta más valor cuando unas suposiciones equivocadas saldrían caras: cambios en varios archivos, cambios de arquitectura o funciones que afectan a varios actores. Si el primer borrador de tu especificación sigue siendo difuso, mantén la fase de especificación más tiempo en lugar de forzar demasiado pronto las tareas o el código.