From 299eb0c0171c06ee1d9a16a9235912ba6893fd57 Mon Sep 17 00:00:00 2001 From: Matt Pocock Date: Sun, 5 Jul 2026 15:08:48 +0100 Subject: [PATCH 1/4] Give wayfinder a distinct Deferred section for beyond-destination work MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Fog is the undiscovered frontier *toward* the destination — in scope, just not yet sharp — so it graduates into tickets as the frontier advances. Work ruled out of *this* effort's scope was being parked in Fog too, where it read as takeable frontier (an unblocked, unclaimed ticket is indistinguishable from a live one). Add a dedicated `## Deferred` section for beyond-the-destination work: it never graduates (the frontier stops at the destination) and returns only as a fresh effort if the destination is redrawn. The "Fog or ticket?" test becomes "Fog, ticket, or deferred?", gated on scope as well as sharpness, and both charting and working-the-map now defer a mis-scoped ticket (close it, one line in Deferred) rather than leaving it on the frontier or logging it in Decisions so far. Builds on #455 (destination as the leading word / destination fixes scope). Co-Authored-By: Claude Opus 4.8 (1M context) --- .changeset/wayfinder-deferred-section.md | 7 +++++++ skills/in-progress/wayfinder/SKILL.md | 21 +++++++++++++++------ 2 files changed, 22 insertions(+), 6 deletions(-) create mode 100644 .changeset/wayfinder-deferred-section.md diff --git a/.changeset/wayfinder-deferred-section.md b/.changeset/wayfinder-deferred-section.md new file mode 100644 index 0000000..070b140 --- /dev/null +++ b/.changeset/wayfinder-deferred-section.md @@ -0,0 +1,7 @@ +--- +"mattpocock-skills": minor +--- + +Give **`wayfinder`** a distinct **`## Deferred`** section for work that lies _beyond_ the destination, separating it from Fog. + +Fog is the undiscovered frontier _toward_ the destination — in scope, just not yet sharp — so it graduates into tickets as the frontier advances. Work ruled out of _this_ effort's scope was being parked in Fog too, where it read as takeable frontier. It now has its own home: the `## Deferred` section, which never graduates (the frontier stops at the destination) and returns only as a fresh effort if the destination is redrawn. The "Fog or ticket?" test becomes "Fog, ticket, or deferred?" — gated on scope as well as sharpness — and both charting and working-the-map now defer a ticket found beyond the destination (close it, record one line in Deferred) rather than leaving it on the frontier or logging it in Decisions so far. diff --git a/skills/in-progress/wayfinder/SKILL.md b/skills/in-progress/wayfinder/SKILL.md index 1b72ca0..7342783 100644 --- a/skills/in-progress/wayfinder/SKILL.md +++ b/skills/in-progress/wayfinder/SKILL.md @@ -41,6 +41,10 @@ The whole map at low resolution, loaded once per session. Open tickets are **not ## Fog + +## Deferred + + ``` ### Tickets @@ -72,14 +76,19 @@ The answer isn't part of the body — it's recorded on resolution (see [Work thr The map is _deliberately_ incomplete: don't chart what you can't yet see. Beyond the tickets lies fog — the dim view of decisions and investigations you can tell are coming but can't yet pin down, because they hang on questions still open. Resolving a ticket clears the fog ahead of it, graduating whatever's now specifiable into fresh tickets — one at a time, until the way to the destination is clear and no tickets remain. -The map's **Fog** section is where that dim view is written down: the suspected question, the area to revisit later, the risk you're deferring. Write as loosely or as fully as the view allows; it doubles as a signpost for collaborators reading where the effort is headed. +The map's **Fog** section is where that dim view is written down: the suspected question, the area to revisit later. It's the undiscovered frontier _toward_ the destination — everything here is in scope, just not yet sharp. Write as loosely or as fully as the view allows; it doubles as a signpost for collaborators reading where the effort is headed. -**Fog or ticket?** The test is whether you can state the question precisely now — _not_ whether you can answer it now. +**Beyond the destination is not fog.** The destination fixes the scope, so anything past it is out of scope no matter how clearly you can see it — and fog, by its nature, points _toward_ the destination, so out-of-scope work doesn't belong there. It goes in the map's **Deferred** section: work you've consciously ruled out of _this_ effort. Fog graduates into tickets as the frontier advances; Deferred never does, because the frontier stops at the destination. -- **Ticket when** the question is already sharp — even if it's blocked and you can't act on it yet. -- **Fog when** you can't yet phrase it that sharply. Don't pre-slice fog into ticket-sized pieces: it's coarser than a ticket, and one patch may graduate into several tickets, or none, once the frontier reaches it. +**Fog, ticket, or deferred?** Two questions: is it _within_ the destination's scope, and can you _state_ it sharply now? -Fog excludes only what's already decided (that's Decisions so far) and what's already a ticket. +- **Ticket when** it's in scope and the question is already sharp — even if it's blocked and you can't act on it yet. +- **Fog when** it's in scope but you can't yet phrase it that sharply. Don't pre-slice fog into ticket-sized pieces: it's coarser than a ticket, and one patch may graduate into several tickets, or none, once the frontier reaches it. +- **Deferred when** it lies _beyond_ the destination — however sharply you can phrase it. Scope, not sharpness, lands it here. + +Deferring is a scoping act, not a step on the route. When a ticket that already exists turns out to sit past the destination — mis-scoped in while charting, or exposed by a resolution — **close it** (a closed ticket is unambiguously off the frontier) and leave one line in the **Deferred** section: the gist plus why it's out of scope, linking the closed ticket. It stays out of **Decisions so far**, which records the route actually walked — a scope boundary isn't a step on it. If the destination is ever redrawn to include it, it returns as a fresh effort, not a resumption. + +Fog excludes what's already decided (Decisions so far), what's already a ticket, and what lies beyond the destination (Deferred). ## Invocation @@ -103,6 +112,6 @@ User invokes with a map (URL or number). A ticket is **optional** — without on 2. Choose the ticket. If the user named one, use it. Otherwise take the first frontier ticket in order. **Claim it**: assign it to yourself before any work. 3. Resolve it — **zoom as needed**: fetch the full body of any related or closed ticket on demand; invoke the skills the `## Notes` block names. If in doubt, use `/grilling` and `/domain-modeling`. 4. Record the resolution: post the answer as a **resolution comment**, **close** the issue, and **append a context pointer** to the map's Decisions-so-far. -5. Add newly-surfaced tickets (create-then-wire); graduate any fog the answer has made specifiable, clearing each graduated patch from the Fog so it lives only as its new ticket. If the decision invalidates other parts of the map, update or delete those tickets. +5. Add newly-surfaced tickets (create-then-wire); graduate any fog the answer has made specifiable, clearing each graduated patch from the Fog so it lives only as its new ticket. If the answer reveals a ticket — this one or another — sits beyond the destination, **defer** it instead of resolving it on the route: close it and record one line in Deferred. If the decision invalidates other parts of the map, update or delete those tickets. The user may run unblocked tickets in parallel, so expect other sessions to be editing the tracker concurrently. From 3ea01314c16e374230be29cd8b067924f000ea6e Mon Sep 17 00:00:00 2001 From: Matt Pocock Date: Sun, 5 Jul 2026 17:35:50 +0100 Subject: [PATCH 2/4] Rename the two buckets to plain map headings: Not yet specified / Out of scope MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Following review: the map-body headings a cold reader sees should be self-evident without having read the skill, so drop the metaphor from the headings — `## Not yet specified` (in-scope, unripe) and `## Out of scope` (beyond the destination). Keep **fog of war** as the leading word: it still titles the explanatory section and drives the "clears the fog" / "graduate the fog" behavior in the prose. Co-Authored-By: Claude Opus 4.8 (1M context) --- .changeset/wayfinder-deferred-section.md | 6 +++-- skills/in-progress/wayfinder/SKILL.md | 30 ++++++++++++------------ 2 files changed, 19 insertions(+), 17 deletions(-) diff --git a/.changeset/wayfinder-deferred-section.md b/.changeset/wayfinder-deferred-section.md index 070b140..327ffff 100644 --- a/.changeset/wayfinder-deferred-section.md +++ b/.changeset/wayfinder-deferred-section.md @@ -2,6 +2,8 @@ "mattpocock-skills": minor --- -Give **`wayfinder`** a distinct **`## Deferred`** section for work that lies _beyond_ the destination, separating it from Fog. +Split **`wayfinder`**'s map-body catch-all into two plainly-named sections — **`## Not yet specified`** and **`## Out of scope`** — so a cold reader can tell in-scope-but-unripe work from work ruled beyond the destination. -Fog is the undiscovered frontier _toward_ the destination — in scope, just not yet sharp — so it graduates into tickets as the frontier advances. Work ruled out of _this_ effort's scope was being parked in Fog too, where it read as takeable frontier. It now has its own home: the `## Deferred` section, which never graduates (the frontier stops at the destination) and returns only as a fresh effort if the destination is redrawn. The "Fog or ticket?" test becomes "Fog, ticket, or deferred?" — gated on scope as well as sharpness — and both charting and working-the-map now defer a ticket found beyond the destination (close it, record one line in Deferred) rather than leaving it on the frontier or logging it in Decisions so far. +Previously both lived under one `## Fog` heading, where out-of-scope work read as takeable frontier (an unblocked, unclaimed item is indistinguishable from a live ticket). Now: *Not yet specified* is the in-scope frontier that graduates into tickets as decisions resolve; *Out of scope* is beyond the destination, closed and never graduating, returning only as a fresh effort if the destination is redrawn. The "Fog or ticket?" test becomes "Ticket, not-yet-specified, or out of scope?", gated on scope as well as sharpness, and both charting and working-the-map now rule a beyond-destination ticket out of scope (close it, one line in *Out of scope*) rather than leaving it on the frontier or logging it in *Decisions so far*. + +The **fog of war** leading word is retained — it still names the concept and drives the graduate-the-fog behavior in the skill's prose; only the human-facing map headings go to plain language. diff --git a/skills/in-progress/wayfinder/SKILL.md b/skills/in-progress/wayfinder/SKILL.md index 7342783..2aff9f7 100644 --- a/skills/in-progress/wayfinder/SKILL.md +++ b/skills/in-progress/wayfinder/SKILL.md @@ -38,13 +38,13 @@ The whole map at low resolution, loaded once per session. Open tickets are **not - [](link) — -## Fog +## Not yet specified - + -## Deferred +## Out of scope - + ``` ### Tickets @@ -74,21 +74,21 @@ The answer isn't part of the body — it's recorded on resolution (see [Work thr ## Fog of war -The map is _deliberately_ incomplete: don't chart what you can't yet see. Beyond the tickets lies fog — the dim view of decisions and investigations you can tell are coming but can't yet pin down, because they hang on questions still open. Resolving a ticket clears the fog ahead of it, graduating whatever's now specifiable into fresh tickets — one at a time, until the way to the destination is clear and no tickets remain. +The map is _deliberately_ incomplete: don't chart what you can't yet see. Beyond the live tickets lies the **fog of war** — the dim view of decisions and investigations you can tell are coming but can't yet pin down, because they hang on questions still open. Resolving a ticket clears the fog ahead of it, graduating whatever's now specifiable into fresh tickets — one at a time, until the way to the destination is clear and no tickets remain. -The map's **Fog** section is where that dim view is written down: the suspected question, the area to revisit later. It's the undiscovered frontier _toward_ the destination — everything here is in scope, just not yet sharp. Write as loosely or as fully as the view allows; it doubles as a signpost for collaborators reading where the effort is headed. +The map's **Not yet specified** section is where that dim view is written down: the suspected question, the area to revisit later. It's the undiscovered frontier _toward_ the destination — everything here is in scope, just not sharp enough to ticket. Write as loosely or as fully as the view allows; it doubles as a signpost for collaborators reading where the effort is headed. -**Beyond the destination is not fog.** The destination fixes the scope, so anything past it is out of scope no matter how clearly you can see it — and fog, by its nature, points _toward_ the destination, so out-of-scope work doesn't belong there. It goes in the map's **Deferred** section: work you've consciously ruled out of _this_ effort. Fog graduates into tickets as the frontier advances; Deferred never does, because the frontier stops at the destination. +**Beyond the destination is a different thing.** The destination fixes the scope, so anything past it is out of scope no matter how clearly you can see it — the fog only ever gathers _toward_ the destination, never past it. Out-of-scope work goes in the map's **Out of scope** section: work you've consciously ruled out of _this_ effort. Not-yet-specified work graduates into tickets as the frontier advances; out-of-scope work never does, because the frontier stops at the destination. -**Fog, ticket, or deferred?** Two questions: is it _within_ the destination's scope, and can you _state_ it sharply now? +**Ticket, not-yet-specified, or out of scope?** Two questions: is it _within_ the destination's scope, and can you _state_ it sharply now? - **Ticket when** it's in scope and the question is already sharp — even if it's blocked and you can't act on it yet. -- **Fog when** it's in scope but you can't yet phrase it that sharply. Don't pre-slice fog into ticket-sized pieces: it's coarser than a ticket, and one patch may graduate into several tickets, or none, once the frontier reaches it. -- **Deferred when** it lies _beyond_ the destination — however sharply you can phrase it. Scope, not sharpness, lands it here. +- **Not yet specified when** it's in scope but you can't yet phrase it that sharply. Don't pre-slice it into ticket-sized pieces: it's coarser than a ticket, and one patch may graduate into several tickets, or none, once the frontier reaches it. +- **Out of scope when** it lies _beyond_ the destination — however sharply you can phrase it. Scope, not sharpness, lands it here. -Deferring is a scoping act, not a step on the route. When a ticket that already exists turns out to sit past the destination — mis-scoped in while charting, or exposed by a resolution — **close it** (a closed ticket is unambiguously off the frontier) and leave one line in the **Deferred** section: the gist plus why it's out of scope, linking the closed ticket. It stays out of **Decisions so far**, which records the route actually walked — a scope boundary isn't a step on it. If the destination is ever redrawn to include it, it returns as a fresh effort, not a resumption. +Ruling something out of scope is a scoping act, not a step on the route. When a ticket that already exists turns out to sit past the destination — mis-scoped in while charting, or exposed by a resolution — **close it** (a closed ticket is unambiguously off the frontier) and leave one line in the **Out of scope** section: the gist plus why it's out of scope, linking the closed ticket. It stays out of **Decisions so far**, which records the route actually walked — a scope boundary isn't a step on it. If the destination is ever redrawn to include it, it comes back as a fresh effort, not a resumption. -Fog excludes what's already decided (Decisions so far), what's already a ticket, and what lies beyond the destination (Deferred). +**Not yet specified** excludes what's already decided (Decisions so far), what's already a live ticket, and what's out of scope (its own section). ## Invocation @@ -100,8 +100,8 @@ User invokes with a loose idea. 1. **Name the destination.** Run a `/grilling` and `/domain-modeling` session to pin down what this map is finding its way to — the spec, decision, or change. The destination fixes the scope, so it's settled first. 2. **Map the frontier.** Grill again, **breadth-first** this time: fan out across the whole space rather than deep on any one thread, surfacing the open decisions and the first steps takeable now. -3. **Create the map** (label `wayfinder:map`): Destination and Notes filled in, Decisions-so-far empty, Fog sketched. -4. **Create the tickets you can specify now** as child issues of the map — then wire blocking edges in a **second pass** (issues need ids before they can reference each other). Wiring sorts them into the frontier and the blocked; everything you can't yet specify stays in the Fog. +3. **Create the map** (label `wayfinder:map`): Destination and Notes filled in, Decisions-so-far empty, the fog sketched into **Not yet specified**. +4. **Create the tickets you can specify now** as child issues of the map — then wire blocking edges in a **second pass** (issues need ids before they can reference each other). Wiring sorts them into the frontier and the blocked; everything you can't yet specify stays in the fog — the **Not yet specified** section. 5. Stop — charting the map is one session's work; do not also resolve tickets. ### Work through the map @@ -112,6 +112,6 @@ User invokes with a map (URL or number). A ticket is **optional** — without on 2. Choose the ticket. If the user named one, use it. Otherwise take the first frontier ticket in order. **Claim it**: assign it to yourself before any work. 3. Resolve it — **zoom as needed**: fetch the full body of any related or closed ticket on demand; invoke the skills the `## Notes` block names. If in doubt, use `/grilling` and `/domain-modeling`. 4. Record the resolution: post the answer as a **resolution comment**, **close** the issue, and **append a context pointer** to the map's Decisions-so-far. -5. Add newly-surfaced tickets (create-then-wire); graduate any fog the answer has made specifiable, clearing each graduated patch from the Fog so it lives only as its new ticket. If the answer reveals a ticket — this one or another — sits beyond the destination, **defer** it instead of resolving it on the route: close it and record one line in Deferred. If the decision invalidates other parts of the map, update or delete those tickets. +5. Add newly-surfaced tickets (create-then-wire); graduate any fog the answer has made specifiable, clearing each graduated patch from **Not yet specified** so it lives only as its new ticket. If the answer reveals a ticket — this one or another — sits beyond the destination, **rule it out of scope** instead of resolving it on the route: close it and record one line in **Out of scope**. If the decision invalidates other parts of the map, update or delete those tickets. The user may run unblocked tickets in parallel, so expect other sessions to be editing the tracker concurrently. From 7d34a8dc38bdb34dadb69109aa2173aad69d8514 Mon Sep 17 00:00:00 2001 From: Matt Pocock Date: Sun, 5 Jul 2026 17:44:13 +0100 Subject: [PATCH 3/4] Split fog and out-of-scope into separate explanatory sections MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit QA follow-up: the Fog of war section was teaching both concepts, which muddies the leading word — fog should point only *toward* the destination. Now Fog of war teaches only the not-yet-specified bucket (with the two-way fog-or-ticket sharpness test restored), and a new Out of scope section owns the scope axis: beyond the destination, closed not graduating, kept out of Decisions so far. Co-Authored-By: Claude Opus 4.8 (1M context) --- .changeset/wayfinder-deferred-section.md | 8 +++++--- skills/in-progress/wayfinder/SKILL.md | 19 +++++++++++-------- 2 files changed, 16 insertions(+), 11 deletions(-) diff --git a/.changeset/wayfinder-deferred-section.md b/.changeset/wayfinder-deferred-section.md index 327ffff..457c64c 100644 --- a/.changeset/wayfinder-deferred-section.md +++ b/.changeset/wayfinder-deferred-section.md @@ -2,8 +2,10 @@ "mattpocock-skills": minor --- -Split **`wayfinder`**'s map-body catch-all into two plainly-named sections — **`## Not yet specified`** and **`## Out of scope`** — so a cold reader can tell in-scope-but-unripe work from work ruled beyond the destination. +Give **`wayfinder`** a first-class notion of **out of scope**, separate from fog. -Previously both lived under one `## Fog` heading, where out-of-scope work read as takeable frontier (an unblocked, unclaimed item is indistinguishable from a live ticket). Now: *Not yet specified* is the in-scope frontier that graduates into tickets as decisions resolve; *Out of scope* is beyond the destination, closed and never graduating, returning only as a fresh effort if the destination is redrawn. The "Fog or ticket?" test becomes "Ticket, not-yet-specified, or out of scope?", gated on scope as well as sharpness, and both charting and working-the-map now rule a beyond-destination ticket out of scope (close it, one line in *Out of scope*) rather than leaving it on the frontier or logging it in *Decisions so far*. +Fog and out-of-scope were conflated under one `## Fog` map section, gated by different things: fog by *knowledge* (can't specify it yet — in scope, unripe, graduates as the frontier advances), out-of-scope by *scope* (beyond the destination — never graduates). Cramming both under "Fog" made out-of-scope work read as takeable frontier (an unblocked, unclaimed item is indistinguishable from a live ticket). -The **fog of war** leading word is retained — it still names the concept and drives the graduate-the-fog behavior in the skill's prose; only the human-facing map headings go to plain language. +Now the map body has two plainly-named sections — **`## Not yet specified`** and **`## Out of scope`** — and the skill's prose splits to match: the **Fog of war** section teaches only the not-yet-specified bucket and keeps the two-way *fog-or-ticket* sharpness test, while a new **Out of scope** section owns the scope axis (beyond the destination, closed not graduating, returns only as a fresh effort if the destination is redrawn). Charting and working-the-map now rule a beyond-destination ticket out of scope — close it, one line in *Out of scope* — rather than leaving it on the frontier or logging it in *Decisions so far*. + +The **fog of war** leading word is retained: it names the concept and drives the graduate-the-fog behavior in the prose; only the human-facing map headings go to plain language. diff --git a/skills/in-progress/wayfinder/SKILL.md b/skills/in-progress/wayfinder/SKILL.md index 2aff9f7..6376ab5 100644 --- a/skills/in-progress/wayfinder/SKILL.md +++ b/skills/in-progress/wayfinder/SKILL.md @@ -44,7 +44,7 @@ The whole map at low resolution, loaded once per session. Open tickets are **not ## Out of scope - + ``` ### Tickets @@ -78,17 +78,20 @@ The map is _deliberately_ incomplete: don't chart what you can't yet see. Beyond The map's **Not yet specified** section is where that dim view is written down: the suspected question, the area to revisit later. It's the undiscovered frontier _toward_ the destination — everything here is in scope, just not sharp enough to ticket. Write as loosely or as fully as the view allows; it doubles as a signpost for collaborators reading where the effort is headed. -**Beyond the destination is a different thing.** The destination fixes the scope, so anything past it is out of scope no matter how clearly you can see it — the fog only ever gathers _toward_ the destination, never past it. Out-of-scope work goes in the map's **Out of scope** section: work you've consciously ruled out of _this_ effort. Not-yet-specified work graduates into tickets as the frontier advances; out-of-scope work never does, because the frontier stops at the destination. +**Fog or ticket?** The test is whether you can state the question precisely now — _not_ whether you can answer it now. -**Ticket, not-yet-specified, or out of scope?** Two questions: is it _within_ the destination's scope, and can you _state_ it sharply now? +- **Ticket when** the question is already sharp — even if it's blocked and you can't act on it yet. +- **Not yet specified when** you can't yet phrase it that sharply. Don't pre-slice the fog into ticket-sized pieces: it's coarser than a ticket, and one patch may graduate into several tickets, or none, once the frontier reaches it. -- **Ticket when** it's in scope and the question is already sharp — even if it's blocked and you can't act on it yet. -- **Not yet specified when** it's in scope but you can't yet phrase it that sharply. Don't pre-slice it into ticket-sized pieces: it's coarser than a ticket, and one patch may graduate into several tickets, or none, once the frontier reaches it. -- **Out of scope when** it lies _beyond_ the destination — however sharply you can phrase it. Scope, not sharpness, lands it here. +**Not yet specified** excludes what's already decided (Decisions so far), what's already a live ticket, and what's out of scope (the next section). -Ruling something out of scope is a scoping act, not a step on the route. When a ticket that already exists turns out to sit past the destination — mis-scoped in while charting, or exposed by a resolution — **close it** (a closed ticket is unambiguously off the frontier) and leave one line in the **Out of scope** section: the gist plus why it's out of scope, linking the closed ticket. It stays out of **Decisions so far**, which records the route actually walked — a scope boundary isn't a step on it. If the destination is ever redrawn to include it, it comes back as a fresh effort, not a resumption. +## Out of scope -**Not yet specified** excludes what's already decided (Decisions so far), what's already a live ticket, and what's out of scope (its own section). +Fog only ever gathers _toward_ the destination. The destination fixes the scope, so work beyond it is **out of scope** — however sharply you can see it, it isn't fog, and it doesn't belong in **Not yet specified**. It gets its own **Out of scope** section on the map: work you've consciously ruled out of _this_ effort. Scope, not sharpness, lands it here. + +Out-of-scope work never graduates — the frontier stops at the destination — so it returns only if the destination is redrawn, and then as a fresh effort, not a resumption. + +Ruling something out of scope is a scoping act, not a step on the route. When a ticket that already exists turns out to sit past the destination — mis-scoped in while charting, or exposed by a resolution — **close it** (a closed ticket is unambiguously off the frontier) and leave one line in the **Out of scope** section: the gist plus why it's out of scope, linking the closed ticket. It stays out of **Decisions so far**, which records the route actually walked — a scope boundary isn't a step on it. ## Invocation From 97dca07b64b3656061f485733e818a412af7764b Mon Sep 17 00:00:00 2001 From: Matt Pocock Date: Sun, 5 Jul 2026 17:48:56 +0100 Subject: [PATCH 4/4] Duplication pass: collapse restated out-of-scope mechanics - Out of scope section: drop embedded 'however sharply you can see it' duplicate; the 'Scope, not sharpness, lands it here' punchline carries the claim once. - Work-through step 5: delegate close+one-line mechanics to the Out of scope section via the 'rule it out of scope' leading phrase instead of restating them. Co-Authored-By: Claude Opus 4.8 (1M context) --- skills/in-progress/wayfinder/SKILL.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/skills/in-progress/wayfinder/SKILL.md b/skills/in-progress/wayfinder/SKILL.md index 6376ab5..0c5e652 100644 --- a/skills/in-progress/wayfinder/SKILL.md +++ b/skills/in-progress/wayfinder/SKILL.md @@ -87,7 +87,7 @@ The map's **Not yet specified** section is where that dim view is written down: ## Out of scope -Fog only ever gathers _toward_ the destination. The destination fixes the scope, so work beyond it is **out of scope** — however sharply you can see it, it isn't fog, and it doesn't belong in **Not yet specified**. It gets its own **Out of scope** section on the map: work you've consciously ruled out of _this_ effort. Scope, not sharpness, lands it here. +Fog only ever gathers _toward_ the destination. The destination fixes the scope, so work beyond it is **out of scope** — it isn't fog, and it doesn't belong in **Not yet specified**. It gets its own **Out of scope** section on the map: work you've consciously ruled out of _this_ effort. Scope, not sharpness, lands it here. Out-of-scope work never graduates — the frontier stops at the destination — so it returns only if the destination is redrawn, and then as a fresh effort, not a resumption. @@ -115,6 +115,6 @@ User invokes with a map (URL or number). A ticket is **optional** — without on 2. Choose the ticket. If the user named one, use it. Otherwise take the first frontier ticket in order. **Claim it**: assign it to yourself before any work. 3. Resolve it — **zoom as needed**: fetch the full body of any related or closed ticket on demand; invoke the skills the `## Notes` block names. If in doubt, use `/grilling` and `/domain-modeling`. 4. Record the resolution: post the answer as a **resolution comment**, **close** the issue, and **append a context pointer** to the map's Decisions-so-far. -5. Add newly-surfaced tickets (create-then-wire); graduate any fog the answer has made specifiable, clearing each graduated patch from **Not yet specified** so it lives only as its new ticket. If the answer reveals a ticket — this one or another — sits beyond the destination, **rule it out of scope** instead of resolving it on the route: close it and record one line in **Out of scope**. If the decision invalidates other parts of the map, update or delete those tickets. +5. Add newly-surfaced tickets (create-then-wire); graduate any fog the answer has made specifiable, clearing each graduated patch from **Not yet specified** so it lives only as its new ticket. If the answer reveals a ticket — this one or another — sits beyond the destination, **rule it out of scope** rather than resolving it on the route. If the decision invalidates other parts of the map, update or delete those tickets. The user may run unblocked tickets in parallel, so expect other sessions to be editing the tracker concurrently.