Objetivo del tema: usar bien al agente para programar. No se enseña a programar; se enseña a pedir el trabajo de forma que salga bien y a comprobar que ha salido bien. Al acabar, el proyecto tiene su primer CRUD completo hecho así, y dos skills que recogen cómo se escribe el código en este proyecto.

Lo que ya está contado en el curso de programación con IA y aquí no se repite: qué es el Spec-driven development y por qué encaja con los agentes, los modos Plan y Build de OpenCode, y la ingeniería de contexto.

Los frameworks de SDD completos (OpenSpec, Spec Kit, cc-sdd) generan requisitos, diseño y tareas en documentos separados. Para un proyecto de este tamaño, donde cada issue es un cambio pequeño o mediano, eso es más papeleo que trabajo. Lo que sí compensa, y es lo que se queda, son dos cosas:

1. La intención escrita en un fichero antes de tocar código, revisada por una persona.
2. Ejecutarla con el contexto limpio, en una conversación nueva.

Ese es el flujo de cada issue:

En Claude Code, Shift+Tab hasta plan mode. En OpenCode, Tab hasta Plan. En ese modo el agente lee el proyecto y propone, pero no escribe código.

Lo que se le dice:

Quiero implementar el issue #12 (gh issue view 12). Antes de proponer nada, hazme
las preguntas que necesites. El resultado de este plan es SOLO el fichero
planes/12-alta-clientes.md: al aprobarlo, guárdalo y para.

El plan tiene que decir qué y cómo:

• Cambios en la base de datos (la migración), en el backend (qué clases en qué capas) y en el frontend (qué componentes y rutas).
• Las decisiones de diseño que haya tomado y por qué.
• Los criterios de aceptación: qué tiene que poder hacer el usuario cuando esté terminado, en frases comprobables («al guardar un cliente sin NIF, el formulario muestra el error y no se crea»). En el tema 5 esas frases se convierten en los tests E2E.

Revisarlo es el trabajo humano del flujo. Es mucho más barato corregir una frase del plan que corregir el código que sale de ella. Si el plan tiene algo que no convence, se le dice y se repite hasta que esté bien.

Al aprobar el plan, el agente guarda planes/12-alta-clientes.md en el worktree y se para. Entonces /clear (/new en OpenCode).

Por qué: al salir del modo plan, por defecto el agente implementa en la misma conversación, arrastrando todo lo que ha leído y descartado mientras planificaba. Ese ruido empeora el resultado y encarece cada petición. Con el plan en un fichero, la conversación de planificar es desechable.

Ejecuta @planes/12-alta-clientes.md. Al acabar, compila y pasa los tests.

El agente implementa con el contexto limpio: solo tiene AGENTS.md, las skills de convenciones que carga y el plan. Cuando termina, el alumno prueba la aplicación en la URL del worktree y, si algo no está bien, se le pide en la misma conversación.

planes/ es la versión mínima de la carpeta de especificaciones de un SDD. Se sube a git: el plan viaja con la rama, entra en develop en el mismo commit que el código y /revisar (tema 5) lo usa para comprobar que el código hace lo que se pidió.

Es un registro de lo que se pidió, no documentación: cuando el código cambie después, el plan no se actualiza. Para que el agente no se confunda con planes viejos, AGENTS.md lleva esta línea:

planes/ es histórico: la fuente de verdad es el código. No leas planes antiguos salvo que te lo pidan.

El contexto es todo lo que el modelo tiene delante en una conversación: AGENTS.md, las skills cargadas, los ficheros que ha leído, la salida de los comandos que ha ejecutado y todo lo que se ha hablado. Cada mensaje lo reenvía entero. Cuanto más lleno, peor trabaja y más cuesta. Reglas:

• Una conversación por tarea. /clear entre tareas. Lo que tenga que sobrevivir, a un fichero.
• El modelo bueno para planificar, el barato para ejecutar cosas claras. /model en Claude Code, /models en OpenCode.
• No pegar logs enteros. Solo el error y las líneas de alrededor.
• Mirar el contador. /context y /cost en Claude Code; OpenCode lo muestra junto a la caja de entrada. Cuando el contexto pasa de la mitad, o se cierra la tarea o se hace /compact.

El agente escribe código de cualquier manera si no se le dice cómo se hace en este proyecto. Y decírselo en cada prompt no escala. Para eso están dos skills de conocimiento (no se invocan: el agente las carga solo cuando va a tocar backend o frontend):

La arquitectura es la que ya conocéis de Programación y DWS: aquí no se inventa una nueva.

Se escriben a partir del código, no de la teoría. Después del primer CRUD, revisado y corregido hasta que esté como tiene que estar, se le pide al agente: «lee el CRUD de clientes y escribe la skill convenciones-backend describiendo cómo está hecho, para que el siguiente salga igual». El alumno corrige lo que no sea una convención sino una casualidad.

La description de una skill de conocimiento dice cuándo cargarla:

---
name: convenciones-backend
description: Cómo se escribe el código del backend en este proyecto (capas, nombres, DTO, migraciones). Cargar siempre antes de crear o modificar cualquier clase Java o fichero SQL.
---

Dos servidores MCP y ninguno más (qué es un MCP: MCP):

• Context7: documentación actualizada de Spring Boot y Angular. Sin él, el agente escribe código de la versión que recuerda, que no es la que usáis.
• Playwright MCP: el agente abre la aplicación en un navegador y la ve. Sirve para que compruebe por sí mismo que una pantalla funciona, y en el tema 5 para generar los tests E2E.

Se configuran con claude mcp add en Claude Code y en opencode.json en OpenCode, siguiendo la página de cada servidor.

En el tema 2 se permitió lo básico. Para programar, el agente tiene que poder compilar, pasar tests y levantar la aplicación sin preguntar en cada paso. La lista de .claude/settings.json queda así:

• Permitido: mvn, npm, npx (incluido npx playwright), docker compose, gh issue, gh run y las lecturas de git (status, diff, log, worktree list).
• Pregunta: escribir ficheros fuera del worktree, docker a secas, cualquier curl a un sitio que no sea localhost.
• Denegado: git push –force, rm -rf, y cualquier git que cambie el repositorio (commit, merge, push), que solo puede ejecutar /git-flow por su allowed-tools.

En OpenCode, lo mismo en la clave permission de opencode.json.

• Configura Context7 y el MCP de Playwright en Claude Code (claude mcp add) y en OpenCode (opencode.json).
• Comprueba que funcionan: pide al agente la forma actual de declarar una ruta en Angular y que abra la aplicación del worktree y te diga qué ve.
• Completa .claude/settings.json con los permisos de este tema y súbelo.

• Crea un issue para la primera entidad de tu proyecto con un CRUD completo (por ejemplo «CRUD de productos») e inícialo.
• Entra en modo plan y pide el plan con el prompt del tema: que pregunte lo que no esté claro y que el resultado sea solo planes/<N>-<slug>.md.
• Lee el plan. Comprueba que tiene migración, clases por capas, componentes y rutas, y criterios de aceptación comprobables. Corrige hasta que esté bien.
• Sal del modo plan, comprueba que el fichero existe y que el agente no ha tocado nada más.
• /clear y Ejecuta @planes/<N>-<slug>.md.
• Prueba la aplicación en la URL del worktree: listado, alta, edición, borrado y las validaciones. Lo que no esté bien se pide en la misma conversación.
• Lee el código generado clase por clase: es la referencia de todos los CRUD que vienen después.

• Pide al agente: «lee el CRUD de <entidad> y escribe la skill convenciones-backend describiendo cómo está hecho, para que el siguiente salga igual». Lo mismo para convenciones-frontend, incluyendo la regla de data-testid.
• Revisa las dos: quita lo que sea casualidad y no convención. Comprueba que la description dice cuándo cargarlas.
• /clear y pide un cambio pequeño en el backend. Comprueba que el agente carga convenciones-backend sin que se lo digas.

• Añade a AGENTS.md la línea sobre planes/.
• /git-flow commit y /git-flow finalizar. Comprueba que el plan ha entrado en develop en el mismo commit que el código.
• Mira /context al final de la conversación de ejecución y anota cuánto ha ocupado.