build2-community/build2-review

¿Qué hace build2-review?

Resolver ROOT

Sea HERE el directorio que contiene este SKILL.md (ruta absoluta desde el contexto del sistema).

ROOT es el árbol de skills de build2. Use el primer candidato cuyo guides/packaging-guide-review.md exista:

1. HERE/../build2 (disposición de hermanos: este directorio junto a una skill build2, incluyendo una copia en un directorio de skills a nivel de usuario)
2. HERE/../.. (disposición anidada: este directorio bajo el subdirectorio skills/ de la skill build2)

Si ninguno existe, deténgase.

Todas las rutas posteriores de read_file son ${ROOT}/....

Esta es una verificación de cordura local y de solo lectura. Existe para detectar problemas de empaquetado antes de publicar, ejecutando la misma lista de verificación que un revisor de cppget.org usaría contra el repositorio. Nunca debe crear, comentar ni fusionar un issue o pull request de GitHub, nunca enviar una rama, nunca enviar un correo electrónico y nunca modificar el repositorio bajo revisión (sin commits, sin etiquetas, sin ediciones de archivos, sin bdep release, sin bdep publish, sin git push). Si un paso a continuación haría tal cambio, omítalo y conviértalo en un hallazgo reportado. El repositorio bajo revisión debe salir de esta verificación exactamente como entró. Redactar un plan para los hallazgos reportados, sin llevarlo a cabo, no cuenta como un cambio, consulte "Modo plan" a continuación para saber cuándo aplica.

La lista de verificación y los criterios en ${ROOT}/guides/packaging-guide-review.md son la fuente de verdad. Copie los elementos de la lista de verificación. No parafrasee los criterios requeridos. No invente criterios de revisión.

Las revisiones cubren solo la compilación y el soporte de empaquetado. Ignore la calidad del código fuente ascendente, la documentación ascendente y el estilo de C/C++ ascendente.

Reglas estrictas

1. Sin cambios visibles externamente: nunca cree, comente ni fusione un issue o pull request de GitHub, nunca envíe una rama, nunca envíe un correo electrónico. Esto es incondicional, se aplica incluso si el usuario lo solicita explícitamente durante la ejecución: decline e indíqueles el flujo de trabajo de revisión manual separado (consulte "Detenerse y preguntar" a continuación) en lugar de hacerlo aquí.
2. Sin cambios en el repositorio bajo revisión: sin commits, etiquetas o ediciones de archivos, sin git push, sin bdep release, sin bdep publish. Solo inspección (git log, git show, git diff, leer archivos). Si compila o prueba algo para verificar un elemento, hágalo fuera del árbol en un directorio temporal, nunca dentro del árbol de trabajo del repositorio revisado.
3. Si se proporciona una ruta local, úsela en su lugar, solo lectura. No cambie a una referencia diferente, no la guarde ni la restablezca.
4. Si se proporciona un repositorio remoto o URL, clónelo en modo solo lectura en un directorio temporal bajo /tmp/claude/. Nunca use remotos con capacidad de push ni git push. Trate el clon como desechable.
5. Nunca marque un elemento de la lista de verificación sin verificarlo personalmente en esta ejecución.
6. Bloqueante vs no bloqueante sigue los criterios de la guía. En caso de duda, dígalo en lugar de degradar silenciosamente un error conceptual de buildfile.
7. La salida es un informe en la conversación (opcionalmente también se escribe en un archivo temporal bajo /tmp/claude/). Nunca lo publique en ningún lugar externo.

Lecturas obligatorias (antes de informar hallazgos)

Lea estos archivos completos con read_file antes de informar cualquier hallazgo. No los revise superficialmente.

1. ${ROOT}/guides/packaging-guide-review.md
2. ${ROOT}/guides/packaging-guide-antipatterns.md
3. ${ROOT}/HOWTO/package-naming.md
4. ${ROOT}/guides/packaging-guide-testing.md, solo el Paso 9 ("Probar el Paquete"). El Paso 10 ("Publicar") fusiona review en main y está fuera del alcance aquí, ignórelo.

Cargue bajo demanda desde el mapa al final. La Lista de Verificación de Revisión Inicial dentro de packaging-guide-review.md es la lista de verificación con la que trabaja. Ese archivo es la única copia.

Argumentos

$ARGUMENTS es el texto después de /build2-review (o después de /build2 review). Analice en orden. Gana la primera regla coincidente.

Primer token	Tipo
vacío / omitido	detección automática después de resolver el destino
initial	lista de verificación completa de envío inicial
version	nueva versión ascendente, basada en diff
revision	nueva revisión de empaquetado, basada en diff más verificaciones adicionales
cualquier otra cosa	tratar como <repo-or-local-path> y detectar tipo automáticamente

Tokens restantes: <repo-or-local-path> (URL de GitHub, owner/repo o una ruta de clon local) y opcional <version>. Si falta el destino, pregunte.

Informe el tipo y la versión elegidos al usuario antes de comenzar.

Obtener el repositorio

Si el usuario proporcionó una ruta local, úsela tal cual, solo lectura.

De lo contrario, clónelo en modo solo lectura en un directorio temporal (nunca haga push a este clon, nunca lo agregue como destino de push para nada más):

git clone --recurse-submodules --shallow-submodules <url> /tmp/claude/<name>

Clasificar

Determine <VERSION> del campo version: del manifest (la última etiqueta publicada si hay varios paquetes). Determine el tipo:

Evidencia	Tipo
Aún no hay etiqueta publicada, o la referencia revisada sigue siendo el primer commit de bdep new	initial
Ya existe una etiqueta vX.Y.Z y esta versión es X.Y.Z+R	revision
Una versión anterior fue etiquetada y esta es una nueva X.Y.Z	version

Verifique el primer commit del repositorio (solo lectura):

git log -p "$(git rev-list --all | tail -1)"

Ese commit debe contener solo archivos generados por bdep new, y su mensaje debe ser la línea de comandos exacta. Registre cualquier desviación como un hallazgo. No lo ignore.

Tipo: initial

Trabaje a través de cada elemento en la sección Lista de Verificación de Revisión Inicial de packaging-guide-review.md contra el repositorio. Marque un elemento solo después de verificarlo personalmente (árbol, manifest, buildfiles, diseño de instalación, pruebas, etiquetas). Use el HOWTO/guía vinculado para cada elemento en lugar de la memoria.

Clasifique cada hallazgo exactamente como lo hace la guía:

Clase	Cuándo
Bloqueante	alta gravedad o impacto, muchos usuarios, error conceptual (opciones de compilación incorrectas en buildfiles), o no se puede corregir más tarde sin romper la compatibilidad
No bloqueante	debe corregirse en una revisión o la próxima versión, no falla la verificación
Nota	solo observación

Cargue bajo demanda mientras verifica:

• nombres: ${ROOT}/HOWTO/package-naming.md
• licencia: ${ROOT}/guides/packaging-license.md
• resumen / README de -tests acompañantes: ${ROOT}/HOWTO/tests-extra-dependencies.md
• encabezados privados: ${ROOT}/HOWTO/third-party-private-headers.md
• opciones de compilación: ${ROOT}/HOWTO/buildfile-compile-options.md
• qué no hacer: ${ROOT}/guides/packaging-guide-antipatterns.md
• comentarios o notas estilo diario en buildfiles, manifest o READMEs (narración de procesos, un enfoque anterior que no funcionó, un percance en el camino): ${ROOT}/guides/packaging-guide-antipatterns.md, "No dejar comentarios o notas estilo diario"

Al verificar "Usa submódulo git y enlaces simbólicos para aguas arriba": también ejecute find . -type l -exec test -d {} \; -print en cada directorio de paquete y confirme que cada resultado tenga una entrada symlink=dir coincidente en el <pkg>/.gitattributes del paquete (consulte ${ROOT}/guides/packaging-guide-summary.md Paso 5). git no registra el tipo de enlace simbólico, por lo que un enlace simbólico de directorio sin esta entrada rompe silenciosamente un checkout de Windows. Trate una entrada faltante como bloqueante.

Probar instalación y distribución

La inspección estática de la lista de verificación no es suficiente. También compile el paquete fuera del árbol para detectar lo que solo aparece en el momento de la compilación (encabezados faltantes o privados que llegan al árbol de instalación, archivos faltantes en el gráfico del buildfile, reglas clean rotas). Haga esto en un directorio temporal bajo /tmp/claude/, nunca dentro del repositorio revisado. Siga el "Paso 9: Probar el Paquete" en ${ROOT}/guides/packaging-guide-testing.md:

1. Caso instalado: b install config.install.root=/tmp/claude/<name>-install, luego compile y ejecute tests/ fuera de la fuente contra esa copia instalada. Confirme que no se instaló nada inesperado (sin encabezados faltantes, sin encabezados privados instalados por error).
2. Distribución de código fuente: b dist config.dist.root=/tmp/claude/<name>-dist config.dist.uncommitted=true, luego en el archivo extraído ejecute configure, update, test y clean. Una bdep test verde por sí sola no es suficiente, así es como cppget.org realmente compila el paquete.

Elimine ambos directorios temporales después. Registre cualquier fallo como un hallazgo (un paquete que no se instala o distribuye correctamente es normalmente bloqueante).

Informe

Presente los resultados al usuario usando la misma disposición de secciones que el comentario de resultado de la guía, pero no lo publique en ningún lado:

Problemas bloqueantes:

...

Problemas no bloqueantes:

...

Notas:

...

Omita secciones vacías. Si escribió una copia temporal, mencione su ruta.

Tipo: version

Diferencie la versión base (revisada anteriormente) contra la versión objetivo. Prefiera un git diff <old-tag>..<new-tag> local si ambas etiquetas están disponibles en el clon, de lo contrario la vista de comparación de GitHub:

https://github.com/<owner>/<project>/compare/vOLD...vNEW

Vigile la compatibilidad a nivel de compilación: los objetivos exportados renombrados o las variables de configuración son cambios que rompen la compatibilidad incluso cuando la API ascendente es estable.

Informe uno de:

1. Sin cambios sustanciales de empaquetado, sin problemas: dígalo claramente, sin lista de verificación necesaria.
2. Sin cambios sustanciales de empaquetado, hay problemas: enumérelos directamente (sin lista de verificación).
3. Cambios sustanciales de empaquetado: ejecute el procedimiento inicial completo anterior, lista de verificación más la prueba de instalación y distribución.

Tipo: revision

Igual que version, más márquelo como hallazgo si no se cumple alguna de estas:

• Los cambios se limitan a correcciones de errores en buildfiles, manifest y archivos de empaquetado similares.
• Las correcciones de código fuente ascendente se limitan a errores críticos retroportados desde el upstream.
• Estrictamente compatible hacia atrás con la versión que reemplaza.
• Sin cambios estructurales importantes (diseño de fuente, nombres de objetivos exportados, nombres de variables de configuración).

Modo plan

Esta skill permanece de solo lectura de cualquier manera, nunca lleva a cabo las correcciones por sí misma. Lo único que cambia es si se redacta un plan para los cambios y mejoras requeridos junto con el informe.

• Si la sesión actual está en modo plan (se espera que el asistente proponga un plan de implementación para su aprobación antes de realizar cambios, en lugar de actuar de inmediato): después de informar, también redacte un plan que aborde los hallazgos bloqueantes y no bloqueantes, luego preséntelo a través del mecanismo de aprobación de planes que el entorno proporcione. Limite el plan a hallazgos bloqueantes y no bloqueantes, omita notas a menos que el usuario lo solicite. Agrupe correcciones relacionadas y señale cualquier que toque el diseño generado de bdep new, manifest o archivos buildfile que necesiten cuidado u orden particular.
• De lo contrario, siga el flujo de informes establecido anteriormente y deténgase ahí. No redacte, proponga ni insinúe un plan de implementación; las correcciones son para el usuario o un flujo de trabajo separado para llevar a cabo.

Detenerse y preguntar

Deténgase en lugar de adivinar cuando alguna de estas sea verdadera:

• No puede determinar la versión o el tipo.
• No puede acceder al repositorio (el clon falla, la ruta local no es válida).
• El primer commit no es un commit de bdep new y el usuario no ha decidido cómo registrar eso en el informe.
• No está claro si un hallazgo es bloqueante o no bloqueante cuando rompería la compatibilidad.
• El usuario solicitó abrir realmente el issue/PR de revisión de GitHub, fusionar algo o enviar el correo electrónico a [email protected]. Eso es un flujo de trabajo separado y fuera del alcance que esta skill no realiza.
• El usuario solicitó crear el paquete en lugar de verificarlo (cambie a build2-package).

Mapa bajo demanda

Necesidad	Archivo
Lista de verificación y criterios	${ROOT}/guides/packaging-guide-review.md
Qué no hacer	${ROOT}/guides/packaging-guide-antipatterns.md
Nombres	${ROOT}/HOWTO/package-naming.md
Licencia	${ROOT}/guides/packaging-license.md
Paquetes acompañantes	${ROOT}/HOWTO/tests-extra-dependencies.md
Crear el paquete	../build2-package/SKILL.md