ComandeskHelp Inicio

Crear y Verificar Flujos

Objetivo

Definir procesos reutilizables que generen trabajo consistente. Un flujo es una receta operativa: ayuda a repetir una forma de trabajar sin depender de memoria, improvisacion o instrucciones sueltas.

No sustituye a una tarea ni a un plan. El flujo describe como se hace un tipo de trabajo; la tarea representa una ejecucion concreta; el plan decide en que orden se hace dentro del proyecto.

Flujo, plan y contrato de fases

Estas piezas se parecen, pero no son lo mismo:

Pieza Pregunta que responde Salida
Flujo Como repetimos este tipo de trabajo? Receta reusable, defaults, pasos y gates
Plan Que vamos a conseguir en este proyecto y en que orden? Fases, entregables, riesgos y tareas
Contrato de fases Que debe cumplir una ejecucion concreta para avanzar o parar? Preflight, gates, evidencias y estado final

Ejemplo:

  • Flujo: publicar cambio del FDS.
  • Plan: mejorar Flowtitude Design System durante mayo.
  • Contrato: generar .windpress, subir version al repo, crear borrador de noticia, generar imagen y bloquear antes de publicar si falta revision.

Un subagente orquestador puede usar o proponer flujos, pero el flujo no debe convertirse en un cajon enorme. Si un proceso se repite, se guarda como flujo. Si solo pertenece a una iniciativa, se queda en el plan.

Que es un flujo

Un flujo puede incluir:

  • nombre;
  • descripcion;
  • categoria;
  • pasos;
  • inputs necesarios;
  • outputs esperados;
  • perfil/subagente recomendado;
  • skills recomendados;
  • criterios de verificacion;
  • condicion de bloqueo o revision humana.

Ejemplo:

  • Flujo: "Crear post de LinkedIn".
  • Tarea: "Crear post LinkedIn sobre orquestar OPS, 8 mayo".
  • Plan: "Fase promocion inicial OPS".

Cuando crear un flujo

Crea un flujo cuando:

  • repites un proceso varias veces;
  • quieres que otros lo ejecuten igual;
  • una tarea requiere varios pasos estables;
  • una recurrente necesita instrucciones consistentes;
  • quieres auditar si el proceso funciona;
  • hay riesgo de olvidar una comprobacion.

No crees flujo si:

  • es una accion unica;
  • aun no sabes como se hace;
  • el proceso cambia en cada ejecucion;
  • solo necesitas una checklist breve en una tarea.

Paso 1: definir problema y salida

Antes de crear el flujo, define:

  • que problema resuelve;
  • que input necesita;
  • que output produce;
  • quien revisa;
  • que se considera valido.

Por que importa:

  • Un flujo sin salida clara se convierte en documentacion decorativa.
  • Si el output no es verificable, cada ejecucion sera subjetiva.

Paso 2: dividir en pasos

Un buen flujo tiene pasos pequenos.

Ejemplo de pasos para contenido:

  1. Recoger contexto.
  2. Proponer enfoque.
  3. Esperar decision si hay varias opciones.
  4. Redactar borrador.
  5. Revisar tono y claims.
  6. Preparar version final.
  7. Pasar a review.

Ejemplo de pasos para despliegue:

  1. Confirmar rama/cambios.
  2. Ejecutar tests/build.
  3. Crear backup si aplica.
  4. Desplegar.
  5. Verificar URL.
  6. Registrar resultado.

Por que importa:

  • Los pasos pequenos permiten bloquear donde toca.
  • Mezclar todo en un paso hace mas dificil detectar fallo.

En Komandesk, los pasos simples tambien generan un contrato interno lineal en meta.flow_contract.

Ese contrato convierte cada linea en un nodo con tipo aproximado:

  • trigger_context: entrada, brief o trigger del trabajo;
  • plan_spec: alcance, especificacion o criterio de salida;
  • ai_work: trabajo general asistido por IA;
  • code_change: implementacion o cambio concreto en codigo/configuracion;
  • test_qa: tests, QA, smoke, preflight o evidencia tecnica;
  • code_review: revision de diff, PR o calidad del cambio;
  • human_gate: decision o aprobacion humana;
  • deploy_publish: despliegue, release o publicacion;
  • docs_comms: documentacion, changelog o comunicacion;
  • create_tasks: generacion de subtareas;
  • wait_schedule: espera, retry o disparo programado;
  • integration: integraciones, APIs o servicios externos;
  • rollback: vuelta atras o restauracion segura.

Los tipos legacy se aceptan por compatibilidad y se canonizan al guardar:

  • agent_task -> ai_work;
  • verify -> test_qa;
  • publish -> deploy_publish.

La UI simple no obliga al usuario a entender esta estructura. Sirve para que, mas adelante, el mismo flujo pueda abrirse en un editor visual de nodos sin rehacer datos.

Cuando edites un flujo existente puedes ajustar el tipo de cada nodo desde el modo simple. Usa esto cuando el texto del paso sea ambiguo pero operacionalmente necesite comportarse como contexto, spec, cambio de codigo, QA, review, gate humano, despliegue, documentacion, integracion, espera o rollback.

Mapa visual y edicion

El mapa visual sirve para entender el flujo sin leer una descripcion larga. Debe priorizar claridad:

  • vertical si el flujo tiene muchos pasos o gates;
  • horizontal solo para procesos cortos;
  • nodos con etiquetas cortas;
  • gates humanos visibles;
  • verificaciones y publicaciones diferenciadas.

Ahora la UI separa dos capas:

  • Editor simple: el formulario principal para crear o editar manualmente por pasos.
  • Vista avanzada de grafo: inspeccion administrativa del contrato lineal, con familias de nodo, requisitos, gates y outputs.

Para editar o crear un flujo, empieza por el modo simple:

  1. Nombre y descripcion.
  2. Pasos en lenguaje normal.
  3. Trigger, estado y defaults basicos si hacen falta.
  4. Guardar o revisar el resumen manual.

No hace falta abrir la vista avanzada para crear un flujo valido. Esa parte no debe interrumpir al usuario no tecnico.

Crear manualmente en modo simple

En Producto -> Flujos -> Nuevo flujo:

  1. Escribe nombre y objetivo.
  2. Anade los pasos, uno por linea.
  3. Usa los accesos rapidos si quieres acelerar pasos frecuentes como contexto, plan, QA o gate.
  4. Revisa el resumen manual.
  5. Ajusta trigger, categoria y estado.
  6. Guarda.

La UI genera el contrato lineal por debajo. Si el texto del paso es suficientemente claro, OPS infiere el tipo de nodo y no hace falta tocar nada mas.

Inspeccionar en vista avanzada

Abre Vista avanzada de grafo solo cuando necesites validar el flujo con mas precision.

Sirve para:

  • comprobar en que familia cae cada nodo: entrada, ejecucion, control o salida;
  • detectar si faltan gates humanos antes de publicar o desplegar;
  • revisar que QA y review aparezcan como checkpoints;
  • ver que outputs produce cada fase sin leer toda la descripcion;
  • corregir el tipo de un nodo ambiguo sin rehacer los pasos.

El selector de tipo ya no aparece como lista caotica. Se agrupa por familias:

  • Entrada y alcance: contexto y plan/spec.
  • Trabajo e integraciones: trabajo IA, codigo e integraciones.
  • Control y decisiones: QA, review, gates, espera y rollback.
  • Salida y seguimiento: deploy, documentacion y tareas derivadas.

La vista avanzada sigue siendo de inspeccion. No convierte el flujo en un n8n completo ni habilita ramas ejecutables que el runtime todavia no soporte.

Ajustar tipos solo cuando aporte claridad

Abre el selector de tipos cuando:

  • el paso dice algo ambiguo como "validar entrega" y necesitas marcarlo como test_qa;
  • una aprobacion debe quedar visiblemente como human_gate;
  • una fase realmente es docs_comms, deploy_publish o create_tasks y quieres que se vea en el grafo.

Evita usarlo para microajustes innecesarios. El modo simple sigue siendo la fuente principal para crear.

Defaults y avanzado operativo

Despues, si aplica, entra en Avanzado para configurar:

  1. Perfil, agente y modelo por defecto.
  2. Skills por defecto.
  3. Deployment target.
  4. Playbook path si es un flujo documental.
  5. Flag ejecutable cuando ya tenga contrato y preflight listos.

Cuando el flujo se marca como ejecutable, OPS ya no confunde "base valida" con "listo para correr". El preflight separa:

  • Base minima OK: nombre, pasos y contrato basico alineado.
  • Listo para ejecutar: ademas de lo anterior, el flujo cumple los controles estrictos que el runner necesita.

Reglas practicas del modo estricto:

  • test_qa exige evidencia esperada en contrato: verification_result y qa_evidence.
  • deploy_publish exige control de salida sensible:

- gate humano, o

- deployment target activo con rollback definido.

  • integration y acciones sensibles deben dejar un bloqueo recuperable si faltan credenciales o acceso externo.
  • El borrador de tarea hereda execution_contract con preflight_required, evidence_required, blocked_fallback y criterios de aceptacion derivados del flujo.

Flujo recomendado de edicion

Para mantener la UI ligera:

  1. Crea o corrige pasos en el editor simple.
  2. Abre la vista avanzada solo para inspeccionar o retipar nodos.
  3. Revisa preflight.
  4. Ajusta defaults IA si hacen falta.
  5. Prueba con una tarea.

El editor visual debe ayudar a ver y ajustar, no obligar al usuario a disenar un grafo tecnico desde cero. Si el usuario no sabe que nodo usar, el texto del paso debe bastar para que OPS proponga un tipo.

Si el flujo necesita mas variedad de tipos, prioriza la semantica del paso y no llenar la UI de botones: los accesos rapidos cubren lo frecuente y el selector de tipo resuelve el resto.

Paso 3: asignar defaults IA

Si el flujo puede usar IA, define:

  • perfil/subagente recomendado;
  • runtime o modelo si aplica;
  • skills necesarios;
  • operating mode;
  • nivel de autonomia;
  • reglas de bloqueo.

Regla:

  • El perfil representa la capacidad funcional.
  • El runtime representa la herramienta que ejecuta.
  • No confundas ambos: cambiar runtime no deberia cambiar el rol del flujo.
  • Usa el selector de skills para anadir slugs existentes desde la biblioteca del workspace.
  • Si un skill no debe cargarse en nuevas ejecuciones, pausalo antes de crear tareas desde el flujo.

Ejemplo:

Para un flujo de publicacion de cambio en FDS:

  1. Perfil: frontend-implementer para preparar artefactos tecnicos.
  2. Skills: instrucciones de WindPress, documentacion y publicacion.
  3. Target: maquina local o repositorio donde se genera el paquete.
  4. Gate humano: revisar noticia, imagen y changelog antes de publicar.

Paso 4: definir human gate

Un flujo debe pedir decision humana cuando:

  • hay que elegir entre opciones;
  • se va a publicar;
  • se va a desplegar;
  • afecta a cliente;
  • cambia configuracion sensible;
  • consume creditos o coste relevante;
  • no hay evidencia suficiente.

Por que importa:

  • La autonomia sin limites genera resultados rapidos pero poco fiables.
  • El gate correcto permite avanzar sin poner en riesgo datos, clientes o produccion.

Paso 5: crear flujo en OPS

Ve a Producto -> Flujos.

Configura:

  • nombre accionable;
  • descripcion;
  • categoria;
  • pasos;
  • perfil/modelo/skills por defecto si aplica;
  • si es ejecutable o solo documental;
  • criterios de verificacion.

Buenas practicas:

  • Empieza simple.
  • Evita meter diez variantes en un mismo flujo.
  • Si un flujo crece demasiado, separalo en dos.
  • Si un flujo depende de credenciales, mencionalo.
  • Para crear una variante, duplica el flujo: la copia queda inactiva hasta que la revises.
  • Activa solo los flujos que ya tengan preflight revisado.
  • Usa Actividad para confirmar quien creo, edito, duplico o lanzo una tarea desde el flujo.
  • Usa Salud para revisar todos los flujos antes de una ronda de trabajo o despliegue.
  • Usa Desglose para revisar como se repartirian las fases por executor y estado antes de crear automatismos mas agresivos.
  • Para flujos que deban ejecutarse en un ordenador concreto, registra un deployment target de tipo local_machine.
  • Si un flujo tiene target por defecto, las tareas generadas desde ese flujo quedan vinculadas a ese target.
  • Si necesitas replicar un flujo entre workspaces de la misma empresa, usa Gestion -> SaaS / Empresas -> Copiar. La copia queda en el workspace destino sin cruzar credenciales ni referencias peligrosas.

Paso 6: verificar con tarea de prueba

No marques un flujo como bueno sin probarlo.

Prueba:

  1. Abrir el flujo.
  2. Ejecutar preflight.
  3. Crear tarea desde el flujo.
  4. Revisar el borrador antes de confirmarlo.
  5. Confirmar perfil/modelo/skills.
  6. Revisar instrucciones heredadas.
  7. Ejecutar en modo controlado.
  8. Revisar output.
  9. Ajustar flujo.

Por que importa:

  • La prueba revela si faltan inputs.
  • Tambien revela si el flujo crea tareas demasiado grandes.
  • El borrador evita tareas sorpresa: antes de crearla se ve titulo, descripcion, estado, executor, modelo y skills.
  • El preflight ahora muestra faltantes accionables por capa: base minima, readiness ejecutable y avisos.
  • La descripcion de la tarea incluye el contrato operativo y el execution_contract guarda evidencia requerida, criterios de aceptacion y bloqueo recuperable para el runner.

Tutorial 1: crear un flujo manual de desarrollo

Usalo para cambios de producto, bugs, refactors pequenos o mejoras tecnicas que puedan pasar por review.

Objetivo del flujo:

  • convertir una peticion tecnica en una tarea ejecutable;
  • asegurar spec, implementacion, QA, review y documentacion;
  • evitar que el worker toque produccion sin evidencias.

Pasos recomendados:

  1. Recoger contexto del proyecto, rama, modulo afectado y enlaces utiles.
  2. Redactar spec breve con alcance, no alcance y criterios de aceptacion.
  3. Implementar el cambio en una rama o workspace controlado.
  4. Ejecutar tests, lint o smoke segun el tipo de cambio.
  5. Revisar diff y riesgos residuales.
  6. Bloquear en human gate si hay migracion, despliegue, credenciales o cambio sensible.
  7. Registrar evidencia, tiempo y siguiente paso.
  8. Actualizar docs o changelog si cambia comportamiento visible.

Tipos de nodo que deberian aparecer:

  • trigger_context para el contexto inicial;
  • plan_spec para la spec;
  • code_change para la implementacion;
  • test_qa para pruebas;
  • code_review para revisar el diff;
  • human_gate solo cuando haya decision real;
  • docs_comms si hay documentacion;
  • deploy_publish si el flujo incluye despliegue.

Criterio de salida:

  • hay commit o diff verificable;
  • se sabe que pruebas se ejecutaron;
  • si algo queda pendiente, esta registrado como bloqueo o siguiente tarea;
  • no hay cambios sensibles sin aprobacion humana.

Errores a evitar:

  • un unico paso llamado "hacer la tarea";
  • QA sin evidencia concreta;
  • publicar o desplegar dentro del mismo paso de implementacion;
  • crear una tarea enorme que mezcle refactor, feature, docs y release.

Tutorial 2: crear un flujo de contenido con seleccion humana

Usalo para comunidad, LinkedIn, newsletters, ideas de posts o investigacion editorial.

Objetivo del flujo:

  • buscar opciones;
  • presentarlas de forma compacta;
  • permitir que una persona elija una o varias;
  • crear tareas derivadas solo con las opciones aprobadas.

Pasos recomendados:

  1. Recoger tema, audiencia, canal y restricciones de tono.
  2. Buscar o generar opciones candidatas.
  3. Normalizar cada opcion con titulo, enlace/fuente, angulo y valor para la comunidad.
  4. Bloquear con decision humana si hay varias opciones.
  5. Crear tareas solo para las opciones seleccionadas.
  6. Redactar o preparar assets.
  7. Pasar a review antes de publicar.
  8. Registrar que opcion se eligio y por que.

Tipos de nodo que deberian aparecer:

  • trigger_context para tema/canal;
  • ai_work o integration para busqueda;
  • human_gate para seleccion simple o multiple;
  • create_tasks cuando la seleccion genera trabajo;
  • docs_comms para pieza final;
  • deploy_publish solo si se publica desde el flujo.

Criterio de salida:

  • las opciones se ven sin ruido tecnico;
  • el detalle queda desplegable para quien lo necesite;
  • la tarea sabe si la decision era radio o multiple;
  • el registro tecnico queda guardado, pero no domina la vista humana.

Tutorial 3: crear un flujo recurrente de mantenimiento

Usalo para escaneos semanales, revisiones de dependencias, evidencia tecnica, checks de seguridad o mantenimiento preventivo.

Objetivo del flujo:

  • convertir una recurrente en trabajo revisable;
  • separar hallazgo, priorizacion y accion;
  • evitar que cada escaneo ensucie proyectos de producto.

Pasos recomendados:

  1. Ejecutar el escaneo o recoger la evidencia.
  2. Clasificar hallazgos por proyecto correcto o por mantenimiento general.
  3. Descartar duplicados y ruido.
  4. Crear tareas solo si el hallazgo es accionable.
  5. Bloquear con decision humana si afecta roadmap, cliente o produccion.
  6. Ejecutar fix pequeno si esta dentro del alcance permitido.
  7. Registrar evidencia, tiempo y recomendacion.
  8. Archivar la tarea recurrente si no produjo accion util.

Tipos de nodo que deberian aparecer:

  • wait_schedule para el disparo recurrente;
  • integration si consulta servicios externos;
  • ai_work para clasificar;
  • create_tasks para acciones derivadas;
  • human_gate para priorizacion sensible;
  • test_qa para verificar fixes;
  • docs_comms para registrar aprendizaje.

Criterio de salida:

  • el hallazgo esta en el proyecto correcto;
  • mantenimiento no se mezcla con producto salvo que haya una accion real del producto;
  • cada tarea derivada tiene spec corta, evidencia y estimacion;
  • si no hay accion, queda claro que se reviso y se cerro.

Tutorial 4: convertir un flujo en una tarea ejecutable

Antes de crear tareas desde un flujo, revisa esta checklist:

  1. El flujo tiene una salida verificable.
  2. Los pasos caben en una ejecucion razonable.
  3. Hay criterios de aceptacion escritos.
  4. El perfil, skills y modelo por defecto tienen sentido.
  5. Las credenciales o accesos necesarios estan claros.
  6. El preflight no marca faltantes criticos.
  7. El human gate aparece solo donde aporta control real.
  8. La tarea resultante incluye estimacion de tiempo.

Si falla un punto, no ejecutes todavia. Corrige el flujo o crea una tarea preparatoria.

Regla practica:

  • Si el flujo no puede explicar como sabremos que termino bien, aun no esta listo.
  • Si el flujo necesita mas de una decision humana central, probablemente debe dividirse.
  • Si el flujo genera varias piezas independientes, crea subtareas en vez de una sola tarea grande.

Tutorial 5: revisar si un flujo es bueno

Un flujo bueno debe poder responder estas preguntas en menos de un minuto:

Pregunta Senal buena Senal mala
Que dispara el flujo? Entrada concreta "Cuando haga falta"
Que produce? Entregable verificable Texto generico
Donde puede fallar? Riesgos o bloqueos visibles Fallos escondidos en descripcion
Quien decide? Gate humano claro Todo automatico por defecto
Como se prueba? QA/evidencia definida "Revisar que este bien"
Como termina? Estado final y registro Queda abierto sin criterio

Abogado del diablo:

  • No todo proceso merece un flujo.
  • Un flujo muy perfecto puede ser mas lento que una buena tarea.
  • Un flujo visual bonito no sirve si el contrato de ejecucion es ambiguo.
  • La automatizacion solo es valiosa si reduce decisiones repetidas, no si oculta decisiones importantes.

Relacion con recurrentes

Una recurrente decide cuando nace trabajo.

Un flujo decide como debe hacerse.

Ejemplo:

  • Recurrente: "cada lunes crear tarea de newsletter".
  • Flujo: "proceso para preparar newsletter".

Separar ambos evita que una plantilla recurrente se vuelva enorme e inmantenible.

Relacion con skills

Un skill aporta conocimiento especializado.

Un flujo organiza pasos.

Ejemplo:

  • Skill: "redaccion editorial B2B".
  • Flujo: "crear post LinkedIn".

El flujo puede requerir el skill, pero no debe duplicar todo su contenido salvo lo necesario.

Errores comunes

  • Crear flujos antes de entender el proceso.
  • No probar el flujo con una tarea real.
  • Mezclar ejecucion, revision y publicacion sin gate.
  • Meter demasiadas variantes.
  • No actualizar el flujo cuando cambia el sistema.
  • Confundir perfil con runtime.

Resultado esperado

Un flujo bueno permite que otra persona o agente ejecute un proceso con menos ambiguedad, dejando claro que inputs necesita, que pasos sigue, cuando se bloquea y como se valida.