Diferencias

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

--- clase:daw:daw-proyecto:tema02 [2026/10/14 12:01] – Orden sustantivo-verbo en todos los subcomandos (/test unit run, /developer code review); los tests siempre por tipo, sin «todos» claude
+++ clase:daw:daw-proyecto:tema02 [2026/10/15 07:02] (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]].
-===== Git en Windows =====
+El bucle es siempre el mismo:
-En Linux y Mac, git viene con bash. En Windows, el instalador de Git ([[https://gitforwindows.org/|Git for Windows]]) trae también **Git Bash**, un bash completo con los comandos de Linux (''ls'', ''cat'', ''grep''...). Hace falta porque el script de este proyecto (''app.sh'') es de bash, y así los mismos ficheros valen para todos. Dos pantallas del instalador importan:
+  - 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.
-{{:clase:daw:daw-proyecto:git-setup-bash.png?500|}}
+Dos consecuencias que explican casi todo lo que viene después:
-Elegir **«Use Git and optional Unix tools from the Command Prompt»**: git y los comandos de Linux quedan disponibles desde cualquier terminal (Git Bash, ''cmd'' y PowerShell), que es lo que necesita el agente para ejecutar ''./app.sh start'' o un ''ls''. El aviso de que tapa el ''find'' y el ''sort'' de Windows no afecta a nada de lo que se hace aquí.
+  * **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).
-{{:clase:daw:daw-proyecto:git-setup-pull.png?500|}}
+El detalle, con los tipos de agente que existen, está en [[cursos:sdd:02-skills-agentes-mcp#agentes|Agentes]].
-Elegir **«Only ever fast-forward»**. En este módulo nunca se hace ''git pull'' (abajo, en las reglas para la IA), pero si alguien lo hace por costumbre, con esta opción el ''pull'' falla cuando las historias han divergido en vez de crear un commit de merge sin avisar. Es lo mismo que hace la skill con ''git merge --ff-only''. En Linux y Mac se consigue con ''git config --global pull.ff only''.
+===== Claude Code y OpenCode =====
-===== El repositorio y el agente =====
+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:
-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.
+^ ^ 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 repositorio del proyecto ====
+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.
-Un único repositorio en GitHub, creado desde cero por cada alumno, con el backend y el frontend dentro:
-<code>
+  * Modos de Claude code
-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)
-├── app.sh                   <- start, stop, status y logs de la aplicación (tema 3)
-├── .kiro/                   <- la spec de cada issue y el steering (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]].
+^ Modo ^ Leer ^ Editar en la propia carpeta ^ Comandos simples (mkdir, mv, cp, rm…) ^ Todo el resto ^
+| **Manual** | ✅ | Pregunta | Pregunta | Pregunta |
+| **Accept Edits** | ✅ | ✅ | ✅ | Pregunta |
+| **Plan** | ✅ | No edita en modo plan | ✅ (revisado por el clasificador) | Pregunta |
+| **Auto** | ✅ | ✅ | ✅ | ✅ (revisado por el clasificador; bloquea lo peligroso pero continua) |
-<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>
+  * Modos de opencode
-=== Las dos ramas ===
+^ Modo ^ Leer ^ Editar en la propia carpeta ^ Comandos simples ^ Todo el resto ^
+| Build | ✅ | ✅ | ✅ | ✅ (sin revisión; solo pregunta al leer .env o salir del workspace) |
+| Plan | ✅ | Denegado (solo escribe en ~/.opencode/plan) | ✅ | ✅ |
+===== El contexto =====
-El proyecto tiene solo dos ramas oficiales:
+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:
-  * ''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).
+  * **Es limitado y se llena.** Cuando está lleno, el agente trabaja peor y cada petición cuesta más.
-  * ''main'': lo que hay en producción. Nunca se trabaja en ella; solo recibe lo que ya está en ''develop'' (tema 6).
+  * **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.
-Se crean las dos en el primer commit y se cambia la rama por defecto en GitHub (//Settings → General → Default branch//) o con ''gh'':
+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]].
-<sxh bash>
+===== Skills =====
-git switch -c develop
-git push -u origin develop
-gh repo edit --default-branch develop
-</sxh>
-==== Instrucciones para el agente: AGENTS.md ====
-''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:
-<sxh plain;title:CLAUDE.md>
-@AGENTS.md
-</sxh>
-Así los dos agentes leen exactamente lo mismo y solo hay un fichero que mantener.
-Lo que va dentro, y nada más:
-  * **Qué es el proyecto**, en dos líneas.
-  * **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 ''.kiro/specs/'' 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.
+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'':
-  * **Dos tipos**. Las **de tarea** se invocan escribiendo ''/nombre'' y hacen algo (''/git-flow'', ''/test''). 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.
-  * **Un subcomando por llamada**: todas las skills de tarea del proyecto reciben familia, sustantivo y verbo, como en el tema 1 (''/git-flow start 12'', ''/test e2e run''). Dentro de ''SKILL.md'' los argumentos llegan en ''$ARGUMENTS'' y la skill hace una cosa u otra según la primera palabra.
-  * **''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>
+<sxh yaml;title:.claude/skills/hola/SKILL.md>
 ---
-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 start 12'', no «start y luego finish».
-  * **''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'' y poner las operaciones en inglés, con la gramática del tema 1. Quedan **cinco**:
-^ Operación ^ Qué hace ^
-| ''start 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 |
-| ''update'' | Trae ''develop'' a la rama del worktree actual |
-| ''finish'' | ''update'', ''--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 |
-| ''publish'' | ''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''.
-  * ''finish'' y ''update'' deducen la rama del worktree en el que se ejecutan, como ya hace la skill original.
-En el tema 3 ''start'' crece para escribir el ''.env'' con los puertos del worktree y ''finish'' para parar los contenedores, y en el tema 5 ''finish'' comprueba antes de fusionar que las tareas, la revisión y los tests están en orden.
-<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''; renombrar las operaciones a ''start'', ''commit'', ''update'', ''finish'' y ''publish''; que ''start'' reciba el número del issue, lo lea con ''gh issue view'' y nombre la rama ''<alumno>-<N>-<slug>''; que ''finish'' ponga ''Closes #N'' en el cuerpo del commit; y que ''publish'' 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 start'' con el primer issue y, sin cerrarlo, ''/git-flow start'' 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 finish'' 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 update'' en el segundo y después ''/git-flow finish''.
-==== Ejercicio 7 ====
-  * ''/git-flow publish''. 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 start'' con un issue nuevo. La skill tiene que pararse y decirte por qué. Deshaz el cambio.