wayfinder → /to-spec: the spec has no link back to its map

[kareblak]

A common wayfinder destination is "a spec, ready for /to-spec". When that hand-off happens, nothing ties the spec to the map it came from:

• /to-spec publishes the spec with no reference to the map.
• The map's Decisions so far ends at the last decision ticket. Nothing on the map points at the spec it was charted for.
• On GitHub, GitLab and Linear the map's children are decision tickets (sub-issues / ## Parent). The spec lands as an unrelated issue, and the /to-tickets implementation tickets hang off the spec, so the whole chain from map to code breaks at that one hop.

setup-matt-pocock-skills/issue-tracker-*.md defines map → ticket and spec → implementation-ticket links, but no spec → map link.

Why it matters: anything that wants to show "this map, its decisions, and the spec and tickets that came out of it" (a person scanning the tracker, or a board built on the tracker) has to rely on a hand-written convention.

Suggestion: when /to-spec runs in a session that worked a wayfinder map, write the link the tracker already uses for parentage, e.g. Part of #<map> on GitHub/Gitea, ## Parent on GitLab, a related/parent relation on Linear. Optionally, /wayfinder (or /to-spec) appends a context pointer to the spec in the map's Decisions so far, the same way it does for closed tickets.

Workaround today: I write Part of #<map> into the spec by hand.

Happy to turn this into an Idea issue once I've hit it in a real session, if that's the better place for it.

[lab1207]

Confirmed at main 49dd158, and this is adoptable as a two-line addition. The gap is exactly where you say it is.

Do this: in skills/engineering/to-spec/SKILL.md, extend step 3 (line 19, the publish step that currently applies only the ready-for-agent triage label) with one sentence: if the spec came out of a wayfinder map, link it the way the tracker links children, then append a context pointer to the map's Decisions so far. Both halves already have a documented form in skills/engineering/setup-matt-pocock-skills/issue-tracker-github.md: child linkage is a sub-issue or Part of #<map> at the top of the child body (lines 10 and 42), and closing a ticket appends a context pointer to Decisions so far (line 46). The spec publish step is the one place that does neither.

Proof that nothing else needs to change: the spec template itself needs no new section, the link rides the existing child-linkage convention, and the Decisions append mirrors the ticket-resolve behavior the map already expects. to-spec is user-invoked (disable-model-invocation: true in its frontmatter), so the human supplies the map number at publish time; no session detection is required.

Confirm: run a wayfinder map to a spec on a test repo and check both directions, the spec body carries the parent link and the map's Decisions so far points at the spec. Your hand-written Part of #<map> workaround becomes the default behavior.

Two caveats. I verified the GitHub tracker doc; GitLab and Linear need their own parent idiom from their tracker docs, so the skill sentence should name the convention per platform rather than hardcoding Part of. And /to-tickets hanging implementation tickets off the spec stays as is; this only repairs the map to spec hop, which is the one you identified as broken.