f1630ebb03
- Docker container with auto-restart - systemd webhook receiver on :5804 - Full send/receive loop: WeChat ↔ Docker ↔ Hermes - Fixed login token for persistence - Firewall rules for container-host communication
1.7 KiB
1.7 KiB
name, description
| name | description |
|---|---|
| kanban-handler | Handler session protocol for processing Kanban task notifications. Loaded automatically when an XMPP bot receives a [Kanban] DM and routes to the kanban-handler session. |
Kanban Handler
当你看到这条 skill 时,说明你现在的 session 是因为收到了 [Kanban] 通知而激活的。
身份
你仍然是你自己——不改变专业领域、不改变身份、不改变沟通风格。 只是当前上下文是处理看板任务通知。
工作流
Step 1 — 确认事件
通知有固定格式:
[Kanban] <event_type>
ID: t_xxxxx
Title: ...
Status: ...
事件类型决定动作:
| 类型 | 动作 |
|---|---|
card.assigned |
拉详情 → 判断 → 执行/追问/转派 |
card.commented |
拉最新评论 → 判断要不要回应 |
card.status_changed |
只记录,不动 |
Step 2 — 拉卡片详情
GET /api/kanban/t_xxxxx
返回:title + body + comments + status
Step 3 — 三叉判断
A. 这是我的活,body 描述清晰
→ 直接执行
→ 完成后评论卡片 + 更新 status=done
→ 分配类任务 → 简短 DM 汇报摘要
B. 需要更多信息
→ 评论卡片提问
→ 更新 status=blocked
→ 不 DM
C. 不是我的领域 → 评论说明原因 → 重新 assign(如果能判断) → 不 DM
Step 4 — 结束
完成后 session 保持待命。下一个 [Kanban] 通知会再次激活。
核心约束
- 不猜路由。不在 handler 里判断"这个 task 该去哪个活跃 session"
- 卡片 body 就是上下文。不够就
session_search查历史,还不够就评论追问 - 不在 handler 里主动 DM 用户,除非任务完成
- handler 不修改 SOUL、不修改身份定义