Spec Driven Development con GitHub Copilot CLI y OpenSpec
Kiquenet
Herramientas: GitHub Copilot CLI
Solución y proyectos NET Framework, ASP.NET MVC ...
En la primera prueba se le proporcionó a Copilot todo el funcional y diseño del módulo de xxxx como proposal.md de OpenSpec, sin apenas contexto adicional sobre el proyecto, y se le dejó planificar e implementar.
Qué pasó:
· OpenSpec no terminaba de integrarse con Copilot CLI, pero el propio CLI lo resolvió usando npx.
· Creó todos los artefactos de planificación (proposal, specs, design, tasks) antes de tocar código, e incluso detectó inconsistencias entre la nueva funcionalidad y el estado actual de la aplicación.
21 mins de planificación y 1 hora en total, la sesión consumió 1.200 créditos de IA !!!
Mejorando dando contexto: Se creó un copilot-instructions.md con invariantes y ADRs de la solución, rellenado con ayuda del propio Copilot.
decidir cómo
estructurar las instrucciones:
¿un fichero único?
¿varios por área?
copilot-instructions.md vs AGENTS.md vs prompts)
tasks.md contradecía
las directrices de copilot-instructions.md ?
OpenSpec es "fluid, not rigid":
los bugs de un cambio aún activo se arreglan dentro del mismo cambio (añadiéndolos como tareas a tasks.md, que es una checklist viva), reconciliando la spec si el fix cambia comportamiento, y solo entonces se archiva — porque "at archive time your specs become the truth of record". Solo se abre un cambio nuevo si la intención cambió fundamentalmente.
1.
El
ecosistema aún se mueve: los
estándares para instrucciones, ADRs y conocimiento del proyecto
(copilot-instructions vs AGENTS.md vs skills…) siguen evolucionando. Mejor una
solución "suficientemente buena" hoy que buscar la perfecta, a la
espera de que la tecnología se consolide.
Con especificaciones delta claras, contexto del proyecto bien cuidado y un humano revisando en los puntos de control, Copilot CLI + OpenSpec es ya una forma viable de desarrollar funcionalidades reales — no un juguete de demos.
El rol del desarrollador se desplaza: menos teclear, más especificar, revisar y decidir.
Consolidar el contexto: seguir acumulando conocimiento en .github/instructions/ y migrar progresivamente funcional/diseño a openspec/specs/ en ficheros pequeños.
El flujo de trabajo recomendado
1. EXPLORE /openspec-explore → discutir el problema, decidir slices
2. PROPOSE
/openspec-propose → generar
artefactos… y REVISARLOS a fondo
3. APPLY
/openspec-apply-change → implementación por agentes
4. REVISAR
probar en local; bugs → tasks.md del MISMO cambio, uno a uno
5. ARCHIVE
solo cuando specs == código; las specs pasan a ser canónicas
Reglas de oro: 8–12 tareas por cambio (si salen 40, trocear en slices); un slice = algo probable de principio a fin; nunca archivar sin verificación manual.
Cuándo usar qué
Quieres… Usa
Programar sin más, con las reglas del proyecto
aplicadas
Nada — las instrucciones se auto-cargan
(guardarraíles pasivos)
Una funcionalidad completa (plan → código → test
→ auditoría)
/agent orchestrator — delega él mismo
en Backend/Frontend/Tester/Security
Una tarea especializada suelta
/agent Backend Agent directamente, o mencionarlo en el prompt
Gestión de cambios spec-first
Skills
— "propose a change for X" dispara openspec-propose
Generar
documentos/artefactos de estrategia
Prompts
(/ + nombre en VS Code; @-mención del fichero en CLI)
Hábitos que multiplican el valor
1. Verificar qué está cargado: /env y /instructions al empezar la sesión. El trabajo agéntico, en CLI/VS Code (en Visual Studio, confirmar 17.14+ y el setting de custom instructions).
2. Referenciar ficheros explícitamente (@design.md, ejemplo canónico como RatingBlocksService): el auto-load es best-effort.
3. Plan mode (Shift+Tab) para todo lo no trivial: aprobación antes de trabajo.
4. Re-anclar sesiones largas: tras /compact o en chats largos, repetir la invariante crítica de la tarea ("recuerda: BD_CHAR, nunca @/:" ).
5. Tratar .github/ como código: si cambia una convención, actualizar instrucciones/agentes va en el mismo PR. Mantener una única declaración canónica de cada regla (las contradicciones aparecen cuando la misma regla vive duplicada en 5 ficheros).
6. Uso headless/CI: copilot --agent="Tester Agent" -p "..." en scripts; /delegate para que el agente cloud abra un PR; /fleet para paralelizar pasos independientes.
Kiquenet
No lo he instalado aún. Supongo que si lo instalas, no afecta, hasta que apliques sus comandos Propose -> Apply -> Archive
Además, veo que cada cierto tiempo lo mejoran o cambian cosas, la última versión es de Julio 2026.
OpenSpec v1.6.0 (Julio 2026)
https://siemprelisto.cl/tecnologias/openspec/00-indice/
Kiquenet
Fission AI publico un benchmark usando un proyecto de CRM Dashboard (CRUD, graficas, filtros, autenticacion). Los resultados comparan el tiempo desde la idea hasta la implementacion verificada:
Framework
Tiempo total
Artefactos
Ideal para
OpenSpec
~12 min
~250 lineas/cambio
Brownfield, iteracion rapida
Spec-Kit
~90 min
Variable
Specs formales y rigurosas
BMAD
~5.5 horas
~800+ lineas
Greenfield complejo
Estos numeros no significan que uno sea “mejor” que otro. Significan que cada herramienta esta optimizada para un escenario diferente:
- OpenSpec sacrifica completitud por velocidad. Ideal para cambios frecuentes sobre codigo existente.
- Spec-Kit prioriza rigurosidad formal. Ideal para sistemas donde las specs son contrato legal.
- BMAD prioriza exhaustividad. Ideal para proyectos nuevos con muchas incognitas.