Skip to content

Instantly share code, notes, and snippets.

@Whamp
Created July 11, 2026 13:45
Show Gist options
  • Select an option

  • Save Whamp/a6ac8d3d3ae37c433dcb0b1bab5cfc17 to your computer and use it in GitHub Desktop.

Select an option

Save Whamp/a6ac8d3d3ae37c433dcb0b1bab5cfc17 to your computer and use it in GitHub Desktop.
Wayfinder to Spec — audit and hydrate a completed Wayfinder map before running /to-spec
description Turn a completed Wayfinder map into a hydrated specification
argument-hint <map-ref>

Wayfinder to Spec

Load and follow /to-spec using this Wayfinder map as the source:

  • Map: $1

If the map reference is missing or cannot be loaded, stop and ask for a valid map URL, issue number, or path.

Audit the handoff

Read the configured issue tracker's Wayfinding operations, then inspect the map and all its child tickets.

Proceed only when:

  • no child ticket is open, blocked, or claimed;
  • Not yet specified contains no unresolved fog;
  • every resolved on-route ticket appears in Decisions so far;
  • deferred or rejected work appears in Out of scope; and
  • the destination is actionable without another product or technical decision.

If any check fails, do not draft a spec. Report the exact open tickets, fog, missing decision links, or scope gaps that keep the map in Wayfinder.

Hydrate the map

Before drafting:

  1. Read the full map.
  2. Read every child ticket linked from Decisions so far and Out of scope.
  3. Read each ticket's full body, resolution comment or Answer section, and linked decision assets.
  4. Treat Destination as the target, Decisions so far as the decision index, and Out of scope as the scope boundary.
  5. Preserve settled decisions. Do not silently reopen, replace, or contradict them.
  6. If two settled decisions conflict, stop and show the conflict to the user.

Then complete the normal /to-spec process. Cite the Wayfinder map and its decision tickets under Further Notes so later agents can recover the source context.

Hand off to implementation planning

After publishing the spec, stop and return:

  • the published spec title and reference;
  • a one-sentence summary of what is now specified; and
  • the exact next command: /to-tickets <published-spec-ref>.

Do not run /to-tickets automatically. Leave the published spec as a review checkpoint before implementation planning begins.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment