Configurar Claude para consistencia es posible desde 2026 usando una jerarquía de archivos específicos: CLAUDE.md define el contexto permanente del proyecto, settings.json controla permisos y hooks automáticos, y los Skills actúan como fuente única de verdad para patrones de código. Con esta estructura, no repetís las mismas instrucciones en cada sesión.
En 30 segundos
- CLAUDE.md es el archivo central de configuración que Claude lee automáticamente al iniciar cada conversación en un proyecto
- Settings.json define permisos, hooks y variables de entorno para evitar aprobar las mismas acciones repetidas veces
- Skills son la fuente única de verdad para patrones de código; no duplicarlos en CLAUDE.md ni en commands
- La jerarquía de configuración es: global → usuario → proyecto. Lo más específico gana
- El comando /init genera un CLAUDE.md inicial analizando el repositorio actual
Claude es un modelo de lenguaje grande desarrollado por Anthropic, diseñado para realizar tareas de escritura, análisis, programación y razonamiento. Fue presentado en marzo de 2023 y ha sido actualizado con múltiples versiones desde entonces.
El problema de la inconsistencia en Claude
Ponele que arrancás una sesión nueva con Claude Code y tenés que volver a explicarle que tu proyecto usa TypeScript estricto, que las funciones van con arrow functions, que los tests usan Vitest y no Jest, y que tenés una convención de nombres para los stores de Zustand. Media hora después, abrís otra terminal, otra sesión, y a repetir todo de cero.
Ese es el problema que más afecta a equipos que trabajan con Claude a diario. No es falta de capacidad del modelo, es falta de configuración persistente. Y lo peor es que cuando la gente intenta resolverlo, cae en otro error igual de frustrante: duplicar las mismas reglas en CLAUDE.md, en los commands, en los agents y en los skills al mismo tiempo. El resultado es contradictorio: las instrucciones se pisan entre sí y Claude empieza a hacer cosas raras.
Claude Code es una herramienta CLI de Anthropic que permite a los desarrolladores interactuar con Claude directamente desde la terminal para tareas de programación, con soporte para contexto persistente por proyecto a través de archivos de configuración en el directorio .claude/.
CLAUDE.md: la base para configurar Claude para consistencia
CLAUDE.md es el archivo que Claude lee al inicio de cada conversación, automáticamente, sin que tengas que pedirlo. Funciona como el brief permanente del proyecto. Todo lo que Claude necesita saber para comportarse bien en ese contexto específico va ahí.
¿Qué debería contener? Stack tecnológico concreto, convenciones de código, patrones preferidos, bugs conocidos del proyecto, restricciones del entorno. No filosofía general de programación: eso ya lo sabe. Lo que necesita son las particularidades tuyas. Ya lo cubrimos antes en nueva versión de Sonnet.
Un ejemplo práctico con una arquitectura real:
- Stack: Next.js 15, TypeScript 5.4 estricto, Tailwind 4, Zustand para state, Vitest para tests
- Convenciones: arrow functions siempre, no usar
any, imports absolutos desde@/ - Patrones preferidos: server components por defecto, client components solo si es necesario, suspense boundaries explícitos
- Bugs conocidos: el endpoint
/api/userstiene un problema de caché que se resuelve con revalidateTag, no con revalidatePath
Para generarlo, la documentación oficial de Claude Code recomienda usar el comando /init directamente en el proyecto. Claude analiza el repositorio y genera un CLAUDE.md inicial que después podés editar. No es mágico (a veces omite cosas o incluye obviedades), pero es un buen punto de partida.
Eso sí: mantené CLAUDE.md liviano. No copies ahí los patrones de código completos. Para eso están los Skills.
Settings: control declarativo sin aprobar lo mismo dos veces
¿Cuántas veces aprobaste que Claude ejecute npm test o que lea archivos de configuración? Si usás Claude Code con cualquier nivel de frecuencia, la respuesta es “demasiadas”.
Settings.json resuelve eso. Es el archivo donde definís permisos permanentes, variables de entorno disponibles para Claude, y hooks que se ejecutan automáticamente antes o después de ciertas acciones.
La jerarquía de configuración funciona en cascada: configuración global (aplica a todos tus proyectos) → configuración de usuario → configuración de proyecto (solo aplica en ese directorio). Cuando hay conflicto, lo más específico gana. Esto es útil porque podés tener permisos amplios globalmente y restricciones más finas por proyecto.
Un ejemplo de settings.json para un proyecto típico:
- Permisos automáticos: leer archivos del proyecto, ejecutar scripts de test, correr el linter
- Hooks pre-commit: ejecutar typecheck y lint antes de que Claude haga un commit
- Variables de entorno: referencias a .env sin exponer los valores directamente
Según la guía de Builder.io sobre configuración de Claude Code, los hooks son el feature más subutilizado: la mayoría de los equipos los ignora y después se quejan de que Claude “hace cosas sin preguntar” o “no hace lo que se le dijo”. La mitad de esos problemas se resuelven con dos líneas en settings.json.
Skills vs Styles vs Commands: qué va dónde
Acá viene lo bueno, y también donde más se confunde la gente.
Las tres herramientas sirven para cosas distintas. Mezclarlas genera duplicación y resultados inconsistentes:
| Componente | Para qué sirve | Ejemplo concreto | Dónde NO va |
|---|---|---|---|
| Skills | Fuente única de verdad para patrones de código | “Siempre que crees un componente React, seguí este patrón de composición con tipos explícitos” | No en CLAUDE.md, no en Commands |
| Styles | Parámetros de tono, extensión y audiencia de las respuestas | “Respuestas técnicas, sin explicar lo obvio, audiencia senior” | No en Skills, no confundir con reglas de código |
| Commands | Prompts reutilizables para tareas concretas | “/review: revisá este PR buscando problemas de seguridad y performance” | No para patrones de código que deberían estar en Skills |
El error más común es copiar un patrón de código en CLAUDE.md Y en un Skill Y en un Command “por las dudas”. Cuando el patrón cambia, actualizás uno y olvidás los otros dos. Claude empieza a recibir instrucciones contradictorias. El resultado es exactamente la inconsistencia que estabas tratando de evitar. Tema relacionado: comparar con otras herramientas.
La regla es simple: un patrón de código, un solo lugar. Si está en un Skill, no está en ningún otro lado.
Modelos y rutas de costo: elegir bien desde el día uno
No todo tiene que correr en Opus 4.7. Esta es una de las decisiones de configuración con mayor impacto en el presupuesto mensual.
La lógica es esta: usá el modelo más potente solo donde realmente lo necesitás. Para el resto, Sonnet 4.6 o Haiku 4.5 hacen el trabajo a una fracción del costo. Según guías de producción publicadas en 2026, equipos que configuran el routing por tarea desde el inicio reportan reducciones de entre 40% y 60% en costos de API versus usar un solo modelo para todo.
- Opus 4.7: decisiones complejas, análisis de arquitectura, code review profundo, razonamiento multi-step
- Sonnet 4.6: escritura de código, ediciones, refactors, generación de tests
- Haiku 4.5: tareas rápidas, clasificación, metadatos, linking, resúmenes cortos
El caching de prompts del sistema también es algo que mucha gente ignora. Si tenés un system prompt largo que se repite en cada llamada (un CLAUDE.md extenso, por ejemplo), el prompt caching puede reducir ese costo significativamente. La documentación de la API de Anthropic describe cómo configurarlo a nivel de llamada.
Para tareas offline, el Batch API procesa requests con descuento y sin necesidad de respuesta en tiempo real. Auditorías nocturnas de código, análisis de logs, generación masiva de tests: todo eso corre más barato en batch.
Estructura de carpetas .claude: dónde va cada archivo
El directorio .claude/ tiene una estructura específica que conviene entender antes de empezar a crear archivos al azar:
~/.claude/settings.json: configuración global del usuario (aplica a todos los proyectos)~/.claude/keybindings.json: atajos de teclado personalizados.claude/settings.json(en el proyecto): configuración específica del proyecto, sobreescribe la global.claude/commands/: commands reutilizables para ese proyectoCLAUDE.md(en la raíz del proyecto): el brief permanente
La cascada de prioridad es predecible: proyecto gana sobre usuario, usuario gana sobre global. Si configurás un permiso en la configuración global y lo desactivás en el proyecto, prevalece el proyecto. En problemas en versiones recientes profundizamos sobre esto.
Un detalle que no está documentado de forma obvia: .claude/settings.json es diferente de ~/.claude/settings.json. El primero es de proyecto (y debería estar en el repositorio para que todo el equipo lo comparta). El segundo es personal y no debería commitearse.
Errores comunes al configurar Claude
Duplicar instrucciones en múltiples componentes
Ya lo mencionamos, pero vale repetirlo porque es el error número uno. Copiar la misma regla en CLAUDE.md, en un Skill y en un Command no la “refuerza”: genera conflictos cuando alguna versión queda desactualizada. Definí cada cosa en un solo lugar.
CLAUDE.md como dumping ground
Meter todo en CLAUDE.md porque “ahí Claude lo lee seguro” termina en un archivo de 500 líneas que Claude procesa completo en cada sesión (costo de tokens) y que es imposible de mantener. CLAUDE.md para contexto del proyecto. Patrones de código en Skills. Preferencias de respuesta en Styles.
No configurar presupuestos por tarea
Muchos equipos configuran Claude sin definir límites de costo por tipo de tarea. Después se sorprenden con la factura de fin de mes. Desde el día uno, definí qué modelo usa cada tipo de tarea y habilitá alertas de uso. Un refactor de archivo que debería costar USD 0.02 en Haiku no debería estar corriendo en Opus 4.7.
Ignorar la migración entre versiones de modelo
¿Alguien verificó el comportamiento de sus prompts al pasar de Sonnet 4.5 a 4.6? Los cambios de versión pueden alterar outputs de formas sutiles, especialmente en prompts con formato estructurado o instrucciones de tono específicas. Migrá una tarea a la vez, no todo el sistema de golpe.
Checklist: auditá tu setup actual
Si ya tenés Claude Code configurado, estos son los pasos concretos para verificar que tu setup está bien armado: Para más detalles técnicos, mirá configuración de Claude Code.
- ¿Existe CLAUDE.md en la raíz del proyecto? Si no existe, corré /init y editá el resultado. Si existe, verificá que no contenga patrones de código que deberían estar en Skills.
- ¿Qué hay en settings.json? Revisá si hay permisos que aprobás manualmente todo el tiempo. Si sí, convertílos en permisos permanentes. Si settings.json no existe, el comportamiento es el default global.
- ¿Los Skills son la fuente única de verdad? Buscá cualquier patrón de código que esté duplicado en CLAUDE.md o Commands. Eliminalo de ahí, que viva solo en el Skill.
- ¿Tenés routing de modelos configurado? Si todo corre en el mismo modelo, revisá las tareas más frecuentes y evaluá si algunas podrían ir a Haiku o Sonnet.
- ¿Usás hooks automáticos? Si aprobás las mismas acciones varias veces por sesión, configuralas en settings.json.
Qué significa esto para equipos en Latinoamérica
El costo de Claude API en USD impacta más en equipos de la región, donde los presupuestos de infraestructura son más ajustados. Un routing de modelos bien configurado desde el inicio puede hacer la diferencia entre un proyecto que cierra los números y uno que no.
Si tu equipo está evaluando adoptar Claude Code para desarrollo, la recomendación concreta es: antes de escalar el uso, invertí media jornada en armar el CLAUDE.md, definir el routing de modelos y configurar los Skills como fuente única de verdad. El ROI de esa media jornada se ve en la primera semana.
Para los proyectos que ya tienen infraestructura web propia, es relevante mencionar que plataformas como donweb.com ofrecen VPS y cloud donde podés alojar los endpoints de tus integraciones con la API de Claude sin depender de servicios externos.
Lo cubrimos en profundidad acá: How I made my Claude setup more consistent.
Para profundizar, mirá How I made my Claude setup more consistent, donde tratamos el tema con más detalle.
Preguntas Frecuentes
¿Qué es CLAUDE.md y para qué sirve?
CLAUDE.md es un archivo de texto ubicado en la raíz de un proyecto que Claude Code lee automáticamente al iniciar cada sesión. Contiene el contexto permanente del proyecto: stack tecnológico, convenciones de código, patrones preferidos y restricciones específicas. No es necesario repetir estas instrucciones manualmente en cada conversación.
¿Cómo evitar repetir las mismas instrucciones en cada conversación con Claude?
La solución es crear un CLAUDE.md en la raíz del proyecto con las instrucciones permanentes, y configurar settings.json con los permisos recurrentes como permisos permanentes. Claude lee ambos archivos automáticamente al inicio de cada sesión. El comando /init genera un CLAUDE.md inicial analizando el repositorio.
¿Cuál es el orden de prioridad en la configuración de Claude Code?
La jerarquía es: configuración de proyecto (.claude/settings.json en el directorio del proyecto) > configuración de usuario (~/.claude/settings.json) > configuración global. Cuando hay conflicto entre configuraciones, la más específica prevalece. CLAUDE.md del proyecto también tiene prioridad sobre instrucciones genéricas.
¿Cuál es la diferencia entre Skills, Styles y Commands en Claude?
Skills son la fuente única de verdad para patrones de código, Styles controlan el tono y extensión de las respuestas (audiencia, nivel técnico), y Commands son prompts reutilizables para tareas concretas. El error más común es duplicar patrones de código en los tres componentes simultáneamente, lo que genera instrucciones contradictorias.
¿Cuándo usar Opus 4.7 vs Sonnet 4.6 vs Haiku 4.5?
Opus 4.7 conviene para decisiones complejas, arquitectura y code review profundo. Sonnet 4.6 cubre la mayoría del trabajo de desarrollo: escritura de código, refactors, tests. Haiku 4.5 es suficiente para tareas rápidas como clasificación, metadatos y resúmenes. Equipos con routing por tarea reportan reducciones de 40-60% en costos versus usar un solo modelo para todo.
Conclusión
La inconsistencia en Claude no es un problema del modelo. Es un problema de configuración. CLAUDE.md, settings.json y Skills son tres herramientas distintas con responsabilidades distintas; usarlas bien es lo que separa un setup que funciona de uno que obliga a repetir las mismas instrucciones en cada sesión.
El cambio más importante que podés hacer hoy es definir una fuente única de verdad para cada tipo de instrucción y eliminar las duplicaciones. Si hacés eso, la consistencia llega sola. Si seguís copiando reglas en todos lados “por las dudas”, el modelo va a seguir comportándose de forma impredecible, y la culpa no es de Claude.