wayfinder: recheck claims before showing the frontier in Handoff

Add a gate at the top of the Handoff section that rereads the session's
assertions — the resolution answer, the appended Decisions-so-far line,
and facts later tickets depend on — against the actual tracker state and
linked assets, fixing whatever doesn't hold, before the Next steps block
reveals the available sessions and new frontier.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

skills/in-progress/wayfinder/SKILL.md

@@ -5,6 +5,10 @@ description: Chart a route through a foggy problem — turn a loose idea into a
 
 A loose idea has arrived — too big for one agent session, and wrapped in fog: the route from here to a plan isn't visible yet. This skill charts it as a **shared map** on the repo's issue tracker, then works its tickets one at a time. The map is domain-agnostic — engineering work, course content, whatever fits the shape.
 
+## Refer by name
+
+Every map and ticket is an issue, so it has a **name** — its title. In everything the human reads — narration, the map's Decisions-so-far, the Handoff — refer to it by that name, never by a bare id, number, or slug. A wall of `#42, #43, #44` is illegible; names read at a glance. The id and URL don't vanish — a name wraps its link, and Handoff commands still paste the URL — but they ride *inside* the name, never stand in for it.
+
 ## The Map
 
 The map is a single issue on this repo's issue tracker, labelled `wayfinder:map` — the canonical artifact. Its tickets are child issues of the map.
@@ -100,11 +104,13 @@ The user may run unblocked tickets in parallel, so expect other sessions to be e
 
 ## Handoff
 
-End every session with a **Next steps** block the user can copy-paste. Two cases:
+**Recheck your claims first.** Before you show the frontier, reread every assertion you're about to hand off — the resolution answer, the Decisions-so-far line you appended, any facts later tickets will depend on — against the actual tracker state and the assets you linked, and fix whatever doesn't hold. The available sessions and the new frontier the human is about to act on are only as sound as the claims underneath them.
+
+Then end every session with a **Next steps** block the user can copy-paste. Two cases:
 
 **Open tickets remain.** Query the map for the currently-unblocked children, then give two copy-paste options: a bare command for one session (you pick the next ticket), and one pinned command per unblocked ticket for running them in parallel. Paste one line per fresh window — opening one, some, or all of them.
 
-> **Next steps** — 3 tickets unblocked. Clear the context, then open fresh sessions.
+> **Next steps** — *<map name>*: 3 tickets unblocked. Clear the context, then open fresh sessions.
 >
 > **One session** — resolves the next unblocked ticket:
 >
@@ -115,9 +121,9 @@ End every session with a **Next steps** block the user can copy-paste. Two cases
 > **Parallel** — paste one line per window, up to all 3:
 >
 > ```
-> Invoke /wayfinder with the map <map-url>, ticket <issue-url>.
-> Invoke /wayfinder with the map <map-url>, ticket <issue-url>.
-> Invoke /wayfinder with the map <map-url>, ticket <issue-url>.
+> Invoke /wayfinder with the map <map-url>, ticket <issue-url>.  # <ticket name>
+> Invoke /wayfinder with the map <map-url>, ticket <issue-url>.  # <ticket name>
+> Invoke /wayfinder with the map <map-url>, ticket <issue-url>.  # <ticket name>
 > ```
 
 **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.