Tres sesiones, un equipo dev autónomo

Nueve bloques, manos al teclado

Cómo trabajamos hoy

Todo queda en un repo

# Clónalo al arrancar — lo usamos toda la sesión
git clone <repo-practicas>   # onedev-practicas-claude
# live/     → ejercicios en sesión
# deberes/  → para casa (antes de la Sesión 2)
# recursos/ → chuletas (git worktree, agentes)

• Cada ejercicio trae su README: objetivo, pasos y criterio de "hecho".
• Lo que no acabemos en vivo queda como deberes.
• El caso práctico es ONEDEV-63 sobre onedev-grid-service.

Qué nos llevamos hecho

Del Kick-off a las manos en el teclado

Lo que ya sabéis, ahora en los dedos

Mismo ejercicio, todos a la vez

Un contexto, el mismo para todos

# En la raíz del repo de OneDev
claude

# /init lee el proyecto y genera un borrador de CLAUDE.md
/init

# Comparar con la plantilla del equipo y cerrar los [CONFIRMAR] del stack

• El borrador de /init es el punto de partida, no el final
• Cerramos en vivo los [CONFIRMAR] del stack de OneDev
• Se versiona en el repo: mismo CLAUDE.md para todo el equipo · live/02-claude-md

El trabajo mal definido

Cuando el trabajo llega mal definido al copiloto, los síntomas son siempre los mismos. Reconocerlos es el primer paso.

Tool · Prompt · Context

La spec como contrato ejecutable

Ingesta de capacidad de red

Proposal → Apply → Archive

El ciclo no es lineal: tiene puntos de retorno definidos. La intención primero, la ejecución después.

Plan → ejecutar → verificar

# 1 · Plan: pide el plan, NO que ejecute (modelo Opus)
/plan implementa el scraper de REE (generación y demanda) — ONEDEV-211

# 2 · Revisa el plan, apruébalo y deja que ejecute (Sonnet)
# 3 · Verifica antes del PR: pytest verde + revisión automática
/code-review

• El plan mode es el Proposal: el contrato antes de tocar código
• /code-review revisa, pero no sustituye al criterio del equipo

Cuatro prácticas

Tu subtarea de ONEDEV-63

Plugins, skills y MCPs

# Un solo archivo configura a todo el equipo igual
.claude/settings.json   # plugins · MCPs · statusline · hook de lint
.mcp.json               # GitHub · sequential-thinking · Postgres
CLAUDE.md               # contexto del repo

Una revisión en cada PR

# .github/workflows/claude-code-review.yml
on: pull_request

# Claude comenta cada PR automáticamente
# Secret del repo: ANTHROPIC_API_KEY (cuenta del equipo)

• El workflow viene en el starter kit, listo para activar
• Solo falta el secret ANTHROPIC_API_KEY de cada equipo
• Consume la API con la cuenta del equipo, no con la personal · live/05-pr-review

Varias features a la vez

Un worktree es otro directorio del MISMO repo con otra rama. Una instancia de Claude por worktree → dos features avanzan en paralelo, aisladas, sin churn de cambiar de rama.

# dos worktrees, dos ramas, dos features de ONEDEV-63
git worktree add ../gs-ree  -b feature/ONEDEV-211-ree           origin/main
git worktree add ../gs-edis -b feature/ONEDEV-212-edistribucion origin/main
git worktree list
# T1: cd ../gs-ree && claude    T2: cd ../gs-edis && claude
claude --worktree 211-ree     # atajo integrado

• La misma rama no se puede checkoutear en dos worktrees · .venv y .env no se comparten
• Reparte ficheros distintos = cero conflictos · mergea A y luego rebase B

Dos subtareas, dos worktrees

Un agente es un contrato, no un asistente

# .claude/agents/qa-reviewer.md  ·  el fichero ES el agente
---
name: qa-reviewer
description: Use PROACTIVELY tras implementar — audita el diff vs criterios
tools: Read, Grep, Glob      # solo lectura → veredicto fiable
model: sonnet
---
Eres un revisor de QA…  # el cuerpo del .md ES el system prompt

• La description es la interfaz pública: el router la lee para decidir si te invoca. "Use when… / Use PROACTIVELY when…" + condición observable = routing fiable
• tools = least-privilege (auditor sin escritura) · model por responsabilidad (Opus razona, Sonnet ejecuta)

PM · Dev · QA en .claude/agents

• Cada rol es un .md independiente; el flujo los encadena PM → Dev → QA/Sec, cada uno con su contexto limpio
• Los auditores van sin permisos de escritura: por eso su veredicto es fiable

Del ticket al APPROVE

/agents   # confirma que cargan los 5 roles del equipo

Un equipo que colabora

Un agent-team es un lead que reparte el trabajo entre varios compañeros en paralelo que se coordinan entre ellos.

# Off por defecto: flag experimental en ~/.claude/settings.json — reinicia Claude
{ "env": { "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1" } }
# Luego, en lenguaje natural → crea un equipo (backend, frontend, QA) para ONEDEV-63

Orquestación multi-agente

Para tareas que un solo contexto no abarca, ultracode (los Dynamic Workflows) deja que Claude orqueste muchos agentes en paralelo, verifique de forma adversaria y sintetice. El coste de tokens deja de ser la restricción; manda la exhaustividad.

Lo que medimos

• 5% del tiempo para explorar y aprender la herramienta
• Qué se puede subir al repo y qué no, y con qué cuenta (zero-retention)

Cómo sabemos que funcionó

• Todos con Claude Code en terminal y el starter kit funcionando
• Cada dev ha completado un ciclo SDD sobre ONEDEV-63
• El CLAUDE.md del repo de OneDev, creado y compartido
• El workflow de PR review listo (falta solo la API key)
• Worktrees y agentes especializados probados; lo demás en deberes