3AceShowHand/agent-skills

Refactorizar

Cuándo Usarlo

• El usuario solicita refactorización, reestructuración, movimiento de código, división o fusión de módulos, simplificación de interfaces, reescritura por etapas, inversión de dependencias o eliminación de código duplicado.
• Un cambio afirma preservar el comportamiento mientras modifica la estructura.
• Una refactorización afecta múltiples sitios de llamada, símbolos públicos, pruebas o límites de propiedad.

Cuándo No Usarlo

• La tarea es una pequeña corrección local de errores sin cambio estructural.
• El usuario solicita explícitamente un cambio de comportamiento y no una refactorización que preserve el comportamiento.
• Se necesita una revisión de diseño más amplia antes de decidir si refactorizar.
• El primer paso adecuado es una revisión de ingeniería general porque el área de riesgo dominante aún no está clara.

Flujo de Trabajo

1. Definir el comportamiento a preservar y la estructura a modificar.
2. Enunciar objetivos no relacionados: sin cambios de funcionalidad, sin cambios de compatibilidad, sin cambios de semántica de errores, sin afirmaciones de rendimiento a menos que se soliciten explícitamente.
3. Inspeccionar llamadores, pruebas, documentación, configuraciones, código generado y superficies públicas afectadas por la refactorización.
4. Agregar pruebas de caracterización cuando el comportamiento sea importante y la cobertura sea débil.
5. Dividir el trabajo en pasos pequeños y reversibles que compilen y prueben entre límites significativos.
6. Separar movimientos o cambios de nombre mecánicos de las ediciones semánticas.
7. Preservar las API públicas a menos que el usuario solicite explícitamente un cambio disruptivo.
8. Eliminar rutas antiguas solo después de que los llamadores se hayan migrado y el comportamiento se haya verificado.

Referencias

• Lea references/refactor-playbook.md antes de planificar una refactorización de varios pasos.
• Lea references/characterization-tests.md cuando las pruebas sean débiles o el comportamiento deba fijarse.
• Lea references/review-checklist.md antes de finalizar una refactorización.

Condiciones de Parada

• El comportamiento a preservar no está claro.
• La refactorización requiere cambios amplios de comportamiento para tener éxito.
• La API pública, la configuración, el protocolo, el almacenamiento, las métricas o la semántica de errores pueden cambiar sin la aprobación explícita del usuario.
• La diferencia mezcla refactorización, trabajo de funcionalidad, optimización de rendimiento y limpieza de una manera que no puede revisarse de forma segura.

Reglas de Salida

• Informar qué comportamiento se pretendía que permaneciera sin cambios.
• Informar los cambios mecánicos por separado de los cambios semánticos.
• Informar las pruebas o comprobaciones que protegen el comportamiento.
• Indicar cualquier aspecto de comportamiento, compatibilidad o rendimiento no verificado.