wayfinderlisted

一个模糊的想法到来了——太大，一个 agent 会话装不下，而且被迷雾包裹：从这里到 **destination** 的路还看不见。Wayfinding 的意义在于找到那条路，而不是冲向 destination。本 skill 把这条路绘制为 repo 的 issue tracker 上的**共享 map**，然后逐个处理它的 **decision tickets**——这些问题的解决是一项 decision，而不是要执行的构建切片——直到路线清晰。 destination 因工作而异，命名它是绘制的第一个动作——它塑造每一个 ticket。它可能是一份要交接并迭代的 spec、一个在规划开始前要锁定的 decision，或一个原地进行的变更，比如数据结构迁移。map 是领域无关的——工���工作、课程内容、任何符合这种形态的东西。 ## 规划，而不是执行 Wayfinder 默认是**规划**性质的：每个 ticket 解决一个 decision，当路线清晰时 map 就完成了——在某人去动手之前，没有剩下需要决定的事了。那种"干脆直接去做"的冲动，通常就是你已到达 map 边缘、该交接的信号。一项工作可以在其 **Notes** 里覆盖这一点——把执行本身带进 map——但若没有，就产出 decisions，而不是 deliverables。 ## 用名称引用 每个 map 和 ticket 都是一个 issue，所以它有一个**名称**——它的标题。在人类阅读的一切内容里——叙述、map 的 Decisions so far——都要用这个名称来引用它，绝不用裸的 id、编号或 slug。满屏 `#42, #43, #44` 难以阅读；名称一眼就能看懂。id 和 URL 不会消失——名称包住了它的链接——但它们_在_名称内部，绝不代替它。 ## Map map 是本 repo 的 issue tracker 上的一个 issue，标注 `wayfinder:map`——这是规范的工件。它的 tickets 是 map 的 child issues。 map 是一个**索引**���而不是存储。它列出已做出的 decisions，并指向持有其细节的 tickets；一个 decision 只存在于一个地方——它的 ticket——所以 map 从不重述它，只做摘要并链接。 **map、它的 child tickets、blocking 关系和 frontier 查询在物理上位于 tracker 的哪个位置，取决于 tracker 类型。** issue tracker 应该已经提供给你了——如果没有，运行 `/setup-rolex-skills`。查阅 tracker 文档的 "Wayfinding operations" 一节，了解 _本_ repo 如何表达它们。如果没有提供任何 tracker，默认使用 local-markdown tracker。 Tracker 特定的接线细节（原生关系 API、label 命名约定、frontier 查询写法）见 `references/<tracker>.md`。**Charting 之前**先用一次小探测确认 tracker 的原生关系能力（sub-issue / blocked-by / 自定义字段），再批量发 ticket——避免走 body 文字降级；如果只有 body 约定可用，停下来跟用户确认走降级方案。 ### Map 正文 整个 map 的低分辨率视图，每