xieshuai0817-hub/LanceSkill

Revisión en dos ejes del diff entre HEAD y un punto fijo que el usuario proporcione:

• Estándares — ¿el código cumple con las normas de codificación documentadas de este repositorio?
• Especificación — ¿el código implementa fielmente el issue / PRD / especificación original?

Ambos ejes se ejecutan como subagentes paralelos para que no contaminen el contexto del otro, y luego esta skill agrega sus hallazgos.

El rastreador de issues debería haberte sido proporcionado — ejecuta /setup-matt-pocock-skills si falta docs/agents/issue-tracker.md.

Proceso

1. Fijar el punto fijo

Lo que sea que el usuario haya dicho como punto fijo — un SHA de commit, nombre de rama, etiqueta, main, HEAD~5, etc. Si no especificó ninguno, pídelo.

Captura el comando diff una vez: git diff <punto-fijo>...HEAD (tres puntos, para que la comparación sea contra la merge-base). También anota la lista de commits con git log <punto-fijo>..HEAD --oneline.

Antes de continuar, confirma que el punto fijo se resuelve (git rev-parse <punto-fijo>) y que el diff no está vacío. Una referencia incorrecta o un diff vacío deberían fallar aquí — no dentro de dos subagentes paralelos.

2. Identificar la fuente de la especificación

Busca la especificación original, en este orden:

1. Referencias a issues en los mensajes de commit (#123, Closes #45, GitLab !67, etc.) — obténlas mediante el flujo de trabajo en docs/agents/issue-tracker.md.
2. Una ruta que el usuario haya pasado como argumento.
3. Un archivo PRD/especificación bajo docs/, specs/ o .scratch/ que coincida con el nombre de la rama o la funcionalidad.
4. Si no se encuentra nada, pregunta al usuario dónde está la especificación. Si dice que no hay, el subagente de Especificación omitirá e informará "no hay especificación disponible".

3. Identificar las fuentes de estándares

Cualquier cosa en el repositorio que documente cómo se debe escribir el código, como CODING_STANDARDS.md o CONTRIBUTING.md.

Además de lo que documente el repositorio, el eje de Estándares siempre lleva la línea base de olores de código a continuación — un conjunto fijo de olores de código de Fowler (Refactoring, cap. 3) que aplica incluso cuando un repositorio no documenta nada. Dos reglas lo vinculan:

• El repositorio anula. Un estándar documentado del repositorio siempre prevalece; donde aprueba algo que la línea base marcaría, suprime el olor.
• Siempre es un juicio. Cada olor es una heurística etiquetada ("posible Feature Envy"), nunca una violación estricta — y, como cualquier estándar aquí, omite cualquier cosa que las herramientas ya apliquen.

Cada olor indica qué es → cómo solucionarlo; compáralo con el diff:

• Nombre Misterioso (Mysterious Name) — una función, variable o tipo cuyo nombre no revela lo que hace o contiene. → renómbralo; si no surge un nombre honesto, el diseño está turbio.
• Código Duplicado (Duplicated Code) — la misma forma lógica aparece en más de un bloque o archivo en el cambio. → extrae la forma compartida, llámala desde ambos.
• Envidia de Características (Feature Envy) — un método que accede más a los datos de otro objeto que a los suyos propios. → mueve el método a los datos que envidia.
• Racimo de Datos (Data Clumps) — los mismos pocos campos o parámetros viajan juntos repetidamente (un tipo que quiere nacer). → agrégalos en un solo tipo, pása ese.
• Obsesión por Primitivos (Primitive Obsession) — un primitivo o cadena que representa un concepto de dominio que merece su propio tipo. → dale al concepto su propio tipo pequeño.
• Switch Repetidos (Repeated Switches) — el mismo switch/if-cascada sobre el mismo tipo se repite en el cambio. → reemplázalo con polimorfismo, o un mapa compartido por ambos sitios.
• Cirugía de Escopeta (Shotgun Surgery) — un cambio lógico obliga a ediciones dispersas en muchos archivos del diff. → reúne los cambios juntos en un módulo.
• Cambio Divergente (Divergent Change) — un archivo o módulo se edita por varias razones no relacionadas. → divide para que cada módulo cambie por una única razón.
• Generalidad Especulativa (Speculative Generality) — abstracciones, parámetros o hooks añadidos para necesidades que la especificación no tiene. → elimínalo; simplifica hasta que surja una necesidad real.
• Cadenas de Mensajes (Message Chains) — larga navegación a.b().c().d() de la que el llamador no debería depender. → oculta el recorrido detrás de un método en el primer objeto.
• Hombre del Medio (Middle Man) — una clase o función que principalmente solo delega. → elimínalo, llama al destino real directamente.
• Herencia Rechazada (Refused Bequest) — una subclase o implementador que ignora o anula la mayor parte de lo que hereda. → elimina la herencia, usa composición.

4. Lanzar ambos subagentes en paralelo

Envía un solo mensaje con dos llamadas a la herramienta Agent. Usa el subagente general-purpose para ambos.

Prompt del subagente de Estándares — incluye:

• El comando diff completo y la lista de commits.
• La lista de archivos fuente de estándares que encontraste en el paso 3, más la línea base de olores del paso 3 pegada completa — el subagente no tiene otro acceso a ella.
• La instrucción: "Informe — por archivo/bloque donde corresponda — (a) cada lugar donde el diff viola un estándar documentado: cita el estándar (archivo + la regla); y (b) cualquier olor de la línea base que detectes: nómbralo y cita el bloque. Distingue las violaciones estrictas de los juicios — las infracciones a estándares documentados pueden ser estrictas, pero los olores de la línea base son siempre juicios, y un estándar documentado del repositorio anula la línea base. Omite cualquier cosa que las herramientas ya apliquen. Menos de 400 palabras."

Prompt del subagente de Especificación — incluye:

• El comando diff y la lista de commits.
• La ruta o el contenido obtenido de la especificación.
• La instrucción: "Informe: (a) requisitos que la especificación pedía y que faltan o están incompletos; (b) comportamiento en el diff que no fue solicitado (expansión del alcance); (c) requisitos que parecen implementados pero donde la implementación parece incorrecta. Cita la línea de la especificación para cada hallazgo. Menos de 400 palabras."

Si falta la especificación, omite el subagente de Especificación y anótalo en el informe final.

5. Agregar

Presenta los dos informes bajo los encabezados ## Standards y ## Spec, textualmente o ligeramente limpiados. No combines ni reclasifiques los hallazgos — los dos ejes están deliberadamente separados (ver Por qué dos ejes).

Termina con un resumen de una línea: hallazgos totales por eje, y el peor problema dentro de cada eje (si lo hay). No elijas un único ganador entre ejes — esa reclasificación es lo que la separación busca prevenir.

Por qué dos ejes

Un cambio puede aprobar un eje y fallar el otro:

• Código que sigue todos los estándares pero implementa lo incorrecto → Estándares aprueba, Especificación falla.
• Código que hace exactamente lo que pidió el issue pero rompe las convenciones del proyecto → Especificación aprueba, Estándares falla.

Reportarlos por separado evita que un eje enmascare al otro.