---
description: Documenta un módulo o componente explicando qué resuelve y cómo
  se usa, no qué hace línea por línea. Úsala cuando el usuario pida
  documentar código, escribir un README de módulo, o diga que algo no se
  entiende.
allowed-tools: Read Grep Glob
---

## Instrucciones

La documentación responde tres preguntas, en este orden:

### 1 · ¿Qué problema resuelve?

Una o dos frases. Escríbelas para alguien que llega al repositorio por
primera vez y no sabe por qué existe este módulo.

### 2 · ¿Cómo se usa?

Un ejemplo completo que funcione al copiarlo. No un fragmento que asuma
configuración no documentada.

### 3 · ¿Qué hay que saber para no romperlo?

- Invariantes que el módulo asume
- Efectos secundarios no obvios
- Dependencias con otras partes del sistema
- Decisiones de diseño que parecen raras y no lo son

## Reglas

**No documentes lo que el código ya dice.** Un comentario que repite el
nombre de la función es ruido:

    ❌  # Obtiene el usuario por id
        def obtener_usuario_por_id(id):

**Documenta lo que el código no puede decir:** por qué se eligió este
enfoque, qué se intentó antes, qué pasa si alguien cambia este orden.

**Sin información con fecha de caducidad.** Nada de "actualmente",
"por ahora", versiones concretas ni nombres de personas.

## Formato

Si el proyecto ya tiene un formato de documentación, síguelo.
Si no, usa markdown con esta estructura:

    # <Nombre del módulo>

    <Qué problema resuelve, 1-2 frases>

    ## Uso

    <ejemplo completo y copiable>

    ## Consideraciones

    <invariantes, efectos, decisiones de diseño>

<!-- Grado de libertad: ALTA. El criterio sobre qué merece documentarse es el valor. -->

---
description: Genera pruebas para código existente siguiendo las convenciones
  del proyecto, priorizando casos borde sobre el camino feliz. Úsala cuando
  el usuario pida pruebas, tests, cobertura, o diga que le falta probar algo.
allowed-tools: Read Grep Glob
---

## Instrucciones

### 1 · Antes de escribir nada, mira cómo prueba el proyecto

Busca las pruebas existentes y detecta:

- Qué corredor de pruebas se usa
- Cómo se nombran los archivos y los casos
- Si usan fixtures, factories o datos en línea
- Cómo se manejan los dobles de prueba

**Sigue esas convenciones aunque prefieras otras.** Una prueba que no se
parece a las demás del proyecto es una prueba que nadie mantiene.

### 2 · Prioriza en este orden

1. **Casos borde**: colecciones vacías, nulos, valores límite, entradas malformadas
2. **Errores esperados**: qué pasa cuando la dependencia falla
3. **Camino feliz**: el caso normal
4. **Regresiones**: si el usuario menciona un bug, la prueba que lo habría atrapado

El camino feliz va tercero a propósito. Es el que ya funciona.

### 3 · Una aserción por concepto

Cada prueba verifica un comportamiento. Si necesitas "y además" para
describirla, son dos pruebas.

### 4 · Nombres que describen el comportamiento

    ❌  test_usuario_1
    ✅  test_rechaza_email_sin_arroba

El nombre debe decir qué se rompió cuando la prueba falla en CI, sin
tener que abrir el archivo.

## Qué NO hacer

- No pruebes implementación: si refactorizar rompe la prueba sin cambiar
  comportamiento, la prueba está mal
- No uses dobles para lo que puedes probar de verdad
- No escribas pruebas que siempre pasan

## Salida

Escribe las pruebas en el archivo que corresponda según la convención del
proyecto. Al final, lista en dos o tres líneas qué quedó sin cubrir y por qué.

<!-- Grado de libertad: MEDIA. Convención del proyecto manda, contenido libre. -->

---
description: Redacta el mensaje de commit a partir de los cambios preparados,
  siguiendo commits convencionales. Úsala cuando el usuario pida un commit,
  un mensaje de commit, o pregunte cómo describir su cambio.
allowed-tools: Read
---

## Cambios preparados

!`git diff --staged`

## Últimos commits del proyecto, para tomar el estilo

!`git log --oneline -12`

## Instrucciones

Estructura:

    <tipo>(<alcance>): <resumen en imperativo, minúscula, sin punto>

    <cuerpo opcional: por qué, no qué>

    <pie opcional: refs, breaking changes>

Tipos: `feat`, `fix`, `refactor`, `docs`, `test`, `chore`, `perf`, `build`, `ci`.

Reglas:

- Imperativo: "agrega", no "agregado" ni "agregando"
- Máximo 72 caracteres en la primera línea
- El cuerpo explica **por qué**. El qué ya está en el diff
- Un `BREAKING CHANGE:` en el pie si la interfaz pública cambió

Si los cambios preparados mezclan varios propósitos, dilo y propón cómo
separarlos en commits distintos, con qué archivos van en cada uno.

Si el estilo de los últimos commits difiere de commits convencionales,
sigue el del proyecto y señálalo en una línea.

Si no hay nada preparado, dilo y detente. No inventes un mensaje.

<!-- Grado de libertad: MEDIA. Formato fijo, redacción libre. -->

---
description: Revisa un pull request o un diff contra las convenciones del
  proyecto y señala lo que falta antes de pedir aprobación. Úsala cuando el
  usuario pida revisar un PR, revisar su diff, pregunte si su cambio está
  listo para subir, o mencione code review.
allowed-tools: Read Grep
---

## Cambios a revisar

!`git diff origin/main...HEAD 2>/dev/null || git diff HEAD`

## Archivos tocados

!`git diff --name-only origin/main...HEAD 2>/dev/null || git diff --name-only HEAD`

## Instrucciones

Revisa en este orden y detente en el primer bloqueante que encuentres.

### 1 · Bloqueantes

Reporta y detente si encuentras alguno:

- Credenciales, tokens o cadenas de conexión en el código
- Datos personales o de cliente en pruebas, fixtures o comentarios
- Cambios en interfaces públicas sin actualizar a quien las consume
- Borrado de pruebas sin reemplazo

### 2 · Correctitud

- Casos borde sin cubrir: colecciones vacías, nulos, valores límite
- Manejo de errores ausente en operaciones que pueden fallar
- Condiciones de carrera o acceso concurrente no protegido
- Aritmética con redondeo, divisiones por cero, desbordamientos

### 3 · Mantenibilidad

- Valores hardcodeados que deberían ser configuración
- Duplicación de lógica que ya existe en el proyecto
- Nombres que no dicen lo que la cosa hace
- Funciones que hacen más de una cosa

### 4 · Pruebas

- ¿Hay prueba para cada rama nueva de comportamiento?
- ¿Alguna prueba existente quedó desactualizada por este cambio?
- ¿Las pruebas prueban comportamiento o implementación?

## Formato del reporte

    BLOQUEANTE  <archivo>:<línea> — <qué está mal y por qué>
    IMPORTANTE  <archivo>:<línea> — <qué está mal>
    MENOR       <archivo>:<línea> — <sugerencia>

Ordena por severidad. Si no hay nada en una categoría, omítela en vez de
escribir "ninguno".

No reescribas el código. Señala y explica; quien decide es quien lo escribió.

Si el diff está vacío, dilo en una línea y detente.

<!-- Grado de libertad: ALTA. El criterio de revisión es el valor. -->

---
description: Descompone un requerimiento o una propuesta en entregables,
  tareas y supuestos, señalando lo que está indefinido. Úsala cuando el
  usuario pida desglosar un alcance, hacer un WBS, estimar un proyecto,
  o mencione que un requerimiento está muy general.
---

## Instrucciones

### 1 · Separa lo definido de lo asumido

Antes de desglosar nada, lista en dos columnas:

    ESTÁ DEFINIDO          ESTOY ASUMIENDO
    <lo que dice el        <lo que hace falta para
     requerimiento>         poder estimar y no está>

**La columna derecha es la más valiosa del ejercicio.** Cada supuesto ahí
es una conversación que hay que tener antes de comprometer una fecha.

### 2 · Desglosa por entregable, no por actividad

    ❌  Análisis, diseño, desarrollo, pruebas
    ✅  Módulo de autenticación funcionando en staging
        Reporte de conciliación mensual generándose solo

Un entregable es algo que se puede enseñar y que alguien puede aceptar o
rechazar. "Análisis" no se puede aceptar.

### 3 · Tres niveles, no más

    Entregable
    └── Componente
        └── Tarea (1 a 5 días)

Si una tarea pasa de cinco días, no está desglosada: está escondiendo algo.
Si necesitas un cuarto nivel, probablemente el entregable son dos.

### 4 · Marca las dependencias y lo que no controlas

Para cada entregable:

- De qué otro entregable depende
- Qué necesita de terceros: accesos, aprobaciones, datos, ambientes
- Qué es camino crítico

## Formato

    ## Entregable 1 · <nombre>

    **Criterio de aceptación:** <cómo se sabe que está terminado>
    **Depende de:** <entregable, o "nada">
    **Requiere de terceros:** <qué y de quién, o "nada">

    | Componente | Tarea | Días | Notas |
    |---|---|---|---|

## Reglas

**Todo entregable lleva criterio de aceptación.** Sin él, el desglose no
sirve para negociar ni para cerrar.

**Los supuestos se escriben aunque sean obvios.** Lo obvio para ti no lo
es para quien firma.

**Lo que no se puede estimar se marca `REQUIERE DEFINICIÓN`** con la
pregunta concreta que hay que responder. No pongas un número inventado.

**No incluyas contingencia dentro de las tareas.** Va aparte, explícita,
para que sea negociable.

## Al final

    <n> entregables · <n> tareas · <n> supuestos · <n> requieren definición

<!-- Grado de libertad: MEDIA. Método fijo, contenido depende del caso. -->

---
description: Construye o actualiza el registro de riesgos de un proyecto con
  probabilidad, impacto, mitigación y dueño. Úsala cuando el usuario mencione
  riesgos, qué puede salir mal, un risk register, o pida evaluar un plan
  antes de comprometerlo.
---

## Instrucciones

### 1 · Identifica por categoría

Recorre estas categorías. No todas aplican a todo proyecto, pero
recorrerlas evita puntos ciegos:

| Categoría | Pregunta que dispara el riesgo |
|---|---|
| **Alcance** | ¿Qué no está definido y alguien asume distinto? |
| **Técnico** | ¿Qué no hemos hecho antes? ¿De qué dependemos y no controlamos? |
| **Recursos** | ¿Quién es irreemplazable en este plan? |
| **Calendario** | ¿Qué depende de qué? ¿Dónde está el camino crítico? |
| **Externo** | ¿Qué proveedor, aprobación o tercero nos puede frenar? |
| **Operación** | ¿Qué pasa el día después de entregar? |

### 2 · Clasifica

**Probabilidad:** Alta (pasa en la mayoría de proyectos así) · Media (ha
pasado antes) · Baja (sería inusual).

**Impacto:** Alto (compromete el objetivo o la fecha) · Medio (cuesta
retrabajo significativo) · Bajo (molesta, se absorbe).

### 3 · Para cada riesgo, escribe la mitigación y el disparador

La mitigación es lo que haces **antes** de que pase. El disparador es la
señal observable de que está pasando.

Un riesgo sin disparador no se puede monitorear: nadie sabe cuándo activar
el plan.

## Formato

    | # | Riesgo | Prob | Imp | Mitigación | Disparador | Dueño |
    |---|---|---|---|---|---|---|

Ordena por impacto descendente, luego por probabilidad.

## Reglas

**Un riesgo se enuncia como causa y efecto**, no como un tema:

    ❌  Riesgo de integración
    ✅  Si la API del proveedor cambia sin aviso, la sincronización
        se cae y perdemos un día en diagnosticar

**Los riesgos Alta/Alto llevan además plan de contingencia**: qué se hace
si ya pasó, no solo cómo evitarlo.

**Todo riesgo tiene dueño nombrado.** "El equipo" no es un dueño.

**Distingue riesgo de problema.** Si ya está pasando, no es riesgo: es un
problema y va a otra lista. Dilo explícitamente cuando lo detectes.

## Al final

    <n> riesgos · <n> alta/alto (requieren contingencia) · <n> sin dueño

<!-- Grado de libertad: MEDIA. Marco fijo, contenido depende del proyecto. -->

---
description: Redacta el reporte de avance de un proyecto para dirección,
  con semáforo, desviaciones y decisiones que se necesitan. Úsala cuando el
  usuario pida un status, un reporte de avance, un update para dirección,
  o prepare un comité de seguimiento.
---

## Instrucciones

El reporte se escribe para alguien que tiene cinco minutos y varios
proyectos. Estructura:

    # <Proyecto> · Avance al <fecha>

    ## Semáforo: 🟢 / 🟡 / 🔴

    <Una frase que justifique el color. Si es amarillo o rojo, la frase
    dice qué lo causa, no qué se está haciendo al respecto.>

    ## Lo que avanzó

    - <entregable completado, con evidencia verificable>

    ## Lo que se movió

    | Compromiso | Fecha original | Fecha nueva | Por qué |
    |---|---|---|---|

    ## Decisiones que necesito

    | Decisión | Quién decide | Para cuándo | Qué pasa si no se decide |
    |---|---|---|---|

    ## Riesgos activos

    - <solo los que cambiaron de estado desde el último reporte>

## Criterio del semáforo

| Color | Significa |
|---|---|
| 🟢 **Verde** | En fecha y alcance. Sin decisiones pendientes que bloqueen |
| 🟡 **Amarillo** | Hay desviación recuperable, o hay una decisión pendiente con fecha límite |
| 🔴 **Rojo** | La fecha o el alcance comprometido ya no son alcanzables sin cambiar algo |

**El semáforo se pone antes de escribir el resto.** Si lo decides al final,
vas a justificar el verde.

## Reglas

**Sin adjetivos de avance.** "Buen progreso" no dice nada. Escribe qué se
completó y qué falta.

**Lo que se movió va aunque sea incómodo.** Un status que oculta
deslizamientos deja de ser útil la segunda vez que alguien lo nota.

**Las decisiones pendientes son la parte más importante.** Es lo único que
el lector puede hacer por ti. Cada una lleva fecha límite y consecuencia
de no decidir.

**No repitas el reporte anterior.** Solo lo que cambió.

**Si un dato no lo tienes, escribe `SIN DATO`.** No estimes.

<!-- Grado de libertad: MEDIA. Estructura fija, contenido libre. -->

---
description: Convierte notas crudas de una reunión en una minuta con acuerdos,
  responsables y fechas. Úsala cuando el usuario pegue notas de junta, pida
  una minuta, un acta, un resumen de reunión, o pregunte en qué quedamos.
---

## Instrucciones

Recibes notas desordenadas. Produce una minuta con esta estructura:

    # <Tema> · <fecha>

    **Asistentes:** <lista, o "no registrados">

    ## Decisiones

    - <qué se decidió> — decidido por <quién>

    ## Acuerdos

    | Qué | Quién | Para cuándo |
    |---|---|---|
    | <acción concreta, en imperativo> | <nombre> | <fecha o "sin fecha"> |

    ## Temas abiertos

    - <lo que quedó sin resolver y quién lo retoma>

    ## Contexto relevante

    <solo si hay algo que alguien ausente necesitaría para entender lo anterior>

## Reglas

**Separa decisión de acuerdo.** Una decisión es algo que ya se resolvió.
Un acuerdo es algo que alguien va a hacer. Confundirlos es el error más
común en las minutas.

**Todo acuerdo necesita dueño.** Si las notas no dicen quién, escribe
`SIN DUEÑO` en mayúsculas. Es información, no un hueco.

**Toda fecha se escribe explícita.** "La próxima semana" se convierte en
la fecha concreta. Si no puedes calcularla, escribe `SIN FECHA`.

**No inventes.** Si las notas son ambiguas sobre quién dijo qué o en qué
se quedó, escribe la ambigüedad tal cual: "queda pendiente confirmar si X
o Y". No resuelvas por tu cuenta lo que la reunión no resolvió.

**Omite lo que no aporta.** Una minuta no es una transcripción. Si algo
se discutió pero no produjo decisión, acuerdo ni tema abierto, no va.

## Al final

Agrega una línea con el conteo:

    <n> decisiones · <n> acuerdos (<n> sin dueño, <n> sin fecha) · <n> temas abiertos

Los sin dueño y sin fecha son la parte accionable: quien lee la minuta
sabe qué tiene que cerrar.

<!-- Grado de libertad: MEDIA. Estructura fija, juicio libre sobre qué entra. -->

---
description: Revisa una propuesta técnico-comercial contra los requisitos de
  las bases y marca cada punto sin evidencia. Úsala cuando el usuario
  mencione propuesta, licitación, bases, anexo técnico, matriz de
  cumplimiento, o pida revisar antes de entregar.
allowed-tools: Read Grep
---

## Instrucciones

### 1 · Extrae los requisitos

Si el usuario dio las bases o el anexo técnico, extrae cada requisito como
una línea verificable. Si solo dio la propuesta, dilo y pide las bases: sin
ellas esto es una revisión de estilo, no de cumplimiento.

Numera los requisitos con la numeración del documento original, no con una
propia. Quien evalúa busca por su número.

### 2 · Para cada requisito, encuentra la evidencia

| Estado | Significa |
|---|---|
| **CUMPLE** | La propuesta lo atiende explícitamente y se puede señalar dónde |
| **PARCIAL** | Lo menciona pero no lo demuestra, o lo atiende a medias |
| **NO CUMPLE** | No aparece |
| **AMBIGUO** | El requisito se puede interpretar de dos formas y la propuesta elige una sin decirlo |

La evidencia es una referencia concreta: sección y página. "Se aborda en
la propuesta" no es evidencia.

### 3 · Revisa los riesgos de compromiso

Aparte del cumplimiento, marca:

- Niveles de servicio aceptados sin reserva
- Penalizaciones sin tope
- Fechas comprometidas sin condicionante
- Alcance que excede lo que las bases piden (regalar trabajo también es un riesgo)
- Cifras que no cuadran entre el apartado técnico y el económico

### 4 · Revisa la consistencia entre apartados

Es donde más se cae una propuesta:

- ¿El perfil que promete el apartado técnico está costeado en el económico?
- ¿Los plazos del cronograma coinciden con los del texto?
- ¿La razón social, RFC y datos fiscales son los mismos en todos los anexos?
- ¿Las firmas requeridas están identificadas?

## Formato

    ## Matriz de cumplimiento

    | Req. | Descripción | Estado | Evidencia | Acción |
    |---|---|---|---|---|

    ## Riesgos de compromiso

    | Riesgo | Dónde | Severidad | Recomendación |
    |---|---|---|---|

    ## Inconsistencias entre apartados

    | Qué | Dice en A | Dice en B |
    |---|---|---|

Cierra con:

    <n> requisitos · <n> cumple · <n> parcial · <n> no cumple · <n> ambiguo
    VEREDICTO: <entregable / requiere corrección>

<!-- Grado de libertad: MEDIA. Método fijo, criterio libre. -->

---
description: Valida que un documento entregable cumpla los criterios de
  completitud, consistencia y formato antes de enviarlo al cliente. Úsala
  cuando el usuario pida revisar un documento, validar un entregable,
  pregunte si un documento está listo para enviar, o mencione control de
  calidad documental.
allowed-tools: Read Grep Bash(bash ${CLAUDE_SKILL_DIR}/scripts/*)
---

## Instrucciones

### 1 · Verificación mecánica primero

    bash ${CLAUDE_SKILL_DIR}/scripts/verificar.sh <archivo>

El script detecta marcadores sin llenar, referencias rotas y secciones
vacías. Lo que reporta son hechos, no opiniones: corrígelos antes de
pasar a la revisión de contenido.

### 2 · Completitud

Para cada sección del documento:

- ¿Existe?
- ¿Tiene contenido real o solo un encabezado?
- ¿Contiene marcadores sin llenar: `TODO`, `XXX`, `[pendiente]`, `<...>`, `Lorem`?
- ¿Las tablas tienen todas sus celdas?

### 3 · Consistencia

- **Terminología**: ¿el mismo concepto se llama igual en todo el documento?
- **Cifras**: ¿los totales suman? ¿el mismo dato aparece igual en todos lados?
- **Fechas**: ¿son coherentes entre sí? ¿alguna está en el pasado sin querer?
- **Nombres**: ¿la razón social, los nombres propios y los cargos están bien escritos y son los mismos en todo el documento?
- **Referencias cruzadas**: ¿"ver sección 4.2" apunta a algo que existe?

### 4 · Riesgo de compromiso

Esta es la parte que más cuesta cuando falla. Marca:

- Compromisos de fecha sin condicionante
- Cifras sin fuente ni supuesto declarado
- Afirmaciones absolutas: "garantizamos", "siempre", "en todos los casos"
- Alcance que excede lo acordado
- Penalizaciones o niveles de servicio aceptados implícitamente

### 5 · Formato

- Jerarquía de encabezados sin saltos de nivel
- Numeración continua en listas y secciones
- Unidades y formato numérico consistentes
- Tablas con encabezado

## Formato del reporte

    BLOQUEANTE  <sección> — <qué falta y por qué impide enviar>
    IMPORTANTE  <sección> — <inconsistencia o riesgo>
    MENOR       <sección> — <formato o estilo>

Ordena por severidad. Omite las categorías vacías.

Cierra con un veredicto de una línea:

    LISTO PARA ENVIAR  /  REQUIERE CORRECCIÓN (<n> bloqueantes)

No reescribas el documento. Señala y explica.

<!-- Grado de libertad: MEDIA. Checklist fijo, juicio libre sobre severidad. -->

#!/usr/bin/env bash
# Verificación mecánica de un documento entregable.
# Reporta hechos. El juicio lo pone Claude.
set -uo pipefail

DOC="${1:-}"
if [ -z "$DOC" ] || [ ! -f "$DOC" ]; then
  echo "USO: verificar.sh <archivo>"
  exit 0
fi

echo "ARCHIVO: $DOC"
echo "LINEAS: $(wc -l < "$DOC" | tr -d ' ')"
echo "PALABRAS: $(wc -w < "$DOC" | tr -d ' ')"
echo ""

echo "== MARCADORES SIN LLENAR =="
if grep -nEi 'TODO|TBD|XXX+|lorem ipsum|\[pendiente\]|\[insertar|\[completar|<placeholder>|PENDIENTE DE' "$DOC"; then
  :
else
  echo "  ninguno"
fi
echo ""

echo "== SECCIONES Y JERARQUIA =="
grep -nE '^#{1,6} ' "$DOC" | head -60 || echo "  sin encabezados markdown"
echo ""

echo "== SECCIONES POSIBLEMENTE VACIAS =="
awk '
  function nivel(s) { match(s, /^#+/); return RLENGTH }
  /^#{1,6} / {
    n = nivel($0)
    # un encabezado sin cuerpo solo cuenta como vacio si el siguiente
    # no es un subnivel suyo
    if (titulo != "" && cuerpo == 0 && n <= prev) print "  linea " nlin ": " titulo
    titulo = $0; nlin = NR; cuerpo = 0; prev = n; next
  }
  /[^[:space:]]/ { if (titulo != "") cuerpo = 1 }
  END { if (titulo != "" && cuerpo == 0) print "  linea " nlin ": " titulo }
' "$DOC" | head -20
echo "  (vacio = encabezado sin contenido ni subsecciones)"
echo ""

echo "== REFERENCIAS CRUZADAS DECLARADAS =="
grep -noEi '(ver|v[eé]ase|consulte|seg[uú]n) (la |el )?(secci|apartado|anexo|cap[ií]tulo|tabla|figura|cl[aá]usula)[^ ]* [0-9IVXivx][0-9IVXivxA-Za-z.]*' "$DOC" | head -25 || echo "  ninguna"
echo ""

echo "== FECHAS ENCONTRADAS =="
grep -noE '[0-9]{1,2}[/-][0-9]{1,2}[/-][0-9]{2,4}|[0-9]{4}-[0-9]{2}-[0-9]{2}' "$DOC" | head -25 || echo "  ninguna"
echo ""

echo "== LENGUAJE DE COMPROMISO ABSOLUTO =="
grep -nEi 'garantiza(mos|r|do)?|siempre|nunca|en todos los casos|sin excepci[oó]n|al 100%|totalmente' "$DOC" | head -25 || echo "  ninguno"
echo ""

echo "== CIFRAS CON MONEDA O PORCENTAJE =="
grep -noE '\$[0-9][0-9,.]*|[0-9][0-9,.]*%|MXN ?[0-9][0-9,.]*|USD ?[0-9][0-9,.]*' "$DOC" | head -30 || echo "  ninguna"
echo ""

echo "== TABLAS =="
echo "  filas de tabla detectadas: $(grep -cE '^\|' "$DOC" 2>/dev/null; true)"

---
description: Verifica que un conjunto de documentos relacionados diga lo
  mismo entre sí: cifras, fechas, nombres y compromisos. Úsala cuando el
  usuario tenga varios documentos de un mismo proyecto, mencione anexos,
  o pregunte si todo cuadra entre sí.
allowed-tools: Read Grep Glob
---

## Instrucciones

Esta skill no revisa un documento: revisa **el conjunto**. El error que
busca es el que solo se ve comparando.

### 1 · Construye el inventario

Lista los documentos a comparar y qué rol tiene cada uno: contrato,
anexo técnico, anexo económico, cronograma, matriz de cumplimiento.

Si falta alguno que los demás referencian, dilo antes de seguir.

### 2 · Compara por dimensión

**Cifras.** Toma cada monto, porcentaje y cantidad, y busca sus
apariciones en todos los documentos. Un monto que aparece distinto en dos
lugares es un hallazgo bloqueante.

**Fechas.** Fechas de inicio, entrega, vigencia y hitos. Verifica además
que sean coherentes: que la entrega no sea anterior al inicio, que la
vigencia cubra el cronograma.

**Nombres y datos fiscales.** Razón social, RFC, domicilio, representante
legal, cargos. Un carácter distinto entre anexos es motivo de descalificación
en un proceso formal.

**Compromisos.** Niveles de servicio, plazos de respuesta, penalizaciones,
entregables. Lo prometido en un documento tiene que estar costeado y
calendarizado en los otros.

**Terminología.** Si el contrato dice "Prestador" y el anexo dice
"Proveedor", uno de los dos está mal.

### 3 · Clasifica cada hallazgo

| Severidad | Criterio |
|---|---|
| **BLOQUEANTE** | Cifras o datos fiscales que no coinciden; compromiso sin respaldo |
| **IMPORTANTE** | Fechas incoherentes; terminología inconsistente en cláusulas |
| **MENOR** | Formato, redondeo, estilo |

## Formato

    | # | Dimensión | Hallazgo | Doc A dice | Doc B dice | Severidad |
    |---|---|---|---|---|---|

Ordena por severidad.

Para cada bloqueante, agrega una línea con **cuál de los dos es el correcto**
si se puede determinar, o la pregunta que hay que hacer si no.

## Al final

    <n> documentos comparados · <n> hallazgos
    <n> bloqueantes · <n> importantes · <n> menores

Si no hay hallazgos, dilo en una línea. No inventes inconsistencias para
llenar el reporte.

<!-- Grado de libertad: ALTA. El criterio de qué cuenta como inconsistencia es el valor. -->

---
description: Audita las skills de un directorio contra las reglas de
  nomenclatura, descripción, estructura y seguridad, y reporta qué corregir.
  Úsala cuando el usuario pida revisar sus skills, auditar el directorio de
  skills, o pregunte por qué alguna de sus skills no funciona bien.
allowed-tools: Read Grep Glob
---

## Instrucciones

Recorre cada `SKILL.md` del directorio indicado y evalúa los siguientes
puntos. Reporta solo lo que falla.

### Frontmatter

- ¿El `---` de apertura es la **primera línea** del archivo? Si no, todo el
  archivo se trata como contenido y la skill no tiene metadatos
- ¿Existe `description`?
- ¿`description` más `when_to_use` suman menos de 1,536 caracteres?
- Si hay `name`: solo minúsculas, números y guiones, máximo 64 caracteres,
  sin las palabras `anthropic` ni `claude`

### Descripción

- ¿Está en tercera persona? Marca cualquier `te puedo`, `puedo ayudarte`,
  `te ayudo`, `you can`, `I can`
- ¿Incluye la parte del **cuándo**? Busca `úsala cuando`, `use when`, o
  equivalente
- ¿El caso principal está al inicio, o la primera oración es genérica?
- ¿Usa términos vagos como `documentos`, `archivos`, `datos`, `cosas`
  sin acotar?

### Nombre del directorio

- ¿Está en gerundio y describe una actividad?
- ¿Es genérico? Marca `helper`, `utils`, `tools`, `misc`, `general`,
  `mi-skill`, `test`

### Estructura

- ¿`SKILL.md` por debajo de 500 líneas?
- ¿Las referencias a otros archivos van a **un solo nivel**? Si
  `reference.md` referencia a un tercer archivo, es una cadena
- ¿Hay rutas absolutas o con barra invertida?
- ¿Las rutas a archivos propios usan `${CLAUDE_SKILL_DIR}`?
- ¿Declara su grado de libertad en un comentario final?

### Seguridad

- ¿`allowed-tools` pide más de lo necesario? Un `Bash` pelado sin patrón
  es un hallazgo
- Si la skill ejecuta acciones con efectos —desplegar, commitear, enviar,
  borrar— ¿lleva `disable-model-invocation: true`?
- ¿Hay credenciales, tokens, rutas de infraestructura o datos de cliente?
- ¿Los comandos `!` que pueden salir con código distinto de cero llevan
  `|| true`?

### Contenido

- ¿Explica cosas que Claude ya sabe?
- ¿Tiene información con fecha de caducidad: versiones concretas, precios,
  nombres en puestos, "actualmente", "por ahora"?
- ¿La terminología es consistente de principio a fin?
- ¿Ofrece varias alternativas donde debería dar una?

### Solapamiento

Compara las descripciones entre sí. Dos skills cuyas descripciones cubren
el mismo territorio se estorban: se dispara la equivocada de forma
inconsistente. Repórtalo con las dos involucradas.

## Formato del reporte

    ## <nombre-de-la-skill>

    BLOQUEANTE  <qué está mal> → <cómo se corrige>
    IMPORTANTE  <qué está mal> → <cómo se corrige>
    MENOR       <qué está mal>

**Bloqueante:** frontmatter que no parsea, descripción sin el "cuándo",
descripción en 1ª o 2ª persona, secretos, acción con efectos sin
`disable-model-invocation`.

Si una skill no tiene hallazgos, escríbela con un `✓` y nada más.

Cierra con:

    <n> skills · <n> sin hallazgos · <n> bloqueantes · <n> importantes
    Solapamientos detectados: <lista de pares, o ninguno>

<!-- Grado de libertad: MEDIA. Checklist fijo, juicio libre sobre severidad. -->

---
description: Convierte la conversación actual en una skill de Claude Code
  reutilizable, analizando qué contexto hizo falta y qué correcciones
  revelaron huecos. Úsala cuando el usuario diga que quiere convertir esto
  en una skill, guardar este patrón, no volver a explicar lo mismo, o
  destilar la conversación.
disable-model-invocation: true
---

> Esta skill se invoca manualmente con `/destilando-conversacion` al final
> de una conversación productiva.

## Fase 1 · Analiza antes de escribir

Responde estas seis preguntas en una lista corta. No escribas el SKILL.md
todavía.

1. **¿Cuál fue la tarea real?** Enúnciala como actividad, en gerundio.

2. **¿Qué contexto tuvo que dar el usuario** que tú no sabías de entrada?
   Sepáralo en (a) convenciones o criterios suyos, y (b) hechos del proyecto.

3. **¿En qué momentos te corrigió**, y qué revela cada corrección sobre lo
   que faltaba en la instrucción inicial?

4. **¿Qué parte de lo explicado era innecesaria** porque ya lo sabías?

5. **¿Qué tan frágil es la tarea?** Alta libertad si varios caminos llegan a
   un buen resultado; media si hay un patrón preferido; baja si un paso en
   falso rompe algo.

6. **¿Con qué frases exactas pediría el usuario esta tarea la próxima vez?**
   Tres variantes, en sus palabras, no en lenguaje de manual.

## Fase 2 · Construye el SKILL.md

### Nombre

Gerundio que describe la actividad, minúsculas con guiones, máximo 64
caracteres, sin `anthropic` ni `claude`. Nunca genérico.

### Descripción

Fórmula: `[qué hace]. Úsala cuando [cuándo usarla].`

- Tercera persona, siempre
- Caso principal al inicio
- Los disparadores salen de la pregunta 6, no de lenguaje formal
- Tope de 1,536 caracteres

### Cuerpo

- Solo lo de la pregunta 2. Nada de lo de la pregunta 4
- Instrucciones permanentes, no pasos de un solo uso: el contenido se queda
  en contexto turno tras turno
- Enuncia qué hacer, no narres por qué
- Si la pregunta 5 dio baja libertad: comando exacto y prohibición explícita
  de variarlo
- Por debajo de 100 líneas

### Frontmatter

- `allowed-tools` solo si ejecuta comandos, con el patrón más acotado posible
- `disable-model-invocation: true` si la tarea tiene efectos irreversibles
- Cierra el cuerpo con `<!-- Grado de libertad: ALTA/MEDIA/BAJA -->`

## Fase 3 · Entrega

1. El análisis de las seis preguntas
2. El `SKILL.md` completo, en un bloque de código
3. El comando `mkdir -p` para crear la carpeta
4. Tres evaluaciones: dos que **deben** disparar la skill y una que **no**
   debe dispararla, con el resultado esperado de cada una

No ofrezcas alternativas. Da una versión, y di qué decisión tomaste en los
puntos donde había más de un camino.

<!-- Grado de libertad: MEDIA. Método fijo, contenido depende de la conversación. -->