Primero va la spec.Y la lees antes que el código.

El ciclo: spec, revisión, plan, revisión, tareas, construcción

En lugar de un prompt enorme y un montón de código, el trabajo pasa por documentos, cada uno revisado por ti antes de escribir el siguiente.

1. Spec: qué y por qué

   Qué debe hacer la funcionalidad, para quién y qué no debe hacer. Sin nombres de archivo ni decisiones técnicas todavía.

2. Plan: cómo

   El enfoque: qué partes cambian, en qué orden, con qué riesgos. El plan responde a la spec.

3. Tareas: pasos pequeños

   Una checklist que el agente puede recorrer y marcar, con cada tarea lo bastante pequeña para comprobarla.

4. Construcción

   Solo ahora escribe código el agente, sobre documentos que ya has leído.

Una plantilla de spec breve

Una spec no necesita ser larga. Seis títulos bastan para detectar la mayoría de los malentendidos:

# Feature name

## Goal
## Non-goals
## Users
## Requirements
## Edge cases
## Open questions

Non-goals y Open questions son los que la gente se salta y los que más necesitan los agentes. Un agente al que se le dice qué no construir, y qué sigue sin decidir, pregunta en lugar de adivinar.

Hacerlo en Claude Code, Codex y Cursor

Los tres pueden escribir los documentos, y cada uno tiene un plan mode para el paso de planificación: el plan mode de Claude Code, el plan mode de Codex y el plan mode de Cursor.

Para automatizar el paso de revisión, pon una regla en CLAUDE.md o AGENTS.md: tras escribir una spec o un plan, el agente te lo envía con request_review en DotMD y espera. El agente se detiene entonces después de cada documento y espera tus comentarios o tu aprobación, sin gastar tokens mientras espera. DotMD puede añadir la regla por ti: mira CLAUDE.md y AGENTS.md.

Una revisión que escala

El chat es un mal sitio para revisar un documento. En su lugar lees la spec con formato en DotMD, seleccionas el pasaje erróneo y pulsas ⌥⌘M. El comentario queda unido a sus líneas, así que el agente sabe exactamente a qué te refieres. Puedes escribir todos los comentarios primero y enviarlos de una vez.

Cuando el agente los ha corregido, cada cambio aparece en el archivo: texto antiguo en rojo, texto nuevo en verde, junto al comentario al que responde. Accept o Reopen en cada uno. DotMD también lista los cambios que nadie pidió. Mira Revisar cambios.

Para una segunda opinión, deja que otro agente revise primero. Una spec escrita por Claude Code y comentada por Codex te llega con los huecos evidentes ya marcados, y tú decides qué observaciones recibe quien la escribió: Un agente revisa a otro.

Herramientas para el desarrollo guiado por specs

• Markdown sin más en el repositorio. Una carpeta docs/specs y la plantilla de arriba son una configuración completa.
• Los plan modes. La forma propia de cada agente de planificar antes de construir.
• GitHub Spec Kit. Un kit de código abierto que da a tu agente comandos para cada paso y escribe spec.md, plan.md y tasks.md por ti: GitHub Spec Kit.

Elijas lo que elijas, los documentos son archivos Markdown, y DotMD lee cualquiera de ellos.

Preguntas sobre el desarrollo guiado por specs

Más preguntas