Un comando slash es un archivo Markdown cuyo cuerpo se convierte en un prompt. Es la forma más simple de dejar de reescribir la misma petición —una revisión, una comprobación de versión, un resumen con la forma que espera tu equipo— y lo menos quisquilloso de toda la configuración. El único punto donde falla son los argumentos. Todo lo escrito tras el nombre del comando llega como un marcador, las palabras sueltas como marcadores numerados, y un cuerpo que no menciona ninguno ignora lo que el usuario pasó mientras sigue anunciando que acepta algo. Este creador escribe el archivo, ofrece los marcadores como botones y señala ese desajuste en ambos sentidos.
Características
Marcadores insertados desde botones en vez de recordados
Avisa cuando se anuncia un argumento que el prompt nunca usa
Avisa cuando el prompt usa un argumento y nada le dice al usuario qué pasar
Lista opcional de herramientas y anulación del modelo
El nombre se comprueba como nombre de archivo, porque en eso se convierte
Alcance de proyecto o personal con la ruta correspondiente
Vista previa de cómo se escribirá el comando
Se descarga como un archivo .md listo para usar
Cómo usar Constructor de comandos
Nombra el comando: será a la vez /nombre y el nombre del archivo
Escribe el prompt insertando $ARGUMENTS o $1 donde va la entrada
Añade una pista de argumento para que el usuario sepa qué pasar
Elige el alcance y descarga el archivo
Ejemplo
Entrada
argument-hint: <pr-number>
Salida
Review pull request #$1.
La pista y el marcador tienen que coincidir, o uno de los dos miente.
Errores comunes y solución de problemas
El comando ignora lo que escribo después. — El cuerpo tiene que usar la entrada. $ARGUMENTS es todo lo escrito; $1, $2 y $3 son las palabras sueltas.
El comando no aparece en la lista. — El nombre del archivo es el nombre del comando, así que debe ir en minúsculas con guiones y estar en el directorio de comandos del alcance elegido.
Falta la descripción en la lista. — Sale del campo description del frontmatter. Sin él, el comando aparece sin etiqueta.
$1 y $ARGUMENTS parecen solaparse. — Se solapan: $ARGUMENTS incluye todo y $1 es su primera palabra. Usa uno u otro salvo que quieras los dos a propósito.
Preguntas frecuentes
¿Cuál es la diferencia entre $ARGUMENTS y $1?
$ARGUMENTS es toda la cadena escrita tras el nombre del comando. $1, $2 y $3 son las palabras separadas por espacios. Usa los numerados cuando el comando reciba un conjunto fijo de entradas y $ARGUMENTS cuando reciba texto abierto.
¿Necesito una lista de herramientas permitidas?
No, y la mayoría de comandos no la usan. Vale la pena cuando un comando debe poder ejecutar algo concreto sin preguntar cada vez, o cuando quieres que no pueda hacer algo que la sesión sí podría.
¿Dónde vive un archivo de comando?
Un comando de proyecto vive en el repositorio para que lo tenga todo el equipo; uno personal te acompaña entre proyectos. La ruta exacta se muestra y se actualiza con el nombre.
¿Un comando puede llamar herramientas o ejecutar órdenes?
El cuerpo es un prompt, así que puede pedir cualquier cosa que la sesión ya pudiera hacer. La lista de herramientas amplía o estrecha lo que se ejecuta sin preguntar; no concede nada nuevo.
¿Cuándo debería ser un comando y no una skill?
Un comando se invoca a propósito escribiéndolo. Una skill se asocia automáticamente cuando una tarea parece relevante. Si quieres decidir tú el momento, escribe un comando; si quieres que ocurra solo, escribe una skill.
Herramientas relacionadas
Constructor de skills — Escribe un SKILL.md con el frontmatter revisado mientras escribes.
Constructor de subagentes — Crea el archivo de definición de un subagente con sus herramientas y modelo.
Constructor de hooks — Crea hooks de settings.json y detecta los matchers que nunca se activan.
Manifiesto de plugin — Genera un plugin.json y mira la estructura de carpetas que espera.