decision-mapping 是一个面向多会话规划的技能，适用于一个松散想法需要超过一个智能体会话才能转化为计划的情况。
用途：当用户提出一个模糊想法、需要经过多次调查和讨论才能明确方向时，该技能帮助建立一份带状态的决策地图，并引导用户按顺序解决其中的开放问题。这些问题可能需要通过原型、研究或讨论来回答。
主要能力：
- 创建决策地图：每个规划工作对应一个紧凑的 Markdown 文件，与项目一起纳入 git 管理。整份地图会作为上下文加载到每个会话中，因此必须保持精简。工单期间创建的资产应在地图中链接，而非重复嵌入。
- 工单结构：地图由编号条目（工单）组成，每个工单是独立章节，包含标题、被阻塞于（blocked by）哪些工单、类型（Research | Prototype | Grilling）、问题与答案。每个工单须控制在一个 100K token 的智能体会话规模内。
- 三种工单类型：
- Research：阅读文档、第三方 API 或本地资源（如知识库），产出一份 Markdown 摘要作为资产。适用于需要当前工作目录之外的知识。
- Prototype：编写 UI 或逻辑代码验证假设、探索设计空间，使用 /prototype 技能，产出原型作为资产。适用于“应该长什么样”或“应该如何表现”是核心问题的场景。
- Grilling：与智能体对话，使用 /grilling 和 /domain-modeling 技能，一次只问一个问题。这是默认类型。
- 战争迷雾（Fog of war）：地图在前沿之外刻意保持不完整。任务是调查前沿，通过解决工单推动前沿向前，一次推进一个节点。当迷雾被推到足够远、通往终点的路径清晰时，不再需要工单，决策地图即视为完成。
使用方式：技能有两种调用模式：
- Bootstrap：用户以一个松散想法调用。运行 /grilling 和 /domain-modeling 会话，一次一个问题地浮现开放决策；写入新的决策地图（大部分是迷雾，识别前沿，可轻易决定的条目就地解决）；然后停止。地图构建是一个会话的工作，不应同时解决工单。
- Resume：用户以现有地图路径和工单编号调用。加载整份地图作为上下文；运行会话解决该工单，按需调用技能（存疑时使用 /grilling 和 /domain-modeling）；在工单正文中记录本次会话解决的内容；添加新发现的工单（含正确的 blocked_by 关系）；然后停止。如果所做的决策使地图其他部分失效，应更新或删除那些节点。
并行性：用户可能选择并行运行工单，因此需预期其他智能体会修改地图。
跳过决策地图：很多时候初始 grilling 会发现没有迷雾、没有未解决工单，除了实现之外无事可做。此时应向用户提供跳过决策地图的机会，因为决策地图仅在需要多会话决策时才必要。若用户跳过，建议直接实现或使用 /to-prd 安排多会话实现。
适用场景：需要多轮调查、原型验证或讨论才能形成计划的松散想法；需要跨会话保持决策状态与依赖关系的规划工作。
限制：每个工单须控制在一个会话规模内；地图须保持紧凑，资产只链接不复制；该技能的详细介绍中未提及收费、价格、平台兼容性等具体信息，暂未提供。