task-handlelisted

# 任务句柄(Task Handle) > 权威设计:仓库 `docs/task-handle.md`。本 SKILL 只讲**你(agent)在 turn 内要做什么**。 > 有两条路径,先看 §0 判断本话题走哪条 —— 规则完全不同,不要混用。 ## 0. 先分流:任务派单(主路径) vs 话题转任务(辅路径) - prompt 里有 **`<task-root>` 块**(本话题根消息是一条飞书任务分享)→ **任务派单主路径**,按 §0.1 处理, **忽略** `<task-handle>` 块的候选匹配流程(派单的认领目标是确定的,不需要匹配)。 - prompt 里只有 **`<task-handle>` 块** → 辅路径(话题转任务),按 §1–§6 处理。 - 两个块都没有 → 本话题没有任务句柄相关的事,跳过本 SKILL。 ## 0.1 任务派单主路径(v4/v4.1,docs/task-handle.md §15) 用户的操作是:建了一条飞书任务 →「发送任务到会话」发进群 → 在这条任务卡片的话题里 @ 你。 `<task-root>` 块里有 `task_guid`、`task_summary`、(通常还有)`topic_link` 和 `task_root_claimed`。 **认领(v4.2 起由 bridge 自动完成)**:主路径的绑定是机械确定的(话题根=任务卡片,guid 唯一), 所以 **bridge 在你跑起来之前就已经自动认领了**——`<task-root>` 块里 `task_root_claimed: yes` + 「bridge 本轮已自动认领」字样时,你只需要: 1. **双 @ 竞态护栏**:先读一遍该任务的现有评论(`lark-cli task comments list`)——已有**其他 agent** 的认领声明 → 同话题的另一个 bot 已接手,评论区不再重复发认领评论(重复评论 = 骚扰),正常配合即可。 2. 发一条**认领评论**(`lark-cli task comments create --resource-type task --resource-id <task_guid> ...`): 一句认领声明 + `topic_link`(用户从任务中心点它直达本话题——这是任务→话题唯一的回跳,别省略)。 例:`已认领,工作话题:<topic_link>`。 3. 然后正常干活(任务标题/描述就是需求;信息太薄就在话题里问,或按 §0.1 里程碑规则发"等拍板"评论)。 **兜底(`task_root_claimed: no` 时——bridge 认领失败,如该任务已被别的话题认领)**:按 prompt 里的 指示走旧认领流程(先查评论区竞态护栏 → 把 `task_guid` 写进 state.json 的 `task_handle.guid` → 发认领评论),或按实际情况在话题里说明冲突。 **维护(全程只用任务评论——v4.1 铁律)**: - 只在**交付 / 失败 / 等拍板**三类里程碑节点发任务评论(每条评论都会推送给任务创建者,滥发=骚扰; 过程性进展写在话题回复里即可,不发评论)。 - **交付的那一轮**:state.json 的 `task_handle` 写 `done: true`,并发一条「已交付,看过请点完成」评论 (附产出链接:MR/文档/结论)。`done: true` 不