gener8v/gener8v.claude-skills.engineering

Antes de un commit, encuentra todo documento que describa lo que el cambio tocó y actualízalo en el mismo commit, o confirma en una línea que ningún documento necesita cambio. Detecta texto obsoleto, documentación faltante y hechos duplicados. Usa antes de cualquier commit o PR, y cuando te pregunten '¿están los docs actualizados?', 'actualiza los docs para este cambio' o '¿me perdí un cambio en el README?'. No es para crear un conjunto de documentación o llenar grandes vacíos (documentation-bootstrap), ni para documentos de pipe gener8v bajo .gener8v/, que son propiedad de los skills de pipe.

¿Qué es gener8v.claude-skills.engineering?

Este skill asegura que el código y su documentación evolucionen juntos en el mismo commit, evitando documentación obsoleta, faltante o duplicada. Es útil para mantener la coherencia entre el comportamiento real del software y lo que los documentos describen, un problema común en proyectos con cambios frecuentes. Está diseñado para entornos de desarrollo que usan agentes de IA como Claude Code, y se activa automáticamente antes de confirmar cambios o al solicitar revisiones de documentación. El skill inspecciona los cambios en el área de staging, evalúa qué documentos deben actualizarse según reglas locales (CLAUDE.md, CONTRIBUTING.md) y una guía de enrutamiento, y guía al desarrollador para editar exactamente las secciones afectadas, confirmando todo junto. No modifica documentos de infraestructura ni crea documentación desde cero, y respeta especificaciones formales como SPEC.md. Al finalizar, reporta los cambios realizados o justifica por qué no fueron necesarios.

Compatible con✓Claude Code~Codex CLI~Cursor

npx skills add https://github.com/gener8v/gener8v.claude-skills.engineering/tree/HEAD/skills/documentation-sync

Documentación

Sincronización de documentación

El código y sus documentos cambian juntos, en el mismo commit. Un documento que está mal es peor que ningún documento.

Tres formas en que los documentos se vuelven incorrectos

Obsoleto. El documento todavía describe el comportamiento, nombre o comando antiguo.
Faltante. Un comportamiento nuevo, un comando nuevo o una configuración nueva no tiene documentación.
Duplicado. El mismo hecho está en dos lugares. Después, una copia cambia y la otra no.

Pasos

Observa qué cambió.

git diff --cached --stat
git diff --stat

Encuentra las reglas propias del repositorio. Lee CLAUDE.md, CONTRIBUTING.md y docs/README.md. Si dicen qué documento es responsable de cada tema, síguelos. Preceden al paso 3.
Enruta cada cambio a su dueño. Usa resources/doc-routing.md. Un hecho tiene un solo hogar. Otros documentos enlazan a él.
Encuentra referencias obsoletas. Por cada nombre que renombraste o eliminaste (una función, bandera, endpoint, configuración, ruta de archivo, comando):
```
git grep -n '<nombre antiguo>'
```
Corrige cada coincidencia en un documento. Vuelve a ejecutar el grep. La postcondición es: sin coincidencias, o solo coincidencias que deben permanecer (por ejemplo, una entrada en CHANGELOG sobre el renombramiento).
Edita. Cambia solo lo que el cambio de código vuelve incorrecto o incompleto. No reescribas secciones no relacionadas. Para redacción clara, usa el skill simple-english si está instalado.
Confirma junto. Agrega los cambios de documentación al área de staging junto con el código. No los pongas en un PR posterior.
Reporta. Enumera los documentos que cambiaste. Si ninguno necesitaba cambio, dilo en una línea y da la razón. Por ejemplo: "Sin docs: refactor interno, sin cambios en comportamiento, comandos o configuraciones."

Cuando el dueño no está claro

Pregunta al usuario. No crees un nuevo documento para evitar la pregunta.

Una prueba útil: ¿es un hecho sobre el estado actual (una configuración, una versión, un estado)? Va en el documento de referencia o estado. ¿Es un procedimiento (pasos que alguien sigue)? Va en la guía, runbook o skill que es dueño de ese procedimiento.

Las especificaciones tienen prioridad

Si el repositorio tiene un SPEC.md (ver engineering:spec-writing) o especificaciones gener8v bajo .gener8v/specifications/, ellas definen el comportamiento deseado.

Si tu cambio hace lo que la especificación dice, la especificación no necesita edición.
Si tu cambio contradice la especificación, detente. Informa al usuario. Cambia primero la especificación, a través de su dueño: engineering:spec-writing para SPEC.md, gener8v:specification para especificaciones de pipe. No edites la especificación en silencio para que coincida con el código.

Documentos de pipe

No edites archivos bajo .gener8v/ manualmente. Los skills de pipe gener8v los escriben y actualizan.

Skills relacionados

engineering:documentation-bootstrap: cuando falta un documento completo, no solo un párrafo.
engineering:github-pr-merge: ejecuta esta verificación antes de un PR.
engineering:github-release: lee la sección Unreleased del CHANGELOG que este skill mantiene actualizada.