briefing

简报

向用户简要呈现当前任务中有助于决策的情况。恢复与任务相关的工作上下文，不要把整段对话或整个代码库都复述一遍。

来源

按以下顺序阅读来源，并在你准备简报的每一点都有依据后停止；其他内容标记为推断：

• 当前对话
• 代码库中最少量的相关文件
• 相关本地文档，例如 AGENTS.md、ARCHITECTURE.md 或附近的模块文档（仅当它们会影响对任务的理解时）

如果文件路径能明显帮助用户重新了解代码，请注明。

重点

根据用户的明确要求判断重点；默认为 status；如果重点混合，则结合所需重点，不要把回复写成选项菜单。

• status — 用户要求了解进展或当前状态：聚焦当前实现状态。
• plan — 用户询问接下来可能采取的步骤：聚焦可能的方案和涉及的区域。
• teach — 用户想了解相关代码：聚焦各部分的职责、边界和流程。
• decision — 用户需要做出决策：聚焦约束、权衡和影响重大的未知事项。

非目标

不要使用此技能来生成：

• 仓库的完整架构总结
• 计划审查、代码审查或设计审查
• 项目路线图重建，除非当前任务依赖于此
• 对整段对话冗长的回顾
• 逐行讲解实现细节，除非用户明确要求

工作流程

1. 确定所需重点（见“重点”）。

2. 明确任务边界。

• 具体说明当前请求。
• 必要时区分当前任务与之前的旁支讨论。

3. 收集必要的上下文。

• 从当前对话开始。
• 只阅读能够说明当前状态的最少量文件和文档。
• 优先查看入口点、已修改文件、相邻接口和稳定文档，避免广泛探索。

4. 综合信息，便于快速了解。

• 将原始发现归纳为用户当前需要了解的少数事实。
• 直接指出相关文件和模块。
• 说明它们与当前任务的关系。

5. 大幅精简。

• 删除重复内容。
• 删除代码细节和价值较低的历史信息。
• 删除推测性陈述，除非明确标注为推断。
• 除非当前任务确实涉及未决问题，否则不要提出开放性问题。

输出

默认总计 8–14 条要点，或篇幅相当的简短章节。

除非用户另有要求，否则采用以下结构：

当前任务

• 用 1–3 条要点说明正在处理的内容。

相关代码

• 列出关键文件或模块，并简要说明其重要性。

当前重要事项

• 说明与当前任务相关的实现事实、行为或约束。

决策背景

• 仅列出用户做出下一步决策所需的信息。
• 只有在有帮助时，才简要说明下一步。