Guardar y reutilizar un workflow de Claude Code
Hola, bienvenido. En la lección anterior aprendimos a seguir un workflow en marcha desde /workflows, y en esta lección vamos a quedarnos con uno. 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.
¿Por qué 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 claude-tasks tiene un uso claro: cada vez que añadamos un endpoint, como el de 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í. Todo lo que veremos es de la 2.1.283, la versión del curso.
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 cómo está montado claude-tasks, 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 en la lección Tu primer workflow con /deep-research y ultracode: 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. Desde la versión 2.1.216, 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