Task Extractor — 任务提取器

任务提取器 解析多任务消息 → 编号队列 → 顺序执行 → 验证每个 → 报告。 激活触发器 在任何包含 3+ 个不同可执行项的用户消息上触发。 标志： 以动词（"build"、"fix"、"send"、"check"、"add"、"research"）开头的多个句子 以逗号或句号分隔的指令 一个段落中混合了多个主题 "also"、"and then"、"plus"、"oh and"、"one more thing" 如果不确定是否激活：激活。 假阳性（结构化 2 项请求）无成本。 假阴性（丢弃任务 #7 中的 12 项）会损害信任。

步骤 1：提取（在执行之前） 将消息解析为单个任务。 每个任务都有： 编号（顺序） 摘要（一行，祈使动词） 类型：BUILD | FIX | RESEARCH | SEND | DEPLOY | CONFIG | OTHER 预估努力：QUICK（< 5 分钟）| MEDIUM（5-30 分钟）| HEAVY（30+ 分钟 / 子代理） 写入 workspace/TASK_QUEUE.md： # TASK_QUEUE — [日期] [时间] # 来源：[频道] # 总计：[N] # 状态：IN PROGRESS | #

• ⏳ [任务摘要]
• ⏳ [任务摘要]
• ⏳ [任务摘要]

步骤 3：执行 按照依赖顺序（不一定是数字顺序）执行任务： 先执行独立的 QUICK 任务（将它们批量并行调用） 然后执行 MEDIUM 任务 HEAVY 任务：生成具有明确范围的子代理 对于每个完成的任务，更新 TASK_QUEUE.md： ⏳ → ✅（完成）或 ❌（失败）或 ⚠️（部分）或 🔄（生成子代理） 填写产物列（文件路径、URL、提交哈希或“n/a”）

步骤 4：调解 在所有任务都尝试完成（或子代理生成）后，回复最终清单： 📋 任务报告 ([完成]/[总计]):

• ✅ [任务] → [产物]
• ✅ [任务] → [产物]
• 🔄 [任务] → 子代理正在运行，完成后会公告
• ❌ [任务] → [失败原因]
• ⚠️ [任务] → [完成的内容，剩余的内容]

步骤 5：验证（在子代理完成时） 当子代理宣布完成时： 更新 TASK_QUEUE.md 如果所有任务现在都标记为 ✅/❌，发送最终摘要 如果任务仍然标记为 ⏳，继续工作

规则 永远不要跳过提取步骤。 即使答案似乎很明显，提取步骤也是安全网。 永远不要在没有证据的情况下将任务标记为 ✅。 证据 = 文件存在、命令成功、API 返回 200、部署 URL 工作。 如果任务失败，说明为什么。 不仅仅是 ❌ —— 包括错误、阻塞器或需要什么。 子代理任务在完成事件到达之前都标记为 🔄。 不要乐观地将它们标记为 ✅。 TASK_QUEUE.md 是事实的来源。 如果上下文溢出，重新阅读它。 如果会话重启，重新阅读它。 一次一个 TASK_QUEUE。 如果在一个 TASK_QUEUE 活动时到达一个新的多任务消息，追加到现有的队列中（重新编号）。 在 5 个任务完成时设置检查点。 更新用户的进度。

边缘情况 “做 X 和也 Y，但等待 Z” X 和 Y 都标记为 ⏳，Z 标记为 🕐（阻塞 —— 注意依赖关系） 子代理超时 标记为 ⚠️，注意尝试了什么，提供重试或手动接管的选项 用户在执行过程中改变主意 更新 TASK_QUEUE.md，取消任务以 strikethrough 标记，继续执行剩余任务 重叠任务 如果任务 3 和任务 7 实际上是同一件事，合并它们。 在产物中注明：“合并为 #3”

反模式 ❌ 阅读消息，立即跳入任务 #1 而不提取所有任务 ❌ 在完成事件之前将子代理任务标记为 ✅ ❌ 说“我会做到”，然后忘记 ❌ 只报告已完成的任务，默默地丢弃未完成的任务 ❌ 询问“哪一个应该先做？”—— 只需根据依赖关系和努力优先级并执行即可