Claude Code en la terminal: 7 mejoras de flujo de trabajo para usuarios avanzados

Claude Code "vanilla" ya es útil tal cual. Lo instalas, le das un prompt y construye lo que le pidas. Ese es el setup de vibe-coding de la mayoría, y cumple.

La versión de Claude Code que usa alguien con la terminal personalizada es otra cosa. Ha preaprobado los comandos de bash en los que confía, así que Claude casi nunca pide permisons. Un CLAUDE.md vive en la raíz del proyecto, así que Claude ya conoce sus convenciones nada más abrir la sesión. Y cuando una sesión empieza a irse por las ramas, el comando al que recurren no es reiniciar.

Este artículo cierra la brecha entre esos dos setups de Claude Code en siete mejoras. Ninguna lleva más de diez minutos de configurar y cada una se amortiza en menos de una semana.

Si nunca has abierto Claude Code, nuestra guía principal de Claude Code es un mejor punto de partida. Todo lo de abajo asume que ya sabes dar prompts y aceptar llamadas a herramientas.

1. Deja de volver a aprobar los mismos comandos

De serie, cada invocación de herramienta nueva te pide aprobación. Bien la primera vez que ejecutas pytest. Pesado a la tercera. A la décima, pulsas Enter sin leer el prompt. Es lo peor de ambos mundos: te has entrenado para ignorar el control de seguridad y aun así te ralentiza.

Por supuesto, existe el modo de "omitir permisos con riesgo" o modo "auto". Hablamos a fondo de sus contrapartidas en mi tutorial sobre Auto Mode y canales en Claude Code.

Definir permisos en el archivo settings.json

La solución es un archivo .claude/settings.json en la raíz del proyecto, con un bloque permissions que preaprueba los patrones en los que confías y bloquea los que no:

{
  "permissions": {
	"allow": [
  	"Bash(pytest *)",
  	"Bash(uv run *)",
  	"Bash(ruff check *)",
  	"Read(~/.zshrc)"
	],
	"deny": [
  	"Bash(curl *)",
  	"Read(./.env)",
  	"Read(./.env.*)",
  	"Read(./secrets/**)"
	]
  }
}

Las reglas se evalúan en orden fijo: primero deny, luego ask y después allow. Gana la primera coincidencia, así que una deny siempre prevalece sobre una allow posterior.

Domina el alcance y los comodines

Tres cosas suelen liarla la primera vez que escribes esto.

1. La primera es el alcance. Un .claude/settings.json del proyecto sobreescribe tu ~/.claude/settings.json global, así que si has permitido Bash(rm *) a nivel global y un proyecto lo deniega, gana el proyecto. Es el comportamiento correcto, pero sorprende a quien espera que las allows globales sean inamovibles.

2. La segunda son los comodines en comandos de red. Bash(curl http://github.com/ *) parece restrictivo, pero no pilla https://, opciones antes de la URL, redirecciones o expansión de variables de shell. El patrón recomendado en la documentación es denegar Bash(curl *) sin más. Luego usa la herramienta WebFetch con WebFetch(domain:github.com) para los dominios que sí quieras permitir.

3. La tercera es el espacio en blanco. Bash(ls *) coincide con ls -la pero no con lsof. Bash(ls*) coincide con ambos. El espacio antes del asterisco hace un trabajo real; merece la pena ser deliberado con cuál escribes.

Unas cuantas combinaciones de teclas van de la mano de los permisos en la categoría de "deja de pelearte con la terminal" y conviene aprenderlas desde el primer día:

• Shift+Tab cambia el modo de permisos (predeterminado, auto-aceptar, plan)

• Esc+Esc abre el selector de rebobinado (más en el punto 3)

• Ctrl+R busca a la inversa en tu historial de prompts, igual que en bash y zsh

• Ctrl+U borra desde el cursor hasta el inicio de línea

• Shift+Enter añade una línea dentro del prompt

La mayoría funcionan de serie en las terminales. Si no, ejecuta una vez el comando /terminal-setup para instalarlo todo.

2. Haz que Claude Code recuerde tu proyecto

Cada sesión arranca con una ventana de contexto limpia.

Por defecto, Claude no recuerda que usas uv en lugar de pip. No recuerda que tus tests viven en tests/ y no en test/. Y las convenciones de API que ayer tardaste diez turnos en explicar también desaparecen. La solución es un archivo CLAUDE.md en la raíz del proyecto. Lanza Claude Code desde ese directorio (o cualquier subdirectorio), y el archivo se carga en el contexto automáticamente antes de tu primer prompt.

La forma más rápida de empezar es /init. Ejecútalo dentro del proyecto. Claude lee la base de código y escribe un CLAUDE.md inicial con los comandos de build, instrucciones de test y convenciones que puede inferir. Luego lo editarás, porque /init te da una base funcional, no un archivo definitivo.

Claude busca contexto en tres sitios, apilados uno sobre otro:

CLAUDE.md del proyecto en ./CLAUDE.md viaja con el repo. Es el mismo para cada persona colaboradora, así que aquí van los hechos del proyecto:

• El gestor de paquetes y la versión del lenguaje
• El comando de test y dónde viven las pruebas
• La estructura de directorios y cualquier convención no obvia
• Todo lo que alguien nuevo debería saber el primer día

CLAUDE.md del usuario en ~/.claude/CLAUDE.md te sigue en todos los proyectos de tu máquina. Aquí van las preferencias personales: tu estilo de código, cómo te gustan las docstrings, los lenguajes a los que recurres primero. No pongas hechos del proyecto, porque se colarán en cada repo que abras.

Auto-memoria es la tercera capa y la escribe el propio Claude. Cuando lo corriges durante una sesión ("aquí usamos snake_case, no camelCase"), registra la corrección en ~/.claude/projects/<project>/memory/MEMORY.md. Las primeras 200 líneas o 25 KB se cargan al inicio de cada conversación en el mismo proyecto. Puedes ver qué se carga con /memory, que también te permite activar o desactivar la auto-memoria.

Una regla de tamaño: mantén cada CLAUDE.md por debajo de 200 líneas. A partir de ahí, el archivo empieza a comerse contexto en cada turno y Claude sigue peor los archivos largos que los cortos. Si el tuyo se alarga, divídelo en .claude/rules/ con ámbitos por ruta. Para profundizar en qué debe ir realmente en un CLAUDE.md, consulta mi guía sobre el mejor CLAUDE.md.

3. Deja de reiniciar sesiones cuando se tuerzan

El instinto, cuando una sesión empieza a ir rara, es hacer /clear y empezar de cero. La mayoría de las veces es el instinto equivocado. Reiniciar tira por la borda las rutas de archivo que Claude estaba editando, el test que fallaba o las restricciones que definiste al principio. Una sesión nueva tiene que reaprenderlo todo, y pagas ese reaprendizaje en tokens y tiempo.

Lo primero es reconocer el síntoma. Esta podredumbre de contexto tiene señales claras:

• Claude vuelve a pedir una ruta de archivo que editó hace cinco turnos
• Repite una sugerencia que ya rechazaste
• Pierde la pista de en qué rama estás
• Lo has corregido más de dos veces en lo mismo en una sola sesión

Cuando veas eso, tienes cuatro opciones, y no son intercambiables:

Compactar tu sesión

 /compact no es tan malo como dicen algunos.

Tu CLAUDE.md del proyecto sobrevive. Claude relee el archivo del disco tras compactar y lo reinyecta, así que tus convenciones no se pierden. También puedes pasarle instrucciones de enfoque para guiar el resumen, como /compact keep the auth refactor decisions, drop the failed test runs. Esa es la diferencia entre un resumen útil y uno genérico.

Usar la opción "deshacer" de Claude Code

El selector de rebobinado con Esc+Esc es el gran desconocido. Abre una lista con todos los checkpoints de prompts de la sesión. Al elegir uno, ofrece tres opciones: restaurar solo la conversación, solo el código o ambos.

"Restore code and conversation" es lo que suele querer la gente. Media hora de malos turnos puede desaparecer sin tocar git. Es lo más parecido a deshacer toda una sesión que tiene Claude Code.

Una vez dejas de reiniciar, el siguiente problema es volver a encontrar las sesiones.

Nombrar y reabrir sesiones

claude -n <name> (o --name) inicia una sesión con nombre, que verás en /resume y en el título de la terminal. Cuando llevas tres frentes a la vez en el mismo repo (una rama de experimento, un refactor, una depuración), los nombres son cómo los distingues. /rename cambia el nombre a mitad de sesión si tu alcance cambia.

Truco: usa /color para distinguir aún más sesiones si ejecutas varias en la misma ventana.

Reabrir una sesión se hace con dos flags. claude --continue (o -c) carga la conversación más reciente en el directorio actual. Úsalo cuando estabas aquí mismo y quieres seguir.

claude --resume abre un selector interactivo, y claude --resume <name-or-id> salta directo a una sesión concreta. Trata las sesiones como ramas de git: flujos de trabajo distintos merecen la suya.

4. Planifica lo difícil, ahorra en lo fácil

El mayor coste de un setup personalizado no es el editor ni los atajos. Es ajustar el cómputo que gastas a la dificultad de la tarea que tienes delante. Tres herramientas trabajan juntas en esto: modo plan, /effort y /model.

Usar el modo plan de Claude Code

El modo plan le dice a Claude que piense el enfoque antes de tocar archivos. Escribe el plan, tú lo revisas, lo apruebas o pides cambios y solo entonces ejecuta.

Un truco para blindar mis planes es un prompt sencillo que uso a menudo:

Red-team this plan from multiple angles using as many Opus 4.7 agents as you need.

Esto lanzará varios subagentes para revisar el plan desde distintas perspectivas y proponer mejoras. Es una buena práctica con planes de más de 500 líneas.

El coste es que planificar y hacer red-teaming añade dos turnos antes de que caiga código, así que para algo menor que una funcionalidad o bugfix importante es excesivo.

Hay cinco formas de entrar en modo plan:

La forma en línea (/plan refactor the auth module to use JWT) es la que más se pasa por alto. Ajusta el modo y la tarea en una sola tecla, en vez de dos. Para un recorrido paso a paso de flujos de revisión previa, en mi tutorial de modo plan en Claude Code lo explico paso a paso.

Ajustar el nivel de esfuerzo adecuado

El esfuerzo es lo siguiente a dominar. Controla cuánto razonamiento extendido hace Claude en cada turno. Más esfuerzo significa razonamiento más profundo, más tokens y respuesta más lenta.

/effort <level> y el flag de CLI --effort <level> aceptan los cinco valores. Low, medium, high y xhigh persisten entre sesiones. Max es solo para la sesión porque elimina el límite de gasto de tokens; lo configuras a propósito cada vez. El valor por defecto para el día a día es low o medium. Reserva high o xhigh para problemas realmente difíciles, y max para cuando prefieres gastar tokens a equivocarte.

Un matiz: un modelo en low con gran contexto a menudo supera al mismo modelo en max con mal contexto. Limpiar tu prompt suele dar más rendimiento que subir el esfuerzo.

Elegir el modelo adecuado

La selección de modelo es donde ahorras de verdad. /model cambia en mitad de sesión, y Opción+P (macOS) / Alt+P (Win/Linux) cambia sin borrar lo que ya has escrito. Aliases que merece la pena conocer:

• sonnet es el comodín para el día a día

• opus para los problemas más duros (el alias best también resuelve a opus)

• haiku cuando prima la velocidad

• sonnet[1m] y opus[1m] son las variantes con contexto 1M

• opusplan ejecuta Opus en modo plan y Sonnet en ejecución

• default quita cualquier override y vuelve al modelo recomendado

Si usas Opus por defecto para todo, cambiar a Sonnet para la mayor parte del día es el mayor recorte de gasto que tienes a mano. 

Opus es la elección cuando estás atascado en algo duro y quieres el modelo más capaz. Sonnet resuelve casi todo lo demás. La diferencia de coste es lo bastante grande como para que "tiro de Opus por si acaso" sea el hábito más caro que puedes dejar en piloto automático.

5. Automatiza lo que aún haces a mano

Cuando desaparece la fricción, el siguiente nivel es el trabajo que sigues haciendo manualmente.

Tareas programadas

Es más fácil que buscar cómo no hacerlo. Dos funciones cubren la mayoría: /loop para comprobaciones periódicas que, si no, tendrías que vigilar, y hooks para garantías que no puedes obtener con una instrucción en CLAUDE.md.

/loop vuelve a ejecutar un prompt o comando con una cadencia recurrente. La sintaxis tiene dos formas:

• /loop 5m <prompt> ejecuta el prompt cada 5 minutos

• /loop <prompt> sin más cede la cadencia al modelo, que decide cuándo volver a ejecutar

Las unidades del intervalo son s, m, h y d, con un mínimo de un minuto. Necesitas Claude Code v2.1.72 o posterior.

Por ejemplo, puedes montar un vigilante de tests: /loop 2m run the test suite and report failures. En lugar de acordarte de lanzar las pruebas tras cada cambio (y olvidarlo la mitad de las veces), Claude cazará un test roto en el siguiente tick de 2 minutos.

El mismo patrón vale para vigilar un despliegue en staging (/loop 10m check if the staging deploy is green) o para hacer tail de logs durante una incidencia intermitente (/loop 1m tail the last 50 lines of app.log and flag errors).

Los loops viven 7 días.

El séptimo día se ejecutan una vez más y se borran. Están vinculados a la sesión, así que --continue o --resume los recupera si cierras y reabres. Para parar un loop antes, pulsa Esc. Si necesitas programación que sobreviva al cierre (una comprobación nocturna, un resumen semanal), usa Routines con /schedule.

Hooks

Los hooks son la otra mitad. Ejecutan comandos de shell en puntos específicos del flujo de Claude, configurados en .claude/settings.json. 

La razón para usar un hook en lugar de una instrucción en CLAUDE.md es clara: CLAUDE.md es orientativo; los hooks se ejecutan sí o sí. El caso clásico es el "pasa siempre el linter tras editar" que Claude se salta a veces. Un hook cierra esa brecha.

Seis eventos cubren la mayoría de casos:

Un mínimo hook PostToolUse que pasa el linter tras cada edición de archivo:

{
  "hooks": {
	"PostToolUse": [
  	{
    	"matcher": "Edit|Write",
    	"hooks": [
      	{ "type": "command", "command": "/path/to/lint-check.sh" }
    	]
  	}
	]
  }
}

Un detalle a memorizar: solo el código de salida 2 bloquea a Claude. La salida 1 se trata como error no bloqueante y Claude sigue adelante, aunque 1 sea el código de fallo típico en Unix. Si tu hook debe hacer cumplir una regla, devuelve 2.

Tampoco hace falta escribir hooks a mano.

Pídeselo a Claude con "write a hook that runs ruff after every file edit" y te redacta el JSON. /hooks lista toda la configuración activa, para no tener que grepear archivos de ajustes cuando algo salta sin esperarlo. Para el catálogo completo de eventos y los esquemas JSON de stdin/stdout, consulta mi tutorial de hooks en Claude Code.

6. Controla cuánto te está costando todo esto

Loops, sesiones largas y Opus por defecto queman tokens. Tres comandos hacen el gasto lo bastante visible como para gestionarlo; el hábito que quieres es echarles un vistazo, no configurarlos sin parar.

/usage muestra tu plan, totales de sesión, desglose por modelo y barras de progreso para las ventanas de límite de uso de 5 horas y semanal.

/context visualiza la ventana de contexto actual como una cuadrícula de colores, con avisos de capacidad y sugerencias sobre qué herramientas o archivos están ocupando espacio. Úsalo cuando una sesión se sienta pesada y dudes entre /compact y /clear.

/statusline configura una barra persistente al pie de tu terminal. Puede mostrar el modelo, el porcentaje de contexto, las ventanas de rate-limit y cualquier cosa que puedas leer del JSON de sesión. Es la que más cambia hábitos, porque pone los números relevantes al coste en tu visión periférica mientras trabajas.

Puedes ejecutar /statusline y describir en lenguaje natural qué quieres ver; Claude genera el script y actualiza los ajustes. La otra opción es escribir tú el script de shell y referenciarlo desde ~/.claude/settings.json:

{
  "statusLine": {
	"type": "command",
	"command": "~/.claude/statusline.sh"
  }
}

Para seguimiento a largo plazo entre sesiones, npx ccusage es una herramienta de la comunidad que agrega el gasto de tokens en el tiempo. Es de terceros, no de Anthropic, pero cubre el hueco entre el /usage limitado a sesión y tu factura mensual.

7. Tres cosas más que merece la pena conocer

Las seis mejoras anteriores son las que uso a diario. Las tres de abajo son funciones reales que uso menos, pero conviene que sepas que existen para sacarlas el día que las necesites.

Usa pulsar-para-hablar con /voice

/voice activa la dictado por pulsar-para-hablar. Mantén Space pulsado, habla, suelta y el texto transcrito aparece en tu prompt. Necesitas la v2.1.69 o posterior y hay veinte idiomas compatibles.

La voz suele ganar al tecleo cuando vas andando pensando en voz alta o dictando la intención al empezar una tarea antes de fijar el wording. Es peor para ediciones línea a línea, donde "cambia la línea 47 a..." es más fácil de teclear.

Trae sesiones de la nube con /teleport

/teleport (alias /tp) trae una sesión en la nube a tu terminal local. Imagina que empezaste una tarea larga en la app web o en iOS, y ahora estás de vuelta en el portátil. Ejecuta claude --teleport para abrir un selector y aterrizar esa sesión en tu terminal con la rama correcta ya checkoutada.

Hay que alinear unos requisitos:

• Estado limpio en git
• El repo correcto
• La misma cuenta de claude.ai que ejecutó la sesión en la nube
• La rama se subió al remoto

No confundas --teleport con --resume. Este último solo reabre sesiones locales del historial de esta máquina. Para verlo a fondo, nuestro tutorial de control remoto en Claude Code cubre el resto.

Haz preguntas al margen con /btw

/btw sirve para esa duda rápida que no quieres que corte el flujo.

Imagina que Claude está a mitad de tarea. Ya has lanzado una edición larga o una llamada a herramienta, y de pronto necesitas saber la regex para IPs o qué flag hace X. 

Solo tienes que escribir /btw <question>, y la respuesta aparece en una superposición que puedes cerrar. La tarea en curso sigue, la respuesta no entra en el historial de la conversación, así que no necesitas abrir una sesión nueva para una consulta puntual ni ensuciar la actual.

Conclusión

La forma más rápida de desaprovechar todo lo de este artículo es intentar aplicarlo en un día. Elige dos o tres, crea memoria muscular con esas y añade el resto cuando las primeras salgan solas.

Tres con las que empezar, cada una para un momento distinto del día, para que no se pisen:

• Un CLAUDE.md de proyecto ajustado más dos o tres reglas con comodines en .claude/settings.json para los comandos de bash que reautorizas en cada sesión. Este es el hábito de preparación por la mañana, y solo lo notas cuando desaparecen las interrupciones.

• La decisión entre /compact y /clear y el selector de rebobinado con Esc+Esc. Este es el hábito de mitad de sesión, y la señal es cuando Claude te vuelve a pedir una ruta que sabía hace una hora.

• Un /loop para una comprobación recurrente que ya te quita tiempo. Este es el hábito en segundo plano: una vez en marcha, se amortiza solo.

Si aún te lías entre Sonnet, Opus y Haiku, nuestro curso Introduction to Claude Models explica cuándo encaja cada modelo. Así las llamadas a /effort y /model se vuelven mucho más sencillas.