flujo-de-trabajo/agent-workflow

Creación de un Flujo de Trabajo

Un Flujo de Trabajo es una unidad de proceso reutilizable que traduce "lo que el usuario quiere hacer" en "qué hacer primero, qué después, qué herramienta usa cada paso y qué produce". Esta habilidad te guía desde los requisitos del usuario hasta un archivo WORKFLOW.md que cumple con la especificación docs/workflow/index.md.

Lee la especificación antes de crear: docs/workflow/index.md (divulgación progresiva de tres niveles, correspondencia uno a uno entre grafo y paso, reglas de proceso, convenciones de llamada a herramientas).

Cuándo Usarlo

• El usuario pide "crear un flujo de trabajo / proceso / flujo estandarizado"
• El usuario describe una tarea de varios pasos que quiere solidificar en un flujo de ejecución automática
• El usuario pide modificar o mejorar un flujo de trabajo existente
• El usuario hizo algo reutilizable y de varios pasos en la sesión y dice "solidifica este flujo"

Proceso de Creación

Fase 1: Comprender la Intención

Primero entrevista; no te apresures a escribir archivos:

1. ¿Qué tarea resuelve? Dale un nombre a la clase de tarea (ej. "revisión de código", "notas de versión").
2. Escenario de activación: ¿cuándo lo usará el usuario? Recopila palabras de activación (chino + inglés).
3. Entradas y salidas: ¿qué entradas se necesitan (archivos/directorios/cadenas)? ¿Qué se produce (archivos/informes)?
4. Pasos existentes: ¿el usuario ya tiene un flujo habitual? Extrae secuencias de llamadas a herramientas, correcciones y formatos de entrada/salida del historial de la sesión.
5. Límites y reglas: ¿qué no se debe hacer? ¿Dónde van los artefactos? ¿Cómo se manejan los fallos?

Completa la información faltante con ask_user antes de pasar a la siguiente fase.

Fase 2: Diseñar el Diagrama de Flujo

Dibuja el flujo de ejecución con mermaid, siguiendo la regla de correspondencia grafo-paso (espec 5.2.1):

• Cada nodo debe tener una sección de paso correspondiente; cada paso debe aparecer una vez en el grafo
• Los nombres de los nodos coinciden exactamente con los nombres de los pasos y son globalmente únicos (el prefijo step-N no necesita aparecer en los nodos)
• Los nodos de decisión usan diamantes {}, también deben tener una sección de paso, y usan Branch para indicar a dónde va cada rama
• Los pasos paralelos (dispersión) son un solo nodo en el grafo
• El grafo debe estar completo: inicio, ramas, fin

Muestra el grafo al usuario para confirmación antes de escribir los pasos.

Fase 3: Escribir el WORKFLOW.md

Crea el directorio y los archivos bajo <workspace>/workflows/<nombre>/:

1. frontmatter (metadatos de Nivel 1):
   • name: en kebab-case, coincidiendo con el nombre del directorio, solo letras minúsculas/dígitos/guiones
   • description: función + momento de uso + palabras de activación (chino e inglés), determina la tasa de activación
   • inputs / outputs: declarar explícitamente, marcar como requeridos
   • version / tags: opcional
2. Resumen: un párrafo que indique qué hace, cuándo usarlo y qué produce
3. Diagrama de flujo: el grafo mermaid coherente con la Fase 2
4. Pasos: una sección ### <id>: <nombre> por paso, con atributos: Tools / Input / Depends on / Action / Check (los nodos de decisión agregan Branch, opcionalmente when)
5. Reglas de proceso: restricciones de orden, dependencias de datos, compuertas de validación, restricciones de efectos secundarios, verificación de estado final
6. Convenciones de llamada a herramientas: preferir herramientas integradas, scripts como alternativa, leer más escribir menos, convenciones de ruta

Divulgación progresiva: coloca tablas largas en REFERENCES.md, lógica determinista en scripts/, mantén el cuerpo ligero (<500 líneas).

Fase 4: Autoverificación y Validación

Después de escribir, verifica contra la especificación:

• Correspondencia uno a uno grafo-paso: no hay nodos "huérfanos" en el grafo, ni pasos "huérfanos" en las secciones
• Nombres de nodo únicos y coincidentes con los nombres de los pasos
• Cada paso tiene un Check concreto y decidible (ej. "el archivo existe y no está vacío", no "confirmar éxito")
• Los nombres de herramienta son precisos (read_file / exec, no "ver el archivo")
• inputs / outputs coherentes con las referencias de los pasos
• Las reglas cubren el manejo de fallos (reintento / reversión / preguntar al usuario)
• La description del frontmatter incluye función y palabras de activación

Usa workflow_list para confirmar que el nuevo flujo de trabajo se ha detectado, y workflow_get <nombre> para verificar que es legible.

Fase 5: Entrega

Informa al usuario:

• El nombre y la ruta del flujo de trabajo
• El escenario de activación (qué frase lo activa)
• Una visión general del flujo (cuántos pasos, decisiones/paralelismo)
• Opcional: sugiere 2-3 solicitudes de prueba reales para verificar que funciona

Modificación de un Flujo de Trabajo Existente

• Lee el contenido actual con workflow_get <nombre> primero
• Mantén el name en el frontmatter y el nombre del directorio sin cambios
• Sigue la misma especificación para los cambios; ejecuta la autoverificación de la Fase 4 después de editar

Notas

• Solo escribe en el espacio de trabajo workflows/, nunca modifiques flujos de trabajo integrados de solo lectura; un flujo de trabajo del espacio de trabajo con el mismo nombre anula al integrado
• Un flujo de trabajo resuelve una clase de tarea; no acumules flujos no relacionados
• Mantén los pasos entre 3 y 8; si son más, divide o referencia un subflujo
• Nunca escribas instrucciones maliciosas o engañosas; las reglas deben ser auditables