actualizar-plantilla

Sincroniza el tooling de este proyecto con la versión actual de su plantilla de origen. Solo toca la capa reutilizable — nunca la documentación ya rellenada ni el código.

El workflow .github/workflows/template-update-check.yml revisa semanalmente si la plantilla publicó mejoras y abre un issue de aviso — esta skill es la que las aplica.

Paso 1 — Leer el origen

Lee .template-origin en la raíz (lo escribe /instanciar):

repo=https://github.com/brayandiazc/project-starter-template-es-ai
commit=<sha-de-la-plantilla-al-instanciar>
fecha=YYYY-MM-DD
versiones=<versiones del CHANGELOG de la plantilla al instanciar, separadas por coma>

Si no existe, pregunta de qué plantilla/variante vino el proyecto y desde qué fecha aproximada, y usa el tag/commit de esa época como base.

Paso 2 — Calcular el diff del tooling

Clona la plantilla a un directorio temporal y calcula qué cambió desde el commit de origen, limitado a las rutas de tooling:

git clone --quiet <repo> /tmp/tpl-update && cd /tmp/tpl-update
git diff --stat <commit-origen>..HEAD -- \
  .claude/ .github/scripts/ .github/workflows/ specs/_template/ \
  docs/conventions/_template.md

Excluye siempre: README.md, docs/ rellenados, CHANGELOG.md, LICENSE y cualquier archivo que el proyecto haya adaptado (compara antes de pisar; si el archivo local difiere de la versión vieja de la plantilla, es una adaptación local — muéstrala y pregunta).

Documentos: distingue NUEVO de EXISTENTE

«No tocar la documentación» es la regla correcta para los documentos que el proyecto ya tiene rellenados. No lo es para los que no existen. Un proyecto que adoptó la plantilla hace tiempo puede estar a dieciséis documentos de distancia —convenciones nuevas, convenciones nuevas, la definición de terminado— y hoy no se los trae nadie: esta skill los excluye por diseño y /instanciar cree que el proyecto es virgen.

# Documentos de la plantilla que el proyecto NO tiene: traerlos es seguro.
(cd /tmp/tpl-update && find docs legal design -type f -name "*.md" 2>/dev/null) \
  | while IFS= read -r f; do [ -e "$f" ] || echo "NUEVO: $f"; done

• No existe → se propone traerlo, con sus placeholders sin rellenar. Es documentación que falta, no documentación que se pisa.
• Existe → no se toca. Se lista como «revisar a mano» y ahí acaba la intervención.

Y revisa los renombrados

Es el fallo silencioso de esta skill, así que va antes de proponer nada: un documento que la plantilla renombró o fusionó no se sustituye, se duplica. Quedan los dos —el tuyo con contenido y el nuevo vacío—, los dos son markdown válido, los enlaces resuelven y ningún check chista.

Busca en el CHANGELOG.md de la plantilla, entre tu versión y la actual, las entradas de ### Changed y ### Removed que mencionen rutas de archivo. Contrástalas con lo que tiene el proyecto y propón la migración par por par: mover el contenido y borrar el viejo, nunca dejar ambos.

Checks que se volvieron más estrictos

Es el caso que más fácil rompe un proyecto ajeno: un check que ya existía empieza a exigir cosas que antes no exigía, y el primer PR sale en rojo por decenas de motivos a la vez. Un rojo así no se arregla: se ignora, y a partir de ahí el check deja de servir.

Antes de traer un check nuevo o actualizado, córrelo y mira qué diría, sin adoptarlo todavía. Si señala mucho, resuélvelo en un commit aparte y anterior.

El caso concreto de hoy: check-placeholders.sh pasó a ver los huecos en prosa ([Un párrafo describiendo…]), que antes eran invisibles. En un proyecto real son unos 160 de golpe. Tiene modo de migración:

bash .github/scripts/check-placeholders.sh --marcar

Los marca en una pasada diciendo que están sin revisar, para que el CI vuelva a verde sin esconder nada: siguen listándose en cada ejecución hasta que alguien los escriba. Solo toca la prosa — los placeholders [MAYÚSCULAS] son valores por sustituir y marcarlos en bloque sí sería taparlos.

Ese commit va antes del que trae el check, y su mensaje debe decir que son heredados.

Endurecimientos recientes — lo que va a señalar el tooling nuevo en un proyecto instanciado antes de que llegaran:

• check-inheritance.sh: tu .template-origin no tiene versiones= — añádela con las versiones que la plantilla tenía cuando instanciaste (están en su CHANGELOG).
• check-placeholders.sh: ya revisa .github/ (salvo scripts/workflows) — el [URL_REPOSITORIO] de ISSUE_TEMPLATE/config.yml va a salir; rellénalo.
• spec-guardrails.sh: exige también design.md y tasks.md sin líneas de plantilla antes de editar código en feat/*/fix/*.
• secret-guardrails.sh: bloquea leer/escribir .env y llaves también vía Bash.

Paso 3 — Proponer y aplicar

Presenta un resumen por archivo (nuevo / actualizado / eliminado en la plantilla) y deja elegir qué aplicar. Trabaja en una rama chore/update-template. Aplica lo aceptado, ejecuta la suite bash .github/scripts/tests/run-tests.sh si existe, y actualiza .template-origin con el nuevo commit y la fecha de hoy.

Paso 4 — Cierre

Muestra el diff final y recuerda abrir un PR. NO hagas commit ni push sin confirmación.

Ejemplo: /actualizar-plantilla → "la plantilla tiene 3 mejoras de tooling desde tu instanciación (hook nuevo, script de enlaces, workflow de calidad); ¿aplico las 3?"

NO pises adaptaciones locales sin preguntar, NO toques documentación ya rellenada ni código de producción, y NO apliques cambios de la plantilla que el proyecto decidió eliminar (p. ej. convenciones borradas a propósito).