Name the wayfinder unit a "decision ticket"

People kept reading a wayfinder ticket as an ordinary implementation
ticket — a slice of a build to execute — when wayfinder uses them as
decision tickets: questions whose resolution is a decision.

Introduce "decision ticket" as a light leading word: the skill
description and its opening line name it (and say what makes it one),
and the ask-matt / engineering README blurbs and the docs page match,
while "ticket" stays the everyday word once the term is established.
Record "Decision ticket" in CONTEXT.md so the "avoid: ticket" domain
rule no longer contradicts wayfinder's deliberate use of the word.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
Matt Pocock
2026-07-13 10:50:29 +01:00
co-authored by Claude Opus 4.8
parent f15b4dca01
commit 7d694b7ae9
6 changed files with 17 additions and 6 deletions
+2 -2
View File
@@ -1,10 +1,10 @@
---
name: wayfinder
description: Plan a huge chunk of work — more than one agent session can hold — as a shared map of investigation tickets on your issue tracker, and resolve them one at a time until the way to the destination is clear.
description: Plan a huge chunk of work — more than one agent session can hold — as a shared map of decision tickets on your issue tracker, and resolve them one at a time until the way to the destination is clear.
disable-model-invocation: true
---
A loose idea has arrived — too big for one agent session, and wrapped in fog: the way from here to the **destination** isn't visible yet. Wayfinding is about finding that way, not charging at the destination. This skill charts the way as a **shared map** on the repo's issue tracker, then works its tickets one at a time until the route is clear.
A loose idea has arrived — too big for one agent session, and wrapped in fog: the way from here to the **destination** isn't visible yet. Wayfinding is about finding that way, not charging at the destination. This skill charts the way as a **shared map** on the repo's issue tracker, then works its **decision tickets** — questions whose resolution is a decision, not slices of a build to execute — one at a time until the route is clear.
The destination varies per effort, and naming it is the first act of charting — it shapes every ticket. It might be a spec to hand off and iterate on, a decision to lock before planning starts, or a change made in place like a data-structure migration. The map is domain-agnostic — engineering work, course content, whatever fits the shape.