--- name: zen-wayfinder description: Map a large goal into settled decisions, unresolved frontiers and next experiments without dropping requested scope. Use for work spanning many sessions or an unclear direction. --- # Zen wayfinder Keep the destination understandable while choosing the next useful step. This is a decision map, not an implementation checklist disguised as a plan. 1. Read the original goal, accepted changes, latest handoff and specifications. Put every requested capability in a coverage ledger. Keep deferred work explicit; do not quietly reduce a complete build to a small demo. 2. Map settled decisions and their evidence. Group unresolved questions by dependency: which unlocks another, which facts need research and which interactions need a prototype. Label assumptions. 3. Show a compact map/table with destination, current evidence, uncertainty, resolution method and owner. Use a diagram when it clarifies dependencies, keeping the text usable without it. 4. Select the next frontier that reduces consequential uncertainty. Settled work may move to spec/tasks while independent research continues when resources and authority permit. Do not invent dependencies merely to force a model/agent arrangement. 5. Define checkpoints as observable outcomes, not scope cuts. Name how each is demonstrated and what it does not prove. Keep integration/production evidence separate from fixtures and source inspection. 6. Update the map when new evidence changes a decision and preserve superseded reasoning. Before pausing write a handoff with destination, current frontier and exact next action. ## Output and persistence Use [the wayfinder map](references/output.md) in a DOC with `data.kind: "wayfinder"`, linked to IDE/RDT/ART/spec/task records. Use actual [MCP writes](../zen/references/tools.md) or the [standalone writer](../zen/references/standalone.md). If absent, deliver a labelled draft; never claim a saved ref. Shared state and authority are in [workflow.md](../zen/references/workflow.md). Example: a remote dashboard needs durable delivery before refresh can prove a write. Device authentication, idempotency and local persistence are separate uncertainties. A connection badge is one observation, not the completed loop. End with complete scope coverage, settled choices, the remaining frontier and one concrete next action.