关于 decision-mapping
decision-mapping 是一项 Agent 技能,可将尚有未决问题的初步想法整理为精简、持续更新的 Markdown 决策图,并分多次会话逐项解决。它通过有序票据组织研究、原型制作和讨论。
主要功能
- 01持续维护的 Markdown 决策图
- 02带依赖关系的编号票据
- 03研究、原型和讨论票据类型
- 04创建与续接工作流程
- 05随决策变化更新决策图
适用场景
- 01将宽泛想法拆分为多会话决策
- 02规划前研究外部依赖
- 03制作原型以验证设计问题
- 04从现有决策图继续工作
安装
复制下面的命令,在终端中运行。
npx skills add https:/ / github.com/ utarn/ engineer-skills --skill decision-mapping安装后在 Claude Code 中输入/decision-mapping确认已加载。
详细介绍
当一个粗略想法需要多个 Agent 会话才能转化为计划时,会调用此技能。它会在 Markdown 文件中创建一份有状态的决策图,并引导用户按顺序处理一系列工单,以解决未决问题——这可能需要原型设计、调研或讨论。
决策图
每项规划工作对应一份精简的 Markdown 文件,作为唯一的决策图,与项目一同纳入 Git 跟踪。它是规范产物——每个会话都会将整份决策图加载为上下文,因此必须保持精简。
工单过程中创建的素材应在决策图中以链接引用,而不是复制到其中。
结构
编号条目(“工单”),每个条目各自构成一个章节,并以编号为键:
## #1: Relational Or Non-Relational Database?
Blocked by: #<ticket-number>, #<ticket-number>
Type: Research | Prototype | Grilling
### Question
<question-here>
### Answer
<answer-here>
每个工单的工作量都应控制在一个 100K token 的 Agent 会话内。
工单类型
工单分为三种:
- 调研:阅读文档、第三方 API 或知识库等本地资源,并创建 Markdown 摘要作为素材。当需要了解当前工作目录之外的信息时使用。
- 原型设计:编写 UI 或逻辑代码来验证假设,或探索设计空间。使用 /prototype 技能,并创建原型作为素材。当关键问题是“应该是什么样”或“应该如何运行”时使用。
- 深入讨论:与 Agent 对话。使用 /grilling 和 /domain-modeling 技能。每次只问一个问题。默认使用此类型。
未知区域
决策图在前沿之外的部分会_有意_保持不完整。你的任务是探索前沿,并解决工单以推进前沿。一次推进一个节点,逐步拨开迷雾。
在某个阶段,迷雾应已充分散去,通往终点的路径也清晰可见。此时不再需要更多工单,决策图也就可以视为“完成”。
调用方式
此技能有两种调用方式:初始化和继续。
初始化
用户提供一个粗略想法来调用。
- 使用 /grilling + /domain-modeling 进行会话,梳理未决事项。每次只问一个问题。
- 编写一份新的决策图——大部分内容保持未知,标明前沿,并在图中直接解决可轻松决定的条目。
- 停止。构建决策图是一项独立会话的工作;不要同时解决工单。
继续
用户提供现有决策图的路径和工单编号来调用。
- 将整份决策图加载为上下文。
- 开展会话以解决该工单,并按需调用技能。如有疑问,使用
/grilling和/domain-modeling。 - 在工单正文中记录本次会话解决的事项。
- 添加新发现的工单(并设置正确的
blocked_by依赖关系)。 - 停止。
如果作出的决定会使决策图的其他部分失效,请更新或删除相应节点。
并行处理
用户可能会选择并行处理工单,因此要预期其他 Agent 会修改决策图。
跳过决策图
很多时候,初始深入讨论后不会留下任何未知区域,也没有未解决的工单。这时除了直接实现外,无需做其他工作。
在这种情况下,你应让用户有机会跳过决策图——因为只有在需要跨多个会话作出决策时,才有必要使用决策图。
如果用户跳过,应建议直接实现,或使用 /to-prd 安排跨多个会话的实现工作。