Diferencias

Muestra las diferencias entre dos versiones de la página.

--- clase:daw:daw-proyecto:tema02 [2026/10/14 01:06] – Nueva sección inicial: el repositorio y el agente (estructura, ramas, AGENTS.md, skills, permisos), con sus ejercicios claude
+++ clase:daw:daw-proyecto:tema02 [2026/10/14 16:05] (actual) – [Claude Code y OpenCode] Lorenzo
@@ Línea 1: / Línea 1: @@
-====== 2. Git en el proyecto ======
+====== 2. IA y agentes ======
-Objetivo del tema: que nadie vuelva a escribir a mano un comando de git del día a día. Al acabar, todo lo de git pasa por la skill ''/git-flow''.
+Objetivo del tema: saber qué es lo que se va a usar durante todo el módulo. Es un repaso rápido de programar con agentes: qué es un agente, cómo funcionan Claude Code y OpenCode, qué es una skill, qué es un MCP y qué son los subagentes y los bucles de revisión. Nada de esto se profundiza aquí: lo que ya está en el [[cursos:sdd:start|curso de programación con IA]] se enlaza, y lo que es de este proyecto se cuenta en su tema (''AGENTS.md'' y la primera skill en el tema 3, la spec y el contexto en el tema 5, las revisiones en el tema 6).
-Lo que ya sabéis y aquí no se repite:
+===== Qué es un agente =====
-  * Git básico, ''.gitignore'' y el formato de los mensajes de commit ''type(#issue):título'': [[clase:daw:daw:1eval:tema01#mensajes_de_commit|Despliegue 1]].
+Un **modelo de lenguaje** responde a un texto con otro texto. Un **agente** es ese modelo metido en un bucle con **herramientas**: puede leer y escribir ficheros, ejecutar comandos y mirar el resultado. La diferencia con un chat es esa: el chat te dice cómo cambiar un fichero; el agente lo cambia, compila, lee el error y vuelve a intentarlo.
-  * Ramas, los tipos de merge, conflictos y, sobre todo, **worktrees** y por qué uno por rama cuando se trabaja con agentes: [[clase:daw:daw:1eval:tema02#worktrees|Despliegue 2]].
-  * Scrum y los tableros de GitHub: [[clase:daw:proyecto:1eval:tema04#scrum_en_github|Proyecto 4]].
-===== El repositorio y el agente =====
+El bucle es siempre el mismo:
-Antes de la primera skill hay que dejar el repositorio del tema 1 preparado para trabajar con el agente: su estructura, sus dos ramas, las instrucciones que lee el agente al empezar y los permisos que tiene.
+  - Recibe una petición («añade un endpoint que devuelva los clientes de una provincia»).
+  - Decide qué herramienta usar (leer ''ClienteController.java'').
+  - Ejecuta la herramienta y el resultado entra en la conversación.
+  - Con lo que ha visto, decide la siguiente (editar el fichero, lanzar ''mvn test'').
+  - Repite hasta que considera que ha terminado, y responde.
-==== El repositorio del proyecto ====
+Dos consecuencias que explican casi todo lo que viene después:
-Un único repositorio en GitHub, creado desde cero por cada alumno, con el backend y el frontend dentro:
+  * **Lo que el agente sabe es lo que tiene en la conversación.** No recuerda nada de la anterior. Lo que tenga que saber siempre, va en un fichero que lee al empezar (''AGENTS.md'', tema 3) o en uno que se le pasa (la spec, el plan).
+  * **Lo que el agente puede hacer es lo que sus herramientas y sus permisos le dejan.** Por eso en este módulo se le dan permisos justos y se le quitan los peligrosos (tema 3 y tema 5).
-<code>
+El detalle, con los tipos de agente que existen, está en [[cursos:sdd:02-skills-agentes-mcp#agentes|Agentes]].
-mi-proyecto/
-├── backend/                 <- Spring Boot (Maven)
-├── frontend/                <- Angular
-├── compose.yaml             <- la aplicación en Docker (tema 3)
-├── compose.override.yaml    <- lo que cambia en desarrollo (tema 3)
-├── manage.sh                <- desplegar en el servidor (tema 6)
-├── planes/                  <- los planes de cada issue (tema 4)
-├── docs/                    <- detalle para el agente, si hace falta
-├── AGENTS.md                <- instrucciones para el agente
-├── CLAUDE.md                <- solo contiene @AGENTS.md
-├── .claude/
-│   ├── skills/              <- las skills del proyecto
-│   └── settings.json        <- permisos del agente, compartidos
-└── .github/workflows/       <- CI y despliegue (tema 6)
-</code>
-La estructura interna de ''backend/'' y ''frontend/'' es la de [[clase:daw:proyecto:1eval:tema02#estructura_de_carpetas|Proyecto 2]].
+===== Claude Code y OpenCode =====
-<note important>El esqueleto del backend nace **sin JPA ni Flyway**. Spring Boot con JPA no arranca si no encuentra una base de datos, y la base de datos llega con Docker en el tema 3. Hasta entonces, el backend es el ''@RestController'' del tema 1 que responde a ''/api/hola''.</note>
+Son los dos agentes de terminal que se usan en el módulo. Se abren en la carpeta del proyecto, leen sus instrucciones fijas y, a partir de ahí, se habla con ellos. Hacen lo mismo con nombres distintos:
-=== Las dos ramas ===
+^ ^ Claude Code ^ OpenCode ^
+| Instrucciones fijas del proyecto | ''CLAUDE.md'' | ''AGENTS.md'' |
+| Skills | ''.claude/skills/'' | ''.claude/skills/'' (la misma carpeta) |
+| Modo plan: solo lee, no toca código | ''Shift+Tab'' hasta //plan mode// | tecla ''Shift+Tab'' |
+| Cambiar de modelo | ''/model'' | ''/models'' |
+| Ver cuánto contexto va usado | ''/context'' | junto a la caja de entrada |
+| Vaciar la conversación | ''/clear'' | ''/new'' |
+| Permisos | ''/permissions'' y ''.claude/settings.json'' | clave ''permission'' de ''opencode.json'' |
+| Servidores MCP | ''claude mcp add'' | ''opencode.json'' |
-El proyecto tiene solo dos ramas oficiales:
+Se usa cualquiera de los dos, y todo lo del proyecto (instrucciones, skills, specs) vale para ambos: lo único que cambia es la configuración. Cómo se instala y se maneja OpenCode, con su caja de entrada, sus modelos y su sesión, está en [[cursos:sdd:03-opencode|OpenCode]]; Claude Code es igual con los nombres de la tabla.
-  * ''develop'': donde se integra el trabajo. Es la rama **por defecto** del repositorio en GitHub, y hace falta que lo sea: GitHub solo cierra un issue desde un commit cuando ese commit llega a la rama por defecto (ver abajo).
-  * ''main'': lo que hay en producción. Nunca se trabaja en ella; solo recibe lo que ya está en ''develop'' (tema 6).
-Se crean las dos en el primer commit y se cambia la rama por defecto en GitHub (//Settings → General → Default branch//) o con ''gh'':
+Modos de Claude code
-<sxh bash>
+^ Modo ^ Leer ^ Editar en la propia carpeta ^ Comandos simples (mkdir, mv, cp, rm…) ^ Todo el resto ^
-git switch -c develop
+| **Manual** | ✅ | Pregunta | Pregunta | Pregunta |
-git push -u origin develop
+| **Accept Edits** | ✅ | ✅ | ✅ | Pregunta |
-gh repo edit --default-branch develop
+| **Plan** | ✅ | No edita en modo plan | ✅ (revisado por el clasificador) | Pregunta |
-</sxh>
+| **Auto** | ✅ | ✅ | ✅ | ✅ (revisado por el clasificador; bloquea lo peligroso pero continua) |
+===== El contexto =====
-==== Instrucciones para el agente: AGENTS.md ====
+El **contexto** es todo lo que el modelo tiene delante en una conversación: las instrucciones fijas, las skills que ha cargado, los ficheros que ha leído, la salida de los comandos y todo lo hablado. Cada mensaje se lo reenvía entero. Dos cosas que hay que tener claras desde el primer día:
-''AGENTS.md'' es el fichero que el agente lee al empezar cada conversación (qué es y cómo se escribe: [[cursos:sdd:03-opencode#agentsmdlas_instrucciones_fijas_del_proyecto|AGENTS.md en OpenCode]]). Claude Code lee ''CLAUDE.md'', así que ''CLAUDE.md'' contiene una sola línea que importa al otro:
+  * **Es limitado y se llena.** Cuando está lleno, el agente trabaja peor y cada petición cuesta más.
+  * **Lo que no está en el contexto no existe para el agente.** Y lo que está de más, estorba: un log de doscientas líneas pegado entero tapa las tres que importan.
-<sxh plain;title:CLAUDE.md>
+De aquí sale la regla de oro del módulo, que ya aparecía en el tema 1: **una conversación por fase**, ''/clear'' entre fases, y lo que una fase necesita de la anterior va en un fichero. Las reglas concretas (qué modelo usar para qué, cuándo compactar) están en el tema 5, y la teoría en [[cursos:sdd:04-ingenieria#ingenieria_de_contexto|Ingeniería de contexto]].
-@AGENTS.md
-</sxh>
-Así los dos agentes leen exactamente lo mismo y solo hay un fichero que mantener.
+===== Skills =====
-Lo que va dentro, y nada más:
+Una **skill** es un fichero de instrucciones que el agente carga cuando toca. Es la forma de enseñarle cómo se hace algo **en este proyecto** sin repetírselo en cada conversación: cómo se cierra un issue, cómo se escriben los tests, qué convenciones sigue el backend. Es una carpeta con un ''SKILL.md'':
-  * **Qué es el proyecto**, en dos líneas.
+<sxh yaml;title:.claude/skills/hola/SKILL.md>
-  * **Cómo se compila, arranca y prueba**: los comandos exactos. En el tema 3 se añade dónde corren Maven y Playwright.
-  * **Reglas del proyecto** que el agente tiene que respetar siempre: las ramas, que git se maneja con ''/git-flow'', que ''planes/'' es histórico (tema 4).
-<note tip>Corto. ''AGENTS.md'' viaja en **todas** las peticiones, así que cada línea de relleno se paga en cada prompt. Lo que sea largo (una explicación de la arquitectura, un procedimiento) va en ''docs/'' y ''AGENTS.md'' dice cuándo leerlo. Es la **divulgación progresiva**: el agente carga el detalle solo cuando lo necesita.</note>
-==== Skills en este proyecto ====
-Qué es una skill y cómo se escribe su ''description'' está en [[cursos:sdd:02-skills-agentes-mcp#skills|Skills]]. La primera skill del proyecto, ''/git-flow'', se escribe en este tema, así que antes hay que saber esto: Lo que hay que saber además para este proyecto:
-  * **Dónde van**: en ''.claude/skills/<nombre>/SKILL.md''. OpenCode también lee esa carpeta, así que hay **una sola copia** para los dos agentes.
-  * **Dos tipos**. Las **de tarea** se invocan escribiendo ''/nombre'' y hacen algo (''/git-flow'', ''/crud''). Las **de conocimiento** no se invocan: el agente las carga solo cuando la tarea encaja con su ''description'' (''convenciones-backend''). Las dos se escriben igual; la diferencia está en la descripción y en que las de tarea tienen un procedimiento.
-  * **''allowed-tools''**: en la cabecera de la skill, la lista blanca de lo que puede ejecutar. Una skill de git que solo puede lanzar ''git'' y ''gh'' no puede borrar una carpeta por error aunque se confunda:
-<sxh yaml>
 ---
-name: estado
+name: hola
-description: Resume el estado del proyecto. Usar cuando se pida qué hay pendiente, cómo va el repositorio o al empezar a trabajar.
+description: Saluda al usuario por su nombre. Usar cuando se invoque /hola.
-allowed-tools: Bash(git status:*), Bash(git worktree list:*), Bash(gh issue list:*)
 ---
+Saluda en castellano a la persona cuyo nombre llega en $ARGUMENTS.
+Si no llega ningún nombre, pregúntalo.
 </sxh>
-''allowed-tools'' lo entiende Claude Code; OpenCode lo ignora y aplica sus propios permisos (abajo).
+Lo que importa de cada parte:
-==== Permisos del agente: lo básico ====
+  * **''description''** es lo que el agente lee para decidir si la carga. Dice qué hace y **cuándo usarla**. Una descripción vaga es una skill que nunca se carga o que se carga cuando no toca.
+  * **El cuerpo** es el procedimiento, escrito como se le explicaría a un compañero nuevo: pasos, en orden, con los comandos exactos y lo que hay que comprobar.
+  * **''$ARGUMENTS''** es lo que se escribe después del nombre: en ''/hola Ana'', ''Ana''. Las skills del módulo reciben así su subcomando (''/test e2e run'').
-El agente pide permiso antes de ejecutar comandos o escribir ficheros. Aceptar uno a uno no es sostenible, y aceptar todo a ciegas tampoco. Lo justo para trabajar:
+Cómo escribir una skill: se le pide al propio agente un primer borrador («escribe una skill que haga X con estos pasos») y se corrige. Se prueba lanzándola y mirando qué hace; si se salta un paso o se inventa uno, se afina el texto. Qué es una skill, cómo se escribe su descripción y los tipos que hay: [[cursos:sdd:02-skills-agentes-mcp#skills|Skills]]. Lo específico del proyecto (dónde van, los dos tipos que se usan, ''allowed-tools'') está en el tema 3, donde se escribe la primera.
-  * **Claude Code**: ''/permissions'' muestra lo permitido. Lo que se permita para el proyecto se guarda en ''.claude/settings.json'', que va al repositorio, para que valga en todos los worktrees:
+===== MCP =====
-<sxh json;title:.claude/settings.json>
+Un **MCP** (//Model Context Protocol//) es un servidor que da al agente **herramientas nuevas**: abrir un navegador y ver una página, consultar la documentación actual de una librería, hacer consultas a una base de datos. El agente las usa como las suyas propias. Lo que es, cómo se conecta y qué servidores existen: [[cursos:sdd:02-skills-agentes-mcp#mcp|MCP]].
-{
-  "permissions": {
-    "allow": [
-      "Bash(git status:*)", "Bash(git diff:*)", "Bash(git log:*)",
-      "Bash(gh issue list:*)", "Bash(gh issue view:*)",
-      "Bash(mvn:*)", "Bash(npm:*)", "Bash(npx:*)",
-      "Bash(docker compose:*)"
-    ],
-    "deny": ["Bash(git push --force:*)", "Bash(rm -rf:*)"]
-  }
-}
-</sxh>
-  * **OpenCode**: en ''opencode.json'' en la raíz del proyecto, la clave ''permission''.
+La diferencia con una skill: la skill es **conocimiento** (cómo se hace algo aquí); el MCP es **capacidad** (poder hacer algo que antes no podía). En el módulo se usan dos y ninguno más, Context7 y Playwright, y se configuran en el tema 5.
-En el tema 4 se completa la lista con lo que haga falta para programar.
+===== Subagentes y bucles =====
+Un agente puede lanzar **otro agente** para una parte del trabajo: un **subagente**, con su propia conversación vacía y, a menudo, con instrucciones y herramientas propias. El principal le encarga la tarea, espera, y recibe **solo el resultado**: todo lo que el subagente ha leído por el camino se queda en su contexto, no en el del principal. Para eso sirven:
-===== Issues y tablero =====
+  * **Mantener limpio el contexto principal.** Buscar en qué ficheros se usa una clase lleva leer veinte; el subagente los lee y devuelve una lista de tres líneas.
+  * **Especializar.** Un subagente que solo revisa, con instrucciones de revisor y sin permiso para editar, no se deja llevar por lo que acaba de escribir. Un agente que revisa su propio código tiende a darlo por bueno; **otro agente, con otro contexto, no**.
-Todo trabajo empieza por un **issue**. El issue es la unidad: de él sale la rama, su número va en los commits y al fusionar se cierra solo.
+Con subagentes se montan **bucles**: un agente hace, otro comprueba, y se repite hasta que la comprobación pasa. El patrón más útil es [[cursos:sdd:05-patrones-agenticos#ejecutor-revisor|Ejecutor-Revisor]]: el ejecutor implementa, el revisor compara el resultado con un criterio (la spec, las reglas de calidad, los tests) y devuelve hallazgos; el ejecutor corrige; otra vuelta. Lo que hace que un bucle funcione o se vuelva loco es su **condición de parada**: tiene que ser algo que se pueda comprobar, no «hasta que esté bien» ([[cursos:sdd:04-ingenieria#ingenieria_de_bucles|Ingeniería de bucles]]).
-El tablero es un **GitHub Project** del repositorio con tres columnas: //Todo//, //In progress// y //Done//. De sus automatizaciones (//Workflows// del proyecto) solo hace falta una, que viene activada de serie: **issue cerrado → Done**. El resto se hace a mano: al crear el issue se añade al tablero, y al empezar a trabajarlo se arrastra a //In progress//. Automatizar eso por línea de comandos no compensa.
+En este módulo el bucle no está dentro de una herramienta: está **en el flujo**, con el alumno en medio ([[cursos:sdd:05-patrones-agenticos#human-in-the-loop_hitl|Human-in-the-loop]]). ''/sdd spec impl'' ejecuta, ''/code review'' revisa con otro contexto y deja los hallazgos en un fichero, el alumno decide, ''/code impl'' corrige, y la condición de parada la comprueba ''/git-flow finish'': tareas hechas, revisión sin hallazgos abiertos, tests en verde. Los tests son el **sensor** del bucle: la única comprobación que no depende de la opinión de nadie, ni de un agente ni de una persona.
-Etiquetas: ''feature'' y ''bug''. No hacen falta más.
+El resto de patrones (pipeline, orquestador, best-of-N...) están en [[cursos:sdd:05-patrones-agenticos|Patrones agénticos]]. No se usan en el módulo, pero conviene saber que existen para reconocerlos cuando una herramienta los lleva dentro.
-Los issues se crean desde la web o con ''gh'':
+===== Lo que el agente no decide =====
-<sxh bash>
+Todo lo anterior hace el trabajo; nada de lo anterior decide **qué** trabajo. Qué se construye, si lo que ha salido es lo que se quería y si se da por bueno, lo decide una persona, y en el módulo eso tiene tres sitios fijos: el issue y la spec, el navegador y los tests, y la revisión antes de cerrar. El agente propone en ficheros y la persona decide entre comandos, nunca dentro de ellos. Es lo que hace que el día de trabajo del tema 1 sea posible sin que nadie se fíe a ciegas.
-gh issue create --title "Alta de clientes" --label feature --body "Formulario de alta con nombre, NIF y email."
-gh issue list
-gh issue view 12
-</sxh>
-===== Las ramas de este proyecto =====
-El modelo de ramas de Despliegue 2 tiene ''develop'', ''release'' y ''master''. Aquí, al ser un proyecto individual con un solo entorno, se recorta a dos:
-  * ''develop'': la integración. Solo existe de verdad **en local**, en la carpeta principal del repositorio; en GitHub está porque es la rama por defecto y es donde se cierran los issues. Nunca se despliega.
-  * ''main'': producción. Cada push a ''main'' despliega en el servidor (tema 6). Nunca se trabaja en ella.
-Y por cada issue, una **rama de trabajo** en su propio worktree:
-^ Cosa ^ Nombre ^ Ejemplo ^
-| Rama | ''<alumno>-<N>-<slug>'' | ''lorenzo-12-alta-clientes'' |
-| Worktree | ''../<repo>-wt-<N>-<slug>'' | ''../mi-proyecto-wt-12-alta-clientes'' |
-El número del issue en el nombre de la rama hace que la skill sepa siempre a qué issue pertenece, sin preguntarlo.
-**Sin pull requests.** En un proyecto individual nadie va a revisar el PR, así que es un trámite que no aporta nada: la rama se fusiona en ''develop'' **en local** y se hace push. La revisión del código la hará la IA antes de fusionar (tema 5).
-===== El ciclo de una rama =====
-  - **Iniciar**: desde la carpeta principal (siempre en ''develop'', actualizada), crear la rama y su worktree.
-  - **Trabajar** en el worktree. Commits pequeños con ''type(#N):título''.
-  - **Actualizar**: si ''develop'' ha avanzado (otro issue que se ha terminado antes), traer ''develop'' a la rama con ''git merge develop''. Los conflictos se resuelven en la rama, nunca en ''develop''.
-  - **Finalizar**: fusionar en ''develop'' con ''--squash'': todos los commits de la rama se funden en uno con el mensaje ''feat(#N): título''. Push de ''develop''. Borrar el worktree y la rama.
-  - **Publicar**: cuando hay algo que sacar, ''develop'' → ''main'' con ''--ff-only'' y push.
-Por qué ''--squash'' hacia ''develop'' y ''--ff-only'' hacia ''main'' está en [[clase:daw:daw:1eval:tema02#usos_de_merge|Usos de merge]].
-==== El commit que cierra el issue ====
-GitHub cierra un issue automáticamente cuando llega a la **rama por defecto** un commit cuyo mensaje contiene ''Closes #N''. Por eso ''develop'' es la rama por defecto, y por eso el commit de la fusión lleva el ''Closes'' en el cuerpo:
-<code>
-feat(#12): Alta de clientes
-Closes #12
-</code>
-Al hacer push de ''develop'', el issue 12 se cierra y el tablero lo pasa a //Done//. No hay que tocar nada en la web.
-===== Reglas para que la IA toque git =====
-Una skill que ejecuta git puede hacer daño si improvisa. Estas reglas van en la skill y no se negocian:
-  * **Nunca ''git pull''**. Siempre ''git fetch --prune'' y ''git merge --ff-only origin/<rama>''. Así, si las historias han divergido, falla en vez de hacer un merge sorpresa.
-  * **Nunca ''--force''**, ni ''--no-verify'', ni ''stash'', ni borrar worktrees con ''--force''.
-  * **Nunca resolver un conflicto**. Si un merge da conflicto, la skill **se para**, enseña ''git status'' y dice qué comandos tiene que ejecutar el alumno. Resolver conflictos es trabajo humano.
-  * **La carpeta principal siempre en ''develop''** y limpia. Si no lo está, la skill se para antes de hacer nada.
-  * **Una operación por invocación**: ''/git-flow iniciar 12'', no «inicia y luego finaliza».
-  * **''allowed-tools'' como lista blanca**: solo ''git'' y ''gh''. Nada de ''rm'', nada de escribir ficheros del proyecto.
-===== La skill /git-flow =====
-Se parte de la skill que ya enlaza Despliegue 2, {{ :clase:daw:daw:1eval:git-flow-skill.md |git-flow-skill.md}}, que es casi lo que hace falta. Se adapta con estos cambios:
-  * Quitar ''release'', ''bajar'' y ''subir''. Quedan **cinco operaciones**:
-^ Operación ^ Qué hace ^
-| ''iniciar N'' | Lee el issue ''N'' con ''gh issue view'', deriva el slug del título, crea la rama ''<alumno>-<N>-<slug>'' desde ''develop'' actualizada y su worktree hermano, y hace push de la rama |
-| ''commit'' | Mira ''git status'' y ''git diff'' del worktree actual y **agrupa los cambios por intención**, no por fichero: un commit por cosa hecha, cada uno con ''type(#N):título''. El ''N'' lo saca del nombre de la rama. Enseña los commits que va a hacer antes de hacerlos |
-| ''actualizar'' | Trae ''develop'' a la rama del worktree actual |
-| ''finalizar'' | ''actualizar'', ''--squash'' en ''develop'' con el mensaje ''feat(#N): <título del issue>'' y ''Closes #N'' en el cuerpo, push de ''develop'', borrar rama remota, worktree y rama local |
-| ''publicar'' | ''develop'' → ''main'' con ''--ff-only'' y push de ''main'' |
-  * El nombre del alumno para las ramas se lee de ''AGENTS.md'' (una línea: «las ramas empiezan por ''lorenzo-''»).
-  * Añadir ''Bash(gh issue view:*)'' a ''allowed-tools''.
-  * ''finalizar'' y ''actualizar'' deducen la rama del worktree en el que se ejecutan, como ya hace la skill original.
-En el tema 3 ''iniciar'' y ''finalizar'' crecen para levantar y parar los contenedores, y en el tema 5 ''finalizar'' lanza antes la revisión por IA.
-<note>''AGENTS.md'' tiene que decir desde ahora: «git se maneja solo con ''/git-flow''; no ejecutes comandos de git que cambien el repositorio fuera de esa skill». Si no, el agente hará ''git commit'' por su cuenta a mitad de una tarea.</note>
 ===== Ejercicios =====
-Todos los ejercicios se hacen en el repositorio del tema 1. Desde el ejercicio 5, ningún comando de git se escribe a mano.
 ==== Ejercicio 1 ====
-  * Escribe ''AGENTS.md'' con: qué es el proyecto, cómo se arranca cada parte y cómo se compila.
+  * Instala Claude Code y OpenCode siguiendo el curso. Abre cada uno en una carpeta vacía y pídele que cree un ''hola.txt'' con la fecha de hoy. Mira qué herramientas ha usado y qué permisos te ha pedido.
-  * Crea ''CLAUDE.md'' con una sola línea: ''@AGENTS.md''.
+  * Con ''/context'' (o el indicador de OpenCode), anota cuánto contexto ocupa una conversación recién abierta y cuánto después de pedirle que lea un fichero grande.
-  * Abre una conversación nueva en Claude Code y otra en OpenCode y pregunta al agente cómo se arranca el backend. Tiene que responder con lo que has escrito.
 ==== Ejercicio 2 ====
-  * Crea la rama ''develop'' desde ''main'' y súbela.
+  * Crea la skill ''/hola'' del tema y comprueba que ''/hola Ana'' saluda y que ''/hola'' a secas pregunta el nombre.
-  * Ponla como rama por defecto en GitHub con ''gh repo edit --default-branch develop''.
+  * Cambia la ''description'' por una vaga («una skill de saludo») y comprueba qué pasa cuando le pides «salúdame» sin invocarla. Vuelve a dejarla bien.
-  * Comprueba en la web del repositorio que al entrar se ve ''develop''.
 ==== Ejercicio 3 ====
-  * Escribe la skill ''/estado'' en ''.claude/skills/estado/SKILL.md'': resume ''git status'', ''git worktree list'' y los issues abiertos con ''gh issue list''.
+  * En Claude Code, pídele que revise un fichero de código cualquiera **usando un subagente** y que te devuelva solo los hallazgos. Compara el ''/context'' antes y después con el de pedirle la misma revisión sin subagente.
-  * Pon en ''allowed-tools'' solo esos tres comandos.
+  * Pídele que corrija uno de los hallazgos y que después un subagente **distinto** compruebe que está corregido. Es el bucle ejecutor-revisor hecho a mano; en el tema 6 lo harán las skills.
-  * Pruébala en Claude Code y en OpenCode.
-  * Crea ''.claude/settings.json'' con los permisos básicos de este tema y comprueba que ''/estado'' ya no pide permiso.
-  * Haz commit de todo y push a ''develop''.
-==== Ejercicio 4 ====
-  * Crea el tablero del repositorio (GitHub Project) con las columnas //Todo//, //In progress// y //Done//.
-  * Comprueba en los //Workflows// del proyecto que está activo «Item closed → Done».
-  * Crea las etiquetas ''feature'' y ''bug''.
-  * Crea con ''gh issue create'' dos issues: «Página de inicio con el nombre del proyecto» y «README con cómo arrancar». Añádelos al tablero.
-==== Ejercicio 5 ====
-  * Descarga {{ :clase:daw:daw:1eval:git-flow-skill.md |git-flow-skill.md}} y guárdala como ''.claude/skills/git-flow/SKILL.md''.
-  * Pide al agente que la adapte a este proyecto: quitar ''release'', ''bajar'' y ''subir''; que ''iniciar'' reciba el número del issue, lo lea con ''gh issue view'' y nombre la rama ''<alumno>-<N>-<slug>''; que ''finalizar'' ponga ''Closes #N'' en el cuerpo del commit; y que ''publicar'' lleve ''develop'' a ''main'' con ''--ff-only''.
-  * Pide que añada la operación ''commit'': agrupar los cambios por intención y proponer los commits antes de hacerlos.
-  * Añade a ''AGENTS.md'' el nombre con el que empiezan tus ramas y la regla «git solo con ''/git-flow''».
-  * Lee la skill entera y comprueba que ''allowed-tools'' solo tiene ''git'' y ''gh''.
-==== Ejercicio 6 ====
-  * ''/git-flow iniciar'' con el primer issue y, sin cerrarlo, ''/git-flow iniciar'' con el segundo. Comprueba con ''git worktree list'' que hay dos worktrees hermanos.
-  * Pasa los dos issues a //In progress// en el tablero.
-  * En el primer worktree pide al agente la página de inicio; en el segundo, el README.
-  * En cada worktree, ''/git-flow commit''. Mira los mensajes: tienen que llevar ''type(#N):título''.
-  * ''/git-flow finalizar'' en el primero. Comprueba en GitHub que el issue está cerrado y en //Done// y que el worktree y la rama han desaparecido.
-  * ''/git-flow actualizar'' en el segundo y después ''/git-flow finalizar''.
-==== Ejercicio 7 ====
-  * ''/git-flow publicar''. Comprueba que ''main'' tiene los mismos commits que ''develop''.
-  * Con la carpeta principal en ''develop'', modifica un fichero sin hacer commit y lanza ''/git-flow iniciar'' con un issue nuevo. La skill tiene que pararse y decirte por qué. Deshaz el cambio.