La aceleración más rápida que obtuve en Claude Code este año no fue una mejora del modelo. Fue aprender a escribir una sola barra diagonal seguida de cuatro letras.
Llevaba usando Claude Code a diario durante más de un año antes de admitir algo vergonzoso: estaba dejando la mayor parte de su potencial sin aprovechar. Abría una sesión, escribía un párrafo entero de instrucciones, veía cómo trabajaba, me topaba con un muro y empezaba una sesión completamente nueva cerrando la terminal por completo. Cada. Vez. Estaba pagando por contexto que seguía tirando a la basura, re-explicando el mismo proyecto desde cero y quemando uso en conversaciones que se habían desviado tanto del tema que Claude básicamente estaba adivinando.
Entonces empecé a usar realmente los comandos slash. No de la forma en que la documentación los lista — alfabéticamente, de manera plana, como un glosario que nadie lee. Me refiero a los cuatro o cinco a los que ahora recurro tan reflexivamente que mis dedos se mueven antes de que mi cerebro termine el pensamiento. Los que deciden si una sesión de construcción de dos horas se siente como fluir o como luchar contra la herramienta.
Esta es la versión práctica de eso. Los comandos slash de Claude Code que genuinamente uso cada día, agrupados por el problema real que cada uno resuelve — contexto que se ha vuelto obsoleto, una compilación que salió mal, un plan que necesitaba ver antes de que se escribiera una sola línea de código. Para cada uno: qué hace, la forma exacta en que lo invoco y el momento específico en que recurro a él en trabajo real.
Un par de los "comandos" que circulan en tutoriales y videos resultaron ser jerga de la comunidad o características que funcionan un poco diferente a como la gente describe. Los marcaré honestamente a medida que avancemos, porque conocer la imagen precisa es todo el punto — un comando que crees que existe pero no existe es peor que ningún comando en absoluto.
Comencemos donde toda buena sesión comienza y termina: con el contexto.
¿Qué son los comandos slash en Claude Code?
Los comandos slash son atajos que activas escribiendo / en el prompt de Claude Code, lo que abre un menú de autocompletado de acciones que puedes ejecutar sin escribir instrucciones largas. Controlan la sesión en sí — limpiar contexto, rebobinar código, retomar conversaciones antiguas, configurar la interfaz — en lugar de ser prompts que envías al modelo.
Esa distinción importa más de lo que parece. Un mensaje normal le pide a Claude que haga algo en tu código base. Un comando slash le pide a Claude Code que haga algo con la sesión en la que estás trabajando. Uno edita archivos; el otro gestiona el entorno en el que esas ediciones ocurren.
El autocompletado aparece en el momento en que escribes / — en la terminal y en la aplicación de escritorio — así que no necesitas memorizar escrituras exactas. Escribe /re y verás /rewind y /resume aparecer juntos. Así es también como descubro comandos que había olvidado que existían, lo cual es la mitad de la razón por la que me molesto en escribir la barra diagonal en vez de buscar un atajo de teclado que medio recuerdo.
Aquí está lo que la mayoría de las hojas de referencia hacen mal: tratan los cuarenta y tantos comandos como igualmente dignos de aprender. No lo son. Uso quizás seis de ellos a diario y el resto casi nunca. Así que no voy a listar todo. Voy a guiarte por el puñado que se gana su lugar en la memoria muscular — y decirte cuáles tiene mal internet.
El primero es el comando que debería haber aprendido el primer día.
Gestión de contexto: /clear, /resume y /rewind
La mayor parte de la frustración que solía sentir en Claude Code se remontaba a una única causa raíz: era malo gestionando contexto. O tenía demasiado (una conversación inflada donde Claude seguía tropezando con instrucciones antiguas e irrelevantes) o había perdido el contexto que realmente quería (una sesión que cerré demasiado pronto y no podía recuperar). Tres comandos solucionaron casi todo.
/clear — el reinicio que evité durante demasiado tiempo
/clear borra el historial de conversación actual de la ventana de contexto y te deja empezar de nuevo — sin eliminar tu memoria de proyecto.
Esa segunda mitad es la parte que tuve mal durante meses, y vale la pena ser preciso porque cambia cuán agresivamente deberías usar el comando. Cuando ejecutas /clear, elimina todo de la ventana de contexto activa: el ir y venir, los archivos que Claude leyó, los callejones sin salida. Pero no toca tu archivo CLAUDE.md. CLAUDE.md se recarga fresco al inicio de cada sesión por diseño, así que sobrevive un /clear y se reinyecta. Tu briefing del proyecto permanece. Solo el equipaje conversacional desaparece.
Solía pensar que limpiar significaba "perder todo y re-explicar todo el proyecto." No es así — no si has puesto las cosas duraderas (arquitectura, convenciones, el esquema de base de datos) en CLAUDE.md donde pertenecen. Esa realización es lo que finalmente me hizo limpiar constantemente en vez de temerlo.
Ahora la regla que sigo: el momento en que termino una tarea lógica y paso a una no relacionada, limpio. ¿Terminé de configurar la autenticación, a punto de construir la página de facturación? /clear. Dos razones. Primero, una ventana de contexto obsoleta llena de detalles de autenticación hace que Claude sea peor en el trabajo de facturación — reconoce patrones en las cosas equivocadas, referencia archivos que no importan, y ocasionalmente edita "útilmente" algo que nunca le pedí que tocara. Segundo, cada token de ese contexto muerto es un token por el que pago y un token que consume mis límites de uso. Una sesión larga y errante es cara en ambos sentidos.
Si solo adoptas un comando de todo este post, que sea este. Limpia entre tareas. Tu calidad de producción sube y tu consumo baja al mismo tiempo, lo cual casi nunca ocurre junto.
Hay un comando relacionado que vale la pena conocer: /compact. Donde /clear descarta la conversación por completo, /compact la resume en una forma comprimida para que conserves la esencia mientras liberas contexto. Recurro a /compact a mitad de tarea cuando un trabajo individual se ha alargado pero todavía necesito su historial; recurro a /clear cuando genuinamente he terminado y cambio de marcha. Diferentes herramientas para diferentes momentos.
/resume — recuperar una conversación que creías perdida
/resume te permite reabrir una conversación anterior de Claude Code seleccionándola de una lista, así que una sesión que cerraste — o incluso limpiaste — no está necesariamente perdida.
Este es el comando que me ahorró un disgusto real. Imagina el escenario: limpio una sesión, cambio de tarea, y veinte minutos después me doy cuenta de que necesitaba algo de la conversación que acabo de borrar — una decisión que tomamos, un fragmento de código que Claude generó, el razonamiento detrás de un enfoque. Antes de /resume, eso se había ido y lo sentía.
Con /resume, ejecuto el comando, obtengo una lista de sesiones recientes, y elijo la que quiero recuperar. Es distinto de rebobinar dentro de una conversación activa — /resume llega a través de sesiones para recuperar una anterior por completo. Piensa en ello como la diferencia entre deshacer tus últimas ediciones en un documento versus reabrir un archivo que cerraste ayer.
El flujo de trabajo que he desarrollado: limpio agresivamente porque sé que /resume me respalda. El miedo a perder contexto era lo que me hacía acumularlo. Una vez que confié en que podía recuperar una sesión antigua cuando genuinamente la necesitaba, limpiar dejó de sentirse arriesgado y empezó a sentirse como higiene.
/rewind — deshacer para código, no solo para conversaciones
/rewind rebobina tu sesión a un punto de control anterior, y puede restaurar tu código, tu conversación, o ambos — de forma independiente.
Este es el comando que cambió cuán ambiciosamente dejo trabajar a Claude. Claude Code crea automáticamente un punto de control capturando el estado de tu código antes de cada edición, cada vez que envías un prompt. Así que cuando un cambio en múltiples archivos sale mal — y en una refactorización grande, a veces pasa — no entro en pánico y empiezo a revertir archivos manualmente. Abro /rewind.
Puedes activarlo de dos formas: escribe /rewind, o presiona Esc dos veces cuando el campo de entrada del prompt está vacío. Ambos abren el menú de rebobinado mostrando tus puntos de control recientes. Luego eliges qué restaurar:
- Restaurar código y conversación — revierte ambos a ese punto, como si los últimos minutos nunca hubieran ocurrido.
- Restaurar conversación — rebobina el chat a un mensaje anterior pero mantén tu código actual. Útil cuando el código está bien pero la conversación tomó un camino confuso.
- Restaurar código — revierte los cambios de archivos pero sigue hablando. Este es el que más uso: "ese enfoque estaba mal, deshaz los archivos, pero sigamos discutiendo por qué."
También hay opciones de "resumir desde aquí" / "resumir hasta aquí" que comprimen parte de la conversación para recuperar contexto — una bonita superposición con la idea de /compact.
Una limitación que absolutamente necesitas conocer, porque ha quemado a gente: /rewind solo rastrea ediciones que Claude hizo a través de sus herramientas de edición de archivos. Los comandos Bash no tienen punto de control. Si Claude ejecutó rm, mv o cp, esos cambios son permanentes — rebobinar no los traerá de vuelta. Los puntos de control también persisten entre sesiones y se limpian automáticamente después de 30 días. Así que rebobinar es una red de seguridad para ediciones, no un sustituto de git. Sigo haciendo commits frecuentemente. Rebobinar es para los momentos intermedios; git es para la verdad fundamental.
Si quieres profundizar en cómo estructuro el uso de tokens alrededor de toda esta limpieza y compactación, lo desglosé por separado en mi guía para reducir los costos de tokens de Claude Code con el enfoque cavernícola — la disciplina de contexto y la disciplina de costos son la misma habilidad con dos sombreros.
Eso cubre el contexto. El siguiente grupo trata sobre calidad — hacer que Claude piense antes de actuar.
Planificación y calidad: modo plan y clarificar-luego-planificar
El mayor salto en mi calidad de producción no vino de un comando de contexto. Vino de forzar a Claude a planificar antes de escribir una sola línea. Hay dos formas en que hago esto — una incorporada, una que construyo yo mismo — y la segunda es la pieza central de todo este post.
Modo plan — ver el enfoque antes de que se escriba código
El modo plan es un estado de solo lectura donde Claude analiza tu código base y propone un plan de implementación completo antes de tocar cualquier archivo, para que puedas revisar y ajustar el enfoque antes de que comience la ejecución.
Nota rápida de precisión, porque esto confunde a la gente: muchos videos y transcripciones llaman a esto "el comando /plan," y eso es solo medio correcto. El modo plan ha estado integrado en el ciclo de permisos de Claude Code durante mucho tiempo — lo activas presionando Shift+Tab dos veces para aterrizar en ⏸ modo plan activado en la parte inferior de tu terminal. A partir de Claude Code v2.1.0, también hay un comando literal /plan que activa el mismo modo, además puedes iniciar con claude --permission-mode plan o hacerlo un valor predeterminado del proyecto en .claude/settings.json. Así que si escuchaste "/plan" y no parecía hacer nada en una versión anterior — por eso es. La ruta de Shift+Tab siempre funciona.
Aquí está lo que el modo plan realmente hace. Mientras está activo, Claude mantiene acceso completo a sus herramientas de lectura — Read, Glob, Grep, WebSearch, WebFetch — pero cada herramienta de escritura está bloqueada: sin Edit, sin Write, sin ejecución de Bash. Lee tu código base, mapea dependencias, razona a través de todo el enfoque, y te entrega un plan numerado. Lo lees. Lo corriges si está mal. Luego lo apruebas, y solo entonces ejecuta.
El momento en que recurro al modo plan: cualquier tarea que toque más de dos o tres archivos, o cualquier cosa donde no estoy 100% seguro de que Claude y yo compartimos el mismo modelo mental de cómo debería ocurrir el cambio. Una migración de base de datos. Una refactorización a través de componentes. Conectar una nueva API a un flujo existente. Para esos casos, ver el plan de Claude captura el malentendido antes de que se convierta en treinta minutos de código incorrecto que luego tengo que rebobinar.
El error que veo cometer a la gente es usar modo plan para todo, incluyendo ediciones triviales de un solo archivo, donde solo añade fricción. El modo plan se gana su lugar en la ambigüedad y la escala. Para "añade un console.log aquí," sáltalo.
El modo plan es poderoso, pero es reactivo — Claude planifica basándose en lo que le dije. La siguiente técnica soluciona el problema más profundo: qué pasa cuando mi prompt en sí estaba incompleto.
Comandos slash personalizados — construir un comando "clarificar, luego planificar, luego ejecutar"
Esta es la sección que te diría que leyeras dos veces. Los comandos slash personalizados son la característica de mayor apalancamiento en Claude Code que la mayoría de la gente nunca toca, y son genuinamente simples de construir.
Un comando slash personalizado es simplemente un archivo Markdown. Creas un archivo en .claude/commands/ (de ámbito de proyecto, compartido con todos en el repositorio) o ~/.claude/commands/ (personal, te sigue en cada proyecto). El nombre del archivo se convierte en el nombre del comando. El contenido del archivo se convierte en el prompt que se envía a Claude cuando lo invocas. Ese es el mecanismo completo.
Así que si ejecuto esto:
mkdir -p .claude/commands
y creo un archivo llamado .claude/commands/build.md, entonces escribir /build en cualquier sesión dentro de ese proyecto inyecta lo que escribí en ese archivo como mi prompt. El comando aparece automáticamente en el menú de autocompletado /.
Ahora — ¿por qué importa esto? Porque el mayor asesino de calidad en la codificación con IA no es el modelo. Es la brecha entre lo que pedí y lo que realmente quise decir. Escribo un prompt vago, Claude hace suposiciones razonables-pero-incorrectas para llenar la brecha, y obtengo código confiado y limpio que resuelve el problema equivocado.
La solución es un comando que fuerza a Claude a cerrar esa brecha antes de que escriba algo. Aquí está el comando real que mantengo en mis repositorios. Llámalo .claude/commands/scope.md:
# Clarifica la solicitud, luego planifica, luego construye.
Estás a punto de implementar: $ARGUMENTS
NO escribas código todavía. Trabaja estos pasos en orden:
1. CLARIFICA. Hazme hasta 5 preguntas específicas sobre cualquier cosa
ambigua en la solicitud — formas de datos, casos límite, nomenclatura,
dónde encaja esto en la arquitectura existente, cómo se ve "terminado".
Si algo es genuinamente inequívoco, no rellenes la lista — pregunta
solo lo que necesites.
2. PLANIFICA. Una vez que responda, reformula la tarea en una oración, luego
dame un plan de implementación numerado: los archivos que crearás o
cambiarás, el orden en que los harás, y cualquier decisión que estés
tomando que debería vetar ahora en lugar de después de que exista el código.
3. ESPERA. Detente y déjame aprobar o corregir el plan antes de que
toques un solo archivo.
Solo después de que apruebe empiezas a implementar.
El marcador de posición $ARGUMENTS es el truco real — lo que sea que escriba después del nombre del comando se inserta ahí. Así ejecuto /scope añadir invitaciones de equipo a la página de configuración y Claude toma "añadir invitaciones de equipo a la página de configuración" como lo que debe clarificar y planificar.
¿Qué me aporta esto en la práctica? Las preguntas de clarificación son donde está la magia. La mitad del tiempo, las preguntas de Claude sacan a la superficie algo que yo no había decidido aún — "¿los usuarios invitados deberían obtener un rol inmediatamente o quedar pendientes hasta que acepten?" — y responderlo en voz alta, antes de que exista código significa que nunca obtengo la implementación incorrecta en primer lugar. El paso del plan me deja entonces vetar un enfoque de forma barata, mientras aún son palabras en una pantalla en lugar de archivos en disco.
No puedo darte un porcentaje limpio de cuánto mejora esto la producción — y quiero ser honesto sobre eso, porque he visto circular la afirmación de que los comandos personalizados de clarificar-luego-planificar mejoran la calidad "hasta un 43% basado en informes internos," y nunca pude encontrar una base real para ese número. Así que no voy a fingir. Lo que puedo decirte del uso diario es cualitativo y consistente: forzar la secuencia de clarificar-luego-planificar-luego-ejecutar reduce significativamente el número de reescrituras de "eso no es lo que quise decir" que hago. El retrabajo que ahorro es todo el retorno de la inversión. Que el número no sea verificable no hace que la técnica sea menos real — solo significa que no la voy a adornar con una estadística que no puedo respaldar.
Si quieres profundizar más en la construcción de estos, escribí un desglose completo del comando slash personalizado /advisor y la capa metacognitiva que añade — los mismos bloques de construcción, diferente propósito. Y la razón por la que todo este enfoque funciona se conecta directamente con por qué la ingeniería de contexto se está convirtiendo en una habilidad fundamental a prueba de futuro: los desarrolladores que ganan con estas herramientas no son los que teclean más rápido, son los que estructuran mejor el contexto y la intención.
Si prefieres que alguien construya una configuración completa de comandos personalizados y agentes ajustada a tu stack en vez de ensamblarla tú mismo, ese es el tipo de trabajo que acepto directamente — puedes ver lo que he construido en mi perfil de Fiverr.
Una breve palabra sobre un comando sobre el que la gente pregunta pero que no existe como creen.
Sobre "/goal" — un patrón que construyes, no un botón que presionas
Me preguntan sobre un comando "/goal" que supuestamente te permite establecer una tarea más una definición de "terminado" y hacer que Claude siga trabajando hasta que un segundo agente verifique que está completo. Investigué esto cuidadosamente, y aquí está la imagen honesta: no hay un comando slash /goal integrado en Claude Code que haga esto. No pude confirmarlo en la documentación actual, y no deberías buscarlo como una característica estándar.
Lo que es real es el patrón detrás — y es un buen patrón. Absolutamente puedes construir tú mismo un flujo de trabajo impulsado por verificación: un comando personalizado que le da a Claude una tarea más criterios explícitos de "definición de terminado", emparejado con un subagente cuyo único trabajo es verificar el trabajo contra esos criterios antes de declararlo terminado. Eso es algo construible, no algo integrado. (El Codex de OpenAI, por separado, incluye un comando literal /goal para ejecuciones autónomas — lo probé y escribí cómo se comporta realmente el comando /goal de Codex. No confundas los dos; son herramientas diferentes.)
La conclusión: si un tutorial te promete un botón mágico /goal de Claude Code, sé escéptico. La capacidad es tuya para ensamblar con comandos personalizados y subagentes — lo cual es más flexible de todos modos.
Ahora las cosas pequeñas que mejoran silenciosamente cada sesión.
Entorno y UX: /statusline y conocer la herramienta
Estos no cambian qué hace Claude. Cambian cuánto puedo ver mientras lo hace — y qué rápido descubro funcionalidades que no sabía que existían.
/statusline — una configuración única que rinde en cada sesión
/statusline configura la barra de estado en la parte inferior de tu terminal, permitiéndote mostrar cosas como el modelo activo, el uso de contexto y el costo — para que puedas ver de un vistazo qué está pasando sin adivinar.
Otra nota de precisión: la gente lo escribe como "/status line" (dos palabras). El comando real es /statusline, una palabra, en el autocompletado. Lo ejecutas una vez, configuras lo que quieres ver, y luego simplemente está ahí cada sesión.
Por qué me molesto: visibilidad del uso de contexto y costos. Cuando mi barra de estado me muestra cuán llena se está poniendo la ventana de contexto, sé que es hora de /clear o /compact antes de que Claude empiece a degradarse — en vez de notar la degradación después del hecho. Ver el modelo activo me recuerda si estoy en el nivel correcto para la tarea. Es una pequeña configuración única que convierte un montón de estado invisible en algo que puedes leer de un vistazo. Para la filosofía más profunda de "ver y dirigir todo lo que Claude hace," profundicé en mi desglose de la capa visual del OS agéntico.
/powerup y /radio — los dos que mencionaré pero no sobrevendré
Dos comandos más reales, incluidos por completitud y honestidad.
/powerup (introducido en Claude Code v2.1.90) es un tutorial interactivo dentro de la terminal — lecciones animadas que cada una enseña algo que Claude Code puede hacer y que la mayoría de la gente se pierde. Es genuinamente útil para descubrir funcionalidades, y le di su propio primer vistazo completo en mi artículo sobre lo que /powerup realmente enseña, así que no repetiré eso aquí.
/radio también es real, y es exactamente lo que suena: abre Claude FM, una estación de radio lo-fi que Anthropic opera, en tu navegador. ¿Es un comando de productividad? No. ¿Lo uso durante las partes aburridas de una compilación? A veces. Lo incluyo porque te dije que te daría la imagen precisa, y la imagen precisa es que existe y es un pequeño nada divertido. Trátalo en consecuencia.
También está /btw — una forma más ligera de hacer una pregunta lateral o añadir contexto sin que inflé tu hilo de conversación principal, lo que mantiene las sesiones largas más esbeltas. Es un mecanismo real que vale la pena conocer si quieres aclararte a mitad de tarea sin descarrilar el flujo.
Ese es el registro honesto. Ahora déjame mostrarte cómo se ve esto cuando se encadena en trabajo real.
Cómo se ve una sesión real con estos comandos encadenados
Los comandos en una lista son abstractos. Así es como realmente se encadenan en un día normal de construcción para mí.
Abro Claude Code en un proyecto. CLAUDE.md carga automáticamente, así que Claude ya conoce el stack y las convenciones — no re-explico nada. Quiero añadir una funcionalidad, así que escribo /scope añadir exportación CSV a la página de reportes. Mi comando personalizado entra en acción: Claude me hace cuatro preguntas (qué columnas, qué formato de fecha, generación del lado del servidor o del cliente, cómo debería ser el nombre del archivo), respondo, me da un plan de cinco pasos, ajusto el paso tres, apruebo.
Construye. A mitad de camino, la lógica de exportación se enreda con la paginación existente y la salida no es correcta. No lo desenredo manualmente — abro /rewind, restauro el código a antes del enredo manteniendo la conversación, y digo "ese enfoque entró en conflicto con la paginación, generemos el conjunto de datos completo por separado." Recuperación limpia, quizás noventa segundos perdidos.
Funcionalidad terminada. /clear. Ventana fresca, memoria del proyecto intacta, cero contexto obsoleto filtrándose a la siguiente tarea. Mi barra de estado — configurada una vez con /statusline hace semanas — muestra que apenas estoy usando contexto, que es exactamente como debería empezar una tarea fresca.
Tres tareas después me doy cuenta de que necesito una decisión de una sesión que limpié antes. /resume, la elijo de la lista, tomo lo que necesitaba, vuelvo al trabajo.
Cinco comandos. Ninguno escribió código. Todos moldearon las condiciones bajo las cuales el código se escribió bien. Ese es todo el punto — los comandos slash no son el trabajo, son el taller.
La parte honesta: dónde me equivoqué, y qué vale tu tiempo
Déjame ser directo sobre las correcciones, porque ver a un practicante retractarse de sus propias suposiciones es más útil que una lista limpia que finge que todo está confirmado.
Pasé demasiado tiempo tratando /clear como una pérdida en vez de como higiene — eso fue un impuesto real al flujo de trabajo que pagué durante meses. "/plan" como comando independiente es más nuevo (v2.1.0) que el modo plan de Shift+Tab sobre el que está construido, así que si estás en una versión anterior, usa el atajo de teclado. "/statusline" es una palabra, no dos. Y el "comando /goal" que la gente describe como integrado en Claude Code no lo es — es un patrón que ensamblas, y confundirlo con el comando /goal real de Codex enturbia las aguas. El número de "43% de mejora de calidad" atribuido a comandos personalizados no tiene base que pudiera encontrar, así que lo dejé caer y te dije por qué en vez de lavar un número no verificable en una afirmación confiada.
Lo que genuinamente vale tu tiempo, en orden de prioridad: /clear entre tareas (mayor y más fácil ganancia), un comando personalizado de clarificar-luego-planificar (mayor ganancia de calidad), /rewind para recuperarse de malas ediciones (mayor reducción de estrés), y modo plan para cualquier cosa ambigua o que involucre múltiples archivos (mayor prevención de "código incorrecto"). El resto — /resume, /statusline, /compact, /btw — son reales, útiles y dignos de conocer, pero son el reparto secundario.
Si tus sesiones de Claude Code actualmente se sienten como conversaciones largas y errantes que empeoran cuanto más duran, la solución no es un mejor modelo. Es una barra diagonal, cuatro letras, y la disciplina de limpiar lo que no necesitas. Ve a construir un comando personalizado esta semana — el ejemplo /scope de arriba, copiado directamente en .claude/commands/scope.md — y úsalo en tu próxima tarea real. La primera vez que las preguntas de clarificación de Claude atrapen una suposición incorrecta antes de que se convierta en código incorrecto, entenderás por qué escribo esa barra diagonal antes de que mi cerebro termine el pensamiento.
Preguntas frecuentes
¿Cuál es la diferencia entre /clear y /rewind en Claude Code?
/clear borra tu historial de conversación actual para empezar una tarea fresca manteniendo tu memoria de proyecto CLAUDE.md, mientras que /rewind rebobina a un punto de control anterior dentro de una sesión activa y puede restaurar tu código, conversación o ambos. Usa /clear cuando cambias a una tarea no relacionada; usa /rewind cuando una edición salió mal y necesitas deshacerla. Consulta la sección de gestión de contexto arriba para el desglose completo.
¿/clear elimina mi memoria de proyecto CLAUDE.md?
No — /clear solo elimina la conversación activa de la ventana de contexto; tu archivo CLAUDE.md se recarga fresco al inicio de cada sesión, así que sobrevive a la limpieza. Es exactamente por eso que puedes limpiar agresivamente entre tareas sin perder el contexto duradero de tu proyecto, siempre que lo importante viva en CLAUDE.md.
¿Cómo creo un comando slash personalizado en Claude Code?
Crea un archivo Markdown en .claude/commands/ (de ámbito de proyecto) o ~/.claude/commands/ (personal), y el nombre del archivo se convierte en el nombre del comando mientras el contenido del archivo se convierte en el prompt enviado a Claude. Usa el marcador $ARGUMENTS para pasar entrada después del nombre del comando. El ejemplo completo de /scope clarificar-luego-planificar está en la sección de planificación arriba.
¿Hay un comando /plan o es modo plan en Claude Code?
Ambos — el modo plan ha estado integrado en el ciclo de permisos durante mucho tiempo (presiona Shift+Tab dos veces), y a partir de Claude Code v2.1.0 también hay un comando literal /plan que activa el mismo estado de planificación de solo lectura. Si /plan no hace nada en tu configuración, probablemente estés en una versión anterior; el atajo Shift+Tab siempre funciona.
¿Hay un comando /goal integrado en Claude Code?
No, no hay un comando /goal estándar en Claude Code que ejecute una tarea hasta una definición de "terminado" con verificación automática. Esa capacidad es un patrón que construyes tú mismo usando un comando personalizado más un subagente de verificación. El Codex de OpenAI incluye un comando /goal separado, pero esa es una herramienta completamente diferente.
Trabajemos juntos
¿Buscas construir sistemas de IA, automatizar flujos de trabajo o escalar tu infraestructura tecnológica? Me encantaría ayudar.
- Fiverr (construcciones personalizadas e integraciones): fiverr.com/s/EgxYmWD
- Portfolio: mejba.me
- Ramlit Limited (soluciones empresariales): ramlit.com
- ColorPark (diseño y marca): colorpark.io
- xCyberSecurity (servicios de seguridad): xcybersecurity.io
