🩺 Auditar de verdad
Hasta aquí aprendiste a clasificar línea por línea en papel. Ahora la pregunta es operativa: ¿cómo ejecutar la auditoría en tu propia configuración y convertir el informe en recortes seguros? La skill lee y diagnostica; quien aplica los cambios eres tú, en otra sesión, con la configuración bajo git.
Qué observar: la línea continua (morada) es lo que la skill hace por sí sola: leer la configuración y emitir un informe. La línea discontinua (cian) cruza una frontera: todo lo que está a la derecha es una decisión humana, tomada en otra sesión. Una auditoría que ya empieza a hacer cambios es una auditoría en la que no confías.
Mapa de la ruta
Contenido detallado
🩺 Ejecutando la skill audit-ablacao
Instalar y ejecutar la skill en tu propia configuración, y leer el informe de 10 secciones sabiendo qué te exige cada una.
La skill lee tu CLAUDE.md (de proyecto y global), tus skills, tus hooks y el settings.json, clasifica cada instrucción y propone una versión mínima. Nunca edita, mueve, elimina ni sobrescribe la configuración, ni hace commits.
Porque el límite es lo que hace confiable la auditoría. No dejas que una herramienta que empieza a hacer cambios se ejecute de forma global; y así nunca auditas nada. Si sabes que es de solo lectura, puedes ejecutarla sin miedo, incluso antes de tener git en la configuración.
Diagnóstico ≠ tratamiento. Aplicar los cambios es una solicitud aparte, a propósito. Y no lo confundas con memory-audit: aquella se ocupa de la memoria guardada de la sesión; esta, de la configuración del agente.
Hay dos destinos posibles: ~/.claude/skills/audit-ablacao/SKILL.md, que se aplica a todos los proyectos, o .claude/skills/audit-ablacao/SKILL.md dentro del repositorio, donde solo aplica. En ambos casos es un cp del SKILL.md y un reinicio de la sesión para que Claude Code lo cargue.
Elegir el destino ya es una decisión de arquitectura de config. Una skill dentro del proyecto se versiona junto con el código, entra en el PR, se puede revisar y no se filtra a los demás proyectos. Una skill global está disponible en cualquier sesión, pero ocupa un espacio en la lista de skills que ve cada proyecto.
La raíz del repositorio ya contiene el SKILL.md instalable — es el motivo por el que la guía queda en guia/ y no en la raíz. Si la skill no aparece, casi siempre hace falta reiniciar la sesión.
Tres ámbitos con activadores distintos. Global (~/.claude/): cada ~6 meses o cuando se lance un modelo importante. Un proyecto: cuando el CLAUDE.md de él supera ~150 líneas. Un conjunto de skills: cuando 3 o más compiten por el mismo desencadenante.
Un alcance demasiado amplio produce un informe que no puedes aplicar; uno demasiado pequeño oculta la redundancia, que casi siempre está entre lo global y el proyecto. Auditar todo de una vez es la forma más común de no recortar nada.
Los detonantes son señales medibles, no una sensación: número de líneas, número de skills en conflicto, lanzamiento de un modelo. Una señal objetiva es lo que evita que la auditoría se convierta en una tarea que nunca llega.
Resumen ejecutivo, métricas, problemas por archivo, candidatas a eliminación, redundancias y conflictos, skills, CLAUDE.md mínimo propuesto, skills propuestas, plan de prueba de ablación (versiones A/B/C) y Top 10 de cambios por impacto ÷ riesgo.
Cada sección te exige algo distinto. Las métricas y los problemas por archivo son información para leer; las candidatas a eliminación y los conflictos requieren tu veredicto; el CLAUDE.md el mínimo es una propuesta, no una sentencia; el Top 10 es la única sección que se convierte en un plan de trabajo inmediato.
Impacto ÷ riesgo ordena el Top 10 porque el objetivo no es reducir al máximo, sino maximizar calidad + autonomía + verificabilidad ÷ complejidad. Los recortes de alto impacto y alto riesgo se abordan después, con pruebas.
Cada skill recibe uno de siete veredictos: KEEP, SIMPLIFY, MERGE, SPLIT, LOAD-ON-DEMAND, CONVERT-TO-CONTEXT o DELETE-CANDIDATE. Es un eje separado del veredicto por línea de CLAUDE.md.
La Skill tiene límites, nombre y alcance: es fácil de auditar y de retirar, a diferencia de «aquel párrafo del medio del CLAUDE.md". Por eso la skill es la unidad adecuada para corregir: puedes desactivar una y medir el efecto.
MERGE resuelve skills que compiten por el mismo disparador; SPLIT resuelve una skill que hace demasiadas cosas; CONVERT-TO-CONTEXT es para lo que era información disfrazada de procedimiento; LOAD-ON-DEMAND elimina el costo de contexto de las ejecuciones que no lo usan.
Ejecutar /audit-ablacao en el alcance elegido, tomar las tres primeras candidatas a eliminar, abrir el archivo citado, revisar el fragmento en su contexto y emitir un veredicto propio: estoy de acuerdo, discrepo o lo envío a TEST.
Es el hábito que distingue una auditoría de la fe ciega. Revisar el fragmento en el archivo original permite detectar los dos errores más comunes del informe: citas fuera de contexto y líneas que parecen redundantes, pero guardan un detalle que solo existe ahí.
Si tienes dudas, TEST — nunca REMOVE. Y la auditoría conserva deliberadamente lo que el modelo no puede inferir: identidad del proyecto, rutas y fuentes de verdad, branding, seguridad, cumplimiento, integraciones y contratos de interfaz.
🔧 Del informe a los recortes: la skill es la unidad correcta
Convertir el Top 10 en cambios aplicados de forma segura, trasladando los procedimientos del CLAUDE.md a skills que se cargan bajo demanda.
El informe se genera en una sesión; los recortes se aplican en otra. Antes de aplicar cualquier cambio, la configuración debe estar bajo control de versiones: un commit limpio antes y un commit del recorte después, para que revertir sea un comando y no una labor de arqueología.
Aplicar los cambios en la misma sesión en la que hiciste la auditoría contamina el juicio: el modelo ya tiene todo el informe en el contexto y tiende a defender sus propias conclusiones. Una sesión nueva lee la configuración tal como está, no como decía el informe.
La reversibilidad es un requisito previo para actuar con valentía. Con git en la config, un recorte agresivo cuesta un git revert; sin git, cuesta recordar lo que estaba escrito, y nadie se acuerda.
Primero las redundancias y los conflictos: la misma regla en tres lugares, dos reglas que se contradicen. Después la microgestión y el legado anticuado. Por último, lo que quedó marcado como TEST, que solo se elimina después de medir.
La redundancia y el conflicto son los cambios con mayor impacto y menor riesgo: borrar la copia no cambia el comportamiento, porque la regla sigue existiendo en un lugar. Empezar por ahí logra una reducción real sin arriesgar nada y despeja el terreno para evaluar lo demás.
El conflicto es peor que la redundancia: con dos reglas contradictorias, el modelo elige una y tú no sabes cuál. Resolver el conflicto es una decisión tuya sobre qué regla vale, no un recorte automático.
Una regla que vive en el CLAUDE.md se lee en cada ejecución, incluso en el 90 % que no tiene nada que ver con ella. La misma regla dentro de una skill solo consume contexto cuando la tarea corresponde. Eso es exactamente el MOVE e o LOAD-ON-DEMAND del informe.
Es la forma más barata de aligerar la configuración sin perder nada: ninguna instrucción se descarta, solo cambia de lugar. Si te da miedo borrar, mover es el recorte que puedes hacer el primer día.
El criterio de partición: el CLAUDE.md se queda solo con lo que es cierto siempre — identidad, guardrails, fuentes de verdad, seguridad. Todo lo demás (procedimiento, formato, receta, integración) se convierte en skill.
Invocar mediante /nome-da-skill en vez de esperar que la descripción coincida con tu frase. Cuando varias skills compiten por el mismo tema, la invocación explícita desempata.
Esto elimina toda una categoría de líneas innecesarias: la regla de enrutamiento en el CLAUDE.md ("cuando el usuario pida X, usa la skill Y"). Si la llamas directamente, la regla de enrutamiento no hace falta — y se leía en cada ejecución.
Un activador basado en una descripción es probabilístico; la invocación explícita es determinista. Cambiar uno por otro reduce el contexto y aumenta la previsibilidad al mismo tiempo: es poco común ganar en ambos frentes.
Cuando el modelo tropieza, hay tres remedios. Mejor prompt: la instrucción no estaba clara. Skill: falta un procedimiento repetible. MCP: falta contexto al que no puede acceder por sí solo.
Elegir mal engorda el CLAUDE.md. El reflejo más común es añadir otra regla global para un problema que se debía a la falta de una herramienta o de un procedimiento; y la regla se queda ahí para siempre, leyéndose en cada ejecución.
El diagnóstico se basa en el fallo observado, no en una suposición: si el modelo no sabía algo, es contexto/MCP; si lo sabía, pero siguió un orden incorrecto, es procedimiento/skill; si entendió mal la solicitud, es prompt.
El ejercicio final de la ruta: quitar tres elementos del Top 10, aplicarlos en una sesión aparte y registrar el antes y el después con dos números: las líneas del CLAUDE.md y la cantidad de reglas: una frase más sobre el comportamiento observado.
Sin un registro, no sabes si la config se hizo más pequeña o si solo la reorganizaste. Y el criterio de éxito no es la reducción: es mantener el comportamiento con menos líneas. Si algo se rompió, puedes identificar el recorte equivocado porque solo fueron tres.
Tres a la vez es un lote pequeño a propósito: así se puede identificar la causa. Después viene el uso en trabajo real durante algunos días, que es donde la Ruta 4 aborda el tema con el plan A/B/C.