任务（task）

SoduWork 的任务能力是一组 MCP 工具，通过 mcp-tools 那座桥调。server 名叫 soduwork。

node <mcp-tools 技能目录>/scripts/mcp.mjs list soduwork            # 有哪些工具、入参是什么
node <mcp-tools 技能目录>/scripts/mcp.mjs call soduwork <工具> '<JSON>'

六个工具

建任务的规矩（不是建议，是硬要求）

① 先聊清楚，再建。 一句话通常不够建出一条像样的任务。缺什么就问什么，一次问一两个，别甩一张表格：

• 要办的是什么——一句话说不清就让人展开；
• 验收要点——做到哪几条才算完？这是最容易被略过、也最要命的一项；
• 谁来办——自己办（assigneeKind:"me"，只建不派），还是交给 AI（"ai"）；
• 在哪个工程上干——涉及改代码的必须问，从 task_options 的 repos 里选；
• 什么时候要。

② 别自己猜 id 和名字。 agentId / flow / repoId 一律从 task_options 回的清单里挑。猜一个填进去，要么建错，要么直接失败。

③ 用 task_propose 出卡，别用文字复述。 以前的做法是把整张卡念一遍、问一句"这么建行吗"——那样人改不了字段，只能回你 "把第三条验收要点换成…"，来回好几轮。现在直接 task_propose：对方屏幕上会长出 一张真正的卡，标题、说明、验收要点、交给谁、走哪个流程、什么时候要，他自己就能改。

所以：

• 提议前别写大段确认文字——卡片本身就是确认，你只需要一句"这么建，行吗"。
• 提议后停下来等。别重复提议，也别自己去调 task_create（人在卡上点了「创建并按流程开始」，界面会建）。
• 人要是在对话里说"把优先级改成高"，你可以重新 propose 一次（覆盖那张卡），别让他去卡上找。

④ 手上有材料就先看。 如果人提到的是这台机器上的某个工程/文件，先去读（ls/read/grep 都行），再填 repoId 和说明。看过再填的任务，和猜出来的任务，质量差得很远。

怎么选流程

task_options 的 flows 里每条都带 desc，照着挑：

• 不用改代码的零散活（写材料、做 PPT、整理文档、查资料）→ 一般是 ai-errand；
• 要改代码并交付→ 看工程用的是哪套（software-delivery / gerrit-autopilot / project-validation-release）；
• 只是先出个原型看看→ product-prototype；
• 拿不准就不填（flow 留空）：不走流程，直接把活派给选中的 AI。

例子

# 1. 先看有哪些选项
node .../mcp.mjs call soduwork task_options '{}'

# 2. 提议出一张卡（不写库、不派活，人能在卡上改）
node .../mcp.mjs call soduwork task_propose '{
  "title": "茶馆竞品调研：定价与功能",
  "note": "对茶馆的同类竞品做调研，重点对比定价策略和功能差异。结果要能直接发给领导看。",
  "checklist": ["列出 3-5 个主要竞品", "逐个对比定价模式和核心功能", "标出茶馆的优势与短板", "产出一份调研报告"],
  "priority": "normal",
  "due": "2026-08-13",
  "assigneeKind": "ai",
  "agentId": "local:claude",
  "flow": "ai-errand"
}'

# 3. 回头看进展
node .../mcp.mjs call soduwork task_list '{"status":"doing"}'
node .../mcp.mjs call soduwork task_get '{"id":"<任务id>"}'

回话的规矩

• 提议完了，只需要一句「这么建，行吗」——别把卡片内容再用文字复述一遍， 他屏幕上已经有了，复述一遍只是刷屏。
• 建完了（人点了卡上的按钮），说清楚建了什么、交给谁、什么时候要，并把任务 id 带上。
• 返回里 warn 不为空＝任务建好了但没交出去（比如那台执行机不在了）。这时候必须明说， 别让人以为已经在跑了——任务是真的建了，可以到任务详情里再派一次。
• dispatched / flowStarted 是 false 且没有 warn，说明这条是"我自己办"的任务，没派给 AI。
• 只说"建好了"不算交付。