| name | decision-mapping |
| author | mattpocock |
| upstream | mattpocock/skills |
| upstreamPath | skills/in-progress/decision-mapping |
| upstreamSha | b38badf7091afc614dedffc03ea8c8ad2b643cb4 |
| lastUpdated | 2026-07-02T01:06:55.000Z |
| tags | ["Planning","Workflow","Matt Pocock"] |
| description | Turn a loose idea into a sequenced map of investigation tickets, then drive them to resolution one at a time. |
| disable-model-invocation | true |
This skill is invoked when a loose idea requires more than one agent session to turn into a plan. It creates a stateful decision map in a markdown file, and drives the user through a sequence of tickets to resolve the open questions - which may require either prototyping, research or grilling. The map is domain-agnostic: it plans engineering work, course content, or anything else that fits the same shape.
The Decision Map
The decision map is a single compact Markdown file, one per planning effort, git-tracked alongside the project. It is the canonical artifact — the whole map is loaded as context into every session, so it must stay compact.
Assets created during tickets should be linked to from the map, not duplicated within it.
Structure
Entries ("tickets"), each its own section keyed by a short dash-case slug that
reads as a mini-title (e.g. relational-db, auth-strategy, cache-layer) —
terse enough to stay token-efficient, and unique within the map.
## relational-db: Relational Or Non-Relational Database?
Blocked by: <slug>, <slug>
Status: open | in-progress | resolved
Type: Research | Prototype | Grilling | Task
### Question
<question-here>
### Answer
<answer-here>
The slug is the canonical id, used in every Blocked by edge and prose
reference; the title after the colon is optional. A ticket
is unblocked when every ticket in its Blocked by list is resolved. A
session claims its ticket by setting Status: in-progress and saving the map
before any work, so concurrent sessions skip it.
Each ticket must be sized to one 100K token agent session.
Ticket Types
There are four types of tickets:
- Research: Reading documentation, third-party API's, or local resources like knowledge bases. Creates a markdown summary as an asset. Use this when knowledge outside the current working directory is required.
- Prototype: Raise the fidelity of the discussion by making a cheap, rough, concrete artifact to react to — an outline, a rough take, a stub, or UI/logic code via the /prototype skill. Creates the prototype as an asset. Use this when "how should it look" or "how should it behave" is the key question.
