task-brief

任务简报

请求过于简略是 Agent 产出平庸结果的最大原因：Agent 会猜测交付内容、受众和限制条件，而用户只有在工作完成后才会发现理解有误。这项技能会把发现问题的时间提前到成本最低的节点——工作开始之前：让 Agent 编写一份简短的任务简报，展示给用户，然后再执行。用户不必费心写出更好的提示词；由 Agent 来梳理结构。

何时运行——何时不运行

在以下情况下运行：

• 用户明确提出要求（例如“先写简报”“开始前先确认你理解了”）；或
• 任务较为复杂——涉及多个步骤、多份文档，或产出需要交给他人阅读（例如备忘录、报告、仪表板、成批文档）——且请求过于简略或含糊，以至于两种合理的理解会导致不同的工作成果。

在以下情况下跳过（直接执行任务）：快速事实查询、单步编辑，以及请求已经足够明确、可以直接执行的情况。对琐碎请求写简报只会增加阻力，而非提升质量——把握适度也是这项技能的一部分。如有疑虑，用一句话重述目标（“我会按 X 来理解——如果不是，请告诉我”）胜过写一份完整简报。

简报

按以下固定格式编写并展示——简短、使用通俗的商务语言：

**Task brief — [short task name]**
- **Goal** — what "done" looks like: the deliverable, its format, its audience,
  and the test it must pass.
- **Context** — everything known that bears on the task: the inputs/files
  provided, relevant background from the conversation or memory, the entities /
  period / parties involved, what already exists.
- **Constraints** — what to avoid and the guardrails: task-specific limits
  (scope, exclusions, deadline, tone) plus whichever standing rules materially
  bite this task (see below).
- **Assumptions** — anything filled in without asking, flagged so the user can
  correct it with one word.
- **Tooling** — the installed skill(s) or tool(s) that will do the work.

编写简报

1. 先提取信息，再提问。 先从请求、此前的对话、用户提供的文件和记忆中提取信息——切勿向用户询问已有的信息。
2. 只问会改变产出的问题。 针对每个信息缺口，判断：不同的回答会产生不同的工作成果吗？如果会，就提问——最多提 2–3 个问题；如有结构化提问工具可用，优先使用，否则就在聊天中列出简短的编号问题。如果不会，就采用合理的默认值，并记录在假设中。不要在任务开始前连珠炮似地盘问用户。
3. 自动加入长期约束——不要询问。 每个组织都有适用于所有工作的规则；应自动将其纳入限制条件（只列出实际适用的规则）。首先从宿主环境中获取规则——包括系统提示词、组织指令、CLAUDE.md / agents 文件、原则或风格文档。如果未定义此类规则，则采用以下默认值：产出是供人审阅的草稿，而非建议；切勿编造事实——应提问或留出明显标注的空白；拼写、日期和货币格式应符合组织的风格规范，且保持一致；机密数据留在本地——在将任何内容交给外部工具之前进行去标识化；遵守操作边界——只做准备工作，未经明确许可，不得发送、发布、付款、提交或签署。
4. 选择合适的工具。 检查实际安装的工具（技能、连接器、脚本），并指出最适合完成工作的具体工具。如果存在更合适的能力但尚未安装，应作为建议说明——切勿让简报依赖用户无法使用的工具。如果没有合适的工具，也要说明，并使用通用能力继续执行。
5. 预先检查模式兼容性。 在工具一项中，检查选定的技能与当前环境实际支持的功能是否兼容——例如 Python 辅助工具、凭据、网络访问和平台限制。如果技能需要的条件在当前环境中不可用，应在简报中说明（“此方案需要 X，但当前环境不支持——备用方案是 Y”），让模式问题在工作开始前就显现，而不是等到任务进行中才发现。
6. 确认后执行。 展示简报并等待用户同意或提出修正——回复一个词“开始”就足够；这只是快速确认，不是填写表格。之后应按照简报开展工作。
7. 完成闭环。 交付时，根据目标一项检查产出，并明确说明“已完成”的各项要求中哪些已满足、哪些仍未完成——绝不声称执行过实际上并未执行的检查。

示例（虚构）

用户：“整理一份关于 Northwind 账户数据的材料，供周四的电话会议使用”

Agent 检查文件夹（找到 northwind-q2-summary.xlsx），然后提出两个问题——受众（内部团队还是客户）和形式（一页式仪表板还是谈话要点备忘录）——并整理出：

**Task brief — Northwind Q2 numbers for Thursday's call**
- **Goal** — a one-page dashboard (PDF via browser print) of the Northwind
  account's Q2 numbers, for the internal team call on Thu 12 Mar; done = the
  reader sees revenue vs budget, pipeline and overdue items at a glance.
- **Context** — source: northwind-q2-summary.xlsx (this folder); Q1 comparison
  available in the same file; internal audience per your answer.
- **Constraints** — internal draft, not for client distribution; figures traced
  to the source file, none invented; consistent currency and date formats.
- **Assumptions** — "numbers" = the account KPIs, not the contract terms (say
  if you want those in).
- **Tooling** — the installed dashboard/visualisation skill; spreadsheet read
  via the local data engine.

用户回复“开始吧，再加上合同续约”——在开始工作前发现并修正了一个问题，而不是事后才发现。

原则

• 草稿，而非建议——简报及其所框定的工作都是供人审阅的草稿，不构成专业建议。
• 绝不编造——用户未补充的缺口应标记为假设或留白，不得用看似合理的猜测填补。
• 适度原则——简报的成本必须低于它所避免的误解造成的成本；琐碎请求无需简报。
• 诚实并校准预期——依据目标行检查结果，并明确报告已完成和待完成的事项。
• 确认环节才是价值所在——在工作开始前纠正误读几乎不费成本；交付后才纠正，同一问题就会耗费整个任务的成本。

数据处理

简报本身通常会引用客户、交易对手或个人背景信息——它只保留在聊天和本地工作文件夹中；绝不要将简报发送给外部工具或第三方工具。如果任务中的某个步骤需要访问外部服务，应先对敏感数据去标识化，并向用户确认数据外发事宜。此技能本身不需要网络、脚本或凭据。

注意事项

1. 提问过多导致疲劳——一开始提出超过 2–3 个问题，用户就会停止回答；其余问题应转为标记的假设。
2. 询问本可读取的信息——询问文件夹或对话中已有的信息，会削弱用户对整份简报的信任。
3. 用泛泛的约束凑篇幅——每份简报都列出所有常规规则，会掩盖真正重要的规则；只纳入会影响当前任务的规则。
4. 跳过闭环步骤——目标行是判断“完成”的标准；交付前不对照检查，就浪费了简报的价值。
5. 依赖工具——把用户没有的工具列为计划；未安装的功能只能作为建议。

收集反馈

如果你发现此技能有需要修正或改进之处，请用结构化说明记录——技能名称、你采取的操作、预期与实际结果、严重程度、建议——保存为纯文本文件，并交给用户归档。由人工处理，没有固定目的地；如用户提出要求，可在范围内修复。这样可以确保改进反馈持续传达给技能作者，而不是消失在聊天记录中。

验证清单

• 已确认任务较为重要（或用户明确调用此技能），而非琐碎请求。
• 提问前已检查请求、对话、文件和记忆。
• 提出的问题不超过 2–3 个，且每个问题都会影响输出。
• 已从宿主环境（或默认设置）注入常规规则，而非向用户询问。
• 已根据环境支持的功能预先筛选路由到的技能。
• 工作开始前已向用户展示简报并获得确认。
• 已依据目标行检查输出；已完成与待完成事项均已报告。

要求

• 无——这是一项仅依赖推理的技能：不需要 Python、网络或凭据。只要 Agent 环境能够读取此文件，就可以运行。