메뉴
Usar para refactorizar código con tests como red de seguridad. Activar cuando el usuario quiera limpiar código, reducir complejidad, extraer función, mejorar nombres, eliminar duplicación, resolver un code smell o reorganizar la estructura interna sin cambiar comportamiento.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Alias global /alfred para abrir el asistente contextual de Alfred Dev sin escribir el namespace completo. Activar solo cuando el usuario invoque explicitamente /alfred.
Protocolo de respuesta ante incidentes en produccion: triaje, mitigacion, causa raiz y postmortem. Usar ante caidas, errores criticos, incidentes de seguridad o degradacion de servicio.
Generar Dockerfile optimizado. Activar cuando el usuario quiera crear contenedor, generar imagen Docker, configurar Docker Compose, contenerizar aplicacion o crear un Dockerfile multi-stage.
Planificar y ejecutar releases: inventario de cambios, versionado semantico, changelog, notas de release y publicacion. Usar antes de cada version nueva.
Auditar accesibilidad WCAG 2.1 nivel AA con checklist y correcciones. Activar ante: accesibilidad web, WCAG, lector de pantalla, contraste, navegacion por teclado, a11y
Levantar SonarQube con Docker, analizar el código y proponer mejoras. También: análisis estático, deuda técnica, code smells, cobertura, calidad automatizada.
| name | refactor |
| description | Usar para refactorizar código con tests como red de seguridad. Activar cuando el usuario quiera limpiar código, reducir complejidad, extraer función, mejorar nombres, eliminar duplicación, resolver un code smell o reorganizar la estructura interna sin cambiar comportamiento. |
Este skill guía un proceso de refactorización seguro. La regla de oro es que la refactorización no debe cambiar el comportamiento observable del sistema, solo mejorar su estructura interna. Para reducir el riesgo de cambios involuntarios, los tests existentes actúan como red de seguridad: deben pasar antes, durante y después de la refactorización.
La refactorización y la adición de funcionalidad son dos actividades distintas que nunca se mezclan en el mismo commit. Si se detecta un bug durante la refactorización, se anota y se corrige en un commit separado.
Identificar el code smell. Antes de refactorizar, tener claro qué problema se está resolviendo. Los code smells más comunes son:
Verificar que los tests pasan ANTES de empezar. HARD-GATE: ejecutar la suite de tests completa (o al menos los tests del módulo afectado) y confirmar que todo está en verde. No se refactoriza sobre una base rota.
Si no hay tests suficientes, escribirlos primero. Si el área a refactorizar no tiene cobertura de tests, escribir tests de caracterización que capturen el comportamiento actual antes de cambiar nada. Estos tests se commitean por separado.
Aplicar la refactorización en pasos pequeños. Cada paso debe ser:
Técnicas comunes: extraer función, renombrar, mover a módulo, introducir parámetro, reemplazar condicional con polimorfismo, simplificar expresión.
Ejecutar tests después de cada paso. No acumular múltiples cambios sin verificar. Si un test se rompe, deshacer el último paso y analizar por qué.
Verificar que los tests SIGUEN pasando al final. Ejecutar la suite completa una última vez. Comparar el comportamiento observable: mismos inputs deben producir mismos outputs.
Hacer commit separado. El commit de refactorización va aparte del commit de nueva funcionalidad. Mensaje descriptivo: refactor: extraer lógica de validación a módulo independiente.
