Tus propios slash commands para Claude Code, productivo en 30 minutos

Si usas Claude Code más de dos semanas, vas a terminar tecleando los mismos prompts varias veces al día. "Revisa este archivo", "Escríbeme un test para", "Despliega a staging". Para eso existen justamente los slash commands personalizados. Un archivo Markdown por comando, sin sistema de plugins, sin paso de build. Te muestro cómo se hace y dónde están las trampas.

1. Entender de qué se trata realmente

Un slash command en Claude Code no es más que un archivo Markdown con frontmatter YAML y un prompt. Cuando escribes /review, Claude Code busca en el proyecto bajo .claude/commands/review.md y en tu home dir bajo ~/.claude/commands/review.md. Si encuentra el archivo, lo lee, reemplaza placeholders como $ARGUMENTS por lo que tecleaste después del comando, y lanza eso como prompt.

Es decir: un comando es tan bueno como el prompt que pones dentro. Sin magia. Pero eso es justo lo que lo hace tan útil, porque versionas tus mejores prompts en lugar de reinventarlos una y otra vez.

2. Crear tu primer comando

Ve a tu proyecto y crea el directorio:

mkdir -p .claude/commands

Ahora mete ahí un archivo review.md. Contenido mínimo:

---
description: Code-Review für den aktuellen File
---

Schau dir den letzten geaenderten File im Working Directory an.
Pruef auf:
- Logik-Fehler oder Edge-Cases die fehlen
- Schlechte Variablen-Namen
- Tests die fehlen sollten

Gib mir maximal 5 konkrete Punkte zurück. Keine Lobhudelei.

Guárdalo. Reinicia Claude Code o simplemente teclea /help, entonces /review (project) debería aparecer en la lista. El (project) significa que viene de tu repo, no de tu directorio de usuario. Si ahora tecleas /review, el prompt se dispara.

3. Pasar argumentos

Lo estático es aburrido. Quieres poder decir "revisa el ARCHIVO X". Para eso hay dos placeholders: $ARGUMENTS se traga todo lo que tecleas después del comando como un único string. $1, $2, $3 se tragan tokens individuales.

Ejemplo fix-issue.md:

---
description: Fix GitHub Issue per Nummer
argument-hint: [issue-number]
---

Fix Issue #$ARGUMENTS nach unseren Coding-Standards.
Schreib Tests dafür, dann commit auf einem feature-Branch.

Llamada: /fix-issue 247 y $ARGUMENTS se convierte en 247.

El campo argument-hint no es cosmético, Claude Code te lo muestra cuando tecleas solo /fix-issue y pulsas Tab. Siempre vale la pena.

4. Meter archivos con la sintaxis @

Si tu comando debe analizar un archivo, puedes incrustar el contenido del archivo directamente en el prompt. Sintaxis: @ruta/al/archivo. Cuando lo combinas con $1, se vuelve muy útil.

security-check.md:

---
description: Security-Audit für einen File
argument-hint: [file-path]
allowed-tools: Read
---

Lies @$1 und pruef auf:
- Hard-coded Secrets oder API-Keys
- SQL-Injection-Patterns
- Unsanitized User-Input

Wenn du was findest, gib genaue Zeilen-Nummern aus.

Llamada: /security-check src/auth.ts. Claude lee el archivo y lanza el prompt con el contenido del archivo como contexto.

5. Ejecutar comandos bash inline

Este es el truco subestimado. Con !`command` puedes ejecutar un comando de shell dentro de tu comando e incrustar la salida en el prompt. Es decir: contexto dinámico sin que Claude tenga que llamar tools primero.

commit-message.md:

---
description: Commit-Message basierend auf staged changes
allowed-tools: Bash(git:*)
---

Hier sind die staged changes:

!`git diff --cached`

Hier ist der current branch:

!`git branch --show-current`

Schreib mir eine Commit-Message im Conventional-Commits-Format.
Eine Zeile Subject, max 72 Zeichen, dann Leerzeile, dann Body.

Importante: el campo allowed-tools: Bash(git:*) permite explícitamente solo comandos git. Sin este whitelisting, Claude pide confirmación en cada llamada bash. Si escribes Bash(*) pasa todo, pero eso es peligroso, así que mejor quédate granular.

6. Comandos personales vs de proyecto

Los comandos de proyecto viven en .claude/commands/ en el repo. Esos los commiteas. Ventaja: tu equipo usa los mismos comandos. Desventaja: tu comando /dailylog que en realidad solo te interesa a ti se cuela en cada proyecto.

Solución: comandos personales. Esos viven en ~/.claude/commands/ y están disponibles en cada proyecto. En /help aparecen marcados como (user).

Mi setup: comandos de workflow como /review, /test, /deploy como comandos de proyecto (compartir con el equipo). Los personales como /note, /commit-msg, /explain-this como comandos de usuario.

7. Namespacing cuando crecen

A partir de 15 comandos la lista plana se vuelve confusa. Solución: subdirectorios. Creas un comando en .claude/commands/git/review.md, aparece en /help como /review (project:git). Con /git/review accedes a él explícitamente.

.claude/commands/
├── git/
│   ├── review.md
│   └── commit.md
├── ci/
│   └── deploy.md
└── docs/
    └── api.md

Empieza con esto pronto si planeas tener más de 5-10 comandos. Renombrar después da trabajo y rompes la memoria muscular.

8. Hacer los comandos realmente útiles

La diferencia entre un juguete y un daily driver es si el comando hace algo que de otro modo harías a mano. Tres patterns que me funcionan a fondo:

Snapshot de estado. /status empaqueta el git status, la salida de npm test y los últimos 5 commits en un prompt y le pregunta a Claude qué sigue. Me ahorra 10 minutos de orientación por la mañana.

Código a documentación. /document $1 lee un archivo, genera comentarios JSDoc y los escribe de vuelta. Aburrido, pero una vez que tienes el comando, nunca más lo haces a mano.

Sanity pre-commit. /prepush corre git diff origin/main...HEAD, le pregunta a Claude si todo encaja con sentido o si hay accidentalmente tres features en el mismo PR.

La lógica es siempre: qué te molesta a diario, dura entre 30 segundos y 3 minutos, y es lo bastante uniforme para un prompt. Eso es justo lo que se convierte en un comando.

9. Las dos trampas

Caos de fallback. Cuando el nombre de tu comando colisiona con uno built-in (por ejemplo /help), gana el built-in. Cuando un comando de proyecto y uno de usuario tienen el mismo nombre, gana el de proyecto. Es decir: antes de soltar /test en ~/.claude/commands/, comprueba que el repo no defina ya un /test.

Olvidar el prompt engineering. Tu comando es un prompt. Si el prompt es vago, la respuesta será vaga. Mete criterios de aceptación ("máximo 5 puntos", "sin halagos", "números de línea concretos"). Si no, recibes el típico muro de texto de Claude.

10. Qué sigue

Cuando hayas escrito tus primeros tres a cinco comandos, te darás cuenta de que algunos en realidad deberían ser hooks. Los hooks corren automáticamente en eventos (PostToolUse, PreCompact), los slash commands los disparas manualmente. Ambos tienen su lugar.

Si quieres aprender más sobre hooks, mira el playbook Hooks gegen Halluzinationen. Si quieres construir slash commands para sub-agents, Erster Sub-Agent in 30 min es el paso siguiente. Y si quieres compartir tu setup, considera convertirlo en un plugin, que en el fondo es solo un directorio de comandos más un poco de archivo manifest.

Mi consejo: crea hoy un único comando, /review.md, con un prompt que ya haya aparecido dos veces en tu historial de chat. Es poco trabajo, payoff inmediato, y después entiendes todo el sistema.

Source

Specs verificadas contra el repo /anthropics/claude-code, a fecha 2026-04-28:

• plugins/plugin-dev/skills/command-development/SKILL.md (ubicaciones, frontmatter, argumentos)
• plugins/plugin-dev/skills/command-development/README.md (formato de archivo, $ARGUMENTS, sintaxis @, !-bash)
• plugins/plugin-dev/skills/command-development/references/plugin-features-reference.md (namespacing)

Documentación oficial: https://docs.claude.com/en/docs/claude-code/slash-commands