Plantillas de prompts para refactorizar código

Refactoriza [componente/módulo/función] para mejorar [problema concreto de
mantenibilidad].

Conservación del comportamiento: Mantén sin cambios [API pública, comportamiento
visible, eventos, manejo de errores, accesibilidad, característica de rendimiento].

Alcance: Limita los cambios a [archivos/límite]. No cambies [no objetivos explícitos].

Pruebas: Identifica las pruebas existentes que demuestran el contrato actual. Añade
cobertura de regresión enfocada si un comportamiento protegido no está cubierto.

Criterios de aceptación: Se reduce la duplicación o el acoplamiento, el
comportamiento público no cambia y el diff no tiene limpieza no relacionada.

Validación: Ejecuta [comando de prueba enfocado], comprobación de tipos y [flujo de
trabajo manual]. Antes de editar, describe el contrato actual y la extracción
segura más pequeña.

Extrae la [región de interfaz] repetida de [componentes padre] en el componente
reutilizable más pequeño.

Conservación del comportamiento: Mantén idénticos las etiquetas visibles, el foco
del teclado, los atributos aria, el estado de carga, los eventos de analítica y el
diseño móvil.

Alcance: Solo [componentes padre], el componente nuevo y las pruebas directas. No
traslades la propiedad de la obtención de datos ni de las mutaciones al componente
extraído.

Pruebas: Conserva o añade pruebas de los estados [vacío, carga, error, con contenido]
y del comportamiento interactivo del que dependen las personas usuarias.

Criterios de aceptación: Los componentes padre usan el componente nuevo, el
comportamiento distinto permanece explícito y ningún prop público ni enlace cambia
de forma inesperada.

Validación: Ejecuta las pruebas enfocadas del componente, inspecciona los estados
renderizados en anchos de escritorio y móvil e informa de cualquier comportamiento
que no se haya podido verificar.

Analiza las diferencias existentes antes de extraer nada.

Encuentra la lógica duplicada en [lista de archivos] y propone la abstracción
compartida más pequeña.

Conservación del comportamiento: Conserva el comportamiento público, los valores
predeterminados, el manejo de errores, la telemetría y el tiempo de cada llamada.

Alcance: No generalices fuera de estas llamadas. Mantén visibles las diferencias
cuando representen reglas de producto en lugar de duplicación accidental.

Pruebas: Relaciona cada prueba existente con el comportamiento compartido que
protege. Añade una prueba para cada divergencia significativa.

Criterios de aceptación: La lógica repetida se centraliza solo cuando el contrato
es realmente el mismo; las llamadas siguen siendo legibles y equivalentes en
comportamiento.

Validación: Ejecuta las pruebas enfocadas de las llamadas y compara su salida
observable antes y después.

Devuelve un análisis de las diferencias comunes frente a las intencionadas antes
de escribir código.

Investiga un problema de rendimiento en [pantalla/flujo de trabajo].

Evidencia: [medición, traza, tiempo, informe de usuario o escenario reproducible].
No supongas que [memoización/caché/división de código] es la respuesta.

Conservación del comportamiento: Mantén sin cambios la carga visible para la persona
usuaria, la vigencia, la accesibilidad, la autorización y el comportamiento de error.

Alcance: Inspecciona primero [rutas]. No introduzcas caché persistente, una nueva
biblioteca de estado ni una dependencia de servidor sin una necesidad medida.

Pruebas: Conserva las pruebas de comportamiento existentes. Añade una comprobación de
regresión o de medición solo si el proyecto tiene una convención estable para ello.

Criterios de aceptación: Nombra el cuello de botella, muestra una línea base y un
resultado, y conserva intacto el comportamiento protegido.

Validación: Ejecuta las pruebas pertinentes, captura la medición acordada y documenta
contrapartidas como la vigencia o la memoria.

Refactoriza [módulo heredado] para que se reduzca [riesgo concreto o coste de
mantenimiento] sin cambiar el comportamiento que se observa externamente.

Conservación del comportamiento: Enumera las entradas, salidas, modos de error,
efectos secundarios, formatos de archivo y requisitos de compatibilidad heredados de
los que dependen los clientes.

Alcance: Trabaja dentro de [módulo/límite]. No actualices dependencias no relacionadas
ni reescribas las llamadas en el mismo cambio.

Pruebas: Primero caracteriza el comportamiento actual con pruebas o fixtures donde
falte cobertura. Incluye casos límite conocidos y entradas con formato incorrecto.

Criterios de aceptación: La nueva estructura es más fácil de razonar, el
comportamiento caracterizado se mantiene estable y las notas de compatibilidad son
explícitas.

Validación: Ejecuta pruebas de caracterización, pruebas de integración existentes,
comprobación de tipos y un escenario manual o de línea de comandos representativo.

Explica el comportamiento desconocido y el riesgo antes de proponer una implementación.

Planifica una refactorización por etapas de [sistema] para lograr [arquitectura
objetivo].

Conservación del comportamiento: Mantén [APIs públicas, compatibilidad de datos,
permisos, flujos de trabajo de usuarios, comportamiento de despliegue y ruta de
reversión].

Alcance: Divide el trabajo en hitos que puedan probarse de forma independiente.
Identifica los archivos que no deben cambiar en el primer hito.

Pruebas: Define las pruebas enfocadas, las pruebas de contrato, las comprobaciones de
migración y los flujos de trabajo manuales que cada hito debe superar antes de que
empiece el siguiente.

Criterios de aceptación: Cada etapa tiene una condición de entrada clara, un resultado
observable, una estrategia de reversión y ninguna dependencia oculta de una etapa
posterior.

Validación: Revisa el plan frente a la arquitectura actual, ejecuta las comprobaciones
de cada etapa y detente si un hito invalida el supuesto original.

No edites código hasta presentar las etapas, los riesgos y las alternativas.