La carpeta .claude que nadie revisa (y que lo cambia todo)

La carpeta .claude es el cerebro invisible de Claude Code. La mayoría de la gente nunca la abre.

Lo que el 90% de los usuarios no sabe

Cuando lanzas Claude Code por primera vez, crea silenciosamente una carpeta .claude en el directorio de tu proyecto. Y otra en tu home directory. La mayoría de los desarrolladores nunca tocan esos archivos.

Es un error. Esa carpeta es la interfaz de configuración más potente de Claude Code. No un archivo CLAUDE.md vagamente documentado, no solo permisos. Todo el sistema de personalización.

La carpeta .claude es la diferencia entre usar Claude Code al 10% y ponerlo a trabajar de verdad para ti.

Las dos carpetas .claude: proyecto vs personal

Lo primero que hay que entender: existen dos carpetas .claude distintas, con roles muy diferentes.

La carpeta .claude dentro de tu proyecto contiene las reglas, comandos, skills y agentes específicos de ese proyecto. Es lo que compartes con tu equipo vía Git. Todo el mundo trabaja con las mismas reglas, los mismos comandos slash, los mismos skills.

La carpeta ~/.claude en tu home directory es tu playbook personal. Tus preferencias, tus atajos y, sobre todo, todo el historial de tus sesiones. Cada conversación de Claude Code queda almacenada en un archivo JSON en algún lugar de esa carpeta. Si buscas una sesión de hace tres semanas, es ahí donde está.

Para ver qué contiene cada una, un comando bash rápido dentro de Claude Code:

!ls .claude/
!ls ~/.claude/

CLAUDE.md: piensa en enrutador, no en enciclopedia

Es el error más frecuente: convertir CLAUDE.md en un bloque de 300 líneas que documenta absolutamente todo. Arquitectura, convenciones de código, estilo de emails, formato de informes financieros, todo en un solo archivo.

El problema: Claude lee ese archivo completo en cada sesión. Cuanto más largo, más contexto consumes para nada.

El enfoque correcto: CLAUDE.md como enrutador. 50 líneas máximo. El archivo le dice a Claude dónde buscar para cada tipo de tarea:

# Para redacción de emails: ver .claude/rules/email-drafting.md
# Para informes financieros: ver .claude/rules/financial-reports.md
# Para el estilo de briefs: ver .claude/rules/brief-writing.md

Claude solo carga las reglas específicas cuando son pertinentes. Resultado: contexto preservado, instrucciones más precisas, menos deriva entre sesiones.

Es la misma lógica que para AutoDream y la memoria persistente entre sesiones: cargar solo lo necesario en el momento justo.

Las reglas: compartimenta cada flujo de trabajo

La carpeta .claude/rules/ es el rincón menos conocido y más útil de todo el ecosistema Claude Code.

Cada archivo Markdown en esa carpeta es una regla dedicada a un tipo de tarea. Email, brief, informe, code review, formato de commit, redacción de documentación... tantos archivos separados como necesites.

Por qué es tan potente: esas reglas son iterativas. Cada vez que Claude hace algo que no coincide con lo que querías, abres el archivo de regla correspondiente y añades una línea. La regla mejora con el uso.

Mis mejores reglas son 6 meses de iteraciones condensados en 30 líneas. Ningún prompt puede reproducir eso.

Para inspeccionar una regla rápidamente sin salir de Claude Code:

!head -15 .claude/rules/email-drafting.md

Comandos slash: transforma cualquier flujo de trabajo en un atajo

La regla es simple: si un archivo Markdown existe en .claude/commands/, se convierte en un comando slash invocable al instante. El archivo se llama process-meeting.md: tienes /process-meeting. Se llama weekly-summary.md: tienes /weekly-summary.

Lo que hace los comandos realmente flexibles es el argumento wildcard. En tu archivo de comando puedes usar $ARGUMENTS como placeholder. Eso te permite hacer:

/process-meeting latest
/process-meeting abc123-meeting-id

El comando sabe entonces si debe buscar la última reunión o una reunión específica por ID. Fireflies, Notion, Linear, da igual tu stack: los comandos slash transforman cualquier operación repetitiva en un atajo determinista.

Skills vs Comandos: ¿cuál es la diferencia concreta?

Es la confusión más frecuente entre los usuarios intermedios.

Los skills tienen trigger words en su descripción. Cuando Claude procesa un transcript y detecta las palabras "action items", el skill action-tracker se activa automáticamente. Sin que tengas que pedirlo.

Un tip de experto: si empiezas a acumular muchos skills similares, desactiva la invocación automática en los más especializados con disable-model-invocation: true en el archivo del skill. Así evitas que Claude use el skill equivocado en un caso ambiguo.

Para construir un equipo completo de agentes con skills en Claude Code, este artículo sobre el equipo de marketing IA detalla el flujo completo.

Agentes especializados: cristaliza tus sub-agentes recurrentes

Los sub-agentes son cada vez más potentes. Pero si usas las mismas configuraciones de agentes una y otra vez, es hora de cristalizarlos en .claude/agents/.

Cada archivo de agente define su nombre, su descripción, las herramientas autorizadas y, sobre todo, el modelo a utilizar. Aquí es donde se pone interesante. Para un agente que analiza transcripts de reuniones, Haiku es más que suficiente. Para un security auditor que hace análisis de vulnerabilidades, quieres Sonnet con más capacidad de razonamiento.

Yo lancé 10 sub-agentes en paralelo para explorar un codebase entero. Cada uno especializado en un módulo. Informe unificado de vuelta. Lo que a mano lleva una hora.

Un tip avanzado: puedes activar context: fork para dejar que un skill se ejecute en su propia ventana de contexto, aislada del contexto principal. Ideal para tareas pesadas que podrían contaminar tu sesión principal.

Settings.json y hooks: la red de seguridad

El archivo settings.json en .claude/ controla lo que Claude puede hacer en tu máquina. Comandos bash autorizados, archivos accesibles, herramientas activadas.

Tres niveles de permisos:

• Todo autorizado: Claude ejecuta sin preguntar (modo yolo, no recomendado para proyectos sensibles)

• Preguntar primero: Claude pide confirmación antes de ejecutar (modo por defecto)

• Nunca: ciertos comandos están bloqueados pase lo que pase

Los hooks funcionan a nivel de settings.json. Un hook pre-tool-use se ejecuta antes de cada llamada a una herramienta. Útil para proteger un archivo .env, registrar acciones o verificar una condición antes de modificar algo.

Para ver todos tus parámetros actuales:

!cat .claude/settings.json

El modelo mental completo: cómo encaja todo

Así es como todos estos elementos funcionan juntos en un ejemplo concreto: un flujo de procesamiento de reuniones con la API de Fireflies.ai.

• 1. La reunión termina. Fireflies captura el transcript automáticamente.

• 2. Lanzas /process-meeting latest en Claude Code.

• 3. Claude carga el comando process-meeting.md y llama a la API de Fireflies.

• 4. En el transcript detecta action items: el skill action-tracker se activa automáticamente.

• 5. Los action items se estructuran según las reglas en .claude/rules/action-items.md.

• 6. El skill auto-follow-up toma el relevo y redacta los emails según .claude/rules/email-drafting.md.

• 7. Todo se almacena en Supabase. Settings.json autorizó las llamadas API de red previamente.

Un solo archivo CLAUDE.md de 50 líneas orquesta todo esto. Lo único que hace es apuntar hacia las piezas correctas en el momento justo.

Por dónde empezar

Si nunca has configurado tu carpeta .claude, este es el orden de prioridad:

• Primero: un CLAUDE.md limpio, corto, orientado a enrutador (nada de enciclopedia)

• Después: una o dos reglas para las tareas que haces a menudo (email, commit messages, code review)

• Luego: un comando slash para el flujo de trabajo más recurrente de tu proyecto

• Opcional pero potente: un skill para los patrones que quieras automatizar

• Por último: settings.json para bloquear los permisos según tu nivel de confianza

Empieza simple. Itera. La carpeta .claude mejora con el uso, no con la planificación.