task_start
LLÁMALA LO PRIMERO, antes de empezar a hacer una tarea recurrente: la pone en ejecución (in_progress) a tu nombre para que otras IAs no la cojan. Solo se puede con tareas activas; si ya está en ejecución devuelve un error con quién la tiene y desde cuándo: entonces NO la hagas. Al acabar, task_done; si la dejas sin hacer, task_release. TAREAS RECURRENTES: algo que hay que hacer una y otra vez (revisar vulnerabilidades, actualizar un paquete, renovar un certificado…). Su content DEBE definir con claridad (1) la actuación a realizar y (2) cómo comprobar que ha salido bien (criterio de éxito verificable), porque cada vez que se hace se registra un resultado y se juzga contra ese criterio. Tiene un calendario: cada intervalCount intervalUnit (day, week, month, year), la próxima fecha (nextDueDate, día del calendario del usuario) y el modo: from_done (la siguiente se cuenta desde el día en que se hizo, por defecto) o fixed (mantiene su calendario aunque se haga tarde). Prioridad como las issues: low, medium (por defecto), high o critical. ESTADOS (state): draft (borrador: en preparación, no está activa, no vence ni avisa), scheduled (programada: activa pero aún no es el momento), due (para realizar: activa y vencida, ya se puede hacer) e in_progress (en ejecución: alguien la está haciendo). Se crea en draft; pásala a active con tasks_update status active cuando el content tenga la actuación y cómo comprobarla (o créala ya con status active si los tiene). CÓMO EJECUTAR UNA: lo PRIMERO, antes de hacer nada, llama a task_start: la marca en ejecución para que otras IAs no la cojan. Si task_start falla porque ya está en ejecución, NO la hagas: la tiene otro. Coge solo las due salvo que el usuario te pida otra. Al terminar, registra el resultado con task_done: result success si se hizo y se comprobó según el criterio del content, o warning si se hizo pero hubo problemas o no se pudo comprobar del todo (explica cuáles en el comment). El comment debe ser autosuficiente: qué revisaste, qué encontraste y qué hiciste (versiones, CVEs, chips a issues creadas). task_done añade una entrada al historial (no se edita ni se borra), libera la tarea y programa la siguiente fecha. Si la abandonas sin hacerla, llama a task_release. Si de la revisión sale trabajo por hacer, crea una issue y enlázala en el comment con su chip. "¿Qué toca hacer?": tasks_list con state ["due"]. Nota = cómo funciona algo; bitácora = qué pasó; issue = qué falta por hacer una vez; tarea recurrente = lo que toca hacer periódicamente. Busca antes con tasks_search/tasks_list para no duplicar.
Tool call template
Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.
{
"id": 1,
"jsonrpc": "2.0",
"method": "tools/call",
"params": {
"arguments": {
"id": "<id>",
"agent": "<agent>"
},
"name": "task_start"
}
}Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ID de la tarea | |
| agent | Yes | Identifícate: modelo y herramienta desde la que trabajas, p. ej. "Claude Opus 5.5 · Claude Code" o "GPT-5 · ChatGPT". Se guarda en la línea junto al nombre de la API key. |