Lección 3 de 13 · 8:51
El onboard: que OpenSpec se explique solo
Lección 3 de 13 · ver temario
- 1Más allá del VibeCoding aparece el Spec-Driven Development
- 2Instala OpenSpec y conoce a Chiquito
- 3El onboard: que OpenSpec se explique solo
- 4Proposal y spec: el porqué y la fuente de verdad
- 5Diseño, tareas y el momento apply
- 6Archivar: cerrar el ciclo y dejarlo documentado
- 7El contexto y el flujo de OpenSpec
- 8Explore: la fase de exploración
- 9Apply: aplica la especificación al código
- 10Verify: verifica el resultado
- 11Personaliza el workflow de OpenSpec
- 12Buenas prácticas y ahorro de tokens
- 13Comparativa de sistemas SDD
Abrimos OpenCode y lanzamos el comando estrella para empezar:
/opsx:onboard háblame en español # claude code y otros
/opsx-onboard háblame en español # opencode
Ese “háblame en español” no es un capricho: el contexto de OpenSpec está en inglés y, si no se lo dices, muchos agentes te contestan en inglés.
El onboard es un tutorial vivo. Comprueba que el CLI está instalado, analiza tu código y te propone tres o cuatro mejoras pequeñas. Eliges una y te va guiando por el ciclo completo, explicándote cada fase mientras la ejecuta sobre tu código de verdad.
Lo primero que hace es un explore: una exploración del proyecto. Aquí se nota que OpenSpec está pensado para brownfield, código que ya lleva tiempo vivo y hay que entender antes de tocar. Después crea el cambio con new: una carpeta en openspec/changes/ con un nombre en kebab-case (algo tipo improve-server-logging) donde va a guardar toda la documentación.
Un detalle: estamos con GPT-5.4 dentro de OpenCode, un modelo razonador. Para esto te recomiendo siempre uno que razone; no hace falta el último de la frontera, pero sí uno decente. Y OpenCode te enseña todo el razonamiento, que para aprender es oro.
Ya tienes el cambio creado. En la siguiente vemos qué mete dentro.