← ClaudeAtlas

wayfinderlisted

Chart and resolve a large, foggy effort as a GitHub map of decision tickets, then hand clear independent subtrees to your implementation workflow as ordinary build issues. Use when an idea is too large or uncertain for one session, when the user invokes wayfinder or supplies a wayfinder map, or when planning must settle research, UI, domain, and scope decisions before implementation begins.
ConnorGriffin/skills · ★ 20 · AI & Automation · score 66
Install: claude install-skill ConnorGriffin/skills
# Wayfinder Find the way to a destination across multiple sessions. Maintain one `wayfinder:map` issue with child decision tickets, resolve one decision per session, and file build issues only when no open decision can invalidate their subtree. ## Operating rules - **Plan, do not build.** Resolve decisions and create planning artifacts. The pull to implement is normally the signal to hand a clear subtree to whatever process builds your work. - **Refer by name.** In human-facing text, wrap issue links in their titles. Never make people decode a wall of bare issue numbers. - **Keep one source for each answer.** The resolution lives in its ticket comment. The map keeps only a one-line gist and link. An ADR keeps only the lasting ruling. - **Work one decision per session.** Parallel AFK research tickets are the sole exception. - **Ground structural decisions in the project's standards.** When a decision ticket settles module or interface shape, judge it by the project's engineering standards document (charter, architecture guide) when one exists, and load `/codebase-design` for the vocabulary when it is available. Interface shape is a decision the map resolves, never one left implicit for the build session. - **Use GitHub's native structure.** Read [references/github-tracker.md](references/github-tracker.md) before any tracker action. Do not replace child issues, blocking relationships, or label claims with body text. ## Evidence v2 Use [the shared envelo