ask-navigator

Ask Navigator

Ask-navigator ist der Navigator der Shipyard: Er nimmt ein Vorhaben entgegen, das noch im Nebel liegt – der Weg von hier zum Ziel ist noch nicht sichtbar – und kartografiert es als Karte von Entscheidungs-Tickets im Issue-Tracker des Repos. Anschließend arbeitet er den Grenzbereich Ticket für Ticket in jeder Sitzung ab, bis der Weg klar ist. Er produziert Entscheidungen, niemals Ergebnisse: Wenn der Weg klar ist, übergibt er, er baut nicht. Die Auslieferung gehört zu /oh-my-claudecode:launch.

Die Rollenvereinbarung. Der Captain (der Mensch) unterschreibt das Ziel (W1) und die Karte (W2); der Navigator entwirft alles andere und beantwortet niemals eine Frage, die dem Captain gehört – eine ausführliche Befragung, bei der der Agent seine eigenen Fragen beantwortet, hat die Rolle gebrochen, nicht nur den Prozess. Fakten sind die Aufgabe des Navigators; Entscheidungen sind die des Captains.

Nebeltest. Ein Vorhaben liegt im Nebel, wenn eine der folgenden Fragen mit „Nein“ beantwortet wird:

1. F1 – Kann das Ziel in einem Satz formuliert werden: die Spezifikation, Entscheidung oder Änderung, zu der dieses Vorhaben den Weg finden soll?
2. F2 – Können die ersten drei Entscheidungen bereits jetzt präzise benannt werden, auch wenn noch keine von ihnen beantwortet werden kann?

Beide „Ja“ → keine Karte nötig; /oh-my-claudecode:launch ausführen (dessen Nebeltor schickt Vorhaben nur hierher, wenn eine Antwort „Nein“ ist). Mindestens ein „Nein“ → zuerst kartografieren. ask-navigator ist auch direkt erreichbar: mit einer lockeren Idee, mit Restfragen aus dem Nebeltor von Launch oder ohne Argument, um die offene Karte fortzusetzen.

Kartengrundlage

Die Karte ist ein einziges Issue mit dem Label navigator:map im Issue-Tracker des Repos; ihre Entscheidungs-Tickets sind Unter-Issues der Karte. Der Tracker sollte von /oh-my-claudecode:drydock aufgezeichnet worden sein; falls kein Tracker aufgezeichnet wurde, einmal nachfragen (GitHub / GitLab / lokales Markdown) und die Antwort in den Notizen der Karte festhalten.

• Tracker-basiert (GitHub, GitLab oder aufgezeichneter Tracker): ein Karten-Issue, Unter-Issues pro Ticket, native Blockierungs-/Unter-Issue-Beziehungen. Parallele Sitzungen und die eigene UI des Trackers rendern den Grenzbereich – die Karte lebt dort, wo Menschen ohnehin hinschauen. Das Label navigator:map anlegen, falls der Tracker es noch nicht hat; Tickettypen leben im Ticket-Text, nicht in Labels.
• Lokaler Markdown-Fallback: .omc/wayfinder/<kartenname>/map.md plus decisions/NN-<name>.md, eine Datei pro Ticket, nummeriert in Abhängigkeitsreihenfolge. Der lokale Modus hat keine gleichzeitige Anspruchsgarantie: Er ist per Konvention ein Einzelfahrer, einmal in den Notizen der Karte festgehalten.

Die Karte ist ein Index, kein Speicher: Eine Entscheidung lebt an genau einem Ort – ihrem Ticket. Die Karte fasst jede Auflösung in einer Zeile zusammen und verlinkt; sie wiederholt nicht die Details.

Dokumentensprache

Karten- und Ticketprosa folgen demselben Dokumentensprachenvertrag wie /oh-my-claudecode:drydock: documentLanguage aus dem Frontmatter von CONTEXT.md lesen, falls vorhanden; falls die Werft nicht angelegt ist, die Sprachfrage einmal während der Kartierung (W2) stellen und das ermittelte Tag in den Notizen der Karte festhalten, damit der spätere Launch-Lauf es übernimmt. Pfade, Labels, Schrägstrich-Befehle, das Label navigator:map, Tickettypnamen (research, loft, grilling, task), HITL/AFK und blockedBy sind stabile Token und bleiben in jeder Sprache bytegenau stabil.

Karte kartografieren

Aufgerufen mit einer lockeren Idee (oder den Restfragen von Launch). Das Kartografieren ist die Arbeit einer Sitzung; es löst nichts von Hand.

1. Audit durchführen, Ergebnisse zurückstellen. Das Audit /oh-my-claudecode:drydock --check im Nur-Bericht-Modus ausführen: Ergebnisse blockieren niemals die Kartierung (eine Karte produziert Entscheidungen, keine Landungen), werden aber wörtlich in den Notizen der Karte festgehalten – das Werfttor von Launch wird diese Schulden eintreiben, wenn das Vorhaben schließlich in die Auslieferung geht. Falls die Werft überhaupt nicht angelegt ist (kein CONTEXT.md, kein docs/adr/), /oh-my-claudecode:drydock einmal anbieten; lehnt der Captain ab, im Nur-Tracker-Modus fortfahren und sämtliches Sediment zurückstellen (siehe Sediment).
2. W1 – das Ziel benennen. Das Skill-Tool mit „deep-interview“ aufrufen und festlegen, wohin diese Karte den Weg finden soll: die Spezifikation, Entscheidung oder Änderung. Das Ziel legt den Umfang fest, daher wird es zuerst geklärt. W1 ist eine Captain-Unterschrift: die Zielformulierung präsentieren und explizite Bestätigung einholen. Kann der Captain selbst mit Hilfe des Interviews kein Ziel nennen, ist das kein Fehler – die besten Kandidaten in einer Rangfolge präsentieren und den Captain auswählen lassen, welches er ansteuern oder ob er das Vorhaben zurückstellen möchte.
3. Den Grenzbereich kartieren. Erneut mit „deep-interview“ befragen, breitenorientiert: den gesamten Raum ausleuchten, statt sich tief in einen einzelnen Strang zu vertiefen, um die offenen Entscheidungen und die jetzt umsetzbaren ersten Schritte zu identifizieren. Wenn dabei kein Nebel sichtbar wird – der Weg zum Ziel bereits klar ist und die Reise in eine Sitzung passt –, ist keine Karte nötig: abbrechen und /oh-my-claudecode:launch empfehlen.
4. W2 – die Karte unterschreiben. Die vorgeschlagene Karte präsentieren: Ziel, erste Tickets mit Typen und Blockierungskanten sowie die Nebelskizze. W2 ist eine Captain-Unterschrift: Eine falsche Granularität verschwendet jede spätere Sitzung. Iterieren, bis unterschrieben.
5. Karte und Tickets erstellen. Die Karte mit navigator:map labeln; Unter-Tickets erstellen; Blockierungskanten in einem zweiten Durchgang verknüpfen (Issues brauchen IDs, bevor sie aufeinander verweisen können). Alles, was noch nicht scharf genug für ein Ticket ist, bleibt in Noch nicht spezifiziert.
6. Recherche-Unteragenten starten. Für jedes gerade erstellte research-Ticket einen Hintergrund-Unteragenten zur parallelen Auflösung starten (siehe Tickettypen), wobei die Erkenntnisse dort erfasst werden, wo das Ticket sie verlinken kann.
7. Anhalten mit dem Sitzungsabschluss-Hinweis: der Kartenlink, wie viele Tickets am Grenzbereich liegen, und „Nächste Sitzung: /oh-my-claudecode:ask-navigator ausführen, um die nächste Entscheidung zu bearbeiten.“

Durch die Karte arbeiten

Aufgerufen mit einer Karte (Link oder Nummer) oder ohne Argument (die offene Karte aufnehmen). Ein Ticket ist optional: Ohne Angabe wird das nächste Grenzbereich-Ticket genommen, nicht eines, das der Captain auswählen muss.

1. Karte laden: die Übersichtsansicht, niemals den gesamten Ticket-Text. Bei Bedarf in den vollständigen Text eines Tickets zoomen.
2. Anspruch vor der Arbeit: das Ticket dem Captain zuweisen (Tracker) oder Claimed-by setzen (lokal) – zuerst, damit parallele Sitzungen es überspringen. Ein offenes, nicht beanspruchtes Ticket ist nicht beansprucht. Falls die Zuweisung nicht möglich ist (Berechtigungen, kein Handle), den Anspruch stattdessen in einem Ticket-Kommentar festhalten.
3. Es auflösen entsprechend seines Typs (siehe Tickettypen). Nach Bedarf zoomen; das Skill-Tool mit „deep-interview“ aufrufen, sobald die Auflösung den Input des Captains benötigt.
4. Die Auflösung aufzeichnen: die Antwort als Auflösungskommentar/-abschnitt posten, das Ticket schließen (als erledigt; ein Ticket, das jenseits des Ziels liegt, als „nicht geplant“ schließen) und eine Zeile an die Bisherigen Entscheidungen der Karte anhängen – [<Ticket-Titel>](link): <einzeilige Zusammenfassung>.
5. Den Grenzbereich fortsetzen: jeglichen Nebel, den die Antwort spezifizierbar gemacht hat, aufnehmen (aus Noch nicht spezifiziert entfernen, neue Tickets erstellen, Kanten verknüpfen); falls die Antwort zeigt, dass ein Ticket jenseits des Ziels liegt, schließen und eine Zeile in Außerhalb des Rahmens hinterlassen; Tickets aktualisieren oder löschen, die die Entscheidung ungültig gemacht hat.
6. Sediment (siehe Sediment).
7. Nach einem Ticket anhalten. Eine Auflösung pro Sitzung ist der Rhythmus – es ist das Kontextfenster-Budget, keine Richtlinie. Der Sitzungsabschluss-Hinweis nennt, was gerade aufgelöst wurde und was nun am Grenzbereich liegt.

Tickettypen

Jedes Ticket ist HITL (mit dem Captain bearbeitet, der für sich selbst spricht) oder AFK (allein vom Navigator getrieben). Ein HITL-Ticket wird nur durch Live-Austausch aufgelöst; der Agent vertritt niemals die Seite des Captains.

Typ	Modus	Aufgelöst durch	Verwendung wenn
research	AFK	Hintergrund-Unteragent: gegen Primärquellen (offizielle Doks, Quellcode, Spezifikationen) recherchieren, eine zitierte Markdown-Datei unter docs/research/<ticket-name>.md hinterlassen (oder der bestehenden Notizen-Konvention des Repos, falls vorhanden), vom Ticket aus verlinken	Eine Entscheidung wartet auf Wissen außerhalb des aktuellen Arbeitsverzeichnisses
loft	HITL	Skill-Tool mit „loft“ aufrufen: ein Wegwerf-Artefakt beantwortet die Frage des Tickets – ein reines Logikmodul in einer klickbaren Shell oder strukturell unterschiedliche UI-Varianten hinter einer Route; der Captain reagiert, die Antwort fließt in die Auflösung ein, das Artefakt bleibt auf einem loft/<name>-Branch	Die Frage ist präzise, aber Prosa kann sie nicht klären – sie muss gesehen oder angeklickt, nicht beschrieben werden
grilling	HITL	Skill-Tool mit „deep-interview“ aufrufen; der Captain entscheidet jede Runde	Konversation ist die Auflösung – der Standardfall
task	HITL oder AFK	Der Navigator treibt es allein voran, wo möglich; andernfalls übergibt er dem Captain eine präzise Checkliste	Manuelle Arbeit, die eine Entscheidung entblockt (Dienst anmelden, Zugriff bereitstellen, Daten verschieben, damit ihre Form sichtbar wird) – sie verdient ihren Platz, indem sie eine Entscheidung entblockt, nicht durch Auslieferung des Ziels

Die Antwort ist niemals Teil des Ticket-Texts; sie wird bei der Auflösung aufgezeichnet. Bei der Auflösung erstellte Objekte werden vom Ticket aus verlinkt, nicht eingefügt.

Kartenkörper

## Ziel

<wie das Ende dieser Karte aussieht: die Spezifikation, Entscheidung oder Änderung, zu der dieses Vorhaben den Weg finden soll. Ein oder zwei Zeilen; jede Sitzung orientiert sich daran, bevor sie ein Ticket auswählt.>

## Notizen

<Domäne; Fähigkeiten, die jede Sitzung konsultieren sollte; dauerhafte Präferenzen; zurückgestellte Drydock --check-Ergebnisse (wörtlich); ermitteltes documentLanguage-Tag; Tracker-Modus-Hinweise für den lokalen Modus>

## Bisherige Entscheidungen

<!-- der Index: eine Zeile pro geschlossenem Ticket, genug, um die Relevanz zu beurteilen, dann beim Link zoomen für das Detail, das das Ticket enthält -->

- [<geschlossener Ticket-Titel>](link): <einzeilige Zusammenfassung der Antwort>

## Noch nicht spezifiziert

<!-- im Rahmen liegender Nebel, den Sie noch nicht ticketn können; wandert mit Fortschreiten des Grenzbereichs weiter -->

## Außerhalb des Rahmens

<!-- Arbeit, die als jenseits des Ziels eingestuft wurde; geschlossen, wandert nie weiter -->

Nebel oder Ticket? Der Test ist, ob Sie die Frage jetzt präzise formulieren können, nicht, ob Sie sie jetzt beantworten können. Ticket, sobald die Frage bereits scharf ist, selbst wenn sie blockiert ist. Noch-nicht-spezifiziert, wenn Sie sie nicht so scharf formulieren können – schneiden Sie den Nebel nicht vorab in ticketgroße Stücke; ein Fleck kann in mehrere Tickets übergehen oder in keines. Außerhalb des Rahmens ist ein rahmender Akt, kein Schritt auf dem Weg: Der Rahmen, nicht die Schärfe, setzt Arbeit dorthin, und sie kehrt nur zurück, wenn das Ziel neu gezeichnet wird.

Sediment

Auflösungen landen im Papierpfad der Shipyard, sobald sie sich setzen – dieselben Slots, die Launch in Phase 1 verwendet:

• ein Begriff, den die Auflösungen gesetzt oder geschärft haben → Glossar von CONTEXT.md (ein Eintrag: Definition, Grenze, aufgelöste Mehrdeutigkeit)
• eine Entscheidung, die den ADR-Test besteht (schwer rückgängig zu machen, ohne Kontext überraschend, ein echter Tradeoff) → docs/adr/NNNN-<name>.md
• eine Geschäftsregel oder ein Hintergrundfakt → docs/business/ (ein Artikel pro Geschäftsfrage)

Wenn die Werft nicht angelegt ist (der Captain hat Drydock zum Zeitpunkt der Kartierung abgelehnt), zurückstellen, nicht überspringen: jede ausstehende Landung als eine Zeile in den Notizen der Karte unter einer Überschrift Zurückgestelltes Sediment festhalten. Der spätere /oh-my-claudecode:launch-Lauf behandelt die nicht angelegten Oberflächen als Ergebnisse, und die zurückgestellten Zeilen sagen ihm genau, was er zuerst landen muss.

Ausstieg – übergeben, nicht bauen

Die Karte ist fertig, wenn keine offenen Tickets mehr vorhanden sind und Noch nicht spezifiziert leer ist. Dann:

1. Bisherige Entscheidungen zu einem Mission Brief zusammenfassen: Zielsetzung, Rahmengrenze, Nicht-Ziele – jetzt formulierbar, weil der Weg klar ist. Nach .omc/wayfinder/<kartenname>/brief.md schreiben, sodass die Übergabe einen Zeiger und nicht den Inhalt übergibt.
2. Empfehlen: „Der Weg ist klar. Führen Sie /oh-my-claudecode:launch mit dem Brief unter .omc/wayfinder/<kartenname>/brief.md aus.“ Die Karte bleibt als Logbuch des Vorhabens bestehen; das Werfttor von Launch übernimmt von dort an alle Prüfungen.
3. Standardeintritt ist Launch Phase 1 (der Papierpfad ist bereits halb voll; sein Grenzbereich räumt schnell). Nur wenn die Entscheidungen bereits wie eine Spezifikation aussehen, darf eine Spezifikation entworfen und Launch in Phase 2 mit dem Spezifikationspfad betreten werden.

Umfang und Nicht-Ziele

• Kein Daemon, kein Modus, kein Always-On-Verhalten, keine Laufzeit-Zustandsmaschine: Die Karte sind gewöhnliche Tracker-Issues oder Repo-Dateien.
• Eingehende Anfragen, die als Nebel ankommen, zu routen ist Sache des Hafens: Ein vages Issue, das von /oh-my-claudecode:harbor übergeben wird, wird wie jede lockere Idee kartografiert, wobei der ursprüngliche Thread und alle unterschriebenen Entscheidungslinks als Material dienen.
• Niemals Team-Lebenszyklus, Aufgabenstatus oder Laufzeitzustand mutieren; niemals Auslieferungs-Tickets veröffentlichen – vertikale Schnitt-Build-Tickets gehören zu Launchs C3, und der Navigator darf Nebel nicht vorab in sie hineinschneiden.
• Niemals eine Entscheidung über das Aufzeichnen hinaus ausführen. Die einzige Ausnahme ist ein task-Ticket, das nur das tut, was eine Entscheidung entblockt.
• Die Bisherigen Entscheidungen der Karte sind ein Index; eine Entscheidung lebt an genau einem Ort, ihrem Ticket.

Abschlussdefinition

Eine Kartierungssitzung endet mit einer vom Captain unterschriebenen Karte und gestarteten Recherche-Tickets. Eine Arbeitssitzung endet mit genau einer aufgezeichneten Auflösung, einem fortgesetzten Grenzbereich und dem ausgegebenen Sitzungsabschluss-Hinweis. Das Vorhaben endet, wenn der Weg klar ist und der Mission Brief mit der Empfehlung von /oh-my-claudecode:launch in den Händen des Captains liegt – jede Entscheidung, die der Navigator im Namen des Captains getroffen hat, mit einem Zeiger darauf, wo sie aufgezeichnet wurde.