decide

decide skill 概览

decide 的作用

decide 是一个面向 C-level advisor 流程的技能，用来把已经获批的战略 memo 转化为可长期保留的公司记忆。在实际使用中，/cs:decide <memo-path> 位于 boardroom 式讨论之后、执行之前：它会确认创始人已批准该 memo，提取决策记录，并通过相关的 decision-logger 工作流进行归档。

它的核心任务不是“帮我做选择”，而是“把我们已经批准的选择记录下来，让未来的 AI 会话可以把它当作公司上下文使用”。

最适合 Knowledge Capture 工作流

decide skill 最适合用于 Knowledge Capture：当你的团队使用 Claude 或 agent 工作流定期开展高管讨论、战略复盘或创始人决策会议时，它会很有价值。尤其适合你想清晰区分以下两类内容的场景：

• 原始讨论、反对意见和会议转录
• 已获批准、应影响未来规划的决策

这种区分很重要，因为尚未定论的讨论不应该意外变成组织记忆。

核心差异：双层记忆模型

上游 skill 描述了一个由 decision-logger 管理的双层模型：

1. 存放在 ~/.claude/decisions/raw/ 下的原始转录
2. 存放在 ~/.claude/decisions/approved/ 下的已批准决策

只有已批准的决策才应进入未来的 /cs:office-hours 和 /cs:founder-mode 调用上下文。因此，decide 比通用的“总结这次会议”prompt 更保守：它在讨论过程和组织记忆之间设置了一道门槛。

什么时候不适合使用 decide

不要把 decide 当成一个泛用的决策助手、头脑风暴工具或项目管理系统来安装。它默认你已经有 board memo、审批状态，以及一套围绕 C-level advisor 的流程。如果你的工作流只是临时笔记，在形成稳定审批流程之前，更适合先使用轻量级的记笔记或总结 prompt。

如何使用 decide skill

decide 安装背景

从 GitHub skill repository 安装：

npx skills add alirezarezvani/claude-skills --skill decide

然后查看源文件：

c-level-advisor/c-level-agents/skills/decide/SKILL.md

这个 skill 的文件范围很窄：主要依据就是 SKILL.md。在给出的目录树中，看不到明显的 helper scripts、references、README 文件或 resource folders，因此是否适合采用，取决于你的环境是否已经支持周边的 C-level commands 以及 decision-logger skill。

使用 decide 所需的输入

命令格式是：

/cs:decide <memo-path>

输入应当是一个 board memo 文件，通常由 /cs:boardroom 生成。高质量输入应包含：

• 决策标题
• 决策日期
• 被选中的方案
• status: APPROVED 或等效的创始人批准标记
• 成功标准
• 停止标准
• 需要保留的反对意见
• 复盘检查点日期

像“我们决定拓展销售”这样的弱输入是不够的。更好的 prompt 可以是：“Use /cs:decide ./memos/2026-02-enterprise-sales.md. Confirm founder approval, extract the chosen option, preserve dissent, and log success criteria, kill criteria, and the Q2 review checkpoint.”

实用的 decide 工作流指南

一个可靠的 decide 工作流通常如下：

1. 在 /cs:boardroom 中完成讨论。
2. 将已获批准的 memo 保存到稳定路径。
3. 确认 memo 明确写明创始人已批准。
4. 运行 /cs:decide <memo-path>。
5. 确认已批准记忆与原始转录材料被分开写入。
6. 将记录下来的决策作为 /cs:execute 或未来规划会议的上下文使用。

这个顺序可以减少意外的记忆污染。只有在决策流程中的同一节点持续使用时，这个 skill 的价值才最大。

采用前应阅读的文件

先阅读 SKILL.md，重点关注这些部分：

• Pipeline Position
• Two-Layer Memory Model
• Input
• Workflow

由于预览中没有额外的支持文件，采用时的主要问题并不是 repository 是否复杂，而是是否匹配：你是否已经有获批 memo，以及一套与该 skill 描述的路径和预期相符的长期记忆约定？

decide skill 常见问题

decide 是用来做决策的 skill 吗？

不是。decide 记录的是已经获批的决策；它不负责组织讨论。它应该放在决策完成之后，通常是在 /cs:boardroom 之后。如果你需要生成选项、分析风险或进行 advisor debate，应先使用更前置的工作流步骤。

decide 相比普通 prompt 好在哪里？

普通 prompt 可以总结 memo，但 decide 编码的是一条治理边界：原始转录是参考材料，而已批准决策会成为长期记忆。这个区别正是使用 decide skill，而不是简单让 Claude “remember this”的主要原因。

新手可以使用 decide 吗？

可以，前提是他们已经理解基于文件的 prompt，并且手头有准备好的 memo。如果还没有使用更完整的 c-level-advisor 命令结构，新手可能会遇到困难，因为 decide 默认存在一条 pipeline，并会引用 decision-logger。在把它用于运营记忆之前，建议先用一份已批准 memo 做测试。

什么会阻碍 decide 成功安装？

最大的阻碍通常是缺少周边 skills、审批状态不清晰，以及 memo 结构混乱。如果你的环境无法调用 /cs:decide、无法访问 memo 路径，或没有兼容的 decision-logger 设置，这个 skill 可能无法完成预期的记忆写入。

如何改进 decide skill

运行前先改进 decide 输入

提升 decide 输出质量最快的方法，是让 memo 写得足够明确。在调用 skill 前添加一个简短的决策头部：

• Status: APPROVED
• Decision: Choose Option B
• Owner: Founder / CEO
• Success criteria: ...
• Kill criteria: ...
• Review checkpoint: ...
• Dissent to preserve: ...

这样可以减少 agent 推断审批状态或自行补全缺失结构的空间。

需要避免的常见失败模式

最常见的失败，是把讨论记录当成决策写入。除非 memo 清楚说明哪个方案胜出，否则不要提交转录、未解决的笔记或多个竞争选项。另一个失败点是遗漏 kill criteria；没有这些标准，未来复盘时就无法判断应该“继续”还是“停止”。

也不要把 decide 当成一个包打天下的记忆命令。它的价值来自选择性写入。

首次输出后继续迭代

第一次运行后，检查写入的决策是否简洁、可审计，并且对未来有用。如果记录过于模糊，就修改 memo，用更清晰的字段重新运行。好的长期记忆应当让未来的 agent 能回答：我们决定了什么，为什么选择它，什么情况会证明它是错的，以及什么时候应该复盘？

为你的操作系统扩展 decide

团队可以通过标准化 memo 模板、加入必需的审批措辞，并让记忆路径与内部约定保持一致，来改进 decide skill。如果你维护这个 repository，有价值的增强包括 README、已批准 memo 示例、验证清单，以及针对 decision-logger 的更清晰依赖说明。这些补充会让 decide 的安装决策更容易，也能减少设置时的不确定性。