Cómo crear tus propios comandos en Claude Code y ahorrar tiempo

Cada vez que iba a escribir algo, le pegaba el mismo tocho de instrucciones. Cómo escribo, qué evitar, qué formato, dónde guardarlo. Un párrafo de doce líneas que tenía en una nota y que copiaba tres veces al día.

Hasta que un día pensé: si escribo siempre lo mismo, ¿por qué lo escribo?

Los comandos personalizados de Claude Code son eso. Escribes las instrucciones una vez, en un archivo, y a partir de ahí solo escribes una barra y el nombre. Es lo que más tiempo me ahorra de todo lo que tengo montado.

¿Cómo se crea un comando propio en Claude Code?

Creando un archivo de texto en una carpeta concreta. Ya está. Eso es todo el mecanismo.

Dentro de tu proyecto, hay una carpeta de configuración de Claude, y dentro de ella una carpeta de comandos. Cada archivo que dejes ahí se convierte en un comando cuyo nombre es el nombre del archivo.

Si creas un archivo llamado resumen.md, tienes un comando /resumen. Lo que escribas dentro del archivo es lo que Claude va a leer cuando lo llames.

No hay que instalar nada, no hay que configurar nada y no hay formato obligatorio. Es un archivo de texto con instrucciones escritas en español.

Cómo se escribe un comando que funcione

Un comando no es un prompt corto. Es el encargo completo que le harías a alguien que empieza hoy y no sabe nada de tu forma de trabajar.

La estructura que a mí me funciona tiene cuatro partes.

Quién eres y qué haces. "Eres el revisor de mis textos. Tu trabajo es señalar lo que no suena a mí." Una o dos frases que fijan el papel.

Qué archivos tienes que leer antes de nada. Esto es lo más importante y lo que casi nadie pone. Si tienes un documento con tu tono, otro con el contexto del proyecto, otro con las reglas del formato, indícalos aquí por su ruta. El comando los carga solo y te ahorras adjuntarlos cada vez.

Los pasos. Numerados y en orden. "Uno: lee el archivo que te paso. Dos: márcame las frases que suenan genéricas. Tres: propón alternativas. Cuatro: no reescribas nada sin que yo lo apruebe."

Lo que no debe hacer. Esta parte es sorprendentemente rentable. "No inventes datos. No cambies el orden de los apartados. No añadas conclusiones que no estaban."

Con esas cuatro partes tienes un comando decente. Y se mejora con el uso: cada vez que el resultado no es el que querías, añades una línea al archivo. A los diez usos, el comando hace exactamente lo que quieres.

Los argumentos

Un comando puede recibir información al llamarlo. En el texto del archivo pones una marca para los argumentos, y cuando escribes /revisar borrador.md, ese nombre de archivo entra donde has puesto la marca.

Eso convierte un comando fijo en uno reutilizable. El mismo /revisar te sirve para cualquier archivo, en vez de tener que escribir cuál cada vez.

Yo tengo comandos con argumento y comandos sin él. Los que actúan siempre sobre lo mismo (mi rutina de cierre del día, por ejemplo) no lo necesitan.

Tres comandos que uso todos los días

Uno de escritura. Carga mi documento de tono y las reglas del formato, y a partir de ahí escribe. La diferencia con pedirlo a pelo es abismal, y no por el prompt: por los documentos que carga sin que yo me acuerde.

Uno de revisión. Le paso un texto y me marca lo que suena a genérico, las repeticiones y las frases de relleno. No lo reescribe: me lo señala. Que reescriba solo es cómodo y acaba borrándote el estilo.

Uno de cierre. Al terminar el día, repasa lo que he tocado, actualiza los documentos de estado del proyecto y me deja apuntado por dónde iba. Es el que más veces me ha salvado el lunes por la mañana.

Los tres nacieron igual: yo escribiendo lo mismo por tercera vez y hartándome.

Comandos de proyecto y comandos globales

Puedes tener comandos que solo existen dentro de un proyecto y comandos que están disponibles en todos.

Mi criterio: si el comando depende de archivos de este proyecto, va en el proyecto. Si es genérico (revisar un texto, resumir un documento largo, prepararme preguntas sobre algo), va en los globales.

Y una ventaja de tenerlos en el proyecto: si el proyecto está en un repositorio, los comandos viajan con él. Cualquiera que lo abra tiene tus comandos.

Encadenar comandos: el paso siguiente

Cuando llevas unos cuantos, aparece la parte divertida: un comando puede llamar a otro.

Yo tengo uno de escritura que, al terminar el borrador, llama al de revisión. Así el texto sale ya pasado por el filtro sin que yo tenga que acordarme de la segunda parte. Lo mismo con el de cierre del día, que llama a un comando de actualizar índices antes de terminar.

Esto suena a montaje complicado y es literalmente escribir en el archivo del primer comando: "cuando termines, ejecuta el comando tal". No hay más magia.

El criterio para decidir si merece la pena encadenar: si dos comandos los llamas siempre seguidos, uno detrás de otro, en el mismo orden, junta los dos. Si a veces llamas solo el primero, déjalos separados. Encadenar cosas que no siempre van juntas te obliga a esperar por pasos que no querías.

Lo que se te va a atascar

Vas a escribir comandos demasiado cortos. "Escribe un post sobre el tema que te diga" no es un comando, es un deseo. Si el archivo tiene tres líneas, el resultado va a ser tan genérico como si no tuvieras comando.

Vas a escribir comandos demasiado largos. El otro extremo. Un archivo de cuatro páginas con todas las excepciones imaginables se vuelve difícil de mantener y el modelo empieza a saltarse cosas del medio. Una página bien escrita rinde más.

Vas a olvidar los archivos que hay que cargar. Es el fallo que más se repite. El comando funciona regular, y resulta que no le has dicho que lea el documento de contexto que lo cambia todo.

Los vas a crear y no los vas a mantener. Un comando que no ajustas después de usarlo se queda a medias para siempre. Trátalo como algo vivo: cada vez que corriges el resultado a mano, esa corrección debería acabar en el archivo.

Vas a tener treinta y usar cuatro. Pasa. Cada dos o tres meses, borra los que no has usado. Una lista de comandos larga y muerta es ruido.

Comandos frente a hooks

No son lo mismo y se confunden mucho.

El comando lo llamas tú cuando quieres. El hook se ejecuta solo, sin que lo llames, en el momento que hayas definido. Si lo que necesitas es que algo pase siempre (que se revise el formato, que te avise al terminar, que no toque un directorio), lo tuyo son los hooks de Claude Code, no los comandos.

Casi todo lo que la gente automatiza acaba siendo una mezcla de las dos cosas: comandos para lo que decides tú, hooks para lo que no se puede olvidar nunca.

Y ahora qué

Mira tu historial de la última semana y busca el mensaje que has escrito más de tres veces con pequeñas variaciones. Ese es tu primer comando.

Créalo hoy, aunque salga regular, y ve corrigiéndolo con el uso. Cuando lleves varios y empieces a encadenarlos, verás que has dejado de usar una IA para pedirle cosas y has empezado a montarte un sistema. Es un salto que cuento con más detalle en cómo una skill me ahorra horas.

Y si acabas de llegar a Claude Code y esto te suena a mucho, empieza por el principio: lo tengo ordenado en Claude Code para no programadores.

Montar tus propios comandos es una pieza del sistema completo que enseño en Yo SA: que el trabajo repetido lo haga la máquina y tú te quedes con las decisiones.

Ver Yo SA