edkuksa/skills
1
0
Fork 0
mirror of https://github.com/mattpocock/skills.git synced 2026-07-29 19:12:34 +07:00
Code Issues Packages Projects Releases Wiki Activity

feat: implement model-invoked prototype skill and enhance wizard functionality

Browse Source
This commit is contained in:
Matt Pocock
2026-06-29 13:51:38 +01:00
parent 6eeb81b5fc
commit 850873cd73
8 changed files with 303 additions and 28 deletions
Download Patch File Download Diff File Expand all files Collapse all files
skills/in-progress/decision-mapping/SKILL.md
+37 -24
View File
@@ -4,7 +4,7 @@ description: Turn a loose idea into a sequenced map of investigation tickets, th
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 discussion.
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 Decision Map
@@ -20,7 +20,8 @@ Numbered entries ("tickets"), each its own section keyed by its number:
## #1: Relational Or Non-Relational Database?
Blocked by: #<ticket-number>, #<ticket-number>
Type: Research | Prototype | Discuss
Status: open | in-progress | resolved
Type: Research | Prototype | Grilling
### Question
@@ -31,6 +32,8 @@ Type: Research | Prototype | Discuss
<answer-here>
```
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
@@ -39,46 +42,56 @@ There are three 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**: Writing UI or logic code to test a hypothesis, or to explore a design space. Uses the /prototype skill. Creates a prototype as an asset. Use this when "how should it look" or "how should it behave" is the key question.
- **Discuss**: Conversation with the agent. Uses the /grilling and /domain-modelling skills. The default case.
- **Grilling**: Conversation with the agent. Uses the /grilling and /domain-modelling skills. The default case.
## Fog of war
The map is _deliberately_ incomplete beyond the frontier. Your job is to investigate the frontier, and to resolve tickets in order to push the frontier forward. Push back the fog of war, one node at a time.
At some point, the fog of war should have been pushed back far enough that the path to the finish line is clear. At that point, no more tickets will be required and the decision map can be considered 'done'.
The map is _deliberately_ incomplete beyond the frontier. Your job is to investigate the frontier, and to resolve tickets in order to push the frontier forward. Push back the fog of war, one node at a time — until the path to the finish line is clear and no tickets remain.
## Invocation
There are two ways this skill can be invoked: **bootstrap** and **resume**.
Two branches. Either way, **every session ends with a [Handoff](#handoff)** — never resolve more than one ticket per session.
### Bootstrap
### Create the map
User invokes with a loose idea.
1. Run a /grilling and /domain-modelling session to surface the open decisions.
1. Run a `/grilling` and `/domain-modelling` session to surface the open decisions.
2. Write a new decision map — mostly fog, frontier identified, trivially-decidable entries resolved inline.
3. Stop. Map-building is one session's work; do not also resolve tickets.
3. Handoff. Map-building is one session's work; do not also resolve tickets.
### Resume
### Work through the map
User invokes with a path to an existing map and a ticket number.
User invokes with a path to an existing map. A ticket number is **optional** — without one, you pick the next decision, not the user.
1. Load the **whole map** as context.
2. Run a session to resolve the ticket, invoking skills as needed. If in doubt, use `/grilling` and `/domain-modelling`.
3. Record what the session resolved in the ticket's body.
4. Add newly-discovered tickets (with correct `blocked_by` edges).
5. Stop.
2. Choose the ticket. If the user named one, use it. Otherwise pick the lowest-numbered `open` ticket that is [unblocked](#structure). [Claim it](#structure): set `Status: in-progress` and save before any work.
3. Resolve it, invoking skills as needed. If in doubt, use `/grilling` and `/domain-modelling`.
4. Record the answer in the ticket's body and set `Status: resolved`.
5. Add newly-discovered tickets with correct `Blocked by` edges. If the decisions made invalidate other parts of the map, update or delete those nodes.
6. Handoff.
If the decisions made invalidate other parts of the map, update or delete those nodes.
The user may run unblocked tickets in parallel, so expect other agents to be editing the map in their own sessions.
## Parallelism
## Handoff
The user may choose to run tickets in parallel, so expect other agents to make changes to the map.
End every session by clearing the context and opening one or more fresh sessions. Close with a **Next steps** block the user can copy-paste. Two cases:
## Skipping The Decision Map
**Open tickets remain.** List the currently-unblocked tickets, then give two copy-paste options: a bare command for one session (you pick the next ticket), and one pinned command per unblocked ticket for running them in parallel. Paste one line per fresh window — opening one, some, or all of them.
Many times, the initial grilling will result in no fog of war. No unresolved tickets. Nothing to do, except implement.
> **Next steps** — 3 tickets unblocked: #4, #5, #6.
> Clear the context, then open fresh sessions.
>
> **One session** — resolves the next unblocked ticket:
> ```
> Invoke /decision-mapping with the map at <path>.
> ```
>
> **Parallel** — paste one line per window, up to all 3:
> ```
> Invoke /decision-mapping with the map at <path>, ticket #4.
> Invoke /decision-mapping with the map at <path>, ticket #5.
> Invoke /decision-mapping with the map at <path>, ticket #6.
> ```
In those situations, you should offer the user the chance to skip the decision map - since the decision map is only needed if multi-session decisions need to be made.
If they skip it, you should recommend either implementing directly or using `/to-prd` to schedule a multi-session implementation.
**No open tickets remain.** The fog is pushed back far enough that the path to the finish line is clear — the map is done. (The initial grilling may also surface no fog at all, in which case there was never a map to build.) Recommend implementing directly, or using `/to-prd` to schedule a multi-session implementation.