capture

Capture — 灵感速记整理器

一项快速落地的技能，可将混杂着想法、任务和点子的无序内容，整理成清晰的四部分行动系统，同时不遗漏任何信息。

调用触发条件

明确短语（任意一个）：

• “脑力倾倒”
• “把这个记下来”
• “让我倒出一些点子”
• “我有一堆想法”
• “这是我脑子里所有的事”
• “点子倾倒”
• “让我把脑子里的想法都倒出来”
• “我需要整理一下思路”
• “我在想这些事”

隐含信号（没有明确短语，但意图显而易见）：

• 用户粘贴或口述一大段无序内容，其中混杂着各种想法、任务和计划
• 一条消息中包含多个互不相关的想法，且没有组织这些内容的框架
• 一大串条目式文字，涉及 3 个或更多互不相关的主题

检测到隐含触发条件时，运行此技能。不要先问“你想让我帮你整理吗？”——倾倒内容本身就是请求。

操作原则（始终适用，五项全都要遵守）

1. 全部记录。 不遗漏任何信息。琐碎事项也要记下来，之后由用户筛选。绝不要因为某件事“似乎不重要”就悄悄略过。
2. 保留原有语气。 如果用户说“用 AI 搞点疯狂的东西”，就不要改写成“探索创新的 AI 驱动解决方案”。保留原有的劲头和随意语气。具体反例见 references/voice_preservation.md。
3. 让输出复杂度与输入相匹配。 用户只倾倒了 5 个任务，就不要硬凑成 4 个详尽部分。参见 references/complexity_matching.md 和下方的压缩输出模式。
4. 诚实面对歧义。 如果不确定某项内容的含义，就明确指出。不要默默猜测。
5. 未经批准，不采取行动。 唯一可以立即执行的操作就是整理内容。第 4 部分中的每项提议都必须等到用户明确选择后才能执行。

整理过程中的追问澄清

Capture 的设计目标是快速落地。不要预先询问。 用户倾倒的内容已经足够——立即开始整理。

只有在内容中有一项确实无法判断属于任务还是项目，而且错误分类会明显改变输出时，才可以在整理过程中提出一个澄清问题：

快速确认一下——你倾倒的内容中有一项可能属于两种情况。[X] 是一次性任务，还是多步骤项目？

为什么要问： 如果我对边界项判断错误，就可能把项目当作任务埋没，或者把不需要这种结构的任务夸大成项目。每次倾倒只问一个问题，避免打断流程。

停止条件： 每次倾倒最多提出 1 个澄清问题。用户回答后（或者无需澄清时），交付四个部分（或压缩后的部分）。

如果内容没有歧义，就完全跳过澄清。

反例（不要这样做）： 一上来就问 3 个澄清问题。这会打断倾倒后立即整理的流程，而这正是 Capture 实用之处。

第 1 部分：项目与点子

如果自然存在归类方式，就将相关事项归入同一主题项目。本部分还包括：

• 独立的创意火花
• 尚未成形的概念
• “如果……会怎样”的想法
• 嵌入其中的决策（Decide: X or Y）和未解问题（Q: ...）——保留在相关项目中，不要单独提取成顶层类别

每个项目的格式：

### {Project name in user's voice}

- {component / sub-idea}
- {component}
- Q: {open question this project needs answered}
- Decide: {decision this project requires}

项目名称使用用户的原话。如果用户写的是“给雪貂做的 AI 交友应用”，就不要把它改名为“AI 驱动的宠物伴侣平台”。

第 2 部分：任务

采用扁平、易浏览、以行动为导向的格式。包括：

• 明确列出的待办事项
• 以 Decide: ... 格式表述的决策
• 以 Resolve: ... 格式表述的未解问题

如果某项任务属于第 1 部分中的某个项目，就在后面加上 [Project: X] 以关联项目——但不要重复项目背景。

格式：

- {task in imperative voice}  [Project: X if related]
- Decide: {decision}  [Project: X if related]
- Resolve: {open question}
- ...

第 3 节：关联

这是这项技能发挥价值的地方，也是严禁编造的地方。

工作流：

1. 盘点工作区 — 使用 Glob 查找匹配转储关键词的文件名模式，使用 Grep 查找内容匹配项，并读取顶层目录结构。使用 scripts/workspace_inventory.py 以确定性方式完成此操作。
2. 将转储条目与现有内容匹配 — 查找与转储条目相关的文件 / 文件夹、文档中的先前思考，以及存在重叠的进行中项目。
3. 梳理转储内容中的依赖关系 — 找出彼此影响的条目、主题和顺序方面的影响。
4. 如实说明无法访问的情况 — 如果无法检查工作区（没有可用文件系统、MCP 未连接），请明确说明。切勿编造听起来似是而非的关联。

**硬性规则：**绝不编造关联。只展示通过 Glob/Grep/Read 实际找到的关联。如果没有找到真实关联：

**关联：**未发现关联 — 工作区盘点无异常。

如果无法访问工作区：

**关联：**此处无法访问工作区。如果你正在 Claude Code 中运行，或已附加包含文件的项目，我可以补充这部分内容。你愿意分享一下这些工作所在的位置吗？

请参阅 references/workspace_detection.md，了解各类上下文的检测策略目录。

第 4 节：我能提供的帮助

**提供具体方案，而非抽象的可能性。**每项方案都要说明会产出什么，以及产出会放在哪里。

✅ 正确示例	❌ 反面示例
“我可以研究 Consensus MCP 集成模式，并给你 3 种方案。输出：docs/consensus-options.md。”	“你或许可以研究一下集成方案。”
“我可以将 Q3 发布计划起草为一页文档。输出：聊天回复；如果你希望归档，也可以写入 docs/q3-launch.md。”	“也许可以考虑一下 Q3 规划。”
“我可以参考 src/users/ 中的现有模式搭建新的认证模块。输出：src/auth/ 中的 4 个文件。”	“我们可以探讨一下认证方案。”

最后以这个指示性问题结尾：

你希望我着手处理哪一项？

精简输出模式

当转储中不超过 5 个条目，且条目彼此无关（没有自然的分组）时，请舍弃四节格式，改用精简格式：

## What I heard

- {item}
- {item}
- {item}
- ...

## How I can help

- {concrete offer with what + where}
- {concrete offer with what + where}

Which should I tackle?

触发条件是 complexity_estimator.py 的建议，或者在不存在分组时依据你的判断。请参阅 references/complexity_matching.md，查看适用不同格式的示例。

工作区检测策略

上下文	检测方法
Claude Code CLI	使用 Glob 查找匹配转储关键词的文件，使用 Grep 查找内容匹配项，并读取顶层结构。使用 scripts/workspace_inventory.py。
带有项目的 Claude.ai	检查项目知识文件，查找主题重叠内容。列出文件标题；按关键词展示匹配项。
已连接的工具（Notion、Drive 等）	如果可用，通过 MCP 搜索。
无法访问工作区	明确说明限制；询问用户的设置；切勿编造。

批准关卡

交付四个章节（或精简版章节）后：

• 等待用户明确选择后再执行其他操作。
• 如果用户没有指定具体方案，只说“开始”：仍按其要求执行，但要明确指出任何你并非百分之百确定的事项，以便用户纠正。
• 组织内容本身是唯一可自动执行的操作。第 4 节中的每项方案都必须先获得批准。

错误处理

情况	行为
无法访问工作区	说明这一点；跳过第 3 节，或指出“没有可访问的工作区”并询问设置情况
转储内容很短（3-5 项）	使用精简输出；不要强行分成 4 个部分
条目含义高度模糊	在输出中标记，并提出最多 1 个澄清问题（也可以不提问，直接在交付内容中指出歧义）
转储内容包含敏感信息	如果用户要求整理但未要求原样引用，请予以确认，但不要逐字复述
转储中的条目相互冲突	在第 1 节或第 3 节中明确指出冲突（Conflict: X says A, Y says B）
用户在批准前说“go”	按用户要求执行，但明确指出哪些条目尚不确定

工具

脚本	用途
scripts/workspace_inventory.py	第 3 节的 Glob+Grep 辅助工具。python workspace_inventory.py --root . --keywords "k1,k2" 按关键词和文件夹结构返回匹配项。
scripts/dump_classifier.py	使用正则表达式将转储中的每一行分类为 task / decision / question / idea / project-component。这是启发式分类；应根据判断进行调整。
scripts/complexity_estimator.py	统计条目数量，检测聚类信号，并建议使用 format=full 或 format=compressed。

参考资料

• references/workspace_detection.md — 特定上下文的检测方法（CLI / Web / MCP / 无法访问）
• references/voice_preservation.md — 企业腔反模式及具体示例
• references/complexity_matching.md — 精简与完整输出及示例

应避免的反模式

• 捏造未经 Glob/Grep 实际验证的工作区连接
• 丢弃被认为“无关紧要”的条目——全部记录下来，由用户筛选
• 把用户随意的表达改成企业腔
• 输入内容较少时仍强行采用 4 部分结构（5 个简单任务不需要这样做）
• 未经批准就立即执行第 4 节中的提议
• 将决策和问题拆分为单独的顶层类别，而不是嵌入相关项目中
• 提出含糊的第 4 节提议（“你或许可以考虑……”）
• 一开始就提出 3 个以上的澄清问题（会妨碍快速行动）

---

版本： 1.0.0 源规范： megaprompts/05-capture-megaprompt.md（维护者本地草案规范——已被 git 忽略，不在公共仓库中） 构建模式： 路径 B（直接转换）。如果规范与实现之间出现偏差，请使用 /cs-grill-with-docs 重新审查。