Comandos Slash de Claude Code: crea comandos personalizados de la A a la Z (2026)

- Esta guía sigue la documentación oficial en code.claude.com/docs/skills (consultada el 20/08/2026) - la antigua página slash-commands ahora redirige aquí, y la lista de comandos integrados se movió a code.claude.com/docs/commands («Commands», con «Slash» eliminado). La documentación de Claude Code cambia rápido, así que algunos campos requieren una build reciente (Claude Code v2.1.x o posterior).

¿Qué es un comando slash en Claude Code? (integrado vs. personalizado)

En Claude Code, un comando slash es cualquier comando que empieza con / y que escribes directamente dentro de una sesión de chat para disparar algo rápido. El glosario oficial de Anthropic ahora lo llama «Command» (quitando «Slash» del texto del producto); esta guía mantiene el término buscado «comando slash» en el título y el texto, porque así es como la gente sigue buscándolo. Hay dos tipos, y es fácil confundirlos.

Los comandos integrados vienen con Claude Code de parte de Anthropic - no hay nada que instalar. Algunos que usarás casi todos los días:

• /help - lista todos los comandos disponibles
• /clear - borra el historial de la conversación y empieza con un contexto limpio
• /compact - comprime la conversación para ahorrar contexto
• /init - genera un archivo CLAUDE.md para el proyecto
• /model - cambia el modelo que estás usando
• /status - revisa el estado de la sesión, la cuenta y el contexto

Los comandos personalizados son los que tú misma creas para empaquetar un prompt que usas mucho en una sola pulsación. En pocas palabras: un comando slash personalizado es un archivo Markdown en .claude/commands/ - el nombre del archivo es el nombre del comando, y el cuerpo del archivo es el prompt que Claude ejecuta cuando lo llamas. En vez de volver a pegar «revisa el diff actual según esta checklist...» cada vez, lo guardas una sola vez y escribes /review.

Y aquí está lo bueno: los comandos personalizados viven en el mismo menú que los integrados. Escribe / y el menú aparece sugiriendo tanto los comandos integrados como los tuyos. Si haces commit de la carpeta .claude/commands/ en tu repositorio, todo el equipo comparte un único conjunto de comandos - y por eso mismo los comandos personalizados les ganan a los «prompts de copiar y pegar» por goleada.

Entonces, ¿por qué no pegar el prompt cada vez? Tres razones prácticas. Un prompt que usas mucho suele ser largo, y se te escapará una línea si lo escribes de memoria. Cada quien en el equipo lo escribe un poco distinto, así que los resultados salen desparejos. Y cuando mejoras el prompt, no hay forma de llevar esa mejora al resto del grupo. Convertirlo en un archivo de comando arregla las tres: el prompt vive en un solo lugar, todos llaman al mismo comando, y editar el archivo lo actualiza para todos. Dicho de otro modo, un comando personalizado convierte un «truco personal» en una «herramienta compartida» que puedes versionar como código.

Crea tu primer comando slash personalizado (.claude/commands)

Vamos a construir un comando /review que hace que Claude revise los cambios de tu código. Tres pasos, cada uno listo para copiar y pegar.

Paso 1 - Crea la carpeta de comandos en la raíz de tu proyecto:

mkdir -p .claude/commands

Windows PowerShell no tiene mkdir -p, así que usa:

New-Item -ItemType Directory -Force .claude/commands

Paso 2 - Crea review.md dentro de esa carpeta. El nombre del archivo (menos el .md) es el nombre del comando. El cuerpo del archivo es el prompt:

You are a strict reviewer. Review the current code changes.

Focus on:
- Logic bugs and unhandled edge cases
- Security holes (unvalidated input, leaked secrets)
- Naming, clarity, and duplicated code

For each issue: give the file + line, the severity,
and a concrete fix. No vague praise.

Paso 3 - Ejecuta el comando en tu sesión de Claude Code:

/review

Claude carga el contenido del archivo como prompt y lo ejecuta al instante. Listo. Acabas de construir tu primer comando personalizado sin escribir una sola línea de código.

Consejo: si acabas de crear el archivo pero el menú / aún no muestra el comando, salta a la sección «Problemas comunes» cerca del final - normalmente es solo la carpeta equivocada o una sesión que hay que reiniciar.

Pasar argumentos a un comando ($ARGUMENTS, $1, argumentos con nombre)

Un comando rígido no se reutiliza mucho. El poder de verdad viene de los argumentos - el texto que escribes después del nombre del comando se inyecta en el prompt.

Agarra todo - $ARGUMENTS. Esta variable captura todo el texto después del nombre del comando. Crea .claude/commands/fix-issue.md:

Fix GitHub issue #$ARGUMENTS. Read the issue description,
find the root cause in the code, then write a fix with tests.

Escribe /fix-issue 123 y $ARGUMENTS se convierte en 123. Escribe /fix-issue 123 security first y $ARGUMENTS se convierte en la cadena completa 123 security first.

Argumentos posicionales - $1, $2... Cuando necesitas cada argumento por separado, usa variables posicionales. Por ejemplo, .claude/commands/rename.md:

Rename the variable `$1` to `$2` across every open file,
keeping the logic intact and updating all references.

Escribe /rename oldName newName y $1 es oldName, $2 es newName. Para argumentos de varias palabras, enciérralos entre comillas: /rename "user id" "customer id".

Argumentos con nombre - el frontmatter arguments. Si quieres nombres con significado en vez de $1/$2, decláralos en el frontmatter (mira la siguiente sección) y refiérete a ellos por nombre. Declara arguments: [from, to] y podrás usar $from y $to - mapeados en el orden de los argumentos.

Referencia rápida de las variables de sustitución:

Nota: la página actual de Skills también lista una forma indexada en 0, $ARGUMENTS[N]/$N ($0 es el primer argumento), junto a la forma indexada en 1, $1/$2, de arriba - ambas aparecen en la documentación a día de hoy, así que revisa la documentación en vivo antes de depender de un índice concreto.

¿Cuál deberías usar? Regla simple. Si el comando solo recibe «un bloque de texto libre» (la descripción de una issue, una pregunta, un fragmento para explicar), $ARGUMENTS basta y es lo más flexible. Si el comando necesita un número exacto de argumentos en un orden fijo (rename: de qué -> a qué), el posicional $1/$2 es más claro. Los argumentos con nombre solo valen la pena cuando un comando tiene varios argumentos fáciles de confundir - ahí $from/$to se lee mejor que $1/$2.

Todos los detalles sobre $ARGUMENTS y los argumentos posicionales están en la documentación de Claude Code (consultada el 20/08/2026) (ahora integrada en la página de Skills - ya no hay una página separada de slash-commands). Para echar un vistazo rápido a toda la sintaxis de comandos, yo tengo a mano la hoja de referencia de Claude Code.

Frontmatter: configura un comando con YAML

Al principio de un archivo de comando, puedes añadir un bloque de frontmatter en YAML (entre dos líneas ---) para configurar el comportamiento. Esta es la parte que la mayoría de las guías se salta por completo, aunque es la que decide de verdad qué tan seguro y cómodo es el comando.

Todo es opcional; en la práctica, solo description vale la pena añadirlo siempre. Aquí tienes un .claude/commands/commit.md que deja que el comando toque solo git y nada más:

---
description: Create a conventional commit from staged changes
argument-hint: [optional scope]
allowed-tools: Bash(git add:*), Bash(git commit:*), Bash(git diff:*)
---

Look at the staged changes and write one tight, accurate
conventional commit (feat/fix/docs/refactor...).
If nothing is staged, tell me to `git add` first.

Con allowed-tools bien configurado, el comando solo puede ejecutar unos pocos comandos git predefinidos - mucho más seguro que dejar a Claude libre para ejecutar lo que quiera. Es un hábito que vale la pena adoptar en cualquier comando que toque el shell.

Inyectar datos en vivo con !`bash` (y referencias a archivos)

Un comando se vuelve mucho más potente cuando él mismo puede tomar el contexto actual en vez de obligarte a pegarlo. Claude Code te deja inyectar la salida de un comando bash directamente en el prompt con la sintaxis !`<command>`.

Lo clave que hay que entender: el comando dentro de !`...` se ejecuta ANTES de que Claude lea el prompt, y su salida se incrusta directo en el contenido. Esto no es Claude decidiendo ejecutar un comando - ya se ejecutó. Aquí tienes un comando /review que toma el diff actual por sí solo:

Review the diff below and point out bugs + security risks:

!`git diff HEAD`

Cuando escribes /review, Claude Code ejecuta git diff HEAD, toma el resultado, lo pega en su lugar y solo entonces le entrega el prompt completo a Claude. Nunca más copias el diff a mano.

Para un bloque bash de varias líneas, usa un bloque cercado que abre con !:

```!
git status --short
git log --oneline -5
```

Nota: mantén !`...` al inicio de una línea o después de un espacio. Si quieres un $ literal (digamos, un precio como \$1.00 en tu texto), escápalo con una \ para que no se lea como argumento.

Compartir comandos: Proyecto vs. Personal + subcarpetas

Los comandos personalizados viven en dos lugares que difieren por su alcance:

• Proyecto - .claude/commands/ en la raíz del repositorio. Haz commit en git y todo el equipo comparte el conjunto. Ideal para comandos específicos del proyecto: /deploy, /test, las convenciones de commit de tu equipo.
• Personal - ~/.claude/commands/ en tu directorio home. Solo tu máquina, pero utilizable en todos los proyectos. Ideal para hábitos personales: /explain, /tldr.

Cuando los nombres chocan, el comando de nivel de proyecto suele ganar, porque está más cerca del contexto del proyecto.

Subcarpetas para agrupar comandos (namespacing). A medida que tu conjunto de comandos crece, crea subcarpetas para agruparlos. Por ejemplo, .claude/commands/git/commit.md muestra el comando bajo un grupo git, manteniendo el menú / ordenado y fácil de buscar.

Este mecanismo de «configura por repositorio, haz commit para compartir con el equipo» es exactamente el espíritu del archivo CLAUDE.md. Si eso es nuevo para ti, lee cómo escribir un CLAUDE.md para tu repositorio para que los dos se complementen: el CLAUDE.md declara las convenciones compartidas, y .claude/commands/ empaqueta las acciones repetitivas.

5 plantillas de comando para copiar y pegar (listas para ejecutar)

Aquí está el conjunto que yo misma uso en el día a día. Cópialas en .claude/commands/ y ajústalas a tu stack.

1. /review - revisa el diff actual (review.md):

---
description: Review current changes for bugs and security risks
---

Review the diff below, prioritizing logic bugs and security holes:

!`git diff HEAD`

For each issue: give file:line, severity, and a concrete fix.

2. /commit - commit convencional (commit.md):

---
description: Write a conventional commit from staged changes
allowed-tools: Bash(git add:*), Bash(git commit:*), Bash(git diff:*)
---

Look at `git diff --staged` and write one accurate
conventional commit. Do not add AI references to the message.

3. /test - ejecuta los tests y arregla los fallos (test.md):

---
description: Run the test suite and fix failing tests
argument-hint: [optional test file path]
---

Run the tests for $ARGUMENTS (run everything if empty).
If any test fails: read the error, find the root cause, fix
the code or the test, then rerun until green.

4. /docs - escribe docstrings (docs.md):

---
description: Write docstrings for the open file
---

Write docstrings for the functions/classes in the open file.
Follow the language's convention, list parameters, return
values, and errors that can be thrown. Keep it short, don't
repeat the function name.

5. /fix-issue - arregla una issue por número (fix-issue.md):

---
description: Fix a GitHub issue by number
argument-hint: <issue-number>
---

Fix issue #$ARGUMENTS: read the description, find the root
cause, write a fix with tests, briefly explain the fix.

[Nuevo en 2026] Los comandos personalizados se fusionan con las Skills - y «Slash Command» ahora es solo «Command»

Este es el gran cambio que la mayoría de las guías actuales aún no ha alcanzado. Según la documentación oficial de las Claude Code Skills (consultada el 20/08/2026), los comandos personalizados se han fusionado en las Skills. La tabla de «Términos obsoletos y renombrados» del glosario oficial lo deja claro: «Slash commands → Commands» (quitando «Slash» del texto del producto) y «Custom commands → Skills», y afirma sin rodeos que «las Skills son la sucesora recomendada de los comandos personalizados» - aunque tus viejos archivos de .claude/commands/ siguen funcionando bien.

En concreto: un archivo .claude/commands/deploy.md y una skill .claude/skills/deploy/SKILL.md crean ambos el comando /deploy, usando el mismo mecanismo de frontmatter. Lo que te importa: tus viejos archivos .claude/commands/*.md siguen funcionando bien - no hay nada que migrar con prisas.

Entonces, ¿cuándo deberías dar el salto a una Skill? Una Skill se diferencia de un comando en dos cosas: (1) es una carpeta, así que puede guardar archivos de apoyo (scripts, plantillas, docs de referencia) junto al prompt; y (2) Claude puede cargarla automáticamente cuando es relevante para la tarea que tienes entre manos, sin que escribas un comando. En resumen: los comandos son mejores para acciones únicas e invocadas a mano; las skills son mejores para capacidades complejas, de varios archivos, que quieres que se disparen solas.

Para profundizar, lee qué son las Skills en Claude Code y luego cómo crear una skill personalizada. Si los conceptos aún se te mezclan, el artículo sobre skills vs subagents vs hooks vs MCP te los desenreda.

Problemas comunes & consejos

• El comando no aparece en el menú /. Comprueba que estás en la carpeta correcta - .claude/commands/ (en plural, con punto delante) - y que el archivo tiene la extensión .md. La primera vez que crees una subcarpeta, reinicia la sesión de Claude Code para que vuelva a escanear.
• Los argumentos no se expanden. Si tu prompt tiene $2 pero solo pasas un argumento, $2 se queda como texto literal. Usa $ARGUMENTS cuando el número de argumentos no es fijo.
• Un $ se lee mal, como una variable. Escribe \$1.00 (con una \) cuando quieras un signo de dólar literal en texto normal.
• Cuándo NO hacer un comando. Si es algo puntual, o es distinto cada vez, escribir el prompt directamente es más rápido. Un comando solo se gana su lugar cuando la acción es repetida y estable. No empaquetes todo en comandos - un conjunto inflado y poco usado solo abarrota el menú /.

¿No quieres escribir el tuyo? Usa un conjunto de comandos ya hecho

Escribir los comandos tú misma es la mejor forma de entender la mecánica y mantener el control - yo le recomendaría a cualquiera construir al menos los primeros a mano. Pero si prefieres tener un conjunto de comandos y skills ya diseñados y probados para flujos de trabajo comunes, echa un vistazo al conjunto ya hecho de comandos y skills de AgentKit: según su página de inicio, reúne más de 108 skills y 45 agentes de IA para Claude Code, divididos en un Engineer Kit y un Marketing Kit. Aun así puedes personalizarlo todo como en cualquier archivo .claude/commands/ normal - solo que no empiezas de cero. Para verlo directamente, puedes probar AgentKit aquí (20% de descuento por el enlace); el sitio indica una garantía de devolución del dinero (sin condiciones específicas señaladas) y actualizaciones de por vida para los kits.

Preguntas frecuentes (FAQ)

¿Dónde se guardan los comandos slash personalizados?

En .claude/commands/ en la raíz de tu proyecto (compartido con el equipo cuando haces commit en git), o en ~/.claude/commands/ en tu directorio home (solo tu máquina, pero utilizable en todos los proyectos). El nombre del archivo menos la extensión .md es el nombre del comando.

¿Cómo paso varios argumentos a un comando?

Usa $ARGUMENTS para agarrar de una vez todo el texto después del nombre del comando, o $1, $2... para cada argumento posicional. Encierra los argumentos de varias palabras entre comillas: /rename "old id" new.

¿En qué se diferencia un comando personalizado de uno integrado?

Los comandos integrados (/help, /clear, /compact...) vienen con Claude Code de parte de Anthropic. Los comandos personalizados son los que creas como archivos Markdown, empaquetando tu prompt o el de tu equipo. Ambos aparecen juntos en el menú /.

¿Puedo ejecutar comandos de terminal dentro de un comando?

Sí. Usa la sintaxis !`<command>` - el comando bash se ejecuta primero y su salida se incrusta en el prompt antes de que Claude lo lea. Por ejemplo, !`git diff HEAD` deja que el comando tome el diff actual por sí solo.

¿Se pueden commitear los comandos y compartirlos con todo el equipo?

Sí. Pon el comando en .claude/commands/ en la raíz del repositorio y haz commit en git. Todos los que clonan el repositorio reciben el mismo conjunto de comandos, manteniendo el flujo de trabajo del equipo en sincronía.

¿En qué se diferencia un comando personalizado de las Skills?

A partir de 2026 los dos se han fusionado, y los archivos de comando antiguos aún funcionan. La diferencia: un comando es un único archivo de prompt, invocado a mano; una skill es una carpeta que puede guardar archivos de apoyo y puede cargarse automáticamente cuando Claude la encuentra relevante. Los comandos sirven para acciones únicas, las skills para capacidades complejas.

Conclusión + próximos pasos

Los comandos slash personalizados son la forma más barata de convertir prompts repetidos en una herramienta compartida: un archivo Markdown, una pulsación, y todo el equipo se beneficia. Empieza con /review y /commit, añade frontmatter cuando necesites seguridad y luego da el salto a una Skill a medida que tu flujo de trabajo se vuelve más complejo. Sigue leyendo con qué son las Skills en Claude Code y cómo crear una skill personalizada, o abre la hoja de referencia de Claude Code para consultar la sintaxis cuando quieras.