Durante el primer mes, usé Claude Code en su estado sin configurar. Escribía instrucciones, presionaba Enter, leía el código de salida y lo corregía. Creía que eso era suficiente. Pero en realidad, era como manejar en una autopista con una licencia solo para autos automáticos recién obtenida: ni siquiera estaba aprovechando la mitad de su rendimiento. Hubo un momento en el que cambiar solo siete configuraciones hizo que el comportamiento ante la misma pregunta se sintiera como algo completamente distinto.
Mucho gusto, soy Hermes. Soy un profesional que usa IA todos los días en el trabajo, especialmente Claude Code. Al leer este artículo, podrás llevarte esas siete configuraciones en un formato que puedes probar de inmediato con valores de configuración reales.
Este contenido es una vista previa gratuita de parte de mi publicación de pago «Claude Code Complete Guide». Dejaré un enlace al final para los interesados.
Por qué el uso "sin configurar" solo da la mitad del rendimiento
Si no configuras nada, Claude Code inicia cada conversación desde un estado en el que no sabe nada del proyecto. No conoce la estructura de directorios, las convenciones de código ni qué verificar antes de hacer commit. Así que, aunque hagas la misma pregunta, un día puede adivinar el comando correcto y otro día puede crear un archivo en el lugar equivocado.
Esto no es un defecto; es así por diseño. La documentación oficial lo dice claramente: «cada sesión comienza desde una pizarra limpia». En otras palabras, la responsabilidad de sacarle rendimiento recae en el usuario. Las siguientes siete son configuraciones específicas para llenar esa «pizarra limpia».
Las 7 configuraciones, con demostraciones
1. CLAUDE.md — Memoria del proyecto
Colocar un archivo llamado CLAUDE.md en la raíz del proyecto hace que Claude Code lo lea al inicio de cada sesión. Sin esto, Claude tiene que adivinar desde cero cada vez.
El contenido debe escribirse con la mentalidad de «escribo esto para no tener que corregir el mismo error otra vez». Escribe detalles concretos que se puedan verificar, no filosofías abstractas.
Resumen del proyecto: API de gestión de inventario (Node.js + PostgreSQL) Ejecuta las pruebas con npm test / Siempre ejecuta npm run lint antes de hacer commit Los manejadores de la API se encuentran en src/api/handlers/
En lugar de «mantén el código limpio», di «indentación de 2 espacios». En lugar de «haz las pruebas bien», di «ejecuta npm test». Solo esta diferencia cambia significativamente la tasa de cumplimiento de Claude. Dado que se dice que la efectividad baja si el archivo supera las 200 líneas, el truco está en mover los procedimientos detallados a la Configuración 7 (Skills), que veremos más adelante.
2. hooks — Hacer cumplir las decisiones con la máquina
CLAUDE.md es una «solicitud», no un «requisito». Este es un malentendido común; es normal que Claude se salte instrucciones por accidente. Las reglas que quieres que se cumplan sí o sí deben bloquearse mecánicamente con un mecanismo llamado hooks.
Escribe una configuración como esta en .claude/settings.json:
Especifica hooks.PreToolUse con el matcher: "Bash" El comando a ejecutar es ~/.claude/hooks/check-test.sh
Aquí tienes una demostración. Antes de agregar esta configuración, me pasaba seguido esto: le pedía a Claude que «corrigiera un bug», y este hacía commit inmediatamente después de corregirlo sin ejecutar las pruebas, y solo después me daba cuenta de que las pruebas estaban rotas.
Al configurar un hook en el evento PreToolUse, un script intercepta justo antes de que Claude ejecute un comando. Si ese script devuelve «código de salida 2», la operación se bloquea.
El contenido del script solo ejecuta npm test si detecta un git commit Si las pruebas fallan, muestra "Las pruebas no pasaron" y devuelve el código de salida 2 El código de salida 2 es la señal para que el hook bloquee la llamada a la herramienta
Desde el momento en que agregué esta pieza, hacer commit con las pruebas en rojo se volvió físicamente imposible. La fortaleza de los hooks es que puedes confirmar el paso de «solicitud» a «exigencia» ejecutando comandos reales.
3. Subagentes — No contamines la conversación principal con investigación
Si le haces leer archivos de registro grandes o explorar todo el código fuente, esa información se acumula en el contexto de la conversación. Cuando el contexto se contamina, la precisión para seguir las instrucciones de la segunda mitad baja.
Para evitarlo, usa subagentes para delegar la investigación y la verificación en una ventana de contexto separada, devolviendo solo el resumen al flujo principal. Por ejemplo, si le pides «investiga la implementación de autenticación en este repositorio y dime los puntos clave», el proceso de exploración (leer muchos archivos y registros) se maneja en una ventana separada, y solo la conclusión regresa a la conversación principal.
✗ Seguir dejando que lea archivos de registro grandes directamente en la conversación principal
◯ Delegar con «que otro agente investigue esto y solo traiga el resumen»
Las tareas que implican «leer mucho solo para obtener información», como resultados de pruebas o recuperación de documentos, valen especialmente la pena delegarlas en subagentes.
4. Modo Plan — Haz que escriba un plan antes de mover las manos
Cuando le pides cambios complejos, Claude puede empezar de repente a escribir código en la dirección equivocada, obligándote a rehacer todo después. El Modo Plan es un modo en el que solo investiga y planifica sin hacer ninguna edición.
Puedes cambiar a este modo con Shift+Tab. En el Modo Plan, Claude lee archivos y ejecuta comandos de investigación, pero no edita el código fuente. Cuando el plan está listo, se te presenta, y solo entonces decides si lo apruebas.
Si te es tedioso decir «propón primero» cada vez, puedes establecer este modo como predeterminado en la configuración del proyecto.
Especifica permissions.defaultMode en settings.json como "plan"
Cuanto más complejo es el cambio, mayor es el retrabajo si el primer paso sale mal. El Modo Plan es un seguro contra ese retrabajo.
5. Modos de permiso — Diseña dónde detenerte
Claude Code tiene varios modos que piden confirmación cada vez que edita un archivo o ejecuta un comando, y modos que avanzan automáticamente hasta cierto punto. Por defecto, pide confirmación para todo excepto para leer.
En el trabajo diario de implementación, un equilibrio donde las ediciones de archivos avanzan automáticamente mientras que el resto requiere confirmación es fácil de manejar. Puedes hacer que ese equilibrio sea el predeterminado escribiendo esto en el archivo de configuración:
Especifica permissions.defaultMode en settings.json como "acceptEdits"
✗ Usar un modo que desactiva todas las comprobaciones solo porque «la confirmación es tediosa»
◯ Automatizar solo las ediciones de archivos y mantener la confirmación para operaciones destructivas (como force pushes o despliegues equivalentes a producción)
En mi experiencia, quienes configuran esto en «todo automático» sin cuidado son los que después se sorprenden con cambios inesperados. Puedes ir aflojando la configuración gradualmente una vez que te acostumbres a dónde quieres que se detenga.
6. Gestión del contexto — Limpia la habitación con frecuencia
Si mantienes una sola conversación de forma indefinida, el historial irrelevante permanece en el contexto, desperdiciando tokens y reduciendo la precisión de las respuestas.
Escribe /clear para borrar la conversación por completo cuando pases a una tarea no relacionada. Con eso basta. Para las conversaciones a las que quieras volver después, usa /rename para ponerles un nombre antes de borrarlas, así podrás recuperarlas sin perderte.
✗ Reutilizar la misma conversación de la mañana a la noche, con los temas no relacionados de ayer todavía rondando
◯ Usar /clear en los límites entre tareas, y /rename primero si es necesario
Si la Configuración 3 (Subagentes) es para «aislar la investigación dentro de una sola tarea», esta Configuración 6 es para «aislar entre tareas». Hacer ambas cosas es la única forma de mantener el contexto realmente limpio.
7. Skills — Mantén los procedimientos fuera de la conversación
Si sigues agregando procedimientos a CLAUDE.md, el archivo se infla, lo que aumenta la cantidad de contenido que se lee al inicio de cada sesión. Además, los procedimientos que no usas normalmente se seguirán leyendo incluso durante tareas no relacionadas.
Ahí es donde entran las Skills. Si colocas un archivo SKILL.md en .claude/skills/, solo se leerá cuando sea necesario. Si CLAUDE.md es la «memoria que se debe leer cada vez», una Skill es un «manual que solo se abre cuando se necesita».
Por ejemplo, si tienes procedimientos largos que no usas con frecuencia, como pasos de revisión de PR o pasos de migración de base de datos, muévelos de CLAUDE.md a las Skills. Las conversaciones diarias se mantienen ligeras, y solo pagas el peso cuando es necesario.
Resumen — ¿Qué pasa sin estas 7?
Estos son los puntos clave.
Sin CLAUDE.md, Claude adivina desde cero cada vez. Sin hooks, las reglas decididas siguen siendo solo «solicitudes» y pueden incumplirse. Sin subagentes y /clear, el contexto se contamina y la precisión baja. Sin el Modo Plan, cargas con el riesgo de retrabajo en cambios complejos. Si configuras los modos de permiso sin cuidado, pierdes el punto donde detener operaciones inesperadas. Sin Skills, CLAUDE.md se vuelve cada vez más pesado.
A la inversa, esta es también la historia de «salir perdiendo si no configuras estas 7». Si estás leyendo esto y ni siquiera has creado un CLAUDE.md ni usado /clear una vez, ese es tu margen de mejora.
No tienes que hacer todo de una vez. Empieza probando solo CLAUDE.md y el Modo Plan en el trabajo de hoy. Incluso eso te hará sentir de inmediato la diferencia con respecto al estado sin configurar.
He recopilado de forma sistemática configuraciones más profundas y errores comunes en la práctica en mi publicación de pago «Claude Code Complete Guide». Si te quedó la curiosidad sobre qué sigue después de estas 7, entra aquí.
