diff --git a/.changeset/wayfinding-rename.md b/.changeset/wayfinding-rename.md new file mode 100644 index 0000000..50623bc --- /dev/null +++ b/.changeset/wayfinding-rename.md @@ -0,0 +1,9 @@ +--- +"mattpocock-skills": minor +--- + +Rename the **`decision-mapping`** skill to **`wayfinding`**, invoked as `/wayfinding`. + +"Decision map" was jargony and inaccurate — only one of the skill's four ticket types (Grilling) is actually a decision. The skill is reframed around the **Wayfinder**: you chart a route through a foggy problem, resolving investigation tickets one at a time until the way to the goal is clear. This makes one coherent leading-word frame (fog of war / frontier / the map) instead of mixing an invented term on top of it. + +Also a pruning pass: unified `node`→`ticket`, bound "the frontier" to the unblocked tickets, dropped the duplicated "one question at a time" (owned by `/grilling`), and trimmed intro no-ops. diff --git a/skills/in-progress/README.md b/skills/in-progress/README.md index a0b9b1f..21dd028 100644 --- a/skills/in-progress/README.md +++ b/skills/in-progress/README.md @@ -2,7 +2,7 @@ Skills that are still being developed. They're not ready to ship — expect rough edges, breaking changes, and abandoned experiments. They're excluded from the plugin and the top-level README until they graduate to a stable bucket. -- **[decision-mapping](./decision-mapping/SKILL.md)** — Turn a loose idea into a sequenced map of investigation tickets, then drive them to resolution one at a time. User-invoked. +- **[wayfinding](./wayfinding/SKILL.md)** — As the Wayfinder, chart a route through a foggy problem — turn a loose idea into a map of investigation tickets and resolve them one at a time until the way to the goal is clear. User-invoked. - **[loop-me](./loop-me/SKILL.md)** — Grill yourself into implementable workflow specs over multiple sessions, using the current directory as a stateful workspace. User-invoked. - **[wizard](./wizard/SKILL.md)** — Generate an interactive bash wizard that walks a human through a manual procedure (setup, a one-off migration, a state transition) — opening URLs, capturing values, writing `.env` and GitHub Actions secrets. User-invoked. - **[writing-beats](./writing-beats/SKILL.md)** — Shape an article as a journey of beats, choose-your-own-adventure style. Pick a starting beat, write only that beat, then pivot to the next, until the article reaches a natural end. diff --git a/skills/in-progress/decision-mapping/SKILL.md b/skills/in-progress/wayfinding/SKILL.md similarity index 68% rename from skills/in-progress/decision-mapping/SKILL.md rename to skills/in-progress/wayfinding/SKILL.md index cc89297..6b1e5bc 100644 --- a/skills/in-progress/decision-mapping/SKILL.md +++ b/skills/in-progress/wayfinding/SKILL.md @@ -1,14 +1,14 @@ --- -name: decision-mapping -description: Turn a loose idea into a sequenced map of investigation tickets, then drive them to resolution one at a time. +name: wayfinding +description: As the Wayfinder, chart a route through a foggy problem — turn a loose idea into a map of investigation tickets and resolve them one at a time until the way to the goal is clear. 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. +You are the **Wayfinder**. A loose idea has arrived — too big for one agent session, and wrapped in fog: you can't yet see the route from here to a plan. Chart it: stand up a map, then work its tickets one at a time. The map is domain-agnostic — engineering work, course content, whatever fits the shape. -## The Decision Map +## The 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. +The map is a single compact Markdown file, one per wayfinding 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. @@ -53,19 +53,19 @@ There are four types of tickets: ## 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 — until the path to the finish line is clear and no tickets remain. +The map is _deliberately_ incomplete beyond the frontier — don't chart what you can't yet see. The frontier is the unblocked tickets at the edge of the known; resolve them to push it forward. Push back the fog of war one ticket at a time, until the way to the goal is clear and no tickets remain. ## Invocation Two branches. Either way, **every session ends with a [Handoff](#handoff)** — never resolve more than one ticket per session. -### Create the map +### Chart the map User invokes with a loose idea. -1. Run a `/grilling` and `/domain-modeling` session to surface the open decisions. Ask one question at a time. -2. Write a new decision map — mostly fog, frontier identified, trivially-decidable entries resolved inline. -3. Handoff. Map-building is one session's work; do not also resolve tickets. +1. Run a `/grilling` and `/domain-modeling` session to surface the open decisions. +2. Write a new map — mostly fog, frontier identified, trivially-decidable entries resolved inline. +3. Handoff. Charting the map is one session's work; do not also resolve tickets. ### Work through the map @@ -75,7 +75,7 @@ User invokes with a path to an existing map. A ticket slug is **optional** — w 2. Choose the ticket. If the user named one, use it. Otherwise pick the first `open` ticket in document order that is [unblocked](#structure). [Claim it](#structure): set `Status: in-progress` and save before any work. 3. Resolve it, invoking skills as needed — including any the `## Notes` block names. If in doubt, use `/grilling` and `/domain-modeling`. 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. +5. Add newly-discovered tickets with correct `Blocked by` edges. If the decisions made invalidate other parts of the map, update or delete those tickets. 6. Handoff. The user may run unblocked tickets in parallel, so expect other agents to be editing the map in their own sessions. @@ -91,18 +91,18 @@ End every session by clearing the context and opening one or more fresh sessions > > **One session** — resolves the next unblocked ticket: > ``` -> Invoke /decision-mapping with the map at . +> Invoke /wayfinding with the map at . > ``` > > **Parallel** — paste one line per window, up to all 3: > ``` -> Invoke /decision-mapping with the map at , ticket auth-strategy. -> Invoke /decision-mapping with the map at , ticket cache-layer. -> Invoke /decision-mapping with the map at , ticket rate-limits. +> Invoke /wayfinding with the map at , ticket auth-strategy. +> Invoke /wayfinding with the map at , ticket cache-layer. +> Invoke /wayfinding with the map at , ticket rate-limits. > ``` -**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. +**No open tickets remain.** The fog is pushed back far enough that the way to the goal 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 chart.) Recommend implementing directly, or using `/to-prd` to schedule a multi-session implementation. ## Notes -An optional block declaring the **domain**, any skills every session should `consult`, and freeform standing preferences the planning surfaces. +An optional block declaring the **domain**, any skills every session should `consult`, and freeform standing preferences for this effort.