Decision Map

Decision Map

Scope and Trigger Boundary

Ask one discriminator before creating anything: Do we know what should be built? If no, map unresolved decisions. If yes, route known design into milestones with plan-prompts or implementation-sized work with task-decomposer. A decision map produces decisions and evidence, never implementation deliverables.

Do not turn vague hopes into implementation tasks merely to make progress appear orderly. A sharp but currently unanswered question is a ticket. A question that cannot yet be stated sharply is fog.

Data Model

A map is one parent tracker item with five sections: Destination, Notes, Decisions so far, Not yet specified, and Out of scope. It is an index, not a duplicate store. A decision exists in exactly one ticket; the map holds only resolution pointers and scope boundaries.

A ticket holds one question, exactly one type label, exactly one interaction label, blockers, visible owner, session claim, and closure state. Refer to maps and tickets by linked title, never a bare identifier. Type labels are decision-map:discussion, decision-map:research, decision-map:prototype, and decision-map:unblock. Interaction labels are authoritative: exactly one of decision-map:hitl or decision-map:afk; ticket bodies must not restate the interaction mode.

Prerequisites

Use gh --version and require gh 2.96.0 or newer only when the user explicitly selects GitHub as the tracker. Verify authentication with gh auth status before that path. frontier.py requires Python 3.12 and only the standard library. .docs/agents/issue-tracker.md, when present, is the authoritative backend choice. Otherwise store maps locally in .docs/decision-maps/<effort>/; select GitHub only when the user expressly asks for it. Do not infer GitHub selection from a remote or authentication. Report the selected backend once and mention project-context-setup when the choice should be persisted. Probe GitHub capability before using native relationships. When older GitHub Enterprise or an older CLI rejects blockedBy, take the degraded path: generated child links in the map and Blocked by: #N lines in ticket bodies. The degraded index exists only to emulate absent tracker relationships.

Workflow

Mode A — Chart the Map

1. Name the destination before discussing its route. Use one concrete either-or question at a time and reuse the effort's vocabulary.
2. Sweep breadth-first for policy, architecture, scope, evidence, access, and design questions. If no fog surfaces, stop: the effort needs no decision map.
3. Ensure labels and the selected backend schema exist. Create the map with all five sections.
4. Create every question already sharp enough to ticket. Give every ticket exactly one type label and exactly one interaction label.
5. Wire blocker edges only after ticket creation, because the backend needs ticket identifiers before it can connect them.
6. Put the remaining unformulated uncertainty in Not yet specified; record conscious exclusions with a reason in Out of scope.
7. Compute the frontier and map state with frontier.py; report created topology and stop.

Charting resolves nothing, runs no research, implements nothing, and never collapses uncertainty to look tidy. Report the AFK-ready frontier separately: those tickets may be advanced by that many independent work invocations, each resolving at most one ticket.

Mode B — Work Through the Map

1. Load only the map body, select the requested frontier ticket or the first item returned by frontier.py, and establish visible ownership.
2. Acquire and verify the session claim before substantive work. Follow references/claim-protocol.md; do not infer exclusivity from assignment.
3. Resolve exactly one ticket by its type. A HITL ticket requires the human's judgment; an agent answering it alone has broken the ticket.
4. Record one closure path: RESOLVED, OUT_OF_SCOPE, or INVALIDATED. Write the decision or evidence in the ticket, close it with the matching backend path, and add only a pointer in Decisions so far or Out of scope.
5. Create newly surfaced sharp questions, graduate them out of fog, and remove only the graduated fog patch. Recompute frontier and state.
6. Report and stop without selecting another ticket.

unblock work is restricted to evidence, access, measurement, setup, or a minimal experiment that makes a decision answerable. It never implements a product feature.

Output

Chart Output

Report map title and identifier, tickets with type and interaction labels, blocker edges, current frontier, remaining fog, computed map state, and the stop condition. Include the AFK-ready frontier count and state that each item requires a separate work invocation.

Work Output

Report the resolved ticket, closure path, recorded decision or evidence, new tickets, changed blocker edges, resulting frontier, state, and stop condition. When the state is COMPLETE, recommend plan-prompts for implementation planning. Do not create an inline plan.