check-wayfinder-maps

检查 Wayfinder 地图

仅限人工操作。 仅当人工按名称要求时才启动此流程。如果你是从其他技能来到这里，请停止，并在执行任何步骤前获得明确确认。读取单张地图无需许可——那是 /read-the-map 的工作，可以直接调用。

对单个仓库中的所有 wayfinder 地图进行只读调查。/wayfinder 一次处理一张地图，而且不会退一步询问 “整个项目进展如何？”——本技能会用一张表回答：哪些已决定、哪些已准备好开始构建、哪些仍不明朗、哪些事项互相阻塞——并为每张地图提供一条可复制的提示词，方便据此采取行动。

读取地图是 /read-the-map 的工作；本技能读取多张地图。 这里的每张地图都会经过该技能的检查清单，并得出结论——定义由该技能负责，而非本技能。本技能负责的是复数所能实现的一切：按就绪程度排序、找出瓶颈，以及发现无人注意到的缺口。

本技能绝不写入。 不添加声明或评论，不关闭事项，不编辑地图。只读取跟踪器并汇报。如果调查发现有值得开展的工作，请交给 /wayfinder、/decisions-to-specs 或 /specs-to-tickets——不要在这里处理。

流程

1. 确定仓库——利用已有信息，不要搜索

按以下顺序，根据眼前已有的信息确定仓库：

1. 如果提供了参数，则使用该参数（owner/name）。
2. 当前工作目录的 git 远程地址——在克隆仓库中，gh 会自动推断。
3. 明确无误的现有上下文——本次会话一直在一个仓库中工作，或者用户此前指定过一个仓库，且之后没有任何信息表明并非如此。

如果以上都无法确定仓库，或者其中两项互相矛盾，立即询问用户要操作哪个仓库——只问一个问题，并将其作为你要做的第一件事。

界线在于了解与搜寻之间。现有上下文无需额外成本，而且通常是正确的；请直接使用。禁止的是主动查找：扫描文件系统以寻找候选项、遍历目录寻找 .git、列出组织的仓库以挑选一个看似合适的仓库。搜索若找到错误的仓库，代价远高于提问，还会让用户等来错误的答案。

完成条件： 在未进行搜索的情况下，确定唯一一个仓库。

2. 了解此跟踪器如何表示 wayfinding

遵循 /read-the-map 的跟踪器约定。这是针对每个仓库进行一次的查询，因此在这里执行一次即可，不必对每张地图重复执行。

完成条件： 你知道如何列出地图的子项，以及如何读取它们的阻塞状态。

3. 批量对每张开放地图执行 /read-the-map 的检查清单

列出所有开放地图，然后对每张地图逐项完成检查清单上的所有项目：完整阅读地图正文、查看子项状态及阻塞情况、检查构建待办事项、前沿、结论和下一步行动。

以成本最低的方式满足各项要求。 一次查询所有地图的子项，胜过逐张地图查询；一次查询仓库中所有开放且非 wayfinder 的议题，即可覆盖所有地图的待办事项。批量处理是为了提高效率，不是为了走捷径——如果批量查询没有返回某张地图，而你因此跳过了它的正文，那就不能算已阅读。

只有地图正文这一项仍须逐张处理：完整阅读每一张地图。这是这里的大部分工作，也是必要的成本——仅凭标题或工单数量无法判断就绪程度。

完成条件： 每张开放地图都有一个结论和一行下一步行动，而且没有任何结论是从工单数量推断出来的。

4. 汇报：先列出表格，再为每张地图提供提示词，最后总结整体情况

按此顺序分为三个部分。提及每张地图和工单时，都要使用其名称并添加链接——绝不能只写 #42。

表格

先列地图编号。 它是标识该行的列，也是下方每条提示词都会重复的信息——读者应当能直接将提示词区块与对应行匹配，而不必先根据标题进行确认。

| # | Map | Open decision tickets | Ready for implementation | Next move |
|---|---|---|---|---|
| [157](url) | <map title> | <count + named open tickets, or "0 — all closed"> | **<verdict>** | <one line> |

按就绪程度排列表格——可构建的地图排在前面，延期的占位地图排在最后——让表格顶部列出可立即开展的工作。

每张地图一个提示词，置于表格下方

Next move 列说明要做什么；下面这些是实际要输入的内容。每行一个代码块，按表格中的顺序排列，每个代码块上方都有一行标签，标明地图——这些代码块是纯提示词，堆叠在一起后除此之外没有任何区别：

157 — 演示文稿时间安排

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

/whats-next 负责提示词格式——/wayfinder <map#> <next thing> in repo <owner/name> 这一行、哪些操作需要附带工作树提醒，以及标签的写法。请遵循它；不要在这里另创一种格式。

• 每张地图一个代码块，绝不两个。 在一张地图上权衡各种选择是 /whats-next 的工作。这项技能对一张地图的回答，就是其评估已经指出的那个操作。
• 可单独复制。 每个提示词都放在自己的代码块中，代码块内只有提示词，没有其他内容；不要把说明文字接在末尾。读者点击一次复制，就能原样粘贴到新的会话中。
• 无路可走的地图不提供代码块——已完成、受阻或刻意延期。请在标签行说明情况，而不是交付不应运行的提示词。

总结起来

用三四段简短文字，不要为了列点而列点，指出：

• 有多少张地图已完成决策，哪些地图能以最低成本开展工作
• 所有地图中每一张真正尚未解决的决策工单（通常很短），以及其中是否有两张实际上在问同一个问题
• 瓶颈——其他地图最依赖哪张地图
• 隐蔽缺口——一张地图从另一张地图的规划中拆分出来后，就再也没有跟进。这类地图很容易被忽略：没有未解决的工单，看起来已经完成，但正文只有一行

完成标准： 用户无需打开任何议题，就能根据表格选定下一次会话的工作，并通过复制一个代码块开始。

成本

/read-the-map 允许查看工单正文；只有一张地图时，这样做成本很低，但如果查看十张地图，就会让快速浏览变成耗上一下午的工作。应少用——仅当地图的 Notes 指出某张工单需要修改，而你又看不出原因时才用。清单中的其他要求都只需查看列表级数据，而列表级数据可以批量获取。

在工作流程中的位置

它位于工作流程之外，俯瞰整个流程。/wayfinder → /decisions-to-specs → /specs-to-tickets → /implement 都针对一张地图操作；/check-wayfinder-maps 会查看所有地图，并告诉你该进入哪一张，以及从哪个入口进入。进入一张地图后，就由 /read-the-map 和 /whats-next 接手——使用同一份清单，但只深入一张地图。

当你离开一段时间后重返某项工作、同时有多张地图在推进而不确定该从哪张入手，或者在规划一段工作周期之前，运行它。