arda/skills
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Split fog and out-of-scope into separate explanatory sections

Browse source 
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) <noreply@anthropic.com>
This commit is contained in:
Matt Pocock 2026-07-05 17:44:13 +01:00
parent 3ea01314c1
commit 7d34a8dc38
2 changed files with 16 additions and 11 deletions
Download patch file Download diff file Expand all files Collapse all files

19
skills/in-progress/wayfinder/SKILL.md
View file

@ -44,7 +44,7 @@ The whole map at low resolution, loaded once per session. Open tickets are **not
## Out of scope
<!-- see "Fog of war": work ruled beyond the destination; closed, never graduates -->
<!-- see "Out of scope": work ruled beyond the destination; closed, never graduates -->
```
### 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