Slash commands en Claude Code: automatiza tareas en 2026

TL;DR

Un slash command en Claude Code es un atajo guardado que invocas con /nombre y empaqueta un prompt, contexto y pasos repetibles. Sirve para dejar de pegar el mismo prompt cada sesión y convertir tareas frecuentes (revisar PR, generar tests, redactar commit) en una sola línea. En este artículo verás cómo crearlos, dónde guardarlos para compartirlos con tu equipo y qué cosas se rompen cuando los llevas a producción real.

El problema: pegar el mismo prompt 40 veces a la semana

En mi experiencia migrando de Java a Python con asistencia de Claude Code, hay un patrón que se repite hasta cansar: pegas el mismo bloque de instrucciones para revisar un diff, generar tests unitarios o redactar un mensaje de commit. Cambias dos palabras y vuelves a pegar. Una semana, dos semanas, un mes. El prompt acaba viviendo en una nota de Obsidian, en un canal de Slack y en tu memoria muscular.

El coste no es solo de tiempo. Cada vez que reescribes el prompt introduces variación: se te olvida pedir el formato de salida, omites una restricción, copias mal la lista de archivos relevantes. El agente trabaja con menos contexto del que debería y los resultados drift entre sesiones.

Los slash commands resuelven exactamente esto. Son la pieza más simple del ecosistema de Claude Code y, a la vez, la primera que conviene dominar antes de saltar a una librería completa de skills o a configuraciones más complejas.

¿Qué es un slash command en Claude Code?

Un slash command es un archivo Markdown guardado en una carpeta concreta del proyecto o del usuario, que Claude Code carga al iniciar la sesión y expone como atajo invocable con /nombre-del-comando. Cuando lo invocas, su contenido se inyecta como prompt en la conversación, opcionalmente con argumentos que tú pasas en línea.

La diferencia frente a una skill es de alcance. Una skill suele empaquetar contexto largo, herramientas y pasos elaborados para tareas complejas. Un slash command es más ligero: una receta corta para una acción repetida. Si tu prompt cabe en 30 líneas y no necesita lógica condicional, casi siempre quieres un slash command, no una skill.

Anatomía de un slash command

Cada comando es un archivo .md con una estructura mínima:

---
description: Genera mensaje de commit en formato conventional commits
argument-hint: [resumen breve del cambio]
---

Analiza los archivos staged con `git diff --cached` y propón un mensaje
de commit en formato conventional commits (feat, fix, chore, refactor).

Contexto adicional del usuario: $ARGUMENTS

Reglas:
- Tipo en minúsculas, scope opcional entre paréntesis
- Descripción imperativa, máximo 72 caracteres en la primera línea
- Cuerpo solo si el cambio no es trivial

El frontmatter con description es lo que aparece en el menú de autocompletado al escribir /. $ARGUMENTS es el placeholder estándar para lo que el usuario pasa después del nombre del comando.

Dónde se guardan: proyecto vs usuario

Esta es la decisión que más diferencia hace en la práctica:

Ubicación	Ruta	Cuándo usarla
Proyecto	.claude/commands/	Comandos específicos del repo: convenciones de commit, scripts internos, reviewers obligatorios
Usuario	~/.claude/commands/	Comandos personales que usas en cualquier proyecto: redactar PR, traducir docs, generar README

Los del proyecto se versionan con git y se comparten con el equipo. Los del usuario son tuyos y no viajan con el repo. Un error frecuente es meter en el repo comandos que solo tú usas: ensucias el árbol y obligas al resto a verlos en su autocompletado.

Implementación paso a paso

Vamos a crear un comando real: /review-diff para que Claude haga una revisión de los cambios staged antes de hacer commit. Es uno que uso a diario.

1. Crear la carpeta de comandos del proyecto

# Desde la raíz del repo
mkdir -p .claude/commands

2. Escribir el comando

Crea el archivo .claude/commands/review-diff.md con este contenido:

---
description: Revisa cambios staged buscando bugs, smells y tests faltantes
argument-hint: [foco opcional, ej. seguridad, performance]
---

Ejecuta `git diff --cached` y revisa los cambios staged.

Foco prioritario del usuario: $ARGUMENTS

Reporta en este orden:
1. Bugs probables (lógica, off-by-one, null checks)
2. Code smells (funciones largas, nombres confusos)
3. Tests faltantes para el cambio
4. Riesgos de seguridad si aplica

No propongas el fix todavía. Solo lista hallazgos con número de línea.

3. Probarlo

Inicia Claude Code en el repo y escribe /review-diff seguridad. El agente debería ejecutar el diff, leer los cambios y devolverte una lista numerada con foco en seguridad. Si no aparece en el autocompletado, reinicia la sesión: los comandos se cargan al arrancar.

4. Iterar sobre el comando

El primer comando casi nunca es el bueno. Lo usas tres veces, ves qué falta y editas el archivo. Esto es lo que más valor da del formato Markdown: no hay compilación, no hay despliegue, abres el archivo y cambias dos líneas.

Casos prácticos que uso en mi flujo

Estos son los slash commands que más me ahorran tiempo en proyectos reales con FastAPI y pipelines de IA:

• /commit: lee el diff staged y genera mensaje en conventional commits.
• /test-this: dado un archivo, propone tests pytest cubriendo casos límite.
• /explain-pr: genera la descripción de un PR a partir del rango de commits frente a main.
• /refactor-check: pide al agente que valide que un refactor no cambia comportamiento, leyendo tests primero.
• /db-migration: genera el esqueleto de una migración Alembic a partir de un cambio en modelos SQLAlchemy.

Si trabajas con arquitecturas más estructuradas, conviene combinar estos comandos con el principio de separación de responsabilidades: cada comando hace una cosa, no intentes meter "revisa, refactoriza y commitea" en un solo atajo.

En Producción

Lo que funciona en tu repo personal cambia cuando metes slash commands en un equipo de 5 o 10 personas. Estas son las consideraciones reales:

Versionado y revisión

Trata .claude/commands/ como código. Cada cambio pasa por PR, con revisor humano. He visto comandos que terminaron pidiendo al agente "ignora los warnings" porque alguien lo añadió en un momento de prisa, y luego el equipo entero arrastró ese sesgo durante semanas.

Coste por invocación

Cada slash command consume tokens al inyectar su contenido en el prompt. Si tu comando tiene 200 líneas de contexto y lo invocas 30 veces al día, eso son tokens reales. En un proyecto pequeño con Claude Sonnet hablamos de céntimos, pero en un equipo con uso intensivo y Opus 4.7 puede sumar 30-50€ al mes solo en comandos. Mantén los archivos cortos: si un comando crece más de 50 líneas, probablemente quieres una skill.

Permisos y herramientas

Un slash command puede pedirle al agente que ejecute git diff, pytest o lo que sea, pero los permisos del harness mandan. Si tu settings.json no autoriza Bash(git diff:*), el agente pedirá confirmación cada vez. Para comandos de uso diario, define los permisos explícitos en settings.json y deja claro en la configuración del repo qué tools tiene disponibles el agente.

Drift entre versiones de Claude Code

El formato de slash commands es estable a fecha de mayo de 2026, pero campos como argument-hint han cambiado entre versiones del CLI. Fija una versión mínima de Claude Code en el README del proyecto si dependes de un campo concreto del frontmatter.

Errores Comunes y Depuración

• Error: el comando no aparece en el autocompletado al escribir /. Causa: lo creaste con la sesión abierta. Solución: reinicia Claude Code; los comandos se cargan al arrancar.
• Error: $ARGUMENTS aparece literal en el prompt. Causa: invocaste el comando sin argumentos y el placeholder no se sustituyó. Solución: añade un fallback en el cuerpo ("si no hay argumentos, asume X") o pasa siempre algo.
• Error: el agente ignora reglas del comando. Causa: tu CLAUDE.md del proyecto contradice al comando. Solución: el orden de prioridad es CLAUDE.md sobre slash command. Mueve la regla al lugar correcto o ajusta el comando para alinear.
• Error: comandos del repo se mezclan con los del usuario y no sabes cuál se ejecuta. Causa: tienes el mismo nombre en .claude/commands/ y ~/.claude/commands/. Solución: el del proyecto gana, pero conviene renombrar para evitar la ambigüedad.

Preguntas Frecuentes

¿Slash command o skill: cuándo usar cada uno?

Usa slash command si tu prompt cabe en 30-50 líneas y la tarea es repetida pero acotada. Usa skill si necesitas empaquetar contexto extenso, varios pasos coordinados o herramientas específicas. Una buena regla es empezar siempre con slash command y promocionar a skill solo cuando el comando crece y se complica.

¿Puedo encadenar varios slash commands?

No de forma nativa. Cada invocación es independiente. Lo que sí puedes hacer es que un slash command pida al agente ejecutar otra acción y luego invocar manualmente el siguiente. Para flujos encadenados de verdad, el camino es subagentes o un harness que orqueste, no slash commands.

¿Funcionan los slash commands en otros agentes como Codex u OpenClaw?

El formato .claude/commands/ es específico de Claude Code. Codex y otros harnesses tienen sus propios mecanismos de comandos personalizados, con sintaxis distinta. Si trabajas con varios agentes, mantén comandos separados o adopta una skill (formato SKILL.md) cuando quieras portabilidad.

Lo que te llevas

Los slash commands son la forma más barata de dejar de repetir prompts en Claude Code. Cuestan diez minutos crearlos, viven en Markdown, se versionan con tu repo y reducen drift entre sesiones. La clave está en empezar pequeño: identifica los tres prompts que más pegas esta semana, conviértelos en comandos y deja que el equipo los itere. Cuando un comando crece más de 50 líneas o necesita lógica condicional, ese es el momento de promocionarlo a skill, no antes.

¿Tienes ya tu set de slash commands favoritos o sigues pegando el mismo prompt cada mañana? Cuéntamelo en los comentarios o en Twitter @sergiomarquezp_. En el siguiente post veremos cómo combinar slash commands con hooks de settings.json para automatizar acciones que se ejecutan sin tener que invocarlas tú.