Usás cuatro comandos de Claude Code. Faltan diez

Con Claude Code se trabaja bien sabiendo poco: escribís lo que querés, aprobás lo que hace, y cuando la conversación se pone larga ponés /clear. Con eso alcanza para el día a día.

Los diez comandos de este artículo no son características extra. Cada uno resuelve un problema que ya estás teniendo, aunque no lo hayas puesto en palabras: la conversación que se llena y encarece, la configuración que nunca hiciste, el cambio que salió mal, y el trabajo que no entra en un solo turno.

Van agrupados por ese problema, no por orden alfabético.

El contexto: lo que más te cuesta sin que lo veas

Este grupo es el que más plata ahorra, y el que peor se entiende.

Claude Code no tiene memoria entre mensajes. Cada vez que respondés, se le reenvía la conversación entera: tus mensajes, sus respuestas, y el contenido de todos los archivos que leyó en el camino. En el turno veinte no estás pagando un mensaje; estás pagando la suma de todo lo anterior.

Eso explica algo que desconcierta: una pregunta corta en una sesión que lleva horas abierta cuesta bastante más que la misma pregunta en una sesión nueva.

/context — mirar dónde se fue el espacio

Dibuja una cuadrícula de colores con lo que hay cargado ahora mismo, dividido por origen: las instrucciones del sistema, tu CLAUDE.md, las herramientas MCP, los archivos leídos, la conversación. Además marca lo que sobra: herramientas que ocupan mucho, memoria inflada, y avisos cuando estás cerca del límite.

Es el único de los diez que no hace nada. Solo muestra. Y es el que conviene correr primero, porque los otros dos de este grupo son decisiones que se toman mirando ese número.

/compact — resumir sin perder el hilo

Toma la conversación hasta acá y la reemplaza por un resumen. Sirve cuando necesitás seguir en el mismo tema pero el contexto se llenó.

Acepta instrucciones sobre qué conservar, y vale la pena usarlas:

/compact quedate con los ejemplos de código y las decisiones de arquitectura

Lo que no se pierde al compactar está definido: tu CLAUDE.md y la memoria del proyecto se vuelven a cargar desde el disco, y de los archivos que se leyeron se releen los cinco más recientes. Lo demás pasa por el resumen.

El detalle que casi nadie sabe: compactar cuesta. Para resumir la conversación hay que leerla entera, así que compactar un contexto grande es en sí mismo una petición grande. No es gratis.

/clear — empezar de cero, y no cuesta nada

Arranca una conversación nueva con el contexto vacío. A diferencia de /compact, no cuesta nada: no hay nada que leer ni que resumir.

De ahí sale la regla más útil de las tres:

• Seguís con el mismo tema y necesitás lo que ya se habló → /compact
• Cambiás de tarea → /clear

Casi siempre es lo segundo. Terminaste de arreglar un error y ahora vas a escribir una función nueva: no hay nada de la conversación anterior que valga lo que cuesta arrastrarlo, y encima compite por la atención del modelo con lo que importa ahora.

Le podés pasar un nombre para encontrar después esa sesión, y volver con /resume.

Los dos que se configuran una vez

/init — que el proyecto se explique solo

Crea un archivo CLAUDE.md en la raíz con lo que hay que saber del proyecto: cómo se compila, cómo se prueba, qué convenciones tiene. Ese archivo se carga en cada sesión, así que deja de hacer falta explicarlo cada vez.

Un aviso que vale más que el comando: ese archivo se paga en todas las sesiones, incluso en las que no tienen nada que ver con lo que dice. Conviene que sea corto y que contenga solo lo que Claude no puede deducir leyendo el código. La estructura de carpetas se deduce; que las pruebas se corren con un comando raro, no.

/permissions — dejar de aprobar lo mismo veinte veces

Abre un panel para manejar qué se permite, qué se pregunta y qué se rechaza. Se pueden ver las reglas por alcance —esta máquina, este proyecto, todos—, agregarlas y sacarlas.

Es el comando que más fricción saca por minuto invertido. Si estás aprobando npm test por decimoquinta vez, ahí se arregla.

Un detalle práctico: se puede correr mientras Claude está trabajando, y el cambio aplica desde la siguiente herramienta que use, en el mismo turno. No hay que esperar a que termine.

Cuando algo sale mal

/rewind — volver atrás

Se abre con el comando o apretando Esc dos veces con el campo vacío. Muestra la lista de mensajes que enviaste, elegís un punto, y decidís qué restaurar:

• El código y la conversación
• Solo la conversación, dejando los archivos como están
• Solo el código, conservando lo que se habló
• Resumir desde acá o hasta acá, que es un /compact apuntado a una parte

Es lo que hay que usar cuando Claude tomó un camino equivocado y arrastró tres archivos con él.

Y acá van los límites, que importan más que la función. No revierte lo que haya hecho un comando de terminal: si Claude corrió rm, mv o cp, eso no se deshace. Tampoco revierte lo que hizo un subagente en segundo plano, ni los cambios que hiciste vos por fuera.

O sea: sirve para deshacer ediciones de archivos dentro de la sesión, y para nada más. No reemplaza a git. La red de verdad sigue siendo hacer commits seguido.

/doctor — revisar la instalación

Hace un chequeo del entorno y ofrece arreglar lo que encuentra: instalaciones duplicadas, problemas de PATH, archivos de configuración mal formados, versiones viejas.

Lo interesante es lo que revisa además de eso. Busca habilidades, servidores MCP y complementos que tenés instalados y no usás, y los compara con lo que te cuestan en contexto. También marca los ganchos que corren lento, y revisa tu CLAUDE.md: quita lo duplicado y recorta lo que Claude podría deducir leyendo el código.

Muestra los hallazgos primero y pide confirmación antes de tocar nada.

Cuando el trabajo no entra en un turno

Estos dos son los que menos se conocen y los que más cambian la forma de trabajar.

/goal — trabajar hasta que se cumpla una condición

Definís una condición de terminado y Claude sigue trabajando solo, turno tras turno, hasta cumplirla:

/goal todas las pruebas de test/auth pasan y el lint sale limpio

Al final de cada turno, un modelo distinto y más chico revisa si la condición se cumple. Si no, Claude arranca otro turno en vez de devolverte el control. La meta se borra sola cuando se cumple, cuando el evaluador la juzga imposible, o cuando falla algo que tenés que arreglar vos.

La parte que decide si funciona bien es cómo escribís la condición. El evaluador no ejecuta comandos ni lee archivos: solo juzga lo que Claude dejó a la vista en la conversación. Por eso “todas las pruebas pasan” funciona —Claude corre las pruebas y el resultado queda escrito— y “el código es prolijo” no.

Una condición que aguanta bien tiene tres partes: un estado final medible, cómo comprobarlo, y qué no se puede tocar en el camino. Y conviene ponerle un techo, algo como o pará después de 20 turnos.

/loop — repetir cada tanto

Repite una instrucción mientras la sesión siga abierta:

/loop 5m fijate si terminó el despliegue

Si no le ponés intervalo, Claude decide solo cada cuánto volver.

La diferencia con /goal es qué dispara el turno siguiente: en /loop es el reloj, en /goal es que la condición todavía no se cumplió. Para esperar algo externo —una compilación, un despliegue— va /loop. Para terminar un trabajo, /goal.

Y uno para saber cuánto llevás

/usage — cuánto gastaste y en qué

Muestra el consumo de la sesión y, si tenés plan, cuánto llevás usado del límite. Pero lo que más rinde es el desglose: atribuye el consumo reciente a las habilidades, los subagentes, los complementos y cada servidor MCP por separado, con su porcentaje.

Ahí es donde se descubre que un servidor MCP que instalaste hace un mes y no volviste a usar se está llevando una porción del total.

También marca comportamientos que pesan más del 10 %, como el contexto largo o los fallos de caché. Con d y w se cambia entre las últimas 24 horas y los últimos 7 días.

Las cifras salen del historial local de esa máquina, así que no incluyen lo que hiciste en otro equipo.

Por dónde empezar

Si vas a incorporar dos, que sean estos:

/context, una vez, para ver de dónde partís. Sin ese número, todo lo demás son suposiciones.

/clear entre tareas. Es gratis, es el más fácil de adoptar, y es el que más diferencia hace en una jornada larga.

El resto entra solo cuando aparece el problema que cada uno resuelve. Que es la razón por la que conviene haberlos leído antes: no para acordarse de la sintaxis, sino para acordarse de que existen.