CommunityProgramación y desarrollogithub.com

refactor (boshu2/refactor)

Simplifica la estructura, interfaces o responsabilidades preservando el comportamiento. Úsalo cuando se solicite una refactorización enfocada o cuando los cambios de funcionalidad necesiten su propia intención.

¿Qué es refactor)?

Esta skill de agente de IA permite ejecutar transformaciones estructurales controladas en código existente, preservando estrictamente el comportamiento observable. Es útil para desarrolladores que necesitan refactorizar secciones específicas de código (extraer funciones, renombrar, simplificar, mover o eliminar código muerto) sin alterar la funcionalidad. Soporta plataformas de agentes como Cursor, Codex y Claude Code a través del formato de skills compatibles con markdown. El flujo de trabajo comienza grabando una línea base honesta, aplica una sola transformación acotada, ejecuta comprobaciones focalizadas y de regresión, y finalmente entrega un informe detallado con diff, comandos, resultados y comportamientos no verificados. La skill enfatiza la neutralidad: exige que las pruebas pasen antes y después sin cambios en fallos preexistentes, que las salidas hash coincidan byte a byte, y que cualquier puerta de neutralidad omitida se declare explícitamente. También introduce el concepto de 'sondas desechables' para evitar el modo de fallo de 'seam prematuro', limitando a dos intentos antes de reportar hallazgos al solicitante.

Compatible con✓Claude Code~Codex CLI~Cursor
npx skills add https://github.com/boshu2/agentops/tree/main/skills/refactor

Installed? Explore more Programación y desarrollo skills: steipete/bluebubbles, steipete/eightctl, steipete/blucli · View all 6 →

Preguntar en tu IA favorita

Abre un nuevo chat con esta habilidad de agente ya precargada.

Documentación

Refactor — un experimento estructural

Refactor cambia la estructura mientras preserva el comportamiento observable. Realiza una transformación seleccionada por el solicitante e informa el resultado.

Indicación

extrae el cálculo de backoff exponencial de RetryRequest en su propia función, sin otro cambio de comportamiento. Registra una línea base, ejecuta go test ./internal/retry/... antes y después, e informa el resumen del diff, comandos, resultados y cualquier cosa no verificada.

Funciona si

  • El informe nombra el comportamiento preservado y cita go test ./internal/retry/... ejecutado tanto antes como después.
  • git diff --stat toca solo internal/retry/backoff.go, nunca un archivo no relacionado.
  • Los hashes de salida golden se capturan y comparan byte a byte siempre que la superficie modificada genere alguna salida, por ejemplo, sha256sum antes y después.
  • La lista de comportamiento no verificado del informe está presente en la salida incluso cuando está vacía, nombrando cualquier superficie que las compuertas hayan omitido.

Procedimiento

  1. Nombra el comportamiento preservado, la superficie de aceptación enfocada y el problema estructural concreto para sus invocantes. Reutiliza los términos del dominio del invocante y los ejemplos de comportamiento aceptados; preserva su significado a través del cambio.
  2. Registra una línea base honesta, incluyendo cualquier fallo ambiental reproducible. Para una evaluación que compare el comportamiento ejecutable, fija el código fuente inicial y construye su línea base antes de las ediciones; conserva ese binario y las entradas de comparación. Compara el candidato usando esas entradas y las mismas herramientas. Esto no añade ningún ritual de comparación ejecutable a la refactorización ordinaria.
  3. Aplica una transformación acotada: extrae, renombra, inlinea, simplifica, encapsula, mueve o elimina código muerto. Juzga el resultado por lo que los invocantes deben entender y dónde debe cambiarse una regla del dominio, no solo por el tamaño del archivo.
  4. Ejecuta la comprobación enfocada y la comprobación de regresión a nivel de paquete más pequeña justificada por la superficie modificada.
  5. Devuelve el resumen del diff, los comandos, los resultados y el comportamiento no verificado.

No combines una corrección de comportamiento recién descubierta con el cambio estructural. Un resultado rojo es evidencia para el solicitante; esta skill no revierte, acota, reintenta, confirma, valida ni enruta trabajo posterior automáticamente.

Responsabilidad y costo de la interfaz

Antes de añadir una interfaz o dividir un módulo, inspecciona invocantes representativos. Cuenta los conceptos que deben coordinar: configuración requerida, ordenamiento, estados, manejo de errores y reglas de dominio repetidas. Un límite útil pone una regla cohesiva bajo un solo responsable y permite a los invocantes solicitar un resultado sin reproducir esa regla. Rechaza un envoltorio que solo añada otro nombre o empuje la misma coordinación a sus invocantes. Los límites existentes son suficientes cuando ningún problema concreto del invocante justifica cambiarlos.

Usa el vocabulario del invocante para las operaciones y tipos extraídos. Una ambigüedad de nombre que cambie el comportamiento pertenece a la definición de dominio existente; consulta Domain solo cuando esa distinción necesite trabajo. Renombrar un símbolo público, un campo persistido o un valor de protocolo es un cambio de compatibilidad a menos que el alcance aceptado lo prevea.

Cuando la transformación necesite una costura (un límite de extracción, interfaz o división de módulo) y exista más de una costura candidata, sondea antes de cortar. Ejecuta la sonda en aislamiento desechable (una rama temporal, un worktree o un árbol copiado que la política del solicitante permita): bosqueja la costura, observa qué fuerza (caos de firmas, ciclos de importación, reescrituras de pruebas), luego descarta la sonda y conserva solo el conocimiento. Condición de parada: como máximo dos sondas; si la segunda costura candidata también se resiste, informa ambos hallazgos al solicitante en lugar de intentar una tercera. Cortar la primera costura imaginable directamente en el árbol de trabajo es el modo de fallo de costura prematura: el límite incorrecto se calcifica porque revertirlo ahora cuesta más que convivir con él.

Compuertas de neutralidad

"Preservar el comportamiento" es una afirmación que ejecutar, no una aserción. Cierra la transformación con prueba de comportamiento idéntico:

  • La comprobación enfocada y la comprobación de regresión a nivel de paquete pasan tanto antes como después, con el mismo conjunto de fallos preexistentes — ningún nuevo rojo, y ningún rojo que haya desaparecido silenciosamente (una prueba que deja de ejecutarse es un cambio de comportamiento).
  • Para superficies que producen salida (generadores, serializadores, formateadores, informes), hashea las salidas: captura hashes golden sobre entradas idénticas antes del cambio y compara byte a byte después. Una discrepancia de hash es una diferencia de comportamiento que hay que sacar a la luz y explicar, nunca ignorar; el solicitante decide si mantener, acotar o revertir el cambio.
  • Los mensajes de error observables, códigos de salida y firmas públicas en la superficie modificada son parte del comportamiento a menos que el solicitante los haya excluido.

Una compuerta de neutralidad que se omitió o acotó después del hecho es el modo de fallo de neutralidad post-hoc: el diff decide qué se probó. Nombra cualquier superficie que las compuertas no cubrieron en la lista de comportamiento-no-verificado del informe.

Referencias

Individual skills in this repo

This repo contains 9 individual skills — each has its own dedicated page.

Skills relacionados