# Comandos disponibles y comandos personalizados

Stack agéntico · Builders · Codex · módulo 04
Lectura: ~9 min

> Un prompt que escribes una y otra vez se convierte en un archivo que activas con una barra. Entregas un comando personalizado en el formato de tu arnés (harness), mantienes los verbos combinables en lugar de crear un comando que haga cinco cosas y conoces las cuatro razones por las que un comando instalado nunca aparece sin avisar: carpetas anidadas, conflicto con un nombre integrado, un proyecto no confiable y sustitución literal de argumentos.

> Diagrama: Todo el módulo en una imagen: un archivo Markdown con fases, una regla de evidencia y una vía de rechazo llega a las carpetas de comandos de cinco arneses, y cuatro fallos silenciosos cortan la flecha entre el archivo y el menú de comandos de barra.

## lo que vas a poder hacer

entregable :: lo que produces

❯ Un comando personalizado funcional en tu arnés. Escribes `/` y aparece en el menú, listo para activarse. Lo construyes en el formato propio de tu arnés y la descarga te da un paquete inicial para adaptar.

La mayoría de los equipos tiene a alguien cuyas revisiones detectan lo que nadie más ve. Un comando personalizado permite que esa revisión se ejecute en una rama que esa persona nunca abrió.

Los comandos integrados son atajos de teclado. En los personalizados, los estándares y la cautela de seguridad del equipo dejan de vivir en una cabeza y pasan a un archivo que el modelo ejecuta bajo demanda. Un `/review-security` escrito por tu responsable de ingeniería es esa persona presente en cada sesión de un principiante, para siempre.

Todos los arneses incluyen comandos integrados y una forma de añadir los tuyos.

Los cinco difieren de verdad en el cómo, así que esa parte se divide por opción más abajo. Lo que importa son los patrones compartidos que hay debajo.

## Los comandos integrados que conviene memorizar

Necesitas los de uso diario, no todos. La misma estructura en los cinco arneses, con nombres distintos.

-   **Un comando de planificación.** Redacta un plan sin tocar nada y entrega contexto limpio al trabajo. La charla de planificación que se filtra al hilo de construcción desvía a los agentes: releen sus propias reflexiones en voz alta como si fueran decisiones. El comando integrado más valioso de todos.
-   **Un comando de estado.** Muestra el modelo activo, permisos, uso de tokens y qué capa de configuración fijó cada cosa. Tu primer paso si algo parece raro, porque "ignora mis reglas" suele significar "ganó otra capa de configuración".
-   **Un comando de permisos.** Cambia lo que puede hacer el agente durante la sesión, sin reiniciar. Sin él, empezar en solo lectura como en el [módulo 2](/stack/builders/codex/module-02.md) exige reiniciar en cuanto hay que escribir, así que la gente deja de hacerlo.
-   **Un comando de modelo.** Cambia de modelo y esfuerzo de razonamiento por tarea. Barato y rápido para renombrar, lento y cuidadoso para una migración.
-   **Un comando de revisión.** Revisa tu árbol de trabajo en su propio contexto, para que quien comprueba el trabajo no sea el hilo que se convenció de hacerlo.
-   **Controles de contexto.** Empezar de cero, reanudar, compactar. Una sesión de horas arrastra cada giro equivocado y el agente lo sopesa igual que los correctos.

> Diagrama: Las seis funciones integradas de uso diario sobre una línea de tiempo de sesión: planificar al inicio; estado, permisos y modelo como tres controles que ajustas a mano en medio; revisar cerca del final; y los controles de contexto que abarcan toda la sesión.

Aprende esos seis. El resto puede esperar.

## Cómo funcionan los comandos personalizados en tu arnés

La misma idea en todas partes: un archivo se convierte en comando. Solo cambian el formato y la carpeta.

> Diagrama: Un archivo de comando se coloca en la carpeta del arnés que uses entre los cinco y todas las rutas convergen en el mismo menú de barra. Guardarlo en git es la rama que entrega el comando al equipo.

Coloca un archivo Markdown en [~/.codex/prompts/<name>.md](#codexpromptsname) y Codex lo recoge como `/<name>`. Sin registro ni reinicio. Un `description:` en el frontmatter —el pequeño bloque de ajustes entre las dos líneas `---` del principio— aparece en el menú de barra. Parece cosmético hasta que tienes treinta comandos y no recuerdas qué hace cada `/audit-`. `$ARGUMENTS` se sustituye por lo que escribes después: `/audit-pr focus on auth` introduce "focus on auth" en el cuerpo. Guarda [.codex/prompts/<name>.md](#codexpromptsname) en git para compartirlo. Los comandos del proyecto solo cargan al marcarlo como confiable.

## Qué distingue a un comando que funciona de uno que se lee bien

Aquí falla en silencio la mayoría de las bibliotecas de comandos. El archivo carga, escribe párrafos seguros y nadie nota durante dos meses que nunca comprobó nada. Tres elementos en el cuerpo lo corrigen.

**Nombra las fases.** No "revisa el diff", sino una secuencia numerada: lee esto, ejecuta aquello, juzga e informa con esta estructura. El [módulo 3](/stack/builders/codex/module-03.md) encontró lo mismo: los flujos numerados cambian más el comportamiento que la prosa. Las cadenas serias de agentes dividen la ejecución en planificar, recopilar, iterar sobre lagunas, observar, sintetizar y revisar. Copia la estructura, no la especificación. Un agente con una gran instrucción optimiza el entregable. Uno con fases debe pasar por los pasos intermedios para llegar a él.

**Mantén el estado fuera del modelo.** Esas cadenas escriben notas de trabajo en archivos en vez de retenerlas en la conversación. Haz una versión pequeña: hallazgos en un archivo temporal o tabla fija, no un párrafo que se disuelve al compactar la sesión. Un resultado que admite diff permite discutirlo.

**Dale una forma de no decir nada.** Un comando que solo puede producir hallazgos los producirá. Define la respuesta vacía como resultado con nombre: `NOTHING FOUND`, o `NEEDS-REVIEW` para lo que no pueda juzgar. Un comando sin vía de rechazo inventa.

> Diagrama: El mismo comando review-security escrito de dos formas. A la izquierda, un párrafo vago que inventa tres hallazgos en un diff limpio. A la derecha, fases numeradas, escritura en archivo, una regla de evidencia y una respuesta vacía definida que devuelve SIN HALLAZGOS.

## El comando vacío

Tu `/review-security` se ejecuta. No informa de problemas. Fusionas.

¿No encontró nada o no comprobó nada? Desde fuera parecen lo mismo. Una comprobación puede pasar sin verificar nada; por eso las cadenas cuidadosas mantienen una revisión independiente y aprobación humana en vez de confiar en un resultado verde. Es peor en un archivo de comandos escrito una vez por alguien competente y ejecutado cientos de veces por personas que suponen que funciona.

La defensa es una regla de pruebas, una línea en el cuerpo: **cada hallazgo debe citar el archivo y la línea de origen, y el informe debe indicar qué archivos se abrieron.** Una cita existe en tu repositorio o no; además, hace honesto el resultado vacío: una ejecución que abrió tres archivos y no encontró nada se lee muy distinto de una que no abrió ninguno.

> Diagrama: Sin una regla de pruebas, una ejecución que abrió tres archivos y otra que no abrió ninguno se reducen al mismo informe de «sin problemas». Con la regla, los dos informes se distinguen y el vacío queda a la vista.

La segunda defensa nunca se elimina con automatización. Los comandos que juzgan pueden ejecutarse sin supervisión. Los que publican, borran, gastan o envían, no. Pon la compuerta en el arnés, no en las instrucciones: para eso está el límite de permisos del [módulo 2](/stack/builders/codex/module-02.md). Una regla dicha al modelo es una preferencia. Una impuesta por el arnés es un límite.

## Dos patrones que compensan

**Combina, no hinches.** Evita que un comando haga cinco cosas. `/audit-pr` solo revisa. `/branch-summary` solo resume. Si necesitas ambos, ejecútalos en secuencia. Los verbos pequeños superan a un megacomando por la misma razón que triunfó `grep | sort | uniq`. Cuando uno pequeño responde mal, sabes qué veinte líneas corregir. Cuando falla uno enorme, debes adivinar cuál de sus cinco tareas salió mal.

**Usa argumentos para el contexto, no para todo el prompt.** Un buen comando tiene un cuerpo estructurado que hace el trabajo y recibe una parte variable como argumento. Uno malo es `Do this: $ARGUMENTS`: vuelves a escribir con una pulsación en lugar de cero. Si todo el comando es el argumento, no has construido nada.

> Diagrama: Tres comandos pequeños encadenados de izquierda a derecha: si uno responde mal, solo se ilumina su casilla y sabes qué veinte líneas corregir. Un comando enorme con cinco tareas: la misma mala respuesta ilumina las cinco y debes adivinar.

## Compartir entre máquinas y compañeros

Tres patrones, de menor a mayor peso:

-   **Dotfiles.** Lo más rápido. Un repositorio de dotfiles guarda tus archivos personales de configuración en git, de modo que los comandos te siguen entre máquinas personales, portátiles de trabajo y contenedores de desarrollo. Crea un enlace simbólico —un archivo que apunta a otro— desde la carpeta de comandos al repositorio, y editar cualquiera de las rutas cambia el mismo archivo.
-   **Guardarlos en el proyecto.** Todos los compañeros del proyecto confiable reciben los mismos verbos. El `/review-security` de un ingeniero sénior copia su criterio de seguridad en cada sesión, incluidas las de quienes no habrían sabido dónde mirar.
-   **Empaquetarlos.** Cuando el conjunto incluya skills compartidas o un servidor MCP, distribúyelo mediante plugins o el marketplace del arnés ([módulo 8] (próximamente)). Es poco frecuente y el siguiente paso natural cuando crece. Observa la dirección de confianza: tu conjunto es seguro porque lo escribiste; instalar el de otro introduce el riesgo del marketplace del [módulo 2](/stack/builders/codex/module-02.md).

## Cuatro fallos silenciosos

Un comando instalado no aparece y las cuatro causas fallan en silencio. Sin error, solo ausencia, y se culpa al modelo de la ausencia.

1.  **La carpeta no se recorre recursivamente.** Los archivos suelen tener que estar directamente en la carpeta de comandos. Un nivel más abajo se ignora en silencio. Atrapa a quien ordena comandos en subcarpetas que no son un espacio de nombres admitido.
2.  **Ganan los nombres integrados.** Si un comando personalizado se llama como uno integrado, se ejecuta el integrado sin avisar. El peor de los cuatro: sí hay salida, pero no es la tuya. Elige `/review-security`, no `/review`.
3.  **Se exige confiar en el proyecto.** Los comandos guardados solo cargan cuando el proyecto está marcado como confiable. Si un compañero no ve tu comando, comprueba esto primero.
4.  **La sustitución de argumentos es literal.** El marcador sustituye texto, sin analizarlo ni escaparlo. Trátalo como un `${1}` crudo en un script de shell: útil, sin sanear y capaz de sorprenderte.

> Diagrama: Un árbol de decisiones con cuatro ramas tras escribir una barra y no ver tu comando: una carpeta que no busca en subcarpetas, un nombre integrado que prevalece, un proyecto que no es de confianza y la sustitución literal de argumentos. Cada rama termina en la comprobación que la confirma.

## Qué haces después

Descomprime el paquete inicial de tu arnés en la carpeta correcta. Ejecuta primero el comando de revisión o resumen en un repositorio real. Son los que antes compensan.

Después crea uno propio. Deja que el agente escriba el archivo mientras tú aportas el criterio. Envía esto:

// shell

```
Encuentra la carpeta de comandos o skills que lee este arnés para comandos
personalizados de barra y dime la ruta exacta antes de escribir nada.

Después escribe ahí un archivo de comando llamado review-security. Su cuerpo debe:
1. Nombrar las fases como una secuencia numerada.
2. Exigir que cada hallazgo cite el archivo y la línea de origen y
   enumere qué archivos se abrieron.
3. Permitir la salida "NOTHING FOUND" si no hay nada y
   "NEEDS-REVIEW" si no puede juzgarlo.
4. No editar nunca archivos.

Después muéstrame el archivo y dime cómo hacer que aparezca en el menú de barra.
```

La pregunta de la ruta va primero a propósito. Una carpeta equivocada cuesta una hora creyendo que tu archivo está roto.

**O hazlo tú:** copia el archivo más parecido del paquete inicial, cambia el nombre para que no choque con uno integrado y edita el cuerpo hasta que tenga las tres partes anteriores.

Pruébalo en ambos casos. Ante un diff limpio deberías obtener `NOTHING FOUND`, no hallazgos inventados. Después introduce un problema obvio y comprueba que lo devuelva con una línea real citada. Un comando que pasa ambas pruebas merece estar en el repositorio. Uno que solo pasa la segunda es de los vacíos.

Editar comandos que ya usas supera a diseñarlos en una página en blanco.

El [módulo 5] (próximamente) desarma el archivo de configuración de tu arnés, donde los comandos se combinan con configuraciones con nombre para ajustar el entorno de principio a fin.

## descargas

// 2 archivos :: listos para usar. copia, adapta, entrega.

[Paquete inicial de comandos (Codex)~12 KBComandos de prompt listos para pegar en ~/.codex/prompts/. Escribe / y aparecerán.codex/command-starter-pack.zipdescargar](/descargas/dev/module-04/codex/command-starter-pack.zip)[Paquete inicial de comandos (Cursor CLI)~3 KBUn ejemplo portable de SKILL.md y la ruta de skills de Cursor para un comando de revisión seguro.cursor-cli/command-starter-pack.mddescargar](/descargas/dev/module-04/cursor-cli/command-starter-pack.md)

## recursos y referencias

// documentación oficial, herramientas e hilos que merece la pena guardar

[Página de la especificación AGENTS.mdTus comandos leen el archivo de memoria que escribiste en el módulo 3. Mantenlo afinado.https://agents.md](https://agents.md)[Flujo multiagente con compuertas de correcciónBrando Miranda explica por qué una comprobación automática puede pasar sin comprobar nada. La razón por la que tu comando de revisión necesita una regla de pruebas.https://cs.stanford.edu/people/brando9/2026/04/13/correctness-gated-multi-agent-workflow.html](https://cs.stanford.edu/people/brando9/2026/04/13/correctness-gated-multi-agent-workflow.html)[Un agente de investigación por fasesUna implementación abierta que divide el trabajo en fases con nombre y guarda el estado fuera del modelo. La estructura que copia un buen cuerpo de comando.https://github.com/happyeungin/agents-deep-research](https://github.com/happyeungin/agents-deep-research)