Empaqueta un workflow real como skill

Toca construir el segundo artefacto del curso: una skill de verdad, end-to-end, sobre un workflow que repites. Vamos a montar /review-pr, que revisa un pull request trayendo sus datos en vivo. Sigue los pasos con un repo tuyo que use GitHub.

El workflow que vamos a empaquetar

Hoy, para revisar un PR, probablemente haces: miras el diff, lees los comentarios, compruebas qué ficheros cambian, y entonces le pides a Claude que opine. Eso son cuatro pasos manuales cada vez. Lo vamos a reducir a /review-pr.

Paso 1 · Crea el directorio

Skill de proyecto (la quieres versionada para el equipo):

mkdir -p .claude/skills/review-pr

Paso 2 · Escribe el SKILL.md

.claude/skills/review-pr/SKILL.md:

---
description: Revisa un pull request abierto y señala riesgos. Úsala cuando el
  usuario pida revisar un PR o comprobar si está listo para merge.
disable-model-invocation: true
allowed-tools: Bash(gh *)
---

## Contexto del PR
- Diff: !`gh pr diff`
- Comentarios: !`gh pr view --comments`
- Ficheros cambiados: !`gh pr diff --name-only`

## Tu tarea
Revisa el pull request de arriba y devuelve:
1. Resumen en 2-3 bullets de qué hace.
2. Riesgos: seguridad, manejo de errores, casos límite, tests que falten.
3. Veredicto: listo para merge, o qué bloquea.
No edites código; esto es solo revisión.

Fíjate en las tres decisiones de diseño, todas de las lecciones anteriores:

• disable-model-invocation: true — es una acción que lanzas tú, en el momento que quieras. No quieres que Claude se ponga a revisar PRs por su cuenta.
• allowed-tools: Bash(gh *) — le das permiso al gh que la skill necesita, sin que te pregunte cada vez. Acotado a gh, no a todo Bash.
• !`gh pr diff` — los datos del PR entran ya resueltos; Claude revisa el diff real, no uno que adivina.

Paso 3 · Pruébala

Desde una rama con un PR abierto:

/review-pr

Claude Code ejecuta los tres gh primero, mete su salida en el prompt y Claude te devuelve la revisión. Sin pegar nada a mano.

Paso 4 · Itéra y versiónala

¿La review se deja algo que a ti te importa (accesibilidad, i18n)? Añádelo a la sección "Tu tarea". ¿Se repite un criterio largo? Muévelo a un fichero de soporte checklist.md y referéncialo. Cuando te guste:

git add .claude/skills/review-pr && git commit -m "feat: add /review-pr skill"

Acabas de versionar una capacidad nueva: todo el equipo que clone el repo tiene /review-pr. Ese es el artefacto.

El patrón, más allá de este ejemplo

Lo que has hecho sirve para casi cualquier workflow repetible:

• /deploy-staging — pasos de despliegue, con disable-model-invocation.
• /changelog — !`git log` desde la última tag, formateado.
• /nuevo-endpoint — scaffolding siguiendo tus convenciones, con un template.ts de soporte.

La pregunta de siempre: ¿qué pego/tecleo una y otra vez? Eso es tu próxima skill.

Qué llevas hasta aquí

• Has construido una skill real con datos en vivo (!`gh ...`), permisos acotados (allowed-tools) e invocación manual (disable-model-invocation).
• Sabes iterarla y versionarla para el equipo.
• Tienes el patrón para empaquetar cualquier workflow repetido.

En la última lección, algo distinto: cómo cambiar el tono y formato con el que Claude te responde.

Fuente oficial: Skills