Estructura del proyecto: Qué guarda Claude Code en tu proyecto
📚 Navegación de la serie: El artículo anterior 12 Inicialización del proyecto te enseñó a usar
/init, generando el primerCLAUDE.mdpara tu proyecto. Este artículo continuará desde ahí: después del/init, ¿qué contiene exactamente la carpeta.claude/que aparece silenciosamente en tu proyecto, quién la administra y debería incluirse en git?
Todos dicen sobre esa carpeta .claude que «no te preocupes, ella misma se encarga», pero la verdad es que solo cuando la entiendes puedes decir que sabes usar Claude Code.
¿Por qué digo esto? Porque casi todas las «funciones avanzadas» de esta herramienta, comandos personalizados, control de permisos, subagentes (subagents), habilidades (skills), al guardarse en disco, son solo unos pocos archivos y directorios dentro de .claude/. Si no entiendes su estructura, te quedarás en blanco ante problemas como «por qué los permisos que configuré no funcionan» o «mis compañeros descargaron el código pero no tienen mis comandos».
Cuando empecé a usarlo cometí un error muy tonto: por conveniencia, escribí directamente una configuración que contenía una contraseña de base de datos en .claude/settings.json, y la subí junto con git push. Para cuando me di cuenta, las claves ya estaban en el historial del repositorio; al final tuve que cambiar contraseñas y reescribir el historial, perdiendo más de media hora. Luego entendí que este tipo de cosas debían ir en settings.local.json, un archivo que Claude Code añade por defecto a gitignore. Un archivo en el lugar equivocado hace toda la diferencia.
En este artículo no te enseñaré cómo configurar en profundidad cada archivo (eso lo dejamos para capítulos específicos más adelante), sino que haremos una sola cosa: darte un mapa panorámico, para que al ver un archivo sepas «qué hace, dónde va, si pertenece al proyecto o a ti, y si debe ser incluido en un commit».
Después de leer este artículo, obtendrás:
- Un mapa completo del directorio
.claude/: qué gestiona cada archivo / subdirectorio - La diferencia fundamental entre la configuración «a nivel de proyecto» y «a nivel de usuario» (acompaña al proyecto vs. te acompaña a ti)
- Una tabla de consulta rápida: qué debe incluirse en git y qué debe ir obligatoriamente en
.gitignore - Un paso a paso sencillo para ver con tus propios ojos cómo lucen estos dos niveles de directorios
01 Primero entiende algo: Claude Code tiene «dos hogares»
Primero la conclusión: La configuración de Claude Code se guarda en dos partes: una parte acompaña al proyecto, y la otra te acompaña a ti. Entendiendo esta regla, todo lo demás tiene sentido.
Analogía: El «archivador de proyectos» de la empresa y los «cajones de tu escritorio». En el archivador de proyectos (a nivel de proyecto) pones las cosas que todos los involucrados en el proyecto deben ver: las normativas del proyecto, quién puede hacer qué; cuando llega un nuevo compañero, puede empezar a trabajar solo con leer lo que hay en el archivador. Los cajones de tu escritorio (a nivel de usuario) guardan tus hábitos personales: tus atajos preferidos, tus preferencias privadas; cuando cambias de proyecto, estas cosas se van contigo.
En el disco, se traduce a dos ubicaciones:
| La parte | Dónde está | A quién afecta | A quién acompaña |
|---|---|---|---|
| Nivel de proyecto (Project) | ./.claude/ en el proyecto | Todos los colaboradores del repositorio | Acompaña al proyecto (se sube a git, compartido por el equipo) |
| Nivel de usuario (User) | ~/.claude/ en tu directorio de inicio | A ti, en todos tus proyectos | Te acompaña a ti (en tu máquina, nunca se sube a un repositorio) |
Aquí hay dos términos que debemos aclarar:
Nivel de proyecto (Project scope): La configuración existe en el repositorio, entra en git, se comparte con todo el equipo. Si cambias una regla y haces el commit, cuando tus compañeros actualicen (pull), el cambio tendrá efecto para ellos también.
Nivel de usuario (User scope): La configuración existe en tu directorio de inicio ~/.claude/, solo te afecta a ti y nunca entra en ningún repositorio. Si vas a cualquier otro proyecto de la empresa, esta configuración irá contigo.
Un ejemplo común de uso: pones «responder en español» o «qué prefijo usar en el mensaje de commit» — que son puramente preferencias personales — en tu ~/.claude/CLAUDE.md a nivel de usuario; de este modo, en cualquier proyecto que abras, Claude seguirá tus hábitos. Por otro lado, un hecho del proyecto como «este proyecto usa pnpm, no npm», lo escribes en el ./CLAUDE.md a nivel de proyecto, y lo subes para compartirlo con el equipo. Si los hábitos personales y las normativas del proyecto se separan desde el principio, te ahorrarás dolores de cabeza en el futuro.
💡 Resumen en una oración: Claude Code tiene «dos hogares»: el
./.claude/del proyecto (acompaña al proyecto, entra en git, compartido por el equipo) y el~/.claude/en el directorio de inicio (te acompaña a ti, no entra en git, solo te afecta a ti).
02 Abrir el .claude/ a nivel de proyecto: Qué hay dentro
Ahora echemos un vistazo a esa carpeta ./.claude/ en el proyecto. En un proyecto en uso, la estructura probablemente se vea así:
tu-proyecto/
├── CLAUDE.md ← Manual del proyecto (también se puede colocar en .claude/CLAUDE.md)
├── CLAUDE.local.md ← Tus preferencias personales en el proyecto (va en .gitignore)
├── .mcp.json ← Configuración compartida de servidores MCP (entra en git)
└── .claude/
├── settings.json ← Configuración compartida: permisos, hooks, modelos predeterminados
├── settings.local.json ← Tu sobreescritura de configuración personal (se ignora automáticamente en git)
├── commands/ ← Comandos de barra personalizados, cada .md es un comando /
├── rules/ ← Reglas modulares del proyecto (separadas del CLAUDE.md)
├── skills/ ← Habilidades: flujos de trabajo que se pueden invocar con / o automáticamente por Claude
└── agents/ ← Subagentes: asistentes específicos, cada uno con un contexto independienteVeamos uno por uno qué hacen, en este artículo solo se señala «qué son y a quién pertenecen»; el uso en profundidad tiene artículos específicos:
CLAUDE.md —— El manual del proyecto. El primer archivo que lee Claude cada vez que entra a un proyecto. Qué es el proyecto, cómo se ejecuta y qué convenciones existen, todo se escribe aquí. Tiene una diferencia fundamental con .claude/settings.json: CLAUDE.md es una «guía» para que Claude la lea (lo intentará hacer, pero no es una restricción estricta), mientras que settings.json es una «configuración» que Claude Code aplica obligatoriamente.
La documentación oficial menciona un detalle: Puedes poner
CLAUDE.mden el directorio raíz del proyecto, o en.claude/CLAUDE.md; esto último ayuda a mantener limpio el directorio raíz del proyecto.
CLAUDE.local.md —— Tus preferencias personales en el proyecto. Son instrucciones superpuestas a CLAUDE.md, relevantes solo para ti personalmente, como «mi base de datos local está en el puerto 5433». Debes agregarlo manualmente al .gitignore (al ejecutar /init, elegir la opción «personal» lo agregará por ti).
settings.json —— El centro de configuración compartido por el equipo. Controla si Claude puede ejecutar ciertas operaciones (permisos), en qué momento ejecutar tus scripts (hooks), y puede configurar qué modelo usar por defecto para este proyecto. Entra en git y es la base de seguridad del equipo.
settings.local.json —— Tu sobreescritura de configuración personal. El mismo formato JSON que el anterior, pero solo te afecta a ti y no se debe hacer commit. Si quieres permitir temporalmente un permiso pero no afectar a tus compañeros, escríbelo aquí. La primera vez que Claude Code crea este archivo, configura automáticamente que git lo ignore — este fue el archivo del principio que «se debía usar, pero se omitió».
Aquí hay un detalle que señala la documentación oficial: añade la regla de ignorar a tu
~/.config/git/ignoreglobal (no al.gitignorede tu proyecto), por lo que si buscas en el.gitignoredel proyecto, no encontrarás esa línea. Si deseas que todo el equipo lo ignore, debes agregar tú mismo una línea al.gitignoredel proyecto.
commands/ —— Comandos de barra personalizados. Cada archivo .md en el directorio se convierte en un comando /nombre_del_archivo. Guarda la instrucción repetitiva que siempre escribes como un archivo, y la próxima vez podrás usar / para llamarla. Oficialmente, commands/ y skills/ se han unificado bajo el mismo mecanismo subyacente; se recomienda usar skills/ para nuevos comandos (soporta adjuntar archivos relacionados), commands/ sigue siendo compatible pero ya no es la ruta recomendada.
rules/ —— Reglas de proyecto modulares. Cuando CLAUDE.md se vuelve demasiado largo (la documentación oficial sugiere mantenerlo bajo 200 líneas), divide las reglas por temas en múltiples archivos bajo rules/, por ejemplo testing.md, api-design.md.
skills/ —— Habilidades. Cada habilidad es un subdirectorio que contiene un SKILL.md. Puede ser invocado manualmente por ti con /nombre_habilidad, o dejar que Claude determine automáticamente si debe usarla dependiendo de la tarea.
agents/ —— Subagentes. Cada archivo .md define a un asistente específico con una ventana de contexto independiente, y el chat principal no los «ensucia». Son ideales para trabajar en paralelo o aislar tareas.
.mcp.json —— Configuración compartida de servidores MCP. Ubicado en el directorio raíz del proyecto, en paralelo con .claude/. Los servidores MCP (Model Context Protocol) se pueden configurar en dos lugares: .mcp.json aquí es para ser incluido en git y compartido con el equipo, por ejemplo, herramientas de base de datos o API internas que necesita el equipo; en cambio, la configuración MCP personal (como herramientas que usas tú solo) se almacena en ~/.claude.json y no formará parte de ningún repositorio. La diferencia entre los dos es: compartir en proyecto vs. uso privado personal.
💡 Resumen en una oración: En el nivel de proyecto
.claude/,CLAUDE.md/rules/es «guía» para que Claude la lea;settings.jsones la configuración que Claude Code «aplica obligatoriamente»;commands/,skills/yagents/son «extensiones» que le instalas.
03 En los mismos directorios, también hay un conjunto en ~/.claude/
Este punto marea más a los principiantes, pero de hecho es muy simple: Los nombres de los directorios anteriores tienen una copia casi idéntica en el nivel de usuario ~/.claude/.
commands/, rules/, skills/, agents/, CLAUDE.md, settings.json — todo esto está en el nivel del proyecto y también en ~/.claude/. La única diferencia es:
(El nivel de usuario ~/.claude/ también tiene varios directorios exclusivos que el nivel del proyecto no tiene: themes/, keybindings.json, output-styles/, workflows/, etc., que se introducirán uno por uno en artículos futuros.)
Lo que pones en ~/.claude/ se aplica a todos tus proyectos; lo que pones en ./.claude/ del proyecto se aplica solo a ese proyecto.
Da un par de ejemplos y lo entenderás:
- Un comando
/commit-es(para generar información de commit en español), colocado en~/.claude/commands/— Así podrás usarlo en cualquier proyecto, sin configurarlo en todos y cada uno. - Pero un comando como «desplegar en el entorno de pruebas de la empresa» claramente es solo para ese proyecto en particular, así que colócalo en el
.claude/commands/del proyecto y súbelo a git para el equipo.
Además de esos «directorios gemelos», en el directorio de inicio ~/ hay dos archivos que solo aparecen en el nivel de usuario y que básicamente nunca necesitas tocar, solo reconócelos:
| Archivo / Directorio | Dónde | Qué es | ¿Debería preocuparte? |
|---|---|---|---|
~/.claude.json | Directorio de inicio | Estado de la aplicación: estado de inicio de sesión (sesión OAuth), tema, servidores MCP personales, registros de confianza y preferencias de UI de cada proyecto. | Casi nunca lo toques, modifícalo con /config |
~/.claude/projects/ | Nivel de usuario | Registro de sesiones de cada proyecto; la memoria automática se coloca dentro del subdirectorio <proyecto>/memory/ | No hace falta escribirlo, se mantiene solo |
Un par de palabras más sobre la memoria automática (auto memory): Ella y el CLAUDE.md son dos cosas distintas. CLAUDE.md son instrucciones que tú escribes para Claude; la memoria automática son las notas que Claude escribe para sí mismo (por ejemplo, los comandos de construcción, trampas que encontró), se guardan en ~/.claude/projects/<proyecto>/memory/ y se reutilizan entre sesiones. No los confundas: tú escribes uno, él escribe el otro.
💡 Resumen en una oración: Los directorios
commands/,skills/, etc., tienen conjuntos separados para nivel de proyecto y de usuario, la diferencia es si "maneja un proyecto" o "los maneja todos";~/.claude.jsony~/.claude/projects/son exclusivos del nivel de usuario, y apenas se deben tocar.
04 Qué subir a git y qué NO subir NUNCA
Esta sección es de lo más práctica, aquí caen errores como la filtración de claves del inicio. Aquí va la regla de oro: Archivos que contengan "local" o contraseñas/claves/token NUNCA se suben a git.
¿Por qué algunos sí y otros no? Es lógico: Lo que comparte el equipo, súbelo a git; lo que es solo para ti o tu computadora, no lo subas.
Analogía: Lo del archivador del proyecto se debe registrar en el inventario (git), los objetos personales de tu cajón no hace falta entregarlos.
Clasifiquemos los archivos comunes de un proyecto sobre «si se sube o no», con esto no te equivocarás:
| Archivo / Directorio | ¿Sube a git? | Por qué |
|---|---|---|
CLAUDE.md | ✅ Subir | Explicación del proyecto compartido por el equipo |
.claude/settings.json | ✅ Subir | Línea base de permisos/configuración compartidos |
.claude/commands/*.md | ✅ Subir | Comandos normalizados reutilizados en el equipo |
.claude/rules/*.md | ✅ Subir | Reglas modulares compartidas por el equipo |
.claude/skills/, .claude/agents/ | ✅ Subir | Habilidades y subagentes compartidos |
.claude/settings.local.json | ❌ No subir | Sobreescritura personal; Claude Code lo añade al gitignore por ti |
CLAUDE.local.md | ❌ No subir | Preferencias del proyecto personales; debes añadirlo al .gitignore manual |
| Cualquier archivo con claves / token / contraseña | ❌ NUNCA subir | Entrar al repositorio = Filtración de datos |
Algunos recordatorios útiles:
No debes preocuparte por ignorar settings.local.json en git. La documentación oficial es muy clara: Claude Code al crear el archivo, configura a git para ignorarlo automáticamente. Si deseas abrir un permiso temporalmente a nivel local, es muy seguro hacerlo aquí.
Debes agregar .gitignore a CLAUDE.local.md tú mismo. Es distinto a settings.local.json, no se ignorará automáticamente — al ejecutar /init al elegir "personal" se agrega solo; si no lo haces así, acuérdate de añadir la línea manualmente.
Las claves nunca deben escribirse directamente en archivos de configuración. La recomendación oficial es hacer referencias a ellas mediante variables de entorno, es decir, escribir ${GITHUB_TOKEN} en vez de pegar el token en texto plano — al arrancar Claude Code lo leerá del entorno del shell, así que el token nunca queda registrado en un archivo. Esta es una regla que se debe cumplir a rajatabla.
💡 Resumen en una oración: Se sube a git lo compartido por el equipo (
CLAUDE.md,settings.json,commands/, etc.); lo que contenga "local" y cualquier clave secreta NO SE SUBE NUNCA;settings.local.jsones ignorado automáticamente y aCLAUDE.local.mdlo debes ignorar tú.
05 Conflicto de configuración, a quién hacer caso: Orden de prioridad en un gráfico
Tal vez ya pensaste en este problema: Si settings.json del nivel de usuario y del nivel de proyecto configuran la misma opción, ¿a cuál de los dos escuchará?
El orden de prioridad dado por la documentación oficial es este (de mayor a menor):
Managed (Administrado por organización, el mayor, nadie lo sobreescribe)
↓
Parámetros de línea de comandos (como --permission-mode, solo por la sesión)
↓
Local (settings.local.json)
↓
Project (settings.json del proyecto)
↓
User (~/.claude/settings.json de usuario, el menor)Truco para recordar: Mientras más "específico" y más "cercano a la operación actual" sea, mayor es su prioridad. Lo que maneje la organización > lo que le indiques al iniciar sesión temporalmente en consola > lo local del proyecto > lo compartido del proyecto > los valores predeterminados globales.
Este gráfico muestra los dos árboles uno junto al otro: El lado izquierdo ./.claude/ de nivel de proyecto (que sigue al proyecto, va al git compartido por el equipo), y del lado derecho ~/.claude/ del nivel de usuario (que te acompaña a ti, controla a todos los proyectos) — ten presente lo que controla cada árbol para no perderte al aplicar configuraciones.
Pero hay que tener en cuenta un detalle muy importante y propenso a trampas — no todos los ajustes obedecen a una lógica de "sobrescritura":
| Tipo de Configuración | En diferentes scopes a la vez | Ejemplo |
|---|---|---|
| Valor escalar (un solo valor) | Toma el más específico, sobrescribe | model: Si se definió en el proyecto, usa el del proyecto |
| Valor en matriz (lista) | Entre distintos scopes se fusionan, sin sobrescrituras | permissions.allow: Se suman el de usuario + el de proyecto + el local superponiéndose |
Es muy fácil cometer un error aquí: Me pasó una vez cuando intentaba denegar cierto comando con deny en settings.json a nivel de usuario. Creía que con esto lo denegaba de forma global; sin embargo, al estar en un proyecto el comando seguía funcionando y por mucho que revisaba el archivo, no le veía el sentido. Al final logré entender que las reglas de permiso se combinan, no se sobrescriben; si a nivel de proyecto fue autorizado (allow), entonces se evalúa de manera conjunta sumándose a la regla de nivel de usuario. Así que nunca intentes cortar de un tajo los permisos configurándolo a nivel global de usuario, debes comprender bien las reglas combinatorias.
💡 Resumen en una oración: El orden de prioridad de mayor a menor es Managed → Línea de comandos → Local → Project → User; pero debes separar qué pasa con valores de tipo escalar como
modellos que se «sobrescriben» frente al listado de tipopermissions.allowque se «superponen/fusionan».
06 A trabajar: Comprobar con tus propios ojos estas dos jerarquías de directorios
Es mejor echar un ojo que quedarse en la lectura. El grupo de comandos que viene a continuación es de sólo lectura, son súper seguros, si sigues las instrucciones verás con claridad la realidad de estos "dos hogares".
Paso 1: Ver el nivel de usuario del directorio local ~/.claude/
Abre un terminal y escribe (Mac / Linux):
ls -a ~/.claudeLos que usan Windows PowerShell pueden usar:
dir $HOME\.claudeResultado esperado: Allí vas a ver que está el settings.json, projects, posiblemente hasta haya commands, skills, etc. — todo esto dependerá de cuánto hayas profundizado el uso de Claude Code. Basta que allí se vea información listada para confirmar la existencia de este "hogar" a nivel usuario y que de hecho está funcionando.
Paso 2: En un proyecto comprobar la presencia del nivel de proyecto .claude/
Toma cualquier proyecto y ve al mismo (haz un cd hacia él) en que ya antes hayas ejecutado Claude Code (y de no ser así, fíjate del artículo anterior usando /init y levanta uno), ahora luego entra:
ls -a .claudeResultado esperado: A lo menos se observará allí el settings.local.json (si hubo ya alguna aprobación de permisos antes), e igual a eso hasta que haya un archivo settings.json. Esto indica ese "archivador de proyectos" en su jerarquía dentro del proyecto, confirmando que es totalmente un espacio aparte del de tu directorio principal.
Paso 3: Validar que settings.local.json fue ignorado correctamente en git
Estando en el proyecto (y siendo este ya un repositorio de git), coloca esto:
git check-ignore .claude/settings.local.jsonResultado esperado: La pantalla en tu terminal ha de mostrar la ruta exacta a este archivo que hemos mencionado (.claude/settings.local.json), con lo que habremos dejado claro que git ya omitirá el seguimiento, — un trabajo que Claude Code elaboró a fondo a cuenta propia por nosotros. De ocurrir algo en que no te da resultado ninguno allí en el output, nos indicaría el hecho de que a lo mejor el de arriba no se ignoró; la mejor jugada es añadir dicho fragmento directamente a la sección final en .gitignore.
Paso 4 (Opcional): Dar un vistazo al contenido del manual de ese proyecto
cat CLAUDE.md(En Windows PowerShell usa type CLAUDE.md)
Resultado esperado: Podrás ver todo esto imprimiéndose y confirmando con resultados extraídos según ya hablamos para la edición con el /init anterior. Y este resulta que es el fichero inicial de comprobación con lo cual va siempre de lleno hacia tus comandos, es útil conocerlo de tal modo que de sobra tienes la forma con la cual ver dónde "reposaba".
⚠️ Solo ten en cuenta un detalle:
git check-ignoretiene que realizarse sí o sí sobre el mismo repositorio git. A caso si no hubo uso del comando para inicializar el git repo y no haya hechogit init, arrojará advertencia diciendofatal: not a git repository, entonces transfórmalo en un proyecto git al principio para ver el mismo suceso.
💡 Resumen en una oración: Usa la verificación con tu línea
ls -a ~/.claudey observar el de usuario, usals -a .claudehacia proyectos para visualizar niveles por cada uno; congit check-ignore .claude/settings.local.jsonse corrobora que se omite; bastará esas solas tres simples reglas de lectura, el ver a "quién es o si lo descarta/ignora el repo git" a fin de obtener toda la mejor visual.
07 Resumen
Con todo esto por fin le habrás echado ojo por todas partes "por el baúl y todas sus raíces de secretos" desde el cual un usuario maneja o gestiona el uso del entorno general dentro con ayuda total en el fondo de las herramientas con las herramientas que provee en cada lugar Claude Code. Revisando y relacionando de manera retrospectiva:
| Lo que debes recordar | Qué es exactamente |
|---|---|
| Los dos hogares | El de nivel de Proyecto ./.claude/ (Va a la par del proyecto, con todo en git) y del usuario local a casa o de manera general a tu terminal y su ~/.claude/ (te acompaña y solo va a tu perfil de uso particular de forma exclusiva sin nada subiéndose a los repos de git) |
| Instrucción de lectura o configuración para que le sirva a él, VS la Guía obligada/configuración forzada | Los casos en general como el CLAUDE.md / rules/ lo verá el agente al pasar; al ser de settings.json ese se lo aplica como un patrón para reglas exactas del flujo |
| Los directorios idénticos Gemelos (Twins) | Casos en commands/ y además como con respecto a los de de skills/ e incluso hasta con agents/ resultarán tener de modo análogo gemelos a nivel del directorio de tu computadora o a nivel de donde usas/guardas proyectos; lo principal cambia solo según quieres hacerlo global al sistema entero de todas tus gestiones de un "hogar personal global a tus trabajos de desarrollo locales o individuales", contra querer enfocar todas sus aplicaciones directo solo al fin para la base del desarrollo o un único marco a resolver |
| Límites con respecto del uso por las herramientas de Git | La forma en usar el que venga y que por nombre integre la cadena con «local» y los donde por motivos contenga/posea cosas tales a modo de usar tokens de claves para bases u otros no debe bajo circunstancia incluir en los compromisos o commits, un simple ejemplo que ya viste: settings.local.json que además se omite sólo desde los metadatos ocultados, pero en cuanto el archivo CLAUDE.local.md para todo ello, al usuario requerirá o le obligará al poner esa orden particular por su mano y a nivel independiente un salto de modo manual |
| Órdenes a prioridades en las acciones | Pasa lo general primero bajo nivel en torno a reglas de Managed → para Línea de comando la consola → Local → de nuevo el del Proyecto particular/Project → User desde del tu de perfiles general o cuenta propia de inicio y preferencias al ambiente y su propia forma particular que tengas allí establecido; donde aplique algo tan concreto a los escalares toma el lugar que por sí sea el mismo que cubra en lugar, es la sobreescritura donde "Reemplazará las configuraciones de la opción por sí o por sus resultados" o se mezclará juntándolo para usar matrices que solo logran que a efectos unifique cosas como matrices mezcladas o arrays conjuntos y acumulados de forma fusionadas |
Ahora deberías ser capaz de: Abrir cualquier proyecto que sea de forma rápida visual y simple verás en .claude/ para comprender luego todos los misterios allí en los archivos que sea cual fuere de cada archivo de cada conjunto que tengas; que logres determinar fácilmente al mismo quién hace o dirige a todos a quién tiene cargo de responsabilidades para gestionar si a cada persona o todos ellos del entorno grupal o a quien de todos subirá de tal forma una versión con git, no falles también para lo del modo que tiene cada cosa cuando una cosa pueda o haya dado paso para usar otra o cuando tenga lugar que resulte a existir contradicción para reglas en cada archivo saber al momento o poder determinar la mejor alternativa o conocer, dónde encontrar o solucionar si alguna cosa causa problemas y qué acción obedecer. Ahora con todo este material posees una total herramienta panorámica tipo mapa a usar desde lo local o la nube para cada entorno base que debes visualizar luego y tomar nota donde vayas en caso o artículos dedicados en profundidad al detalle a modo tal que logres guiar un buen enfoque sobre tu conocimiento y desarrollo por parte del equipo todo de forma adecuada — verás la regla al fin de usar bien el settings.json y de los archivos más importantes a las otras herramientas y como redactar CLAUDE.md de la manera y con formas aptas en uso óptimo todo ello sabrás y entenderás qué cosas poder mejorar cuando un experto se ponga a revisar cosas así a un subagente local.
El siguiente artículo a consultar lo tienes a punto y ya desde aquí es posible abordar a 14 «Interfaz e interacciones o sus atajos / Keyboard Shortcuts» — Al dejar vista o aclarado de la arquitectura de todo o un esquema estructural del programa todo será una forma más estática; de lo estático aquí, hay todo para lograr ahora o ir desde todo un modelo que debes operar luego para así empezar su verdadero rol conociendo y explorando todo acerca tu sistema completo, al llegar entonces de frente a usar ya la "interfaz operativa en su mejor forma para usar y probar comandos allí en tu consola particular". Para lograr un ambiente a fondo te dejaré de antemano el ver allí en toda la pantalla dónde revisar tu zona más operativa del agente e interface y así probar los atajos a tus controles para volver los movimientos un modo con memoria a largo modo con las memorias corporales por reflejos en un ambiente rápido; para tener mucha eficacia en forma más segura de ti al uso y el escribir o dictar lo rápido al sistema.