Skill de Atendium Workflows

La skill Atendium Workflows enseña al asistente a trabajar con el runtime conversacional real de Atendium: nodos, conexiones, ramas, facts, blackboard, pausas entre turnos, integraciones y acciones humanas.

Descargar Atendium Workflows .zip

Cómo instalarla

Descargá el ZIP con el botón de arriba.
Extraé la carpeta atendium-workflows/ completa. Conservá SKILL.md, INSTALL.md, references, scripts, fixtures, agents y evaluations; no alcanza con copiar sólo el archivo principal.
Instalala en tu asistente según la plataforma. El detalle está en INSTALL.md dentro del ZIP:

Asistente	Dónde ponerla
Cursor	`.cursor/skills/atendium-workflows/` o `.agents/skills/atendium-workflows/` del proyecto, o `~/.cursor/skills/atendium-workflows/`
Claude Code	`.claude/skills/atendium-workflows/`
Claude Projects / ChatGPT / Gemini	Subí `SKILL.md` y los `.md` de `references/` como knowledge; pegá en instrucciones que debe seguir ese `SKILL.md`
Chat genérico	Pegá `SKILL.md` al inicio de la sesión y las references relevantes antes de pedir JSON

Después pedí un workflow de Atendium o usá un comando $atendium-workflows. Este ZIP instala la skill en el asistente; el JSON del workflow es un entregable distinto que se genera al usarla.

Cuándo usarla

Crear o modificar un workflow de un agente.
Clasificar intención desde el primer mensaje.
Diferenciar WhatsApp, web u otros canales.
Aplicar días y horarios de atención.
Capturar datos durante varios turnos.
Atender, asesorar o madurar consultas con un agente conversacional compacto.
Consultar Nexus, Google Sheets o una API.
Pedir aprobación antes de una acción sensible.
Transferir una conversación a una persona.
Revisar, endurecer, simular o explicar un workflow existente.

Invocación

$atendium-workflows <comando> <objetivo o archivo>

También puede activarse al pedir naturalmente un workflow de Atendium. El comando explícito permite controlar exactamente el tipo de trabajo.

Comandos

Comando	Para qué sirve
`shape`	Indaga mediante choices y diseña la arquitectura sin generar JSON.
`build`	Genera el workflow en `draft`, escenarios mock y reporte validado.
`edit`	Modifica un workflow preservando lo que queda fuera del pedido.
`critique`	Revisa experiencia conversacional, claridad, ruteo y elección de nodos sin editar.
`audit`	Busca errores técnicos, secretos, conexiones, handles, ciclos y ramas faltantes.
`simulate`	Recorre escenarios mock sin credenciales ni efectos reales.
`validate`	Valida, corrige y repite hasta aprobar o encontrar un bloqueo concreto.
`harden`	Agrega fallbacks, expiraciones, idempotencia y participación humana.
`optimize`	Reduce nodos, llamadas LLM y consultas externas innecesarias.
`explain`	Describe el recorrido turno por turno y rama por rama.

Ejemplos

$atendium-workflows shape atención para ventas, soporte y administración
$atendium-workflows build capturar un prospecto de WhatsApp y crear un deal en Nexus
$atendium-workflows critique workflow.json
$atendium-workflows harden workflow.json
$atendium-workflows simulate workflow.json

Descubrimiento guiado

Cuando faltan decisiones importantes, la skill no obliga al usuario a conocer nodos. Hace de una a tres preguntas por tanda:

¿El tratamiento cambia según el canal?

A. Todos los canales siguen la misma lógica.
B. Cada canal tiene rutas o respuestas diferentes.
C. Sólo WhatsApp tiene tratamiento especial.
D. Otro — describilo con tus palabras.

Se puede responder de manera compacta: 1B, 2A, 3D: fuera de horario sólo tomar datos.

La entrevista puede descubrir decisiones sobre intención, canal, origen proactivo, horarios, identidad, fuente de verdad, captura, riesgo, respuesta y continuidad.

Diseño centrado en conversaciones

La skill trata todo workflow como una conversación multivuelta, no como un flujo lineal. En cualquier punto el usuario puede:

responder sólo una parte de lo pedido;
corregir un dato anterior;
cambiar de tema o interrumpir con una pregunta;
pedir volver atrás, cancelar o reiniciar;
solicitar una persona.

Por eso cada espera define cómo continuar, qué facts conservar, cuáles invalidar y desde qué nodo reanudar. Un cambio temporal puede responder la nueva consulta y volver al proceso pendiente; un cambio permanente puede abandonar la rama anterior y limpiar únicamente sus datos.

Los retornos no se dibujan como ciclos. El workflow mantiene un DAG válido y vuelve lógicamente mediante estado persistido, nextStartNodeId o ruteo de reentrada. Así puede regresar a una captura anterior sin repetir identidad, saludo ni información todavía válida.

La skill contempla las políticas de conversación y el catálogo de facts del runtime: corrección, interrupción, reanudación, cambio de tema y limpieza de dependencias. Comprueba la configuración actual antes de habilitarlas y conserva las políticas existentes al editar. El mock modela decisiones aportadas por el escenario; la clasificación real y la persistencia se verifican con el harness del runtime.

Diseño conversacional compacto

Para atención, asesoramiento, venta consultiva y maduración, la skill parte de un agente conversacional con memoria y captura de facts. Separa rutas cuando cambian el objetivo, el conocimiento, los permisos o las acciones. El grafo representa decisiones operativas, no cada pregunta del guion.

Usá agente para conducir una conversación abierta y descubrir datos de forma progresiva.
Usá captura tipada (collect) cuando completar y validar datos es el objetivo explícito o una precondición real de una acción.
Tener datos comerciales por descubrir no convierte una conversación en un formulario.
La pregunta de cada dato vive en el slot del collect. Un mensaje previo que espera y después entra al collect descarta la respuesta y repite la pregunta; el texto de contexto va en el mismo turno, sin esperar.

Optimizá turnos obligatorios, repeticiones y claridad del canvas, preservando controles y efectos verificables; no persigas un número fijo de nodos.

Criterios de construcción

Texto exacto usa mensaje fijo; razonamiento abierto usa agente.
Datos tipados y multivuelta usan captura estructurada.
Canal, horario, texto e intención utilizan el router específico.
Las operaciones de Nexus usan el nodo nativo antes que HTTP manual.
Una aprobación puntual y una transferencia humana no son lo mismo.
Las credenciales nunca se escriben dentro del workflow.
Todas las ramas importantes incluyen fallback, error o salida terminal.

Cobertura del canvas y los nodos

La revisión del 22 de octubre de 2026 cubre los 26 tipos de nodo del canvas React, el formulario de configuración y el esquema y runtime compartidos. Incluye agente, mensaje fijo, variables, transformación, código, HTTP, Google Sheets, mock, condiciones por datos/horario/mensaje/origen, routers de intención/canal, captura, notas, subagentes, derivación, aprobación, llamadas a workflow/agente, WhatsApp Flow, voz, Nexus CRM, acciones de conversación y salida silenciosa.

La skill distingue los nodos CRM secuenciales de las tools CRM opt-in del agente, contempla reutilizar oportunidades con deal.ensure y documenta requisitos y ramas de error. También guía RAG por nodo, elección de modelo, diseño conversacional compacto y resultado final.

Validación funcional con mocks

La skill incluye un simulador offline. El asistente genera un archivo de escenarios que indica qué salida debe tomar cada nodo y qué camino o efecto se espera.

python3 scripts/validate_and_simulate.py workflow.json \
  --scenarios scenarios.json \
  --report report.json

La simulación puede comprobar:

datos completos e incompletos;
éxito y error de Nexus, Sheets o HTTP;
aprobación, rechazo y vencimiento;
fallback de intención;
diferencias por canal y horario;
corrección de datos y limpieza de facts dependientes;
cambio de intención y retorno al proceso pendiente;
preservación de identidad y otros facts transversales entre turnos;
nodo terminal o handoff esperado.

Con un checkout de Atendium y sus dependencias instaladas, agregá --repo /ruta/al/repositorio --require-native al comando para ejecutar además el validador nativo. El reporte falla si esa validación no puede realizarse. Sin checkout, queda expresamente pendiente.

Los escenarios permiten afirmar efectos prohibidos y cantidades, y comprueban el resultado también cuando hay una pausa. No ejecutan las condiciones ni los modelos: las ramas se especifican en el escenario. El simulador lineal señala los casos de fan-out que necesitan el harness nativo.

Los efectos aparecen como mocked: true: no se envían mensajes ni se modifican sistemas externos.

Resultado de `build`

Una construcción completa entrega:

Resumen de entrada, rutas, identidad y acciones.
Workflow en draft, o plan semántico identificado como tal y pendiente de compilar antes de validar el JSON persistido.
IDs y credenciales pendientes claramente señalados.
Escenarios mock.
Reporte de validación.
Límites de lo que todavía requiere prueba real.

Continuidad comercial opcional

Cuando una rama produce una demo, cotización, lead o deal que necesita seguimiento posterior, la skill puede sugerir Nexus después de entregar el workflow. Si el flujo combinado ya fue solicitado, continúa con Nexus dentro de ese alcance. La recomendación identifica el nodo y la rama determinística de origen, evita duplicar mutaciones ya realizadas y ofrece un prompt listo para $nexus-sales-automations.

La sugerencia es opcional y no bloquea el workflow. Cuando Nexus no fue solicitado, la sugerencia no ejecuta la otra skill y no inventa pipeline, etapa, owner, SLA ni cadencia. Si el caso es sólo informativo o no requiere seguimiento, no muestra la recomendación.

Límites

Los mocks no verifican credenciales, permisos, entrega efectiva de mensajes, existencia de recursos ni respuestas reales de modelos o APIs. Activar o ejecutar efectos reales requiere autorización y una prueba controlada posterior.