Back to Details

decision-mapping

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese
This skill is invoked when a loose idea requires more than one agent session to turn into a plan. It creates a stateful decision map in a markdown file, and drives the user through a sequence of tickets to resolve the open questions - which may require either prototyping, research or discussion.
当一个模糊的想法需要多个Agent会话才能转化为计划时，会调用此Skill。它会在Markdown文件中创建一个有状态的决策地图，并引导用户完成一系列工单以解决未决问题——这些问题可能需要原型开发、研究或讨论。

The Decision Map

决策地图

The decision map is a single compact Markdown file, one per planning effort, git-tracked alongside the project. It is the canonical artifact — the whole map is loaded as context into every session, so it must stay compact.
Assets created during tickets should be linked to from the map, not duplicated within it.
决策地图是一个简洁的Markdown文件，每个规划任务对应一份，与项目一起由Git追踪。它是标准工件——整个地图会作为上下文加载到每个会话中，因此必须保持简洁。
工单处理过程中创建的资产应在地图中添加链接，而非在地图内重复内容。

Structure

结构

Numbered entries ("tickets"), each its own section keyed by its number:
markdown
undefined
编号条目（“工单”），每个条目都是一个以编号为标识的独立章节：
markdown
undefined

#1: Relational Or Non-Relational Database?

#1: Relational Or Non-Relational Database?

Blocked by: #<ticket-number>, #<ticket-number> Type: Research | Prototype | Discuss
Blocked by: #<ticket-number>, #<ticket-number> Type: Research | Prototype | Discuss

Question

Question

<question-here>
<question-here>

Answer

Answer

<answer-here> ```
Each ticket must be sized to one 100K token agent session.
<answer-here> ```
每个工单的规模应控制在一个100K Token的Agent会话内。

Ticket Types

工单类型

There are three types of tickets:
  • Research: Reading documentation, third-party API's, or local resources like knowledge bases. Creates a markdown summary as an asset. Use this when knowledge outside the current working directory is required.
  • Prototype: Writing UI or logic code to test a hypothesis, or to explore a design space. Uses the /prototype skill. Creates a prototype as an asset. Use this when "how should it look" or "how should it behave" is the key question.
  • Discuss: Conversation with the agent. Uses the /grilling and /domain-modelling skills. The default case.
工单分为三种类型：
  • Research（研究）：阅读文档、第三方API或知识库等本地资源。生成Markdown摘要作为资产。当需要当前工作目录之外的知识时使用此类型。
  • Prototype（原型开发）：编写UI或逻辑代码以验证假设，或探索设计空间。使用/prototype Skill。生成原型作为资产。当核心问题是“它应该是什么样子”或“它应该如何运行”时使用此类型。
  • Discuss（讨论）：与Agent对话。使用/grilling和/domain-modelling Skill。这是默认类型。

Fog of war

战争迷雾

The map is deliberately incomplete beyond the frontier. Your job is to investigate the frontier, and to resolve tickets in order to push the frontier forward. Push back the fog of war, one node at a time.
At some point, the fog of war should have been pushed back far enough that the path to the finish line is clear. At that point, no more tickets will be required and the decision map can be considered 'done'.
地图在当前边界之外是故意不完整的。你的任务是探索边界，通过解决工单来推进边界。一步步拨开战争迷雾，逐个节点推进。
在某个阶段，战争迷雾会被充分拨开，通向终点的路径变得清晰。此时不再需要更多工单，决策地图即可视为‘完成’。

Invocation

调用方式

There are two ways this skill can be invoked: bootstrap and resume.
此Skill有两种调用方式：bootstrap（初始化）和resume（恢复）。

Bootstrap

初始化

User invokes with a loose idea.
  1. Run a /grilling and /domain-modelling session to surface the open decisions.
  2. Write a new decision map — mostly fog, frontier identified, trivially-decidable entries resolved inline.
  3. Stop. Map-building is one session's work; do not also resolve tickets.
用户通过一个模糊的想法调用。
  1. 运行/grilling和/domain-modelling会话，梳理出未决决策。
  2. 编写新的决策地图——大部分内容处于迷雾中，明确边界，简单可决的条目直接在地图内解决。
  3. 停止。地图构建是一个会话的工作；不要同时解决工单。

Resume

恢复

User invokes with a path to an existing map and a ticket number.
  1. Load the whole map as context.
  2. Run a session to resolve the ticket, invoking skills as needed. If in doubt, use 
    /grilling
    and 
    /domain-modelling
    .
  3. Record what the session resolved in the ticket's body.
  4. Add newly-discovered tickets (with correct 
    blocked_by
    edges).
  5. Stop.
If the decisions made invalidate other parts of the map, update or delete those nodes.
用户通过现有地图的路径和工单编号调用。
  1. 加载整个地图作为上下文。
  2. 运行会话以解决工单，根据需要调用其他Skill。如有疑问，请使用
    /grilling
    和
    /domain-modelling
    。
  3. 将会话解决的内容记录在工单主体中。
  4. 添加新发现的工单（并设置正确的
    blocked_by
    依赖关系）。
  5. 停止。
如果做出的决策使地图的其他部分无效，请更新或删除这些节点。

Parallelism

并行处理

The user may choose to run tickets in parallel, so expect other agents to make changes to the map.
用户可能会选择并行处理工单，因此要考虑到其他Agent会对地图进行修改。

Skipping The Decision Map

跳过决策地图

Many times, the initial grilling will result in no fog of war. No unresolved tickets. Nothing to do, except implement.
In those situations, you should offer the user the chance to skip the decision map - since the decision map is only needed if multi-session decisions need to be made.
If they skip it, you should recommend either implementing directly or using 
/to-prd
to schedule a multi-session implementation.
很多时候，初始的grilling会话不会产生战争迷雾。没有未解决的工单。除了直接实现之外，无需其他操作。
在这种情况下，你应该为用户提供跳过决策地图的选项——因为只有当需要跨多会话决策时，决策地图才是必要的。
如果用户选择跳过，你应该建议直接实现，或者使用
/to-prd
来安排跨多会话的实现任务。