whats-next

下一步是什么

结束一个会话，并交接下一个会话的开场内容：一段足够简短、能一眼读完且无需编辑即可复制的提示词。

沿着当前路线图前进。 除非当前路线图已完成，否则下一步必须仍在同一张路线图上。不要提出其他工作、诱人的支线任务，也不要提出途中想到的清理工作——一次只处理一张路线图，这是 /wayfinder 的全部准则；这项技能最容易在这里偏离准则。

输出的是提示词，不是建议。 人类采取行动所需的一切都要放在可复制的代码块中。代码块容纳不下的推理，写在上方的一行标签里，或者干脆不写。

流程

1. 确定路线图和仓库

按以下顺序，从参数、会话或跟踪器中确定；如果都无法确定，就询问，而不是搜索。询问人类要处理哪张路线图，而不是在仓库中四处寻找；这项技能针对的是你刚才正在处理的路线图。

完成条件： 确定一个路线图编号和一个 owner/name。

2. 刷新路线图，然后查看其状态

重新调用 /read-the-map——几乎每次都要这样做，即使本会话已读取过这张路线图。只有在上次读取后跟踪器不可能发生变化时，才跳过重新读取：期间没有认领、关闭或评论。状态过时正是把已失效工作的提示词交还给人类的原因；不确定时就刷新。

它负责清单、判定结果以及判定结果 → 下一步操作的对应关系；这项技能只将其答复转换成可粘贴的内容，不增添任何判断。

如果结果是 Done——所有事项均已关闭、拆分并合并——那么这是唯一一种下一步离开当前路线图的情况。说明这一点，并让人类选择下一项工作。

如果它指出的入口已过时——路线图指定的下一张工单实际上已在跟踪器中关闭——请先停下，不要为它编写提示词。指出工单、其已关闭状态，以及路线图目前仍声称的内容，然后询问人类如何清理，而不要自行猜测：移除该工单并重新计算前沿，将关闭视为路线图自身的进展并继续，或将其标记为误关闭。

完成条件： 已掌握其判定结果、它指出的一到两个入口，以及每张子工单的状态；所有信息都不超过一次读取的时效。

3. 精简选项

最多两个或三个。 一项操作只有在它是阻塞项——最多其他工作都在等它——或快速项——能在一次短会话中完成并从看板上移除——时才值得列出。其他事项都不算下一步；完全省略，不要将其列为第三优先选项。

完成条件： 所有保留下来的操作都符合上述两种理由之一。

4. 交接提示词

每项操作使用一个代码块，格式见下方；如果该操作是构建工单，则遵循那条规则，而不是自行判断。代码块之后不要写任何内容，除非确有无法写进代码块的信息，此时只写一行。

完成条件： 人类可以复制任一代码块，原样粘贴到一个新会话中；其中每张构建工单都包含 /implement 和工作树那一行。

5. 列出完整看板

在“下一步是什么”代码块下方，列出路线图的其余内容：一个标明路线图名称的标题、一张包含所有工单的表格，以及其余当前可接手工作的可直接粘贴提示词。三者的格式都见看板。

完成条件： 标题中包含路线图编号，并将其链接到对应议题，同时附上标题；第 2 步中的每张子工单和待办工单都恰好在表格中出现一次；“下一步是什么”所选项以外的每个已就绪事项都有自己的代码块——或者你已说明前沿中没有其他事项。

提示词格式

/read-the-map 指定的入口决定格式。**如果该入口是构建工单，请跳到下面的规则——这就是这类工单的全部答案。**其他情况有两种格式。

**地图上的决策工单。**一个 wayfinder:<type> 子项。它没有自己的技能，因此通过 /wayfinder 启动：

/wayfinder <map#> take #<n> — <title> in repo <owner/name>

**由人工调用的技能。**技能放在最前面，不会出现 /wayfinder——技能会接收地图或工单本身：

/decisions-to-specs <map#> in repo <owner/name>
/specs-to-tickets <map#> in repo <owner/name>
/prototype #<n> in repo <owner/name>
/implement #<n> in repo <owner/name>

提示词尽量压缩成一行——下一次会话会自行读取地图，因此解释工作内容的提示词只是赘述。

如果操作会写入仓库——/decisions-to-specs、/implement、/prototype——请在提示词末尾加上工作树提醒，这样粘贴时就会一并带上：

/decisions-to-specs 157 in repo mtngtools/mtng-dotnet-mono
Work in a worktree.

仅修改跟踪器的操作（take、/specs-to-tickets）不需要提醒——没有需要隔离的内容。

构建工单始终使用 /implement，并在工作树中执行

构建工单是地图上任何尚未关闭、且不是 wayfinder:<type> 子项的问题——也就是 /specs-to-tickets 从已定稿规范中拆分出的待办项，不论它还带有其他什么标签。/read-the-map 会在清单第 3 项准确收集这一组工单。如果工单来自那里，其提示词就由本节规定，上面两种格式都不适用。

每个构建工单都要返回以下两行，无论它出现在第 4 步的选项中，还是看板的“立即就绪”区块中：

/implement #<n> in repo <owner/name>
Work in a worktree.

构建工单绝不能使用 /wayfinder <map#> take #<n>。take 是处理决策的入口——审查、研究、绘制图表——将它用于构建工单，会让下一次会话重新决定那些已经定案并写入规范的工作。构建待办意味着动词必须是 /implement，没有第二种选择。

**绝不能删掉工作树那一行。**它只有一行，而且即使粘贴到不会加载该技能的会话中，也能保留下来。

**该工作树从哪个基准分支创建，应由 /implement 决定，而不是由本提示词决定。**它会获取更新，检查是否存在重叠的工作树和未合并的 PR，并在创建任何内容前询问人工——包括确认工作是否应基于尚未合并的 PR。在检查尚未运行之前就在提示词中指定基准，会对其结果妄加推测，因此这一行应保持上面那样简短。

标签

只有一个区块时，无需标签。超过一个时，每个区块上方都要加上一行标签，说明它为何列在清单中：

解除另外三个工单的阻塞

/wayfinder 157 take #163 — presentation timing base unit in repo mtngtools/mtng-dotnet-mono

快速处理——解决最后一项决策

/decisions-to-specs 157 in repo mtngtools/mtng-dotnet-mono
Work in a worktree.

标签用于在区块之间进行选择。它们不会包含粘贴后的提示词所需的指令——下一次会话必须知道的内容都应放在区块内。

看板

标题、表格和可立即开始的提示词，均基于第 2 步中 /read-the-map 已收集的工单和待办事项构建——无需再检查一次跟踪器。

标题应以地图编号作为指向其议题的链接，后接标题。 绝不能只写单词“Board”，也不能只写标题，更不能只写 #157——多个会话会同时运行，每个会话最终都会生成这样的看板；看板一旦滚出视野，无法定位或打开，就成了无用文本：

## Board: [#157](https://github.com/mtngtools/mtng-dotnet-mono/issues/157) — presentation timing

编号才是地图的标识， 也是最容易被省略的部分。只写标题看似没问题，但人们要采取行动时仍得搜索：跟踪器上的标题会改写，不同地图中可能出现近似重复的标题，而下面各区块中的每条提示词都需要编号，而不是标题。## Board: presentation timing 和 ## Board 一样有问题——每次都要先写编号。

添加链接。 /read-the-map 已经获取了地图，因此这里添加其 URL 不费事；标题也是人们打开地图本身的入口——下方工单表格中的行也添加链接，原因相同。还得复制编号并粘贴到搜索框，说明你没有写好链接。

两部分都要与跟踪器中的内容完全一致。如果标题很长，也要写完整标题——名称被截断和没有名称的问题一样。

工单表格。 所有子工单，无论开放还是已关闭，再加上构建待办事项——不只是前沿工单，这样人们无需打开跟踪器就能看到整张地图。

| # | Ticket | Type | Status | Blocked by |
|---|---|---|---|---|
| [163](url) | presentation timing base unit | wayfinder:task | open, unclaimed | — |
| [164](url) | grill: base unit for timing | wayfinder:grilling | closed | — |
| [165](url) | grill: frame boundary rule | wayfinder:grilling | open, unclaimed | — |

可立即开始的提示词。 每条符合以下条件的工单都要有一个 提示词格式 区块：开放、未阻塞、无人认领，并且带有 wayfinder:grilling 标签或来自构建待办事项——也就是第 4 步精选工单以外可接手的工作。grilling 工单通过 /wayfinder <map#> take #<n> 接手；构建工单则使用上文规则中的两行 /implement 区块，其中也包括 worktree 行——这里与第 4 步遵循同一规则。

每个区块都要有一行加粗标签，写明工单——不用说明原因，只需足以区分堆叠在一起的区块：

#165 — grill：frame boundary rule

/wayfinder 157 take #165 — grill: frame boundary rule in repo mtngtools/mtng-dotnet-mono

#171 — frame clock adapter

/implement #171 in repo mtngtools/mtng-dotnet-mono
Work in a worktree.

跳过已在第 4 步粘贴过的工单——整条回复中每条工单只出现一个区块，绝不能重复。如果“下一步是什么”精选工单之外没有符合条件的工单，就不要在这里添加区块；用一行文字说明，而不是让这个部分空着。

在流程中的位置

处于会话交接的衔接点。/read-the-map 说明这张地图目前的状态；/whats-next 说明要输入什么来处理它。只有在问题是到底该看哪张地图时，才使用 /check-wayfinder-maps——这与这里的问题不同。/check-wayfinder-maps 会为整个仓库中的每张地图列一行；这个技能的看板则为当前这张地图上的每条工单列一行——前者是多张地图的概览，后者是深入查看单张地图。

与 /are-decisions-from-this-session-saved 配合使用：前者确保本次会话没有遗漏任何内容；本技能则确保下一次会话开始时无需重新决定当前所处的位置。