Skill de QA compartida en el plugin de Claude Code: composer qa y el quality gate de SonarQube

Hola, bienvenido. Empezamos el primer bloque opcional del curso, el que añade más piezas al plugin team: la skill de QA, una guardia que bloquea los comandos peligrosos y los 2 subagentes del proyecto. Te interesa si quieres que la QA, la guardia y los subagentes sean los mismos en todos los repos del equipo, con su versión. Si tu equipo no usa SonarQube ni quiere más piezas en el plugin, puedes saltarte el bloque entero: el resto del curso no depende de él.

En esta lección vamos a llevar al plugin la skill de QA, que da un veredicto GO o NO-GO con composer qa y, si el repo usa SonarQube, con su quality gate.

Si te saltas alguna lección del bloque, cuando una lección posterior modifique un archivo del plugin, copia el archivo completo en vez de aplicar el diff. El CHANGELOG.md es la excepción: de él solo copias la entrada nueva, porque es el acta.

Para seguir esta lección necesitas SonarQube levantado en localhost:9000, como en el Setup Profesional, y Docker con unos 3 GiB libres para él. Si todavía no lo tienes, se levanta con un solo contenedor, con volúmenes para que los datos se conserven aunque lo pares. Desde cualquier pestaña:

Tarda 1 o 2 minutos en arrancar. Para saber cuándo está listo:

Cuando aparezca SonarQube is operational, sal con Ctrl+c. Abre http://localhost:9000, entra con admin y admin, y cambia la contraseña cuando te lo pida. El puerto va publicado en todas las interfaces, y no solo en 127.0.0.1, porque el análisis llega al servidor por host.docker.internal. Con --restart unless-stopped, el contenedor arranca solo cada vez que arranca Docker. Si quieres saber más de SonarQube con Laravel, tienes el artículo Cómo añadir SonarQube a Laravel para detectar deuda técnica y vulnerabilidades↗ (se abre en una pestaña nueva).

Tu proyecto trae una skill qa en .claude/skills/qa/. Ejecuta composer qa, lanza ./sonar.sh, espera unos 20 segundos y consulta los issues abiertos con curl. Para un repo funciona. En el equipo de Marta, después de copiarla de repo en repo, tenía 3 problemas:

• La key del proyecto escrita a mano. La consulta de issues lleva la key de SonarQube en la URL, y una de las copias consultaba los issues de otro proyecto, porque alguien copió la carpeta sin cambiarla.
• Claude leía el .env. Para la consulta, la skill le pide a Claude que saque SONAR_TOKEN del .env con awk. El token pasa por la sesión, y el .env deja de ser un archivo que Claude no toca.
• La espera a mano. El análisis de SonarQube es asíncrono, y la skill espera unos segundos antes de consultar. En 5 de los 6 repos esa espera se perdió en algún cambio, y la skill leía los issues del análisis anterior.

La skill de QA de la lección Skill de Claude Code para la QA de un proyecto Laravel↗ (se abre en una pestaña nueva) del curso de Claude Code era la de un repo. La que vamos a escribir es la del equipo: la misma en todos los repos, sin nada escrito a mano que dependa de uno de ellos, y con la parte de SonarQube en el sonar.sh de cada repo.