Clear Task

Say it clear, do it right.

这个 Skill 做什么

用这个 Skill 把一句不够清楚的需求，整理成一份能直接执行的任务说明。

核心原则：

1. 先把用户想做什么讲清楚。
2. 再问最关键的缺失信息。
3. 让用户确认需求。
4. 用户确认后，再生成内部执行方案并开始做。

不要一上来就开工。需求没有确认前，不要进入 Stage3，也不要执行实际任务。

工作流程

按这个顺序来：

1. Stage1：理解需求，把用户的想法整理成一个工作流程模型。
2. Stage2：找出会影响结果的缺失信息，提出少量关键问题，或给出合理默认值。
3. 确认门：把整理好的需求用通俗语言发给用户，让用户确认、修改需求描述，或修改需求细节。
4. Stage3：用户确认后，生成内部 AgentTaskGuidancePackage，用专家视角给出执行指导和验收标准。
5. 执行任务：根据内部执行包完成用户真正要的结果。
6. 汇报结果：说明完成了什么、改了哪些文件、用了哪些默认值，以及自检结果。

Stage1：先理解需求

把用户请求看成一个“要完成的工作流程”，不要只列一个简单步骤清单。即使用户要的是产品、文档、游戏、分析报告或代码，也要先理解它的流程。

需要完整格式时，读取：

• references/stage1-universal-process-model.md

Stage1 至少要整理这些内容：

• request_summary：用户想要什么
• business_goal：为什么要做，目标是什么
• scope：做哪些，不做哪些
• actors：谁会参与或使用
• inputs：需要哪些输入
• outputs：要产出什么
• workflow_graph.nodes：流程节点
• workflow_graph.edges：节点之间的关系
• business_rules：业务规则
• assumptions：暂时的假设
• open_questions：还没确认的问题
• source_evidence：依据来自哪里

没有确认的信息只能放进 assumptions 或 open_questions，不要当成事实说。

Stage2：补齐关键信息

Stage2 的目标不是问很多问题，而是问最少、最关键的问题。

只问那些会明显改变后续执行的问题。如果用户让你推荐方案，就给出合理默认值，并记录到 accepted_defaults。

需要完整格式时，读取：

• references/stage2-clarification-handoff.md

满足下面条件时，Stage2 才算准备好：

• 阻塞问题已经回答，或
• 阻塞问题已经有用户接受的默认值，且
• 剩下的问题不会阻碍执行，或用户明确交给后续 Agent 自行处理。

注意：Stage2 准备好，不代表可以自动进入 Stage3。必须先让用户确认。

确认门：必须让用户点头

Stage2 之后必须暂停，向用户确认需求。不要在同一轮回复里直接进入 Stage3。

确认时用用户能看懂的话，不要展示内部术语和复杂结构。

输出格式：

• 需求描述：用一小段话说明用户要做什么。
• 需求细节：说明范围、交付物、限制、默认值、假设和非阻塞问题。
• 需要你确认：问用户是否继续。

给用户这三个选择：

• 确认，继续
• 修改需求描述: ...
• 修改需求细节: ...

只有用户明确同意，才算确认。例如：

• 确认
• 继续
• 可以
• 批准
• go ahead

如果用户回复含糊，就继续追问一句，不要擅自开工。

如果用户修改需求描述：

1. 更新 Stage1 的 UniversalProcessModel。
2. 检查 Stage2 是否也需要调整。
3. 更新或重新生成 Stage2 的 UniversalRequirementHandoff。
4. 回到确认门，再让用户确认。

如果用户修改需求细节：

1. 更新 Stage2 中的范围、默认值、假设、限制、交付物和问题。
2. 不要自动进入 Stage3。
3. 回到确认门，再让用户确认。

如果修改后出现新的阻塞问题，只问这些新问题。拿到答案后更新 Stage2，再回到确认门。

Stage3：生成内部执行包

只有用户明确确认后，才能开始 Stage3。

Stage3 会生成一个内部 AgentTaskGuidancePackage。默认不要展示给用户。它是执行任务时给 Agent 自己看的工作包。

Stage3 要做这些事：

1. 判断任务属于什么领域，以及后续该用什么工作方式。
2. 选择一个主要专家角色和若干辅助专家角色。
3. 生成专家执行建议。
4. 生成专家验收标准。
5. 合并成一份内部执行包，不要发明用户没说过的新需求。

需要完整格式和专家规则时，读取：

• references/stage3-agent-task-guidance-package.md
• references/expert-roles-and-acceptance.md

什么时候可以执行

满足这些条件后，可以继续执行：

• 用户已经明确确认需求。
• 阻塞问题已解决，或已有用户接受的默认值。
• 用户要的是一个实际交付结果。
• 当前工具和工作区可以完成任务。

遇到这些情况要暂停并询问：

• 用户还没确认需求。
• Stage2 还有阻塞问题。
• 执行会意外修改大量文件或影响外部系统。
• 需要账号、密钥、付费服务、联网操作或破坏性操作。
• 用户只要求分析、规划或查看内部执行包。

输出规则

• 保留从用户输入、Stage1、Stage2 到专家建议的可追溯关系。
• 区分 confirmed_facts、accepted_defaults、assumptions 和 expert_recommendations。
• 只把真正影响执行的问题标为阻塞问题。
• 验收标准必须能检查，有明确通过条件。
• 不要写“体验好”“功能完整”“质量高”这类空话。要改成可以观察和验证的标准。
• 如果专家建议互相冲突，要记录冲突，并给出保守处理方案。
• 默认不要展示完整 AgentTaskGuidancePackage。
• 执行完成后，用专家验收标准做自检。

内部执行包结构

这个结构只给内部使用。除非用户明确要求，不要直接展示。

AgentTaskGuidancePackage:
  title:
  objective:
  expected_outcome:
  downstream_agent_role:
  confirmed_scope:
  requirements:
  process_model:
  expert_task_guidance:
  consolidated_execution_plan:
  expert_acceptance_criteria:
  consolidated_acceptance_criteria:
  risks_and_edge_cases:
  unresolved_questions:
  assumptions:
  conflicts:
  traceability:
  suggested_next_prompt:

默认给用户看的内容

Stage3 之前，只给用户看：

• 需求描述
• 需求细节
• 已接受的默认值和假设
• 剩余的非阻塞问题
• 请用户确认、修改需求描述，或修改需求细节

执行完成后，只汇报：

• 完成了什么
• 使用了哪些关键决策或默认值
• 新建或修改了哪些文件和产物
• 按必须通过的标准做了哪些自检
• 还有哪些注意事项或非阻塞问题