Skill de Claude Code para la QA de un proyecto Laravel

Hola, bienvenido. En la lección anterior creamos /review-diff, la primera skill de claude-tasks, que revisa los cambios contra las normas del proyecto antes de un commit. En esta lección vamos a crear la segunda, project-qa, que ejecuta el circuito de calidad del proyecto con Sail y, sobre todo, lo interpreta: qué dice Rector en seco, qué archivos no cumplen el formato de Pint, qué errores da Larastan y qué tests fallan con Pest. Veremos qué hacer cuando Rector propone cambios, que es el caso que más cuidado pide, y qué implica tener una skill versionada en el repositorio, al alcance de todo el equipo.

¿Por qué una skill, si nuestro CLAUDE.md ya dice que una tarea está terminada cuando ./vendor/bin/sail composer qa pasa entero? Porque esa línea solo fija el criterio para dar una tarea por terminada, y saber que el circuito tiene que pasar no le dice a Claude qué hacer cuando se para en el primer paso y los otros 3 se quedan sin ejecutar, cómo presentar los cambios que propone Rector para que tú decidas, o cómo resumir el resultado para que veas de un vistazo si el cambio está listo. Es justo el caso que describe la documentación para crear una skill: un apartado de CLAUDE.md que ha crecido hasta convertirse en un procedimiento. Además, las instrucciones de la skill solo entran en el contexto cuando se usa, y CLAUDE.md se queda corto, que es como lo queremos.

Y hay una segunda razón que tiene que ver con el equipo. Si cada uno le pide la QA a Claude a su manera, cada uno recibe un informe distinto y con criterios distintos sobre qué aplicar y qué no. Con la skill en el repositorio, el procedimiento es el mismo para todos, y cuando cambia, cambia para todos en el mismo commit.

Para seguir esta lección necesitas claude-tasks con el commit de la skill /review-diff de la lección anterior, los contenedores de Sail levantados y una sesión de Claude Code abierta en la raíz del proyecto. No hace falta ninguna versión especial de Claude Code más allá de las que ya hemos usado en la sección.

La skill no inventa nada nuevo: se apoya en 3 piezas que ya tenemos y tiene que ser coherente con ellas. La primera es el script qa que montamos en la lección Crear el proyecto Laravel con Sail para trabajar con Claude Code, con estos pasos en composer.json:

La segunda son las reglas de .claude/settings.json. En allow están composer qa, composer test, composer stan, composer pint, composer rector:dry y artisan test con cualquier opción, todos con ./vendor/bin/sail delante, así que Claude los lanza sin preguntarte. En ask está ./vendor/bin/sail composer rector, que te pide confirmación siempre, incluso en auto mode. Y como vimos en la lección del sandbox, todos los comandos de Sail se ejecutan fuera del sandbox, así que lo único que los controla son esas reglas y el modo de permiso.

La tercera es el CLAUDE.md del proyecto, que ya dice que todo va con Sail, que composer qa solo comprueba y el formato se arregla con composer pint, que Rector solo se ejecuta en seco y que nunca se cambia una aserción para que un test pase. La skill convierte esas normas en pasos concretos.