Task Dispatch
Automated task scheduling and execution for task management systems.
Quick Start
用户说"设置任务调度"或"部署 ClawBoard"时,按以下流程引导:
Step 1: 检测环境
CODEBLOCK0
Step 2: 部署 ClawBoard(如未安装)
CODEBLOCK1
Step 3: 启动服务
CODEBLOCK2
Step 4: 配置 Agent 环境
在 Agent 工作目录创建 .env 文件:
CODEBLOCK3
Step 5: 打开看板
- - 前端看板: http://127.0.0.1:5173
- 后端 API: http://127.0.0.1:3000
- 输入
.env 中的 BOARD_ACCESS_TOKEN 登录
Step 6: 设置定时调度(可选)
用户说"设置定时调度"时:
CODEBLOCK4
Agent Role
You are a dispatcher, not an executor.
- - Your job: plan, dispatch, verify, update status
- NOT your job: implement tasks yourself
- Task execution: delegated to subagents
- You verify results and update task status
Data Source of Truth
| What | Source |
|---|
| Task data | API endpoint (e.g., http://127.0.0.1:3000/api/tasks/...) |
| Task files |
tasks/*.json (written by API) |
| Project docs |
projects/<project-name>/docs/ |
|
NOT source of truth | Frontend dashboard (view only) |
ClawBoard Deployment Guide
Prerequisites
- - Node.js >= 18
- Git
- PM2 (auto-installed by
./clawboard install)
Installation Commands
| Command | Description |
|---|
| INLINECODE7 | Install dependencies, create .env |
| INLINECODE8 |
Start frontend + backend services |
|
./clawboard stop | Stop all services |
|
./clawboard status | Check service health |
|
./clawboard token | Show current access token |
|
./clawboard token --generate | Generate new token |
Verification Checklist
After deployment, verify:
- 1. ✅ Backend API responds: INLINECODE13
- ✅ Frontend loads: open http://127.0.0.1:5173
- ✅ Token works: INLINECODE14
- ✅ Agent .env configured with token
Common Issues
| Issue | Solution |
|---|
| Port 3000 in use | INLINECODE15 then kill process |
| Port 5173 in use |
lsof -i :5173 then kill process |
| Token not working | Regenerate with
./clawboard token --generate |
| Services not starting | Check logs in
~/ClawBoard/logs/ |
Dispatch Operations
Overview
This skill enables agents to:
- 1. Check task boards for dispatchable tasks
- Spawn subagents to execute tasks
- Verify completion and update task status
- Continue dispatching until no tasks remain (no waiting for next cron)
Key Principle: Continuous Dispatch
CODEBLOCK5
Dispatch Loop
CODEBLOCK6
API Reference
Get Projects
CODEBLOCK7
Get Tasks
CODEBLOCK8
Create Project
CODEBLOCK9
Create Task
CODEBLOCK10
Update Task
PUT {TASKBOARD_API_URL}/api/tasks/projects/{projectId}/tasks/{taskId}
Authorization: Bearer {TOKEN}
Content-Type: application/json
{
"status": "in-progress",
"claimedBy": "agent-id"
}
Task Selection Rules
A task is dispatchable if ALL conditions are met:
| Condition | Requirement |
|---|
| INLINECODE19 | INLINECODE20 |
| INLINECODE21 |
"todo" or
"in-progress" (unclaimed) |
|
assignee | Empty or null |
|
claimedBy | Empty or null |
|
dependencies | All have
status: "done" |
Priority Order
- 1.
P0 > P1 > P2 > INLINECODE31 - Same priority: earlier
createdAt first
Subagent Execution
Prepare Dispatch Context
Before spawning subagent, prepare context using the Dispatch Template:
See references/dispatch-template.md for full template.
Required fields to fill:
- - Task Identity (from task data)
- Goal (one sentence)
- Hard Constraints (what NOT to do)
- Deliverables (from task.deliverables)
- Acceptance Criteria (from task.acceptanceCriteria)
- Output Format (completion_signal block)
Spawn with Wait
Use sessions_spawn with the dispatch context:
CODEBLOCK12
The main agent should:
- 1. Fill dispatch template with task context
- Spawn subagent with the template
- Wait for completion (blocking or polling)
- Parse
completion_signal from response - Verify deliverables and update status
- Immediately continue to next task
Completion Signal
Subagent must return a completion_signal block:
CODEBLOCK13
Parse this block to determine task outcome:
- -
status: done → Verify deliverables, update to INLINECODE37 - INLINECODE38 → Update to
failed with INLINECODE40
Status Transitions
CODEBLOCK14
Important: Tasks go to review after subagent completes, not directly to done. User or main agent verifies before done.
Verification Checklist
After subagent completes, verify:
- 1. Deliverables exist
- Check all paths in
deliverables array
- Files should be non-empty
- 2. Acceptance criteria met
- Review each criterion
- Mark pass/fail
- 3. Update status
- All pass →
review
- Any fail →
failed with
blockingReason
Heartbeat Response
When triggered by cron/heartbeat:
- - No dispatchable tasks: Return
HEARTBEAT_OK (silent, no message to user) - Tasks dispatched: Report results, then check for more
- Continue until empty: Don't stop after one task
Failure Handling
When a task fails or has no valid execution:
- 1. Record the reason in
blockingReason field - Clear invalid occupation (
claimedBy) - Return task to actionable state (
todo or in-progress) - Never fail silently - always log or report
Common Failure Scenarios
| Scenario | Action |
|---|
| Subagent timeout | Set failed, clear claimedBy, log reason |
| Subagent returns INLINECODE55 |
Set
failed with
blockingReason |
| Deliverables missing | Set
failed, clear
claimedBy |
| API error | Log error, skip this round, try next time |
Dispatch Principles
- 1. Only dispatch
executionMode=auto tasks - Priority order:
todo first, then unclaimed INLINECODE62 - Respect assignee: Don't re-dispatch if
assignee is set - Verify before done: Tasks go to
review first, then done after verification
Configuration
See references/config.md for:
- - Task board adapters
- Priority mappings
- Execution timeouts
- Retry policies
Example Usage
Deploy ClawBoard
CODEBLOCK15
Setup with User Guidance
CODEBLOCK16
Manual Dispatch (runs until empty)
CODEBLOCK17
Setup Periodic Check
CODEBLOCK18
The cron will trigger the dispatch loop, which runs until no tasks remain.
任务调度
任务管理系统的自动化任务调度与执行。
快速开始
用户说设置任务调度或部署 ClawBoard时,按以下流程引导:
步骤 1:检测环境
bash
检查 Node.js
node --version # 需要 >= 18
检查 ClawBoard 是否已安装
ls -la ~/ClawBoard 2>/dev/null || echo ClawBoard 未安装
步骤 2:部署 ClawBoard(如未安装)
bash
克隆仓库
git clone https://github.com/CCCaptain0129/ClawBoard.git ~/ClawBoard
cd ~/ClawBoard
安装依赖并初始化
./clawboard install
生成访问令牌(自动保存到 .env)
./clawboard token --generate
步骤 3:启动服务
bash
cd ~/ClawBoard
./clawboard start
检查状态
./clawboard status
步骤 4:配置 Agent 环境
在 Agent 工作目录创建 .env 文件:
bash
获取令牌
TOKEN=$(cat ~/ClawBoard/.env | grep BOARD
ACCESSTOKEN | cut -d= -f2)
写入 Agent 工作目录
echo TASKBOARD
APIURL=http://127.0.0.1:3000 >> ~/.openclaw/workspace-<名称>/.env
echo TASKBOARD
ACCESSTOKEN=$TOKEN >> ~/.openclaw/workspace-<名称>/.env
步骤 5:打开看板
- - 前端看板: http://127.0.0.1:5173
- 后端 API: http://127.0.0.1:3000
- 输入 .env 中的 BOARDACCESSTOKEN 登录
步骤 6:设置定时调度(可选)
用户说设置定时调度时:
json
{
name: ClawBoard 调度巡检,
schedule: { kind: every, everyMs: 300000 },
payload: {
kind: agentTurn,
message: 执行 task-dispatch 调度检查。无任务时返回 HEARTBEAT_OK。
},
sessionTarget: isolated,
delivery: { mode: none }
}
Agent 角色
你是调度员,不是执行者。
- - 你的职责:规划、调度、验证、更新状态
- 不是你的职责:亲自实现任务
- 任务执行:委托给子 Agent
- 你验证结果并更新任务状态
数据真实来源
| 内容 | 来源 |
|---|
| 任务数据 | API 端点(例如 http://127.0.0.1:3000/api/tasks/...) |
| 任务文件 |
tasks/*.json(由 API 写入) |
| 项目文档 | projects/<项目名称>/docs/ |
|
非数据真实来源 | 前端看板(仅查看) |
ClawBoard 部署指南
前置条件
- - Node.js >= 18
- Git
- PM2(由 ./clawboard install 自动安装)
安装命令
| 命令 | 描述 |
|---|
| ./clawboard install | 安装依赖,创建 .env |
| ./clawboard start |
启动前端 + 后端服务 |
| ./clawboard stop | 停止所有服务 |
| ./clawboard status | 检查服务健康状态 |
| ./clawboard token | 显示当前访问令牌 |
| ./clawboard token --generate | 生成新令牌 |
验证检查清单
部署后,验证:
- 1. ✅ 后端 API 响应:curl http://127.0.0.1:3000/health
- ✅ 前端加载:打开 http://127.0.0.1:5173
- ✅ 令牌有效:curl -H Authorization: Bearer $TOKEN http://127.0.0.1:3000/api/tasks/projects
- ✅ Agent 的 .env 已配置令牌
常见问题
| 问题 | 解决方案 |
|---|
| 端口 3000 被占用 | lsof -i :3000 然后终止进程 |
| 端口 5173 被占用 |
lsof -i :5173 然后终止进程 |
| 令牌无效 | 使用 ./clawboard token --generate 重新生成 |
| 服务无法启动 | 检查 ~/ClawBoard/logs/ 中的日志 |
调度操作
概述
此技能使 Agent 能够:
- 1. 检查任务看板以获取可调度任务
- 生成子 Agent 来执行任务
- 验证完成情况并更新任务状态
- 持续调度直到无任务剩余(不等待下一次定时触发)
关键原则:持续调度
触发一次 → 循环执行直到无任务 → 结束
而不是:
触发一次 → 派发一个任务 → 等待下次触发
调度循环
python
def dispatch_loop():
while True:
task = selectdispatchabletask()
if not task:
return HEARTBEAT_OK # 本轮结束
# 派发并等待完成
result = spawnandwait(task)
# 验收
if result.success:
update_task(task.id, status=review)
else:
update_task(task.id, status=failed, blockingReason=result.error)
# 【关键】立即继续下一轮,不返回
# 循环会自动检查下一个任务
API 参考
获取项目
GET {TASKBOARDAPIURL}/api/tasks/projects
Authorization: Bearer {TOKEN}
获取任务
GET {TASKBOARDAPIURL}/api/tasks/projects/{projectId}/tasks
Authorization: Bearer {TOKEN}
创建项目
POST {TASKBOARDAPIURL}/api/tasks/projects
Authorization: Bearer {TOKEN}
Content-Type: application/json
{
id: my-project,
name: 我的项目,
description: ...,
taskPrefix: MP,
color: #3B82F6,
icon: 📁
}
创建任务
POST {TASKBOARDAPIURL}/api/tasks/projects/{projectId}/tasks
Authorization: Bearer {TOKEN}
Content-Type: application/json
{
title: 任务标题,
description: ...,
status: todo,
priority: P1,
executionMode: auto,
assignee: agent-id
}
更新任务
PUT {TASKBOARDAPIURL}/api/tasks/projects/{projectId}/tasks/{taskId}
Authorization: Bearer {TOKEN}
Content-Type: application/json
{
status: in-progress,
claimedBy: agent-id
}
任务选择规则
满足所有条件时,任务才可调度:
| 条件 | 要求 |
|---|
| executionMode | auto |
| status |
todo 或 in-progress(未认领) |
| assignee | 空或 null |
| claimedBy | 空或 null |
| dependencies | 所有依赖项 status 为 done |
优先级顺序
- 1. P0 > P1 > P2 > P3
- 相同优先级:较早的 createdAt 优先
子 Agent 执行
准备调度上下文
在生成子 Agent 之前,使用调度模板准备上下文:
完整模板请参见 references/dispatch-template.md。
需要填写的必填字段:
- - 任务标识(来自任务数据)
- 目标(一句话)
- 硬约束(禁止事项)
- 交付物(来自 task.deliverables)
- 验收标准(来自 task.acceptanceCriteria)
- 输出格式(completion_signal 块)
生成并等待
使用调度上下文调用 sessions_spawn:
json
{
runtime: subagent,
mode: run,
task: <已填写的调度模板>,
timeoutSeconds: 300
}
主 Agent 应:
- 1. 使用任务上下文填写调度模板
- 使用模板生成子 Agent
- 等待完成(阻塞或轮询)
- 从响应中解析 completion_signal
- 验证交付物并更新状态