/ask-navigator

name: ask-navigator
description: "Shipyard's navigator — chart a foggy effort (destination unclear, questions not yet stateable) into a map of decision tickets on the repo's issue tracker, then work the frontier one ticket per session until the way is clear, and hand the collapsed decisions to /launch as a mission brief. Wayfinding, not building: it produces decisions, never deliverables."
argument-hint: "<loose idea | residual questions | map link or number | nothing to continue the open map>"
level: 3
disable-model-invocation: true
pipeline: [deep-interview, ask-navigator]

Ask Navigator

Ask-navigator is the shipyard's **navigator**: it takes an effort wrapped in fog — the way from here to the destination isn't visible yet — and charts it as a **map of decision tickets** on the repo's issue tracker, then works the frontier one ticket per session until the route is clear. It produces **decisions, never deliverables**: when the way is clear it hands off, it doesn't build. Delivery belongs to `/oh-my-claudecode:launch`.

**The role contract.** The captain (the human) signs the destination (W1) and the chart (W2); the navigator drafts everything else and **never answers a question that belongs to the captain** — a grilling session in which the agent answers its own questions has broken the role, not just the process. Facts are the navigator's job; decisions are the captain's.

**Fog test.** An effort has fog when either answer is no:

1. **Q1** — Can the destination be stated in one sentence: the spec, decision, or change this effort is finding its way to? 2. **Q2** — Can the first three decisions be stated precisely right now, even though none of them can be answered yet?

Both yes → no map is needed; run `/oh-my-claudecode:launch` (its fog gate sends efforts here only when an answer is no). Either no → chart first. `ask-navigator` is also reachable directly: invoke it with a loose idea, with residual questions handed over by launch's fog gate, or with no argument to continue the open map.

Map home

The map is a **single issue** labelled `navigator:map` on the repo's issue tracker; its decision tickets are child issues of the map. The tracker should have been recorded by `/oh-my-claudecode:drydock`; if none was recorded, ask once and remember the answer inside the map's Notes.

The tracker is the **only map medium** — there is no local fallback: one map issue, child issues per ticket, native blocking/sub-issue relationships. Concurrent sessions and the tracker's own UI render the frontier — the map lives where humans already look. A map written to local files strands decisions where later sessions, the captain, and launch will never find them; do not fall back to local files. If the tracker is unreachable, stop and report the blocker. Create the `navigator:map` label if the tracker doesn't have it yet; ticket types live in the ticket body, not in labels.

**One-time migration for existing local maps:** On a no-argument continuation, if no tracker map is found but `.omc/wayfinder/<slug>/map.md` exists, treat it as an import source — never start a second map or continue from the local copy as a live backend. Read that map and its `decisions/` entries, identify the configured tracker, and ask the captain to confirm the import. After confirmation, create one `navigator:map` parent issue, one child issue for each decision ticket, native sub-issue and blocking relationships, and carry over the frontier, ruled-out work, settled decisions, and mission brief. Put each resolution on its corresponding child issue and add a parent-issue comment recording the source path and import date. Keep the local files unchanged as the audit source; verify every decision, resolution, and dependency is represented before declaring the import complete. The tracker then becomes the sole live map. If the tracker is unavailable or the captain declines, stop without creating a local map or a duplicate effort.

The map is an **index, not a store**: a decision lives in exactly one place — its ticket. The map gists each resolution in one line and links; it never restates the detail.

Document language

Map and ticket prose follow the same document-language contract as `/oh-my-claudecode:drydock`: read `documentLanguage` from `GLOSSARY.md` frontmatter when present (a legacy yard with only `CONTEXT.md` reads it there and never gets a second glossary; drydock's legacy glossary migration renames it); if the yard is not laid, ask the language question once during charting (W2) and record the resolved tag in the map's Notes so the later launch run inherits it. Paths, labels, slash commands, the `navigator:map` label, ticket-type names (`research`, `loft`, `grilling`, `task`), `HITL`/`AFK`, and `blockedBy` are stable tokens and stay byte-for-byte stable in every language.

Chart the map

Invoked with a loose idea (or launch's residual questions). Charting is one session's work; it hand-resolves nothing.

1. **Run the audit, defer the findings.** Run the `/oh-my-claudecode:drydock` `--check` audit in report-only mode — the mechanical subset via `node scripts/shipyard-audit.mjs`, the heuristic classes via the drydock prose audit: findings never block charting (a map produces decisions, not slot landings), but they are recorded verbatim in the map's Notes — launch's yard gate will collect that debt when the effort finally enters delivery. If the yard is not laid at all (no `GLOSSARY.md`, no `docs/adr/`), offer `/oh-my-claudecode:drydock` **once**; if the captain declines, proceed in tracker-only mode and defer all sediment (see Sediment). 2. **W1 — name the destination.** Call the Skill tool with "deep-interview" and pin down what this map is finding its way to: the spec, decision, or change. The destination fixes the scope, so it is settled first. **W1 is a captain signature: present the destination statement and get explicit confirmation.** If the captain cannot state a destination even with the interview's