Skip to main content
Este documento define el proceso para gestionar cambios de requerimientos en proyectos construidos con AI coding agents. El objetivo es que los cambios se implementen sin romper lo existente, con documentación trazable y contexto claro para la AI.

Principio fundamental

Un cambio sin evaluación de impacto es una apuesta. Antes de pedirle a la AI que modifique algo, el equipo humano debe entender qué se toca, qué se puede romper, y qué documentación debe actualizarse. La AI ejecuta; el humano decide.

1. Tipos de cambio

Cada tipo tiene un flujo diferente. Identificar el tipo ANTES de actuar.

1.1 Clasificación

1.2 Regla de decisión rápida

  • Si el cambio toca 1-2 archivos y no modifica el schema de BD → flujo corto (sección 3)
  • Si el cambio toca 3+ archivos, modifica schema, o cambia flujos de navegación → flujo completo (sección 4)

2. Estructura de documentación de cambios

2.1 Carpeta de cambios

2.2 Anatomía de un documento de cambio (CHG-XXX_nombre.md)

2.3 CHANGE_LOG.md (registro permanente)

Este archivo es el registro histórico de todos los cambios. NUNCA se borra. Cuando un cambio se completa, su resumen se mueve aquí y el archivo individual en pending/ se elimina.

3. Flujo corto (cambios de bajo riesgo)

Para correcciones y ajustes menores que tocan 1-2 archivos y no modifican schema.

3.1 Pasos

  1. Documentar: Crear un CHG-XXX mínimo (solo metadata + qué cambia + estado actual + estado deseado).
  2. Implementar en sesión limpia: Abrir nueva sesión. Dar contexto: “El archivo X actualmente hace Y. Necesito que haga Z. No modifiques ningún otro archivo.”
  3. Verificar: Probar que funciona Y que no rompió nada adyacente.
  4. Cerrar: Pedirle a la AI que actualice la documentación relevante. Mover resumen a CHANGE_LOG.md. Eliminar el archivo en pending/.

3.2 Prompt template para la AI (flujo corto)


4. Flujo completo (cambios de medio-alto riesgo)

Para cambios de requerimiento, cambios que tocan 3+ archivos, o cualquier cosa que modifique schema de BD o flujos de navegación.

4.1 Paso 1: Documentar el cambio

El PO o quien detecta el cambio crea el documento CHG-XXX en docs/changes/pending/ con las secciones: metadata, qué cambia, por qué cambia, estado actual, estado deseado. Regla: No avanzar a implementación sin documento de cambio. Si el cambio es verbal, documentarlo primero.

4.2 Paso 2: Analizar impacto (con ayuda de la AI)

Abrir una sesión DEDICADA al análisis, NO a la implementación. Prompt template para análisis de impacto:
Con el análisis, llenar la sección “Análisis de impacto” del documento de cambio.

4.3 Paso 3: Planificar la implementación

Con el impacto claro, definir el plan de implementación ANTES de ejecutar. Regla de secuencia: Implementar en este orden estricto:
  1. Schema de BD (si aplica) → migración primero
  2. Backend (API, servicios, tipos) → la base
  3. Frontend (componentes, páginas) → lo visible
  4. Tests → validar todo
  5. Documentación → cerrar el loop
Regla de granularidad: Cada paso del plan debe ser lo suficientemente pequeño para validarlo individualmente. Si un paso toca más de 3 archivos, subdividirlo.

4.4 Paso 4: Implementar por pasos

Abrir una NUEVA sesión limpia para la implementación. No reutilizar la sesión de análisis. Prompt template para implementación por pasos:
Entre pasos:
  • Verificar que lo implementado funciona.
  • Verificar que lo anterior no se rompió.
  • Confirmar para continuar o corregir antes de avanzar.

4.5 Paso 5: Verificar el cambio completo

Después de todos los pasos de implementación:

4.6 Paso 6: Actualizar documentación y cerrar

Prompt para cierre:
Después de que la AI actualiza:
  • Revisar que las actualizaciones son correctas.
  • Eliminar docs/changes/pending/CHG-XXX_nombre.md.
  • El registro en CHANGE_LOG.md queda como evidencia permanente.

5. Regla del lifecycle de documentos de cambio

Este es el flujo de vida de cada documento de cambio:
Regla de limpieza: Un archivo en pending/ que lleve más de 2 semanas sin actividad debe ser revisado. Si el cambio ya no aplica, moverlo a CHANGE_LOG.md con estado “Descartado” y eliminarlo de pending.

6. Patrones anti-regresión

Estos patrones previenen que la AI rompa cosas al implementar cambios.

6.1 Dar contexto explícito de lo que NO debe cambiar

Siempre incluir en el prompt una sección de restricciones:

6.2 Validar después de cada paso

No implementar más de un paso sin validar. La secuencia es:

6.3 Sesiones limpias para cambios

NUNCA implementar un cambio en una sesión donde ya se estaba trabajando en otra cosa. Siempre:
  1. Cerrar o limpiar la sesión actual.
  2. Abrir sesión nueva.
  3. Dar contexto del cambio (documento CHG-XXX).
  4. Implementar.

6.4 Branch por cambio (si usan Git)

Cada cambio de tipo “Cambio de requerimiento” o “Cambio de prioridad” debería tener su propia branch:
Esto permite revertir el cambio completo si algo sale mal, sin afectar main.

7. Cuándo NO usar este protocolo

  • Bug fixes simples (un botón no funciona, un texto está mal): corregir directamente, no hace falta documento de cambio.
  • Refactors internos que no cambian comportamiento: usar proceso de refactor estándar, no este protocolo.
  • Nuevos features que no modifican nada existente: usar el flujo normal de implementación (PRD → Arquitectura → Schema → Implementar).
Este protocolo es SOLO para cuando algo que ya existe necesita cambiar.

8. Checklist rápido de gestión de cambios

Antes de implementar cualquier cambio, verificar:
  • ¿Tengo un documento CHG-XXX creado con estado actual y estado deseado?
  • ¿Sé cuántos archivos se afectan? (determina flujo corto vs completo)
  • ¿Tengo análisis de impacto? (para flujo completo)
  • ¿Tengo un plan de pasos secuenciales?
  • ¿Voy a usar una sesión limpia?
  • ¿Definí explícitamente qué NO debe cambiar?
Después de implementar:
  • ¿El feature modificado funciona según el estado deseado?
  • ¿Los features adyacentes siguen funcionando?
  • ¿Los tests pasan?
  • ¿La documentación principal está actualizada?
  • ¿El resumen está en CHANGE_LOG.md?
  • ¿Eliminé el archivo de pending/?

9. Cómo usar este protocolo

Como skill de Claude Code (.claude/skills/change-management/SKILL.md)

Copiar a .claude/skills/change-management/SKILL.md. Claude lo cargará cuando detecte que se está gestionando un cambio.

Como referencia en CLAUDE.md

Agregar al CLAUDE.md del proyecto:

Para herramientas agnósticas

Los principios (documentar antes de cambiar, analizar impacto, implementar por pasos, verificar, actualizar docs) aplican sin importar la herramienta. Los prompt templates se adaptan al formato de la herramienta.