decision-maplisted

# Decision map — multi-session planning on the issue tracker A loose idea has arrived — too big for one session, and wrapped in fog: the way from here to the **destination** is not visible yet. This skill charts the way as a **shared map** on the repo's issue tracker, then works its **decision tickets** — questions whose resolution is a decision, not slices of a build to execute — one at a time until the route is clear. The destination varies per effort, and naming it is the first act of charting. It might be a spec to hand off, a decision to lock before implementation planning starts, or a change made in place. The map is domain-agnostic. ## Plan, don't do Each ticket resolves a decision; the map is done when nothing is left to decide before someone goes and does the thing. The pull to just do the work is usually the signal you have reached the edge of the map and it is time to hand off. An effort can override this in its Notes — carrying execution into the map — but absent that, produce decisions, not deliverables. ## Refer by name Every map and ticket is an issue, so it has a name — its title. In everything the human reads, refer to it by that name, never by a bare id or number; the id and URL ride inside the name as a link, never stand in for it. ## Tracker resolution and the write gate Resolve the tracker in this order; never assume one: 1. **Whatever the project's own docs designate**: when the repository's documentation records a tracker workflow (an issue-