Subagentes de Claude Code para tests, rendimiento y migraciones en Laravel
Hola, bienvenido. En la lección anterior creamos route-contract-auditor y vimos que lo que de verdad limita a un subagente son su lista de herramientas y la configuración del proyecto, mientras que las reglas de su prompt dependen de que el modelo las cumpla. En esta lección vamos a completar el equipo de claude-tasks con 3 subagentes más: test-writer, que escribe los tests de Pest que faltan, performance-advisor, que busca problemas de rendimiento en el acceso a la base de datos, y migration-reviewer, que revisa las migraciones antes de ejecutarlas. Después veremos cuándo llamar a cada uno y cómo forzar el que quieres cuando Claude no elige el esperado.
Si vienes del curso anterior, echarás de menos un cuarto agente, security-reviewer. No lo vamos a crear, y el motivo lo vimos en la lección Revisar la seguridad del código con Claude Code: qué usar y cuándo: su lista de comprobaciones de Laravel, con la asignación masiva, las referencias directas a objetos, las consultas sin bindings o los datos sensibles en las respuestas, vive ahora en .claude/claude-security-guidance.md, y el plugin security-guidance la aplica en cada turno sin que nadie tenga que invocarla. Un subagente de seguridad solo trabajaría cuando se lo pidieras, así que duplicaría esa lista y además llegaría tarde.
Para seguir esta lección necesitas claude-tasks con el commit de la lección anterior y una sesión de Claude Code en la raíz del proyecto. Esta vez no hay que reiniciar: la carpeta .claude/agents/ ya existía cuando arrancó la sesión, así que Claude Code detecta los archivos nuevos en unos segundos.
Una misión estrecha por agente
Los 3 agentes siguen el mismo patrón que el auditor de endpoints, y es lo que hace que funcionen. Cada uno tiene una misión estrecha, una description que dice cuándo usarlo con las palabras que aparecerán en tus peticiones, solo las herramientas que necesita para esa misión y un formato de respuesta fijo. ¿Por qué tan estrecha? Porque un agente que «revisa el código» compite con la conversación principal y con todos los demás por las mismas peticiones, y Claude no sabe cuándo elegirlo. En cambio, un agente que revisa migraciones antes de ejecutarlas tiene un momento claro en tu trabajo, y su descripción lo dice.
Este es el reparto:
| Subagente | Misión | Herramientas | Modelo |
|---|---|---|---|
test-writer |
Escribir los tests de Pest que faltan y dejarlos en verde | Read, Grep, Glob, Edit, Write, Bash |
sonnet |
performance-advisor |
Encontrar consultas N+1, cargas innecesarias e índices que faltan | Read, Grep, Glob |
sonnet |
migration-reviewer |
Dar un GO o un NO-GO a una migración antes de ejecutarla | Read, Grep, Glob |
haiku |
Fíjate en la columna de herramientas, porque aplica lo que vimos en la lección anterior. test-writer es el único que escribe y ejecuta, porque su trabajo es dejar tests que pasan. Los otros 2 revisan, y como no tienen Bash, Edit ni Write, no pueden ejecutar ni modificar nada aunque su prompt se equivocara. Para ellos, «solo lees» es una restricción real.
- 02test-writer: los tests que faltan
- 03performance-advisor: el acceso a la base de datos
- 04migration-reviewer: antes de ejecutar migrate
- 05Cuándo llamar a cada uno
- 06Probarlos en claude-tasks