Subagentes en un plugin de Claude Code: el auditor de arquitectura y el corrector de Sonar

Hola, bienvenido. En esta lección vamos a llevar al plugin team los 2 subagentes de tu proyecto: el auditor de arquitectura y el corrector de SonarQube. Vamos a decidir con qué modelo trabaja cada uno y a versionar con el repo la memoria del auditor, para que lo que aprende en una auditoría lo aproveche todo el equipo y no solo quien la lanzó.

Qué es un subagente y cómo se invoca lo tienes en la lección Qué son los subagentes de Claude Code y cuándo usarlos↗ (se abre en una pestaña nueva) del curso de Claude Code. Aquí nos centramos en lo que cambia cuando el subagente forma parte de un plugin.

La configuración que copiamos del Setup Profesional trae 2 subagentes en .claude/agents/: architecture-auditor, que revisa que el código cumple la arquitectura del proyecto, y sonar-fixer, que corrige los issues de SonarQube hasta dejar el quality gate en verde. En el equipo de Marta, después de copiarlos de repo en repo, se encontraron con esto:

• El modelo del auditor era distinto según el repo. En 2 copias trabajaba con opus y en 4 con sonnet, porque alguien lo cambió en un repo para ir más rápido y esa copia fue la que se siguió copiando.
• La memoria del auditor era de cada persona. El auditor tiene memoria de proyecto, donde apunta los falsos positivos que le corriges para no repetirlos. Pero el .gitignore del proyecto la dejaba fuera de git, así que cada persona tenía la suya y el auditor de Jorge volvía a marcar lo que Aitor ya le había corregido.
• El corrector consultaba los issues de otro proyecto. Como la skill de QA, llevaba la key de SonarQube escrita en la consulta y leía el token del .env con awk.

Los 3 problemas tienen la misma causa: cada copia evolucionó por su cuenta. En el plugin, el modelo, las instrucciones y la forma de consultar SonarQube se deciden una vez para todo el equipo, y la memoria pasa a ser del repo.