wayfinder
将单个 Agent 会话无法容纳的大型工作规划成 Issue 跟踪器上的共享调查地图,并逐个解决工单,直到通往目标的路线清晰。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
メニュー
将单个 Agent 会话无法容纳的大型工作规划成 Issue 跟踪器上的共享调查地图,并逐个解决工单,直到通往目标的路线清晰。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
使用并行 sub-agents 为一个 module 生成多套差异显著的 interface 设计。适用于用户希望设计 API、探索 interface 选项、比较 module 形态,或提到“design it twice”的场景。
运行交互式 QA session:用户通过对话报告 bugs 或 issues,agent 随后创建 GitHub issues;同时在后台探索 codebase,获取上下文和 domain language。适用于用户希望报告 bugs、开展 QA、通过对话创建 issues,或提到“QA session”的场景。
通过用户访谈创建一份由微小 commits 组成的详细 refactor plan,并将其提交为 GitHub issue。适用于用户希望规划 refactor、创建 refactoring RFC,或将 refactor 拆分为安全的增量步骤。
从当前对话中提取一份 DDD 风格的 ubiquitous language glossary,标出歧义并提出规范术语,保存到 UBIQUITOUS_LANGUAGE.md。适用于用户希望定义 domain terms、建立 glossary、收紧术语、创建 ubiquitous language,或提到“domain model”或“DDD”的场景。
询问当前情境适合使用哪个 Skill 或工作流。本 Skill 是仓库内其他 Skills 的路由入口。
从用户指定的固定点(commit、branch、tag 或 merge-base)开始,从两个维度审查代码变更:Standards 检查代码是否遵守仓库记录的编码规范,Spec 检查实现是否符合原始 Issue、PRD 或规格。两个审查由并行子 Agent 分别完成,再并列汇报。适用于用户希望审查分支、PR、开发中的改动,或要求“审查自 X 以来的变更”时。
| name | wayfinder |
| description | 将单个 Agent 会话无法容纳的大型工作规划成 Issue 跟踪器上的共享调查地图,并逐个解决工单,直到通往目标的路线清晰。 |
| disable-model-invocation | true |
一个松散想法刚刚出现:规模超过单个 Agent 会话,并且笼罩在迷雾中;从当前位置通往目标(destination)的路线尚不可见。Wayfinding 的任务是找到这条路,不能直接冲向终点。本 Skill 会在仓库的 Issue 跟踪器上绘制一张共享地图,再逐个处理地图中的工单,直到路线清晰。
每项工作的目标都不同,为目标命名是绘图的第一个动作,它会塑造之后的每张工单。目标可能是一份交给后续流程继续迭代的规格、一项必须在规划前确定的决策,也可能是直接在原处完成的变更,例如数据结构迁移。地图不限定领域:工程工作、课程内容或任何符合这种形态的任务都可以使用。
Wayfinder 默认用于规划:每张工单解决一项决策;地图在路线已经清晰、真正执行工作前再无待决定事项时完成。想要直接动手,通常说明你已经到达地图边缘,应当进行交接。某项工作可以在 Notes 中覆盖这条默认规则,把执行本身纳入地图;没有明确覆盖时,产出决策,不产出交付物。
每张地图和工单都是一个 Issue,因此都有自己的名称,也就是标题。在所有供人阅读的内容中,包括过程叙述和地图的 “Decisions so far”,都要用名称引用,绝不能只写裸露的 id、编号或 slug。满墙的 #42, #43, #44 无法快速阅读;名称一眼即可理解。id 和 URL 仍然保留,但应包裹在带链接的名称中,不能代替名称本身。
地图是当前仓库 Issue 跟踪器中的一个独立 Issue,带有 wayfinder:map 标签;它是标准产物。地图工单作为它的子 Issues 存在。
地图是一份索引,不是内容存储区。它列出已经作出的决策,并指向保存细节的工单。一项决策只存在于一个位置,也就是对应工单;地图只写摘要并提供链接,绝不再次完整叙述。
地图、子工单、阻塞关系和前沿查询具体保存在哪里,由跟踪器决定。 Issue 跟踪器应当已经配置;没有时运行 /setup-matt-pocock-skills。阅读跟踪器文档中的 “Wayfinding operations” 一节,了解当前仓库如何表达这些概念。尚未配置跟踪器时,默认使用本地 Markdown 跟踪器。
这是整张地图的低分辨率视图,每个会话只加载一次。尚未关闭的工单不在正文中罗列;它们是打开状态的子 Issues,应通过查询获取。
## Destination
<走到地图终点时应得到什么:本次工作正在寻找的规格、决策或变更。用一两行写明;每个会话在选择工单前都先以此校准方向。>
## Notes
<所属领域;每个会话都应查阅的 Skills;本项工作长期适用的偏好>
## Decisions so far
<!-- 索引:每张已关闭工单一行。摘要只需足以判断相关性,细节通过链接进入工单查看。 -->
- [<已关闭工单标题>](link) — <答案的一行摘要>
## Not yet specified
<!-- 参见“战争迷雾”:尚无法形成工单的范围内迷雾;随着前沿推进逐渐转化。 -->
## Out of scope
<!-- 参见“范围之外”:已经确定超出目标的工作;保持关闭,永不转化。 -->
每张工单都是地图的一个子 Issue;跟踪器中的 Issue id 就是它的身份。工单正文只写需要回答的问题,规模限制在一次 100K token 的 Agent 会话内:
## Question
<本工单要解决的决策或调查事项>
每张工单带有一个 wayfinder:<type> 标签,类型为 research、prototype、grilling、task 之一,参见工单类型。
会话必须在开始任何工作前,先把工单分配给负责推进地图的开发者,以此完成认领,使并行会话能够跳过它。Assignee 就是认领标记:打开且无人分配的工单尚未被认领。
阻塞关系使用跟踪器的原生依赖功能。这一点很重要,因为跟踪器自身 UI 会直观显示前沿,使用户无需打开地图就能看到哪些工单可领取。只有不支持原生阻塞关系的跟踪器,才退回到正文约定。阻塞当前工单的所有工单都已关闭时,它属于未阻塞状态;**前沿(frontier)**由所有打开、未阻塞、未认领的子工单组成,也就是已知区域的边缘。
答案不写在工单正文中,而在解决工单时记录,参见推进地图。处理工单时创建的产物应通过链接附在 Issue 上,不能直接粘贴进去。
每张工单要么属于 HITL,由能够亲自表达意见的人类参与完成;要么属于 AFK,由 Agent 独立推进。HITL 工单只能通过实时交流解决,Agent 永远不能替人类回答其应回答的部分。一个自行回答所有问题的 grilling Agent 已经违反了这条规则。
/prototype Skill 生成 UI 或逻辑代码。将原型作为产物链接。关键问题是“它应该长什么样”或“它应该如何表现”时使用。/grilling 和 /domain-modeling Skills 进行对话,每次只问一个问题。这是默认类型。地图被有意保持为不完整状态:看不清的部分不要提前绘制。现有工单之外是战争迷雾(fog of war)。你能够模糊预见将来需要作出的决策和调查,但由于它们依赖尚未解决的问题,目前无法准确描述。解决一张工单会清除前方迷雾,把现在已经能够描述的内容逐项转化为新工单;这个过程持续进行,直到通往目标的路线清晰,并且没有剩余工单。
地图的 Not yet specified 一节用于记录这种模糊视图:可能存在的问题、以后要重新审视的区域。它表示朝向目标、尚未发现的前沿;其中所有内容都属于当前范围,只是还没有清晰到足以形成工单。根据当前可见程度,可以写得很粗略,也可以较为完整。协作者阅读地图时,它同时提供方向提示。
迷雾还是工单? 判断标准是现在能否准确写出问题,不能以现在是否能够回答问题为依据。
Not yet specified 不包含已经决定的事项(Decisions so far)、已经存在的开放工单,以及范围之外的工作(下一节)。
迷雾只会朝向目标聚集。目标固定了范围,因此越过目标的工作属于范围之外;它不是迷雾,也不能放进 Not yet specified。地图使用单独的 Out of scope 一节,记录你有意识地从本次工作中排除的内容。进入这里的原因是范围,不是清晰度。
范围之外的工作永远不会转化为工单;前沿到达目标即停止。只有重新定义目标时,这些工作才会再次出现,并且应作为一项全新工作,不能恢复原地图继续推进。
把某项内容排除在范围外是一项范围界定动作,不是路线中的一个步骤。已经存在的工单后来被发现位于目标之外时,无论是绘图时错误纳入,还是其他工单的结论揭示了这一点,都应关闭它;关闭状态会明确将它移出前沿。同时在 Out of scope 中留一行:写出摘要和排除原因,并链接到已关闭工单。它不能进入 Decisions so far;后者只记录实际走过的路线,范围边界不属于路线步骤。
有两种模式。无论采用哪一种,一个会话都绝不能解决超过一张工单。
用户以一个松散想法调用。
/grilling 和 /domain-modeling 会话,确定地图最终通向什么:规格、决策或变更。目标决定范围,因此必须最先明确。wayfinder:map 标签:填写 Destination 和 Notes,保持 Decisions-so-far 为空,并把迷雾概括写入 Not yet specified。用户通过地图 URL 或编号调用。指定工单属于可选项;未指定时,由你选择下一项决策,不要求用户选择。
## Notes 中指定的 Skills。拿不准时使用 /grilling 和 /domain-modeling。用户可能并行运行多个未阻塞工单,因此要预期其他会话会同时修改跟踪器。