ComandeskHelp Inicio

Crear Tareas Recurrentes

Objetivo

Automatizar trabajo periodico sin perder control humano. Una recurrente no debe ser "una tarea que se dispara sola y ya esta"; debe crear trabajo con contexto, proyecto, fecha, instrucciones y criterio de parada.

Esta guia es especialmente importante para tareas editoriales, reporting, mantenimiento, auditorias y cualquier proceso que se repite cada dia, semana o mes.

Que es una recurrente

Una recurrente es una plantilla que genera tareas en una frecuencia definida.

Debe responder:

  • que tarea crea;
  • cuando la crea;
  • en que proyecto;
  • con que perfil o responsable;
  • si la ejecuta humano o IA;
  • que instrucciones lleva;
  • como evita duplicados;
  • en que estado debe quedar.

Cuando usar una recurrente

Usala para:

  • revisar noticias o temas cada dia;
  • preparar informes semanales;
  • lanzar checklist de mantenimiento;
  • revisar incidencias periodicas;
  • recordar verificaciones operativas;
  • crear tareas de auditoria de skills/subagentes;
  • generar trabajo editorial que necesita aprobacion.

No la uses para:

  • decisiones que cambian mucho cada vez;
  • tareas sin proyecto;
  • acciones peligrosas sin revision;
  • procesos que aun no has probado manualmente.

Antes de crearla

Define:

  • titulo base;
  • frecuencia;
  • proyecto;
  • departamento;
  • responsable, perfil o subagente;
  • runtime/modelo si es IA;
  • instrucciones;
  • estado inicial esperado;
  • estado final esperado;
  • condicion de bloqueo;
  • criterio de terminado.

Por que importa:

  • La recurrente multiplicara cualquier error que tenga.
  • Si una plantilla esta mal, cada ejecucion genera ruido.
  • Si no hay criterio de bloqueo, puede avanzar cuando deberia esperar.

Paso 1: probar manualmente primero

Antes de automatizar, crea una tarea manual equivalente.

Comprueba:

  • el titulo se entiende;
  • el proyecto es correcto;
  • las instrucciones producen el resultado esperado;
  • el perfil/subagente es adecuado;
  • el estado final es el correcto;
  • la tarea no necesita datos que solo tu sabes.

Por que importa:

  • Automatizar un proceso no probado solo hace que el error ocurra mas rapido.
  • Una prueba manual ayuda a descubrir si falta contexto.

Paso 2: crear plantilla recurrente

Ve a Automatizacion -> Automatizaciones.

Configura:

  • nombre de plantilla;
  • frecuencia;
  • proyecto;
  • departamento;
  • tipo de ejecucion;
  • perfil/subagente si aplica;
  • modelo/runtime si aplica;
  • skills requeridos;
  • instrucciones completas;
  • fecha o regla de ejecucion.

Si la recurrente publica, despliega o crea un artefacto externo, configura tambien:

  • deployment target;
  • credencial asociada al target o al runtime;
  • contrato de salida;
  • preflight obligatorio;
  • estado final esperado.

Buenas practicas:

  • Incluye dia y mes de ejecucion en la tarea generada si ayuda a auditar.
  • Evita titulos identicos si se ejecuta a diario.
  • Si el trabajo requiere decision, deja claro que debe quedar en waiting o review.

Contrato minimo de una recurrente automatica

Una recurrente automatica debe declarar que resultado verificable espera. El contrato evita que el worker diga "terminado" sin haber dejado evidencia.

Campos recomendados:

  • automation_level: nivel de autonomia permitido.
  • preflight_required: si debe bloquear antes de ejecutar cuando falten campos.
  • completion.next_status: estado esperado al terminar.
  • requires_human_gate: si hay decision, publicacion o riesgo.
  • required_outputs: lista de evidencias minimas.
  • fallback: que hacer si falta credencial, target, input o runtime.

Ejemplos:

  • Blog WordPress: post_id, preview_url, status=draft, featured_media_id si hay imagen, categoria y autor.
  • Topics de comunidad: lista de temas, fuente/contexto usado, fecha, siguiente estado waiting o review.
  • Auditoria semanal: resumen, hallazgos, tareas propuestas y siguiente estado review.
  • Release local: version, archivo generado, commit, ruta del artefacto y bloqueo si falta repo local.

Si la salida no se puede comprobar, no deberia ir a done.

Paso 3: decidir estado inicial

Estados recomendados:

  • inbox: si alguien debe clasificarla.
  • next: si una persona debe ejecutarla.
  • queued: si IA puede ejecutarla automaticamente.
  • waiting: si la plantilla solo crea recordatorio pendiente de input.

Regla practica:

  • Si la tarea puede ejecutarse sin preguntar, puede ir a queued.
  • Si debe proponer primero, debe terminar en waiting o review.
  • Si puede publicar, desplegar o afectar cliente, requiere gate humano.

Patron editorial recomendado

Fase 1: propuesta.

  • La tarea recurrente propone temas.
  • Incluye fecha de ejecucion.
  • No desarrolla articulos completos.
  • No publica.
  • Queda bloqueada o en review hasta decision humana.

Fase 2: desarrollo.

  • Se crea una tarea nueva o se continua la existente con el tema elegido.
  • El agente desarrolla el contenido.
  • El resultado pasa a review.
  • La publicacion queda fuera salvo confirmacion.

Por que importa:

  • Separar propuesta y ejecucion evita que el sistema tome decisiones editoriales solo.
  • El usuario mantiene control sobre tema, tono y oportunidad.

Paso 4: lanzar ejecucion manual

Despues de crear o editar una recurrente, lanza una prueba manual.

Comprueba:

  • se crea una sola tarea;
  • no duplica una tarea activa del mismo dia;
  • el proyecto es correcto;
  • la fecha de ejecucion aparece;
  • el perfil/modelo es correcto;
  • las instrucciones son completas;
  • el estado resultante es el esperado.

Si falla, corrige la plantilla antes de dejarla activa.

Paso 5: revisar duplicados

Una recurrente debe evitar crear trabajo duplicado para la misma fecha si ya existe una tarea activa.

Senales de duplicado:

  • dos tareas con mismo titulo y fecha;
  • dos tareas del mismo template en el mismo dia;
  • una tarea activa y otra nueva con instrucciones identicas;
  • una tarea en review y otra en queued para el mismo trabajo.

Que hacer:

  • cerrar o archivar duplicado;
  • corregir plantilla;
  • dejar comentario en la tarea conservada;
  • verificar siguiente ejecucion.

El watchdog de recurrentes debe dejar una alerta de sistema cuando una plantilla no puede generar trabajo o queda bloqueada por una instancia viva. Si la plantilla necesita correccion, OPS crea o reutiliza una tarea de revision con tag recurring-watchdog.

Paso 6: documentar decision

Si una recurrente tiene reglas especiales, dejalas en descripcion.

Ejemplos:

  • "Debe proponer temas y esperar decision."
  • "No publicar automaticamente."
  • "Si runtime no esta disponible, bloquear con motivo."
  • "Si ya hay tarea activa del dia, reutilizar."

Por que importa:

  • Las reglas viven con la plantilla, no en memoria.
  • Otro operador debe entender que hara la automatizacion.

Checklist antes de activar

  • Plantilla probada manualmente.
  • Proyecto asignado.
  • Frecuencia correcta.
  • Fecha de ejecucion visible o inferible.
  • Perfil/runtime coherente.
  • Instrucciones completas.
  • Regla de duplicados comprobada.
  • Estado final esperado definido.
  • Human gate si hay decision o riesgo.

Errores comunes

  • Crear recurrentes sin proyecto.
  • Dejar queued para tareas que deben proponer primero.
  • No incluir fecha de ejecucion.
  • No probar manualmente.
  • No revisar duplicados.
  • Cambiar proveedor/modelo sin registrarlo.
  • Cerrar automaticamente trabajo que requiere aprobacion.

Resultado esperado

Una recurrente sana crea trabajo predecible. Al verla, deberias saber que hara hoy, por que lo hara, donde caera la tarea y cuando debe detenerse.