Comandos disponibles y comandos personalizados

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 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.

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.

opencode lee archivos de comandos de .opencode/command/ en el proyecto y de la carpeta global de configuración, en Markdown o JSON. El cuerpo es el prompt y $ARGUMENTS recibe lo que escribes tras el nombre. También carga rutas compatibles con Claude, así que sirve un conjunto .claude/ existente salvo que desactives la compatibilidad. Guarda la carpeta del proyecto en git y el comando viajará con el repositorio.

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 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.

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.

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. 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.

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). 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.

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.

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 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 (opencode)~12 KBComandos Markdown/JSON para .opencode/command/ con $ARGUMENTS conectado.opencode/command-starter-pack.zipdescargarPaquete 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

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.mdFlujo 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.htmlUn 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