wesammustafa/Claude-Code-Everything-You-Need-to-Know

Revisión de CLAUDE.md

Auditar un CLAUDE.md contra los modos de fallo que realmente afectan la calidad de salida.

Premisa: CLAUDE.md se carga en el contexto en cada sesión, por lo que cada línea o bien paga su alquiler o te cuesta tokens en cada turno para siempre. La mayoría de los problemas de "el modelo no sigue las instrucciones" son problemas de instrucciones.

Pasos

1. Leer el archivo objetivo (por defecto ./CLAUDE.md; también verificar ~/.claude/CLAUDE.md y cualquier **/CLAUDE.md anidado si el proyecto los tiene, ya que el más cercano tiene prioridad).
2. Puntuar cada dimensión a continuación y citar las líneas específicas que fallan.
3. Generar el informe en el formato que aparece al final. Proponer reescrituras concretas, no "considera ser más específico".

Qué verificar

Especificidad — la dimensión de mayor impacto.

• Señalar directivas no falsables: "escribe código limpio", "sigue las mejores prácticas", "ten cuidado", "usa nombres adecuados".
• Cada regla debe poder verificarse leyendo un diff. "Refactorizar funciones de más de 40 líneas" es verificable; "mantén las funciones cortas" no lo es.

Anclajes nombrados.

• Las reglas que hacen referencia a "la configuración", "nuestra capa de API" o "el patrón habitual" obligan a redescubrir en cada sesión. Reemplazar con rutas reales: src/config/env.ts, src/api/client.ts.
• Verificar que cada ruta, comando y nombre de archivo mencionado aún exista. Reportar los que estén obsoletos: un CLAUDE.md que apunte a un archivo eliminado desorienta activamente.

Actualidad.

• Números de versión, nombres de modelos y comandos de herramientas que ya no coinciden con el repositorio.
• Instrucciones para un framework, script o directorio que haya sido eliminado.
• Verificar comandos de compilación/test/lint contra package.json, Makefile, pyproject.toml o equivalente: un comando de prueba incorrecto es peor que ninguno.

Inflado y alquiler.

• Cualquier cosa que se pueda derivar del código mismo (listados de árbol de archivos, listas de dependencias, repetir lo que hace una función). Claude puede leer el repositorio.
• Procedimientos largos que solo aplican a una tarea ocasional: esos pertenecen a una habilidad, cuyo cuerpo se carga solo cuando se usa, en lugar de estar en contexto en cada turno.
• Consejos genéricos que aplican a todo software en todos lados y por lo tanto no enseñan nada sobre este proyecto.

Conflictos.

• Reglas que se contradicen entre sí, o que contradicen lo que realmente hace el código. Señalar ambos lados y preguntar cuál gana.
• Sorpresas de prioridad: un CLAUDE.md anidado o ~/.claude/CLAUDE.md que anula lo que el autor espera.

Lo que falta. Las brechas que vale la pena señalar, si están ausentes:

• Cómo ejecutar pruebas, compilar y hacer lint — las tres cosas necesarias para autoverificar un cambio.
• Restricciones no obvias del proyecto (un directorio que no debe tocarse, un archivo generado, un paso de migración requerido).
• Convenciones que son genuinamente sorprendentes y no visibles con una lectura rápida del código.

Formato de salida

## Revisión de CLAUDE.md — <ruta> (<N> líneas)

**Veredicto:** <una oración>

### Bloqueante
- L<n>: <línea citada> → <reescritura concreta>

### Vale la pena arreglar
- L<n>: <línea citada> → <reescritura concreta>

### Eliminar (cuesta contexto en cada sesión, no aporta nada)
- L<n>–<m>: <qué y por qué>

### Faltante
- <brecha> → <línea sugerida para agregar>

**Tamaño estimado después de ediciones:** <N> líneas (desde <M>)

Reglas

• Citar números de línea reales y texto real. Nunca inventar un hallazgo para llenar una sección.
• Si una sección no tiene hallazgos, escribir Ninguno. — un archivo limpio es un resultado válido.
• Preferir eliminar en lugar de reescribir. El mejor CLAUDE.md es lo suficientemente corto como para que la gente realmente lo lea.
• No editar el archivo a menos que se solicite. Primero informar.