wayfinder

A loose idea has arrived — too big to see end-to-end, and wrapped in fog: the way from here to the destination isn't visible yet. Wayfinding is about finding that way, not charging at the destination. This skill charts the way as a shared map — kept in the current task by default, or raised onto the repo's issue tracker when the route must become durable — then works its decision tickets one at a time until the route is clear.

The destination varies per effort, and naming it is the first act of charting — it shapes every ticket. It might be a spec to hand off and iterate on, a decision to lock before planning starts, or a change made in place like a data-structure migration. The map is domain-agnostic — engineering work, course content, whatever fits the shape.

Plan, don't do

Wayfinder is planning by default: each ticket resolves a decision, and the map is done when the way is clear — nothing left to decide before someone goes and does the thing. Execution can be included when the user authorizes it; record that scope in Notes. Tracker text records context and decisions, but does not itself authorize implementation or additional writes.

The map must earn its permanence

A map is a way of seeing before it is a pile of artifacts. Do not confuse charting the territory with publishing every contour as an issue.

Begin in the current task. If the human wants to walk the route now, keep walking: hold the map in the conversation or one working artifact, resolve frontier decisions one at a time, and fold each answer into the destination. A sharp question is not automatically a ticket merely because it has acquired a name.

Move the map onto the issue tracker only when it must become durable coordination: the work will pass between sessions or people, tickets need separate owners, an external event blocks progress, or the human explicitly asks for a tracker map. Prepare the proposed map and child tickets before seeking any missing write authorization. Apply the tracker-write rules to every publication and subsequent mutation.

One at a time describes focus, not question count. Keep one coherent decision in focus. Use grilling's focused rounds: ask one question for a substantial tradeoff, or a small batch of independent questions that help settle the same decision. Defer questions that depend on unanswered ones, preserve settled answers, and follow the user's preferred pace. Continue through as many decisions as the human wants to settle without asking the whole frontier at once.

The map is the canonical route while wayfinding. When the destination is a specification, the finished specification becomes the canonical decision store; the map points to it. Never force an implementer to reconstruct the specification from a trail of issue comments.