Before filing
Skill
wayfinder
What went wrong
A wayfinder "Work through the map" session, resolving a grilling ticket, fourth in a chain of
four (01 → 02 → 03 → 04), on a mid-flight map. [HARNESS/MODEL — fill in before sending.] The
session did the reading right: it opened tickets 02 and 03 in full before starting — retrieval
worked — and then treated them as context to skim rather than constraints to hold. Four concrete
misses, each a settled fact restated in text the session had loaded:
- Sketched a domain object using an ASCII-sketching technique taken from ticket 02 while
skipping the step ticket 02's own resolution mandated (reading the glossary first) — producing
a wrong-shaped sketch the human had to correct.
- Re-floated two placements as open that ticket 02 had pinned to a named component slot.
- Drew only a variant ticket 03 had explicitly ruled out.
- Proposed a label inside chrome whose ownership ticket 02 had assigned elsewhere — the one miss
that, when the human caught it, productively amended two earlier tickets.
Why that was a problem: a late-chain ticket has very little left to decide — the session acted as
if it had more, and the human spent the session re-stating decisions the agent had already read.
The skill's step 3 says "Zoom as needed": reachability with relevance-judgment delegated to
the session, and that judgment calibrated by the ticket's Question, not by what the chain had
pinned. "Zoom as needed" answers how much to read, and the answer is fine — the reading
happened. It does not answer what the reading is for. Resolutions read as background stay
re-decidable. The map guarantees that prior decisions are reachable; nothing in the skill makes
them held.
Proposed change
In wayfinder/SKILL.md, "Work through the map" step 3: replace the sentence our port carried
verbatim from the snapshot we track —
Zoom as needed; use whichever skills the ## Notes block names. If in doubt, use /grilling
and /domain-modeling.
— with a mandatory compile pass first (this is the wording we now run locally, reviewed against
our writing-for-agents levers):
- Resolve it. Compile the chain's constraints first: open the full body of every closed
ticket in the whole Blocked by chain and distil each resolution into a one-line
constraint inventory of what it pins — facts, placements, vocabulary; read what the
## Notes block names up front, the glossary before any label or sketch that speaks domain
vocabulary. The map keeps decisions reachable; the inventory makes them held. The chain
outranks the Question as written: where a prior resolution has settled, reframed, or
dissolved part of it, say so to the human before working, and work what remains. Check every
question, sketch, and option against the inventory before putting it to the human; a check
that fails is put to the human as a conflict — the option against the pin — for the human to
call. Zoom beyond the chain as needed; use whichever skills the ## Notes block names. If in
doubt, use /grilling and /domain-modeling.
The choices behind the wording, so each can be reviewed on its merits:
- Completion criterion, checkable and exhaustive. "Every closed ticket in the whole
Blocked by chain" is enumerable; "a one-line constraint inventory" is a countable artifact per ticket;
"every question, sketch, and option" binds the output side. The demand is legwork, not a vague
"understand the prior decisions".
- Leading word: pins. One token anchoring facts, placements, and vocabulary. The name
"constraint inventory" carries the exhaustiveness (an inventory is complete by definition) and
the recasting (a constraint is satisfied, not skimmed — "decision inventory" names where the
lines come from, not what they do, and invites the re-decidable reading that failed).
- The chain outranks the Question as written. Chart-time tickets carry a rough picture; each
resolution can teach the map something a later ticket's written Question did not know — so a
downstream Question can be stale through no one's forgetfulness. The session says so to the
human before working and works what remains, rather than silently grilling a stale question.
- A failed check is surfaced, never decided. A check that fails is put to the human as a
conflict — the option against the pin — for the human to call. The agent surfaces the clash; it
never decides the pin. This is not hypothetical: the fourth miss above became the session's one
genuine decision exactly because the human caught the clash and called it, amending two earlier
tickets. The clause moves that catch from the human to the agent's own check — the human's
effort goes to judging conflicts, never to re-stating what the agent already held. (In our copy,
step 5 already records the consequence: a decision that invalidates other tickets updates or
deletes them.)
- Positive phrasing. The step states compile/check/surface behavior; the failure modes are
never spoken as prohibitions.
- Co-location. The pass lives inside the resolve step, where the work happens — not a
separate section read at map-load and forgotten by ticket time.
- Scope choices. "Chart the map" gets nothing (no closed chain exists at chart time); the
inventory stays in-context rather than a file artifact (each session distils fresh; no stale
file to maintain); on-demand zoom survives beyond the chain.
One wording choice left open for you: the clause "read what the ## Notes block names up front,
the glossary before any label or sketch that speaks domain vocabulary" is written from our maps,
whose ## Notes name a glossary. If that is too specific for the skill as you intend it, the
repo-neutral shape would be: "read what the ## Notes block names up front, before any artifact
that speaks its vocabulary." Our incident's first miss was exactly this ordering (technique
imported, glossary skipped), so we'd want some clause that fixes required-reading before
domain-speaking output — the exact wording is yours to call.
Happy to open a PR with the wording if you'd rather react to a diff.
Before filing
SCOPE.mdand checked.out-of-scope/, and this isn't covered by either.Skill
wayfinder
What went wrong
A wayfinder "Work through the map" session, resolving a grilling ticket, fourth in a chain of
four (
01 → 02 → 03 → 04), on a mid-flight map. [HARNESS/MODEL — fill in before sending.] Thesession did the reading right: it opened tickets 02 and 03 in full before starting — retrieval
worked — and then treated them as context to skim rather than constraints to hold. Four concrete
misses, each a settled fact restated in text the session had loaded:
skipping the step ticket 02's own resolution mandated (reading the glossary first) — producing
a wrong-shaped sketch the human had to correct.
that, when the human caught it, productively amended two earlier tickets.
Why that was a problem: a late-chain ticket has very little left to decide — the session acted as
if it had more, and the human spent the session re-stating decisions the agent had already read.
The skill's step 3 says "Zoom as needed": reachability with relevance-judgment delegated to
the session, and that judgment calibrated by the ticket's Question, not by what the chain had
pinned. "Zoom as needed" answers how much to read, and the answer is fine — the reading
happened. It does not answer what the reading is for. Resolutions read as background stay
re-decidable. The map guarantees that prior decisions are reachable; nothing in the skill makes
them held.
Proposed change
In
wayfinder/SKILL.md, "Work through the map" step 3: replace the sentence our port carriedverbatim from the snapshot we track —
— with a mandatory compile pass first (this is the wording we now run locally, reviewed against
our writing-for-agents levers):
The choices behind the wording, so each can be reviewed on its merits:
Blocked bychain" is enumerable; "a one-line constraint inventory" is a countable artifact per ticket;"every question, sketch, and option" binds the output side. The demand is legwork, not a vague
"understand the prior decisions".
"constraint inventory" carries the exhaustiveness (an inventory is complete by definition) and
the recasting (a constraint is satisfied, not skimmed — "decision inventory" names where the
lines come from, not what they do, and invites the re-decidable reading that failed).
resolution can teach the map something a later ticket's written Question did not know — so a
downstream Question can be stale through no one's forgetfulness. The session says so to the
human before working and works what remains, rather than silently grilling a stale question.
conflict — the option against the pin — for the human to call. The agent surfaces the clash; it
never decides the pin. This is not hypothetical: the fourth miss above became the session's one
genuine decision exactly because the human caught the clash and called it, amending two earlier
tickets. The clause moves that catch from the human to the agent's own check — the human's
effort goes to judging conflicts, never to re-stating what the agent already held. (In our copy,
step 5 already records the consequence: a decision that invalidates other tickets updates or
deletes them.)
never spoken as prohibitions.
separate section read at map-load and forgotten by ticket time.
inventory stays in-context rather than a file artifact (each session distils fresh; no stale
file to maintain); on-demand zoom survives beyond the chain.
One wording choice left open for you: the clause "read what the
## Notesblock names up front,the glossary before any label or sketch that speaks domain vocabulary" is written from our maps,
whose
## Notesname a glossary. If that is too specific for the skill as you intend it, therepo-neutral shape would be: "read what the
## Notesblock names up front, before any artifactthat speaks its vocabulary." Our incident's first miss was exactly this ordering (technique
imported, glossary skipped), so we'd want some clause that fixes required-reading before
domain-speaking output — the exact wording is yours to call.
Happy to open a PR with the wording if you'd rather react to a diff.