Qué hace
Toma un punto fijo que indiques (un commit, una rama, un tag, main, HEAD~5), comprueba que se resuelva y que el diff no esté vacío; después busca la especificación (referencias a issues en los mensajes de commit, una ruta que indiques o un archivo de especificación en docs o specs). También localiza los documentos de estándares del repositorio. Ejecuta dos subagentes en paralelo para que no se contaminen entre sí: un revisor de Standards que cita la regla para cada incumplimiento documentado y además aplica una base de doce code smells de Fowler como criterios de juicio, y un revisor de Spec que informa de requisitos faltantes o parciales, expansión del alcance (scope creep) y requisitos que parecen implementados pero son incorrectos, citando la línea de la especificación. Los dos informes se mantienen separados a propósito, sin una clasificación combinada.
Resultado
Una sección de Standards, una sección de Spec y un resumen de una línea por eje con el peor problema de cada uno.
Ideal para
Revisar una rama o una pull request frente a las convenciones del equipo y el issue de origen.
Riesgo medio: solo instrucciones, sin scripts, pero ejecuta comandos de git, puede obtener el issue de origen mediante el flujo de trabajo del tracker descrito en la documentación del repositorio y lanza subagentes que leen tu código. Es de solo lectura sobre los archivos. Espera docs/agents/issue-tracker.md de la Skill de configuración del autor; si no está, te pide la especificación. No probado en ejecución: necesita un repositorio git real, un tracker y subagentes, así que no hay demo y el frontend lo marca como no verificado. Por Matt Pocock, MIT.