Habilidades de Claude Code

El repositorio incluye un conjunto de habilidades de Claude Code en .claude/skills/ que automatizan las partes más pesadas del flujo de trabajo del mantenedor: revisiones de PR, clasificación de issues, squash-merge, generación de changelog y más.

Cada habilidad reside en su propio directorio con un archivo SKILL.md. Claude Code las carga automáticamente al abrir el repositorio; invócalas describiendo lo que deseas en lenguaje natural o mediante referencia explícita (por ejemplo, /squash-merge 1234).

Habilidades disponibles

Flujo de trabajo de revisión de PR

La habilidad github-pr-review-session es la herramienta principal para los días de revisión. Una sesión típica se ve así:

> review 1234

La habilidad lee AGENTS.md, el manual del revisor y el diff + commits del PR, y luego redacta una revisión. Utiliza:

• Comentarios en línea sobre el diff para cada hallazgo 🔴 bloqueante, 🟡 de advertencia o 🔵 de sugerencia vinculado a una línea específica
• Cuerpo de la revisión para el veredicto general, resumen de comprensión, referencias cruzadas y problemas a nivel de plantilla no vinculados a una línea
• Hashes de commit sin formato (nunca envueltos en backticks: GitHub los enlaza automáticamente)
• Nombres de usuario con @ en todo el contenido de la revisión

Los hallazgos siguen la taxonomía de retroalimentación: 🔴 [blocking] retiene el PR, 🟡 [warning] debería abordarse, 🔵 [suggestion] es opcional, 🟢 [praise] señala lo que funciona, y ✅ [resolved] reconoce un hallazgo atendido en una nueva revisión. El PR Review Protocol es la referencia canónica para los niveles y el formato Markdown del cuerpo de la revisión.

La skill siempre muestra un borrador para aprobación antes de publicar. Las revisiones se publican bajo la identidad del revisor humano, no como un bot.

Revisar después de los cambios:

> re-review 1234

O trabaja a través de la cola:

> go through the queue

Flujo de trabajo de triaje de incidencias

La skill github-issue-triage ejecuta barridos autónomos del backlog dentro de límites de autoridad definidos. Sin argumentos ejecuta una pasada de accounting (estado del backlog, luego solicita un modo); de lo contrario, los modos son:

• Triaje: procesar issues sin etiquetas de triaje: clasificar, aplicar etiquetas, vincular a PRs abiertos, señalar reportes de bugs incompletos, redirigir issues de seguridad
• Sweep: pasada completa del backlog en orden de prioridad (corregido-por-PR-fusionado → duplicados → r:support → candidatos obsoletos)
• Obsoleto: aplica la política canónica de incidencias obsoletas (status:stale, ventana de respuesta, exclusiones y reactivación)
• Won’t-fix: cerrar issues que violen una restricción de ingeniería fundamental con nombre, citando la restricción y su referencia en AGENTS.md/RFC
• Single: gestiona un issue por número o URL

Las definiciones de etiquetas se encuentran en Labels; las etiquetas de triaje que aplica la skill (r:needs-repro, r:support, stale-candidate, las etiquetas de ciclo de vida status:* y las etiquetas de resolución) están todas definidas allí. El procedimiento de inactividad se encuentra en el protocolo de la skill issue-triage, con contexto del lado del revisor en Reviewer playbook → Issue triage. La skill escala las ambigüedades al usuario antes de actuar.

Estrategia de fusión en squash

ZeroClaw utiliza squash-merge para todos los PRs. La habilidad squash-merge genera tanto la insignia Merged en color púrpura como un mensaje de squash con formato conventional-commits que incluye el historial completo de commits en el cuerpo.

¿Por qué existe la habilidad?

La combinación de fusión predeterminada de GitHub:

• Omite el número de PR del asunto
• Formatea el cuerpo de manera inconsistente
• No coincide con las convenciones del proyecto

Hacer push directo de un squash a master omite el mecanismo de fusión de PR: el PR aparece como “Closed” en lugar de “Merged” (sin insignia morada, sin cierre automático del issue vinculado, sin asociación de fusión). La skill usa gh pr merge --subject --body para obtener tanto la insignia como el commit con el formato correcto.

Formato

• Asunto: <PR title> (#<number>): debe seguir conventional commits (feat(scope): …, fix: …, etc.)
• Cuerpo (PR con múltiples commits): lista con viñetas de - <sha corto> <asunto del commit> de la rama del PR
• Cuerpo (PR de un solo commit): cuerpo completo del commit, o vacío si no hay uno

Comprobaciones previas al vuelo

La habilidad se detiene en:

1. PR no está abierto
2. La PR apunta a una rama que no es master
3. Hay conflictos de fusión (el usuario debe solicitar al autor que realice un rebase)
4. CHANGES_REQUESTED revisión pendiente
5. gh CLI < 2.17.0 (falta las banderas --subject/--body)

Un estado REVIEW_REQUIRED solicita confirmación pero no bloquea.

Invocación

> squash-merge 1234

o explícito:

> /squash-merge 1234

La habilidad siempre confirma el asunto y el cuerpo generados antes de llamar a gh pr merge.

Generación de registro de cambios

changelog-generation genera CHANGELOG-next.md para una versión consultando gh por las PRs fusionadas desde la última etiqueta, agrupándolas por el prefijo de conventional-commits y formateándolas según el estilo de changelog de la casa. Úsalo como parte del manual de lanzamiento, antes de ejecutar release-stable-manual.yml.

Editando las habilidades

Las skills son Markdown simple con frontmatter YAML. Su campo description es lo que Claude Code usa para decidir cuándo activarlas: sé específico e incluye frases de activación concretas ("review 1234", "triage issues", etc.). Usa skill-creator para editarlas; este hace cumplir la estructura y ayuda a ejecutar evaluaciones para medir la precisión de activación.

Cuando el comportamiento de una habilidad diverja de lo que describen los documentos (por ejemplo, si cambia el manual del revisor), actualiza la habilidad y cualquier documentación que la haga referencia. El archivo SKILL.md de la habilidad es la fuente canónica para la automatización; los documentos de contribución son la fuente canónica para los humanos.