When a loose idea needs more than one agent session to become a plan, invoke this skill. It creates a stateful decision map in a markdown file and walks the user through resolving open questions in ticket order; these questions may require prototyping, research, or discussion.
The Decision Map
A Decision map is a compact Markdown file, one per planning effort, and is git-tracked with the project. It is the canonical artifact:Every session loads the entire map as context, so it must stay compact.
Assets created during Tickets should be linked from the map, not copied into it.
Structure
Numbered entries ("tickets"), each an independent section, keyed by number:
## #1: Relational Or Non-Relational Database?
Blocked by: #<ticket-number>, #<ticket-number>
Type: Research | Prototype | Grilling
### Question
Answer
Each ticket must be sized to fit within a 100K token agent session.
Ticket Types
Three types of tickets:
- Research: Read documentation, third-party APIs, or local resources such as knowledge bases. Create a markdown summary as an asset. Use when knowledge outside the current working directory is needed.
- Prototype: Write UI or logic code to test a hypothesis, or explore the design space. Use the
/prototypeskill. Create a prototype as an asset. Use when the core question is "how should it look" or "how should it behave". - Grilling: Converse with the agent. Use
/grillingand/domain-modelingskills. Ask one question at a time. Default type.
Fog of war
The Map is intentionally incomplete beyond the frontier. Your job is to investigate the frontier and resolve tickets in order to push the frontier forward. Advance one node at a time, pushing back the fog of war.
At some point, the fog of war will be pushed back far enough that the path to the finish line becomes clear. At that point no more tickets are needed, and the decision map can be considered done.
Invocation
Two invocation modes:bootstrap and resume。
Bootstrap
The user invokes with a loose idea.
- Run a
/grilling+/domain-modelingsession to surface open decisions. Ask one question at a time. - Write a new decision map: mostly fog, the frontier identified, obviously decidable entries resolved inline.
- Stop. Building the map is one session's work; do not resolve tickets at the same time.
Resume
The user provides an existing map path and ticket number.
- Load the whole map as context.
- Run a session to resolve that ticket, invoking skills as needed. When unsure, use
/grillingand/domain-modeling。 - Record in the ticket body what this session resolved.
- Add newly discovered tickets (with the correct
blocked_byedges）。 - Stop.
If new decisions invalidate other parts of the map, update or delete those nodes.
Parallelism
The user may choose to run tickets in parallel, so expect other agents to modify the map.
Skipping The Decision Map
Often, the initial grilling will not produce a fog of war: there are no unresolved tickets, so there is nothing else to do but implement.
In this case, let the user choose to skip the decision map, since it is only needed for multi-session decisions.
If the user skips it, suggest implementing directly, or using /to-prd to schedule multi-session implementation.