Subagentes de Claude Code para tests, rendimiento y migraciones en Laravel
Hola, bienvenido. En esta lección vamos a completar el equipo con 3 subagentes más. 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. Los 3 nuevos son 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.
Quizá eches de menos un cuarto agente, uno que revise la seguridad. No lo vamos a crear, y el motivo lo vimos en la lección de revisar la seguridad del código: 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 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. La misión tiene que ser 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 ahí se ve 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 el proyecto