Guardar y reutilizar un workflow de Claude Code
Hola, bienvenido. En esta lección vamos a quedarnos con un workflow, después de aprender en la lección anterior a seguir uno en marcha desde /workflows. La ejecución de audit-endpoints que lanzamos hace 2 lecciones hizo lo que queríamos, así que vamos a guardarla como comando del proyecto en .claude/workflows/, a lanzarla por su nombre, a adaptarla para que reciba datos con args y a editarla con la skill /workflow-authoring. Terminaremos con los patrones que hacen que un workflow sea más fiable que una sola pasada y con el commit del workflow guardado.
Merece la pena guardarlo porque lo que se puede repetir de un workflow es la orquestación entera: qué se reparte entre qué agentes, cómo se cruzan sus resultados y qué se hace con los hallazgos que no se sostienen. Si vuelves a escribir el prompt cada vez, Claude escribe un script nuevo cada vez, y cada uno puede repartir el trabajo de otra forma. Guardado, el mismo proceso se ejecuta igual en cada rama, y en nuestro proyecto tiene un uso claro: cada vez que añadamos un endpoint, como el que añadiremos en la lección de Spec-Driven Development, podemos auditarlo con la misma orquestación que ya hemos revisado.
Para seguir esta lección necesitas la ejecución de audit-endpoints en la lista de /workflows, así que trabaja en la misma sesión de las 2 lecciones anteriores. Si ya no aparece, vuelve a lanzar el prompt de la lección Tu primer workflow con /deep-research y ultracode y revisa el script como vimos allí.
Guardar la ejecución como comando
Abre /workflows, selecciona la ejecución de audit-endpoints y pulsa s. Se abre el diálogo de guardado, donde Tab cambia entre las 2 ubicaciones posibles y Enter guarda:
| Ubicación | Para quién |
|---|---|
.claude/workflows/ en el proyecto |
Todo el que clone el repositorio |
~/.claude/workflows/ en tu carpeta personal |
Solo tú, en todos tus proyectos |
Si tienes definida la variable CLAUDE_CONFIG_DIR, la ubicación personal es la carpeta workflows/ dentro de esa ruta, y el diálogo te enseña la ruta completa para que no haya dudas.
Para audit-endpoints elegimos la del proyecto, y el motivo es el mismo que con los subagentes: la auditoría depende de route-contract-auditor y de nuestra configuración, así que su sitio es el repositorio, junto al agente que usa. La ubicación personal encaja mejor con un workflow que no dependa de ningún proyecto. Y si alguna vez tienes uno de cada con el mismo nombre, se ejecuta el del proyecto.
Al guardarlo, Claude Code escribe en .claude/workflows/ un archivo .js con el script de la ejecución, que tiene la forma que vimos al lanzarlo: el bloque meta y el cuerpo que orquesta los agentes. En el curso no lo reproducimos, porque es el script que Claude escribió para tu ejecución y el tuyo no va a coincidir letra a letra con el de nadie. Lo que sí tiene que coincidir es lo que revisaste antes de aprobarlo. Además, Claude Code comprueba antes de escribir que ni .claude, ni .claude/workflows, ni el propio archivo son un enlace simbólico, y si lo son te enseña un error en lugar de escribir fuera del sitio que has elegido.
- 02Lanzarlo por su nombre
- 03Pasarle datos con args
- 04Editar el script con /workflow-authoring
- 05Los patrones que lo hacen fiable
- 06Hacer el commit