用途
decision-mapping 用于处理这样一种情况：一个松散想法需要超过一个 agent session 才能变成 plan。此时调用该 skill，它会在 markdown file 中创建 stateful decision map，并带用户按 ticket 顺序解决 open questions；这些问题可能需要 prototyping、research 或 discussion。
主要能力
Decision Map
Decision map 是一个紧凑 Markdown file，每个 planning effort 一个，并随项目被 git-tracked。它是 canonical artifact：每个 session 都会把整张 map 加载为 context，所以它必须保持紧凑。
Tickets 期间创建的 assets 应从 map 链接过去，不要复制进 map。
结构
编号 entries（"tickets"），每个独立 section，以编号为 key：
## #1: Relational Or Non-Relational Database?
Blocked by: #<ticket-number>, #<ticket-number>
Type: Research | Prototype | Grilling
### Question
Answer
每个 ticket 的大小必须适合一个 100K token agent session。
Ticket 类型
三类 tickets：
- Research：阅读 documentation、third-party APIs，或 knowledge bases 等 local resources。创建 markdown summary 作为 asset。当需要当前工作目录外的知识时使用。
- Prototype：编写 UI 或 logic code 来测试 hypothesis，或探索 design space。使用 /prototype skill。创建 prototype 作为 asset。当核心问题是 "how should it look" 或 "how should it behave" 时使用。
- Grilling：与 agent 对话。使用 /grilling 和 /domain-modeling skills。一次问一个问题。默认类型。
Fog of war
Map 在 frontier 之外是有意不完整的。你的工作是调查 frontier，并按顺序解决 tickets 来推动 frontier 前进。一次推进一个 node，推开 fog of war。
到某个时刻，fog of war 会被推得足够远，通往 finish line 的路径会变清楚。那时不再需要更多 tickets，decision map 可视为 done。
使用方式
两种调用方式：bootstrap 和 resume。
Bootstrap
用户带着松散想法调用。
- 运行 /grilling + /domain-modeling session，浮现 open decisions。一次问一个问题。
- 写一张新的 decision map：大部分是 fog，frontier 已识别，显然可决定的 entries 内联解决。
- 停止。建 map 是一个 session 的工作；不要同时解决 tickets。
Resume
用户提供 existing map path 和 ticket number。
- 把 whole map 作为 context 加载。
- 运行一个 session 解决该 ticket，按需调用 skills。不确定时使用 /grilling 和 /domain-modeling。
- 在 ticket body 中记录本 session 解决了什么。
- 添加新发现的 tickets（带正确 blocked_by edges）。
- 停止。
如果新 decisions 使 map 其他部分失效，更新或删除那些 nodes。
并行
用户可能选择并行运行 tickets，所以要预期其他 agents 会修改 map。
跳过 Decision Map
很多时候，初始 grilling 不会产生 fog of war：没有未解决 tickets，也就没有别的要做，只剩 implement。
这种情况下，应让用户选择跳过 decision map，因为只有 multi-session decisions 才需要它。
如果用户跳过，建议直接 implement，或使用 /to-prd 安排 multi-session implementation。
适用场景
- 一个松散想法需要多个 agent session 才能形成 plan。
- 存在多个 open questions，需要按依赖顺序逐个解决。
- 问题类型涉及 research、prototype 或 grilling。
- 需要一张随项目 git-tracked、可跨 session 加载的 canonical artifact。
限制
- 每个 ticket 的大小必须适合一个 100K token agent session。
- map 必须保持紧凑，assets 应链接而非复制进 map。
- 只有 multi-session decisions 才需要 decision map；若初始 grilling 未产生 fog of war，可跳过。
- 并行运行 tickets 时需预期其他 agents 会修改 map。
- 关于收费、价格、平台支持等具体信息，资料中暂未提供。