wayfinder

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

A loose idea has arrived — too big for one agent session, and wrapped in fog: the route from here to a plan isn't visible yet. This skill charts it: stand up a map, then work its tickets one at a time until the way to the goal is clear. The map is domain-agnostic — engineering work, course content, whatever fits the shape.

你有了一个零散的想法——它太大，无法在单个Agent会话中处理，且笼罩在迷雾之中：从当前状态到形成计划的路径尚不清晰。本Skill可为此规划路径：创建一张工单地图，然后逐一处理其中的工单，直至通往目标的路径清晰可见。这张地图与领域无关——无论是工程工作、课程内容，只要符合这种模式都适用。

The Map

工单地图

The map is a single compact Markdown file, one per wayfinding 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

结构

Entries ("tickets"), each its own section keyed by a short dash-case slug that reads as a mini-title (e.g.

relational-db

auth-strategy

cache-layer

) — terse enough to stay token-efficient, and unique within the map.

markdown

undefined

工单条目以短横线命名的slug作为唯一标识，slug同时作为迷你标题（例如

relational-db

、

auth-strategy

、

cache-layer

）——需简洁到能控制token用量，且在地图内唯一。

markdown

undefined

relational-db: Relational Or Non-Relational Database?

Question

<question-here>

Answer

<answer-here> ```

The slug is the canonical id, used in every

Blocked by

edge and prose reference; the title after the colon is optional. A ticket is unblocked when every ticket in its

Blocked by

list is

resolved

. A session claims its ticket by setting

Status: in-progress

and saving the map before any work, so concurrent sessions skip it.

Each ticket must be sized to one 100K token agent session.

<answer-here> ```

slug是标准ID，用于所有

Blocked by

关联和文本引用；冒号后的标题为可选内容。当工单的

Blocked by

列表中所有工单均标记为

resolved

时，该工单即解除阻塞。会话需先将工单

Status

设为

in-progress

并保存地图，以此“认领”工单，避免并行会话重复处理。

每个工单的规模应控制在单个100K token的Agent会话范围内。

Ticket Types

工单类型

There are four 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: Raise the fidelity of the discussion by making a cheap, rough, concrete artifact to react to — an outline, a rough take, a stub, or UI/logic code via the /prototype skill. Creates the prototype as an asset. Use this when "how should it look" or "how should it behave" is the key question.
Grilling: Conversation with the agent. Uses the /grilling and /domain-modeling skills. Asks one question at a time. The default case.
Task: Literal manual work that must be done before the discussion can move forward — nothing to decide, prototype, or research. Moving data from one place to another, signing up for a third-party service, provisioning access. The agent automates it where it can; otherwise it hands the human a precise checklist to do by hand. Resolved when the work is done; the answer records what was done and any resulting facts (credentials location, new URLs, row counts) later tickets depend on.

工单分为四种类型：

Research（调研）：查阅文档、第三方API或知识库等本地资源，生成Markdown摘要作为资产。当需要当前工作目录以外的知识时使用此类型。
Prototype（原型）：通过创建低成本、粗糙的具体工件（如大纲、草稿、代码 stub，或通过/prototype Skill生成UI/逻辑代码）提升讨论的清晰度，生成的原型作为资产。当核心问题是“外观应如何设计”或“行为应如何实现”时使用此类型。
Grilling（深度问询）：与Agent进行对话，使用/grilling和/domain-modeling Skill，每次提出一个问题。这是默认类型。
Task（任务）：讨论推进前必须完成的实际手动工作——无需决策、原型制作或调研。例如将数据从一处迁移到另一处、注册第三方服务、配置权限等。Agent会尽可能自动化处理；若无法自动化，则向用户提供精确的手动操作清单。任务完成后标记为resolved；答案部分需记录已完成的工作及后续工单依赖的关键信息（如凭证位置、新URL、行数统计等）。

Fog of war

战争迷雾

The map is deliberately incomplete beyond the frontier — don't chart what you can't yet see. The frontier is the unblocked tickets at the edge of the known; resolve them to push it forward. Push back the fog of war one ticket at a time, until the way to the goal is clear and no tickets remain.

地图在当前探索边界之外故意保持不完整——不要规划尚未可见的内容。边界是已知领域边缘的未阻塞工单；解决这些工单即可推进边界。逐一消除战争迷雾，直至通往目标的路径清晰且无剩余工单。

Invocation

调用方式

Two branches. Either way, every session ends with a Handoff — never resolve more than one ticket per session.

分为两种分支场景。无论哪种情况，每个会话都必须以交接流程结束——每个会话最多解决一个工单。

Chart the map

创建工单地图

User invokes with a loose idea.

Run a
```
/grilling
```
and
```
/domain-modeling
```
session to surface the open decisions.
Write a new map — mostly fog, frontier identified, trivially-decidable entries resolved inline.
Handoff. Charting the map is one session's work; do not also resolve tickets.

用户通过零散想法调用本Skill。

运行/grilling和/domain-modeling会话，梳理待决策事项。
创建新地图——大部分内容为迷雾状态，明确当前边界，同时即时解决无需过多思考的条目。
执行交接流程。创建地图是单个会话的工作，请勿同时处理工单。

Work through the map

处理工单地图

User invokes with a path to an existing map. A ticket slug is optional — without one, you pick the next decision, not the user.

Load the whole map as context.
Choose the ticket. If the user named one, use it. Otherwise pick the first
```
open
```
ticket in document order that is unblocked. Claim it: set
```
Status: in-progress
```
and save before any work.
Resolve it, invoking skills as needed — including any the
```
## Notes
```
block names. If in doubt, use
```
/grilling
```
and
```
/domain-modeling
```
.
Record the answer in the ticket's body and set
```
Status: resolved
```
.
Add newly-discovered tickets with correct
```
Blocked by
```
edges. If the decisions made invalidate other parts of the map, update or delete those tickets.
Handoff.

The user may run unblocked tickets in parallel, so expect other agents to be editing the map in their own sessions.

用户通过现有地图的路径调用本Skill。工单slug为可选参数——若未指定，由系统而非用户选择下一个待处理的工单。

加载整个地图作为上下文。
选择工单：若用户指定了slug则使用该工单；否则按文档顺序选择第一个未阻塞的
```
open
```
工单。认领工单：将
```
Status
```
设为
```
in-progress
```
并保存后再开展工作。
解决工单，按需调用相关Skill——包括
```
## Notes
```
块中指定的Skill。若存疑，可使用/grilling和/domain-modeling。
在工单主体中记录答案，并将
```
Status
```
设为
```
resolved
```
。
添加新发现的工单并设置正确的
```
Blocked by
```
关联。若已做出的决策导致地图其他部分失效，则更新或删除相关工单。
执行交接流程。

用户可并行处理未阻塞工单，因此需考虑其他Agent在各自会话中编辑地图的情况。

Handoff

交接流程

End every session by clearing the context and opening one or more fresh sessions. Close with a Next steps block the user can copy-paste. Two cases:

Open tickets remain. List the currently-unblocked tickets, then give two copy-paste options: a bare command for one session (you pick the next ticket), and one pinned command per unblocked ticket for running them in parallel. Paste one line per fresh window — opening one, some, or all of them.

Next steps — 3 tickets unblocked:
auth-strategy
,
cache-layer
,
rate-limits
. Clear the context, then open fresh sessions.
One session — resolves the next unblocked ticket:
Invoke /wayfinder with the map at <path>.
Parallel — paste one line per window, up to all 3:
Invoke /wayfinder with the map at <path>, ticket auth-strategy.
Invoke /wayfinder with the map at <path>, ticket cache-layer.
Invoke /wayfinder with the map at <path>, ticket rate-limits.

No open tickets remain. The fog is pushed back far enough that the way to the goal is clear — the map is done. (The initial grilling may also surface no fog at all, in which case there was never a map to chart.) Recommend implementing directly, or using

/to-prd

to schedule a multi-session implementation.

每个会话结束时需清空上下文并开启一个或多个新会话。以用户可复制粘贴的下一步操作块收尾，分为两种情况：

仍有未处理工单：列出当前未阻塞的工单，然后提供两种可复制粘贴的选项：一个用于单会话的基础命令（由系统选择下一个工单），以及每个未阻塞工单对应的固定命令（用于并行处理）。每个新窗口粘贴一行——可开启其中一个、部分或全部会话。

下一步操作 — 3个未阻塞工单：
auth-strategy
、
cache-layer
、
rate-limits
。清空上下文，然后开启新会话。
单会话 — 处理下一个未阻塞工单：
Invoke /wayfinder with the map at <path>.
并行处理 — 每个窗口粘贴一行，最多可开启全部3个会话：
Invoke /wayfinder with the map at <path>, ticket auth-strategy.
Invoke /wayfinder with the map at <path>, ticket cache-layer.
Invoke /wayfinder with the map at <path>, ticket rate-limits.

无未处理工单：迷雾已被充分驱散，通往目标的路径清晰可见——地图已完成。（初始深度问询也可能未发现任何迷雾，这种情况下无需创建地图。）建议直接实施，或使用/to-prd安排多会话的落地工作。

Notes

备注

An optional block declaring the domain, any skills every session should

consult

, and freeform standing preferences for this effort.

可选块，用于声明领域、每个会话应

consult

的Skill，以及本次探索的通用偏好设置。