do-work

Do-Work Skill

用于捕获和处理任务的统一入口。

操作：

• do：捕获新任务／请求 → 创建 UR 文件夹（逐字保存输入）和 REQ 文件（队列项），始终成对创建，然后验证覆盖情况
• work：处理待处理请求 → 制定计划（并验证计划）、探索、构建、测试
• verify：根据原始输入评估已捕获的 REQ → 检查覆盖情况并自动修复（捕获后也会自动运行）
• cleanup：整理归档 → 将散落的 REQ 移入 UR 文件夹，关闭已完成的 UR

核心概念： do 操作始终会同时生成 UR 文件夹（保留原始输入）和 REQ 文件（队列项）。每个 REQ 都通过 user_request frontmatter 链接回其 UR。所有请求都必须成对创建，无论简单还是复杂。

捕获 ≠ 执行。 do 操作用于捕获请求，work 操作用于执行请求。两者严格分开。do 操作完成文件写入并汇报后，立即停止。不要开始处理队列，不要开始实现，也不要“热心地”转入 work 操作。是否执行始终由用户决定。唯一例外是用户在同一次调用中明确提出类似“添加这个，然后运行”或“捕获这个并开始处理”的要求。

路由决策

第 1 步：解析输入

检查 “do work” 后面的内容：

按顺序检查以下模式——匹配到的第一个模式优先：

优先级	模式	示例	路由
1	空输入或单独调用	do work	→ 询问：“开始工作循环吗？”
2	仅含操作动词	do work run、do work go、do work start	→ work
3	验证关键词	do work verify、do work check、do work evaluate	→ verify
4	清理关键词	do work cleanup、do work tidy、do work consolidate	→ cleanup
5	版本关键词	do work version、do work update、do work check for updates	→ version
6	更新日志关键词	do work changelog、do work release notes、do work what's new、do work what's changed、do work updates、do work history	→ version
7	描述性内容	do work add dark mode、do work [meeting notes]	→ do

步骤 2：保留载荷

关键规则：绝不丢失用户的内容。

单词规则：单个单词要么是已知关键词，要么含义模糊——绝不是“描述性内容”。

• 匹配路由表中的关键词（例如，“version”“verify”“cleanup”）→ 直接路由到相应操作。
• 不匹配任何关键词（例如，“refactor”“optimize”）→ 含义模糊。询问：“你想将 ‘{word}’ 作为新请求添加，还是另有所指？”

只有当输入明确具有描述性（多个单词、一句话、功能请求等）时，才路由到 do。

如果路由确实不明确，且用户提供了多个单词的内容：

• 默认路由到 do（添加任务）
• 保留 $ARGUMENTS
• 如果确实含义模糊，询问：“将此内容作为请求添加，还是启动工作循环？”
• 用户只回复 “add” 或 “work” → 使用原始内容继续操作

动作动词（→ Work）

这些词表示“处理队列”： run、go、start、begin、work、process、execute、build、continue、resume

验证动词（→ Verify）

这些词表示“检查请求质量”： verify、check、evaluate、review requests、review reqs、audit

注意：“check”只有在单独使用或后接目标时才路由到 verify（例如，“do work check UR-003”）。后接描述性内容时则路由到 do（例如，“do work check if the button works” → do）。

清理动词（→ Cleanup）

这些词表示“整合归档”： cleanup、clean up、tidy、consolidate、organize archive、fix archive

变更日志动词（→ Version）

这些词表示“显示发布说明”： changelog、release notes、what's new、what's changed、updates、history

注意：复数形式的 “updates” 路由到变更日志显示。单数形式的 “update” 路由到更新检查。两者都由 version 操作处理。

内容信号（→ Do）

这些内容表示“添加新任务”：

• 超出单个动词的描述性文本
• 功能请求、错误报告、想法
• 截图或上下文
• “add”“create”“I need”“we should”

示例

路由到 Work

• do work → “准备处理队列了吗？”（确认）
• do work run → 立即启动工作操作
• do work go → 立即启动工作操作

路由到 Verify

• do work verify → 评估最近一个 UR 的 REQ
• do work verify UR-003 → 评估指定的 UR
• do work check REQ-018 → 评估 REQ-018 所属的 UR
• do work evaluate → 评估最近一个 UR 的 REQ
• do work review requests → 评估最近一个 UR 的 REQ

路由到 Cleanup

• do work cleanup → 整合归档，关闭已完成的 UR
• do work tidy → 与 cleanup 相同
• do work consolidate → 与 cleanup 相同

路由到变更日志（通过 Version）

• do work changelog → 显示变更日志（最新内容位于底部）
• do work release notes → 与 changelog 相同
• do work what's new → 与 changelog 相同
• do work updates → 与 changelog 相同
• do work history → 与 changelog 相同

路由到 Do

• do work add dark mode → 创建 REQ 文件和 UR 文件夹
• do work the button is broken → 创建 REQ 文件和 UR 文件夹
• do work [400 words] → 创建 REQ 文件和 UR 文件夹，并包含完整的原文输入

载荷保留规则

需要澄清但用户已提供内容时：

1. 不要丢失 $ARGUMENTS——在上下文中保留完整载荷
2. 提出简单的问题：“将此内容作为请求添加，还是启动工作循环？”
3. 接受简短回复：用户只回复 “add” 或 “work”
4. 使用原始内容继续操作：将所选操作应用于已保存的参数
5. 绝不要求用户重新粘贴内容

这样可以实现两阶段提交模式：

1. 捕获意图载荷
2. 确认操作

动作参考

请遵循以下详细说明：

• do action - 请求捕获
• work action - 队列处理
• verify-request action - 已捕获请求的覆盖验证（在捕获后运行，也可手动运行）
• verify-plan action - 计划覆盖验证（在 work action 中完成规划后运行）
• cleanup action - 归档整合与 UR 关闭
• version action - 版本、更新与变更日志