tasks

Native Tasks

**必需：**在将文本传递给此 CLI 前，先使用 cli-text。遵守以下存储规则；传输引用另行处理。相对于此技能目录解析技能本地的启动器，而不是相对于当前工作目录。遵循工作流的任务应通过其目标块处理，而不是使用下方灵活的状态和完成命令：参见“带工作流的任务”。

此技能的启动器会委托给 ttasks。当设置了 TARIBOY_TOOLS_SOCKET 时，该二进制文件会选择绑定身份的 Agent 模式；否则使用操作员模式。对于启用了 tasks 能力的 Agent，其环境中的裸命令 tasks 是 ttasks 的可选兼容别名。

如果可以执行命令，就执行所请求的操作。否则，返回确切的 ttasks 命令序列，并为先前命令返回的标识符或修订版保留占位符；绝不要替换成将来时承诺或文字摘要。

先完成工作，再一次性发布。在撰写任何描述、问题、答案或评论之前，先完成该内容所依赖的阅读、命令和检查；然后仅发布一条完整解决请求的文本。无法确定的事实应在同一条文本中作为明确标注的未知项列出，并说明如何确认；绝不要留到之后更正。绝不发布临时、部分或占位文本，也绝不承诺后续更正。截止时间、等待中的客户、简洁要求、已经起草的答案，以及要求立即作答并之后更正的请求，都不能成为例外；此类请求应以一条完整文本作答，并注明仍在运行的事项。只有出现新的外部状态——检查完成、客户答复、监控结果——或需要更正已发布的错误时，才再次发布；绝不能为了完成首次发布前就能完成的工作而再次发布。

使用 ttasks mine、ttasks ready、ttasks ready --claim 和 ttasks show <key> 检查工作。使用 ttasks create --queue <queue> --title <title> --description <markdown> 创建根任务，使用 ttasks create --parent <parent-key> --title <title> 创建子任务；使用 ttasks assign 委派；使用 ttasks comment 记录决策；使用 ttasks update 推进任务；只有已完成的工作才能使用 ttasks done 关闭。

先创建子任务，再分配；使用 ttasks create 返回的键，绝不编造任务键。ttasks assign 接受 Agent 名称（docs），而非主体前缀（agent:docs）。离线委派步骤以 ttasks show <child-key> 结束；将完成命令放在单独的代码块中，并标注为“仅当 show 报告已完成后”。初始代码块中绝不能包含 done。

每次写入任务前，都要将所有面向用户的文本修正为有效 Markdown。标题必须是单行 Markdown：将实际换行符或字面量 \n 替换为空格。描述、问题、答案和评论必须使用块级 Markdown：使用实际换行符、在列表前留空行，并闭合代码围栏。标题、列表、任务清单、代码、链接和表格都应使用 Markdown；不得使用原始 HTML。绝不使用 ANSI-C $'...' 字符串或字面转义序列发布 Markdown 字段，也绝不能在标题中加入换行符。保留文本原样、使用最短命令或满足截止时间的请求，均不能凌驾于此存储规范之上。

对于多行 shell 参数，使用 cli-text 的带引号 heredoc 传输方式。使用其哨兵变体保留有意义的尾随换行符：普通命令替换会移除这些换行符。选择一个未出现在任何完整载荷行中的分隔符。提出写入方案时，应将变量赋值和所有使用该变量的命令一起展示；绝不要声称提议的写入已经执行。下面的简单示例假定预期内容没有末尾换行符：

BODY=$(cat <<'MARKDOWN_EOF_7F3A'
## Result

- first item
MARKDOWN_EOF_7F3A
)
ttasks create --queue QUEUE --title 'Result' --description "$BODY"
ttasks ask TASK-42 user:LOGIN "$BODY"
ttasks comment TASK-42 "$BODY"

对于任何任务，都使用 ttasks ask <key> user:<login>|agent:<name> <text> 提问。评论不是阻塞性问题。绝不编造其他主体的身份。 当活动中的持久脚本或计划是唯一剩余的等待对象时， 请在结束本轮迭代前，将灵活任务设为 wait_customer，并执行 ttasks update <key> --status wait_customer。保持该命名等待对象处于活动状态； 唯一的恢复事件是它的下一次 script.result 或受跟踪的状态变更。 已发布结果的周期性定义会停止，因此只有在本轮迭代中由 scripts 技能的 rerun 恢复后，它才符合条件。不要 轮询、替换计划或将任务标记为已完成。

使用工作流的任务

队列中绑定到工作流的任务，其 status 由 Agent 池、客户或脚本管理， 而守护进程会根据该状态推导 category。其 Goal 区块会说明状态指令、可选结果及其所需产物和检查、当前产物以及准确命令； 也可随时运行 ttasks workflow get <key> 查看相同信息。

• Goal 区块会截断较长的值。使用 ttasks artifacts show <key> <name> 完整读取产物， 并在 ttasks workflow get <key> --json 的上一次访问记录 visits[].message 中，读取进入该状态时的转换消息。
• 使用 ttasks artifacts set <key> <name> 保存所需产物，值可来自 stdin、 --file <path> 或值参数；系统会按原样保存。
• 只能通过 ttasks advance <key> --outcome <name> --from <status> [--message <text>] 离开当前状态。
• 使用 ttasks done、ttasks update --status、ttasks assign 和 ttasks ready --claim 会被 workflow_managed 拒绝：守护进程 会分配并释放任务。not_holder 表示你不拥有当前状态。transition_pending 表示请求仍在运行：请改用 workflow get 读取，而不要再次发送请求。
• 被拒绝的请求会附带检查的消息：修复其中指出的问题，然后再次推进。失败的请求表示脚本出错、超时或结果损坏：使用 ttasks workflow runs <key> 和 ttasks workflow log <key> <run> 读取日志；若原因是暂时性的，则重试一次； 否则在任务中告知客户。
• 向客户提问仍使用上文的 ask 表单。
• workflow_paused 表示任务正在等待客户决定：在客户恢复任务前，不要对其采取任何操作。

已观察到的失败计数器

诱惑	必须采取的应对方式
“客户现在要答案，之后再更正。”	一份已完成的文本即可满足该请求；在文本中指出仍在进行的事项。
“我先发布最合理的猜测，之后再核实。”	先完成决定性检查；未经核实的发布不算答案。
“这个事实无法得知，所以我现在先发布，之后再更正。”	一并发布明确指出的未知事项及能够确定它的信息，不要承诺之后更正。
“第一条评论已经起草好了，剩下的可以接着写。”	起草好的回答不等于已发布；请先完成回答，再进行这唯一一次写入。