wayfinder: Ein riesiges, neblig es Vorhaben kartieren
Für ein großes, unklares Vorhaben, das größer als eine Sitzung ist und im Nebel liegt: statt loszubauen, kartiert dieser Skill eine gemeinsame Landkarte aus Entscheidungs-Tickets (Fragen, deren Auflösung eine Entscheidung ist, keine Bau-Slices) und arbeitet sie eine nach der anderen ab, bis der Weg klar ist.
Wann brauche ich das?
Ein Greenfield-Projekt oder ein Mega-Feature, dessen Weg von hier zum Ziel noch nicht sichtbar ist.
Nicht für ein gut umrissenes Feature (dafür reicht grill-me).
Planen, nicht Tun
Jedes Ticket löst eine Entscheidung; die Karte ist fertig, wenn der Weg klar ist und nichts mehr zu entscheiden bleibt, bevor jemand losbaut. Standardmäßig entstehen Entscheidungen, keine Deliverables.
Die Karte: angepasst, ein Dokument, das du pflegst
Im Original ist die Karte ein Issue auf dem Tracker mit nativen Kind-Ticket-/Blocking-Beziehungen.
Ohne Jira-Anbindung wird die Karte stattdessen ein Markdown-Dokument, das du selbst pflegst
(z.B. .scratch/wayfinder/<vorhaben>.md im Repo, oder eine Confluence-Seite): nach jeder
aufgelösten Frage schlägt die KI den aktualisierten Abschnitt als Snippet vor, du fügst ihn ein.
Genau dasselbe Copy-Paste-Muster wie bei to-spec/to-tickets.
## Ziel
<wie sieht das Ende dieser Landkarte aus: die Spec, Entscheidung oder Änderung, zu der dieses
Vorhaben den Weg findet. Ein bis zwei Zeilen.>
## Notizen
<Domain, Skills, die jede Sitzung heranziehen sollte; Standing-Preferences>
## Bisherige Entscheidungen
- <Titel der geklärten Frage>: <ein-Zeilen-Gist der Antwort>
## Noch nicht spezifiziert
<Nebel: Fragen, die absehbar kommen, aber noch nicht scharf genug sind, um ein Ticket zu werden>
## Außerhalb des Scopes
<bewusst ausgeschlossene Arbeit>
Tickets (einzelne Fragen) können optional als echte Jira-Issues angelegt werden, wenn Sichtbarkeit fürs Team wichtig ist, dann trägst du sie manuell ein und verknüpfst Blocking-Kanten selbst. Für eine reine Solo-Planung reicht das Dokument allein.
Ticket-Typen
| Typ | Läuft über |
|---|---|
| Recherche: eine Faktenfrage, die eine Entscheidung braucht | research, seriell im selben Chat statt parallel über Subagenten |
| Prototyp: die Diskussion mit einem billigen, konkreten Artefakt anheben | prototype |
| Grillen: der Normalfall, ein Gespräch | das Interview-Prinzip aus grill-me |
| Aufgabe: manuelle Arbeit, die vor einer Entscheidung erledigt sein muss (Zugang beantragen, Daten verschieben) | nichts zu entscheiden, aber blockierend |
Was entfällt: Claiming
Im Original weist eine Sitzung sich selbst ein Ticket zu, damit parallele Sitzungen es überspringen. Das löst ein Problem, das nur bei mehreren gleichzeitig laufenden Agenten-Sessions entsteht. Ohne Agenten gibt es bei uns keine Nebenläufigkeit zu koordinieren: du arbeitest ohnehin ein Ticket nach dem anderen, in genau einer Sitzung. Der Abschnitt fällt ersatzlos weg, das ist eine Vereinfachung, keine Lücke.
Nebel des Krieges
Die Karte ist bewusst unvollständig: nicht kartieren, was man noch nicht sehen kann. Jenseits der aktuellen Tickets liegt der Nebel: Fragen, die absehbar kommen, aber noch nicht scharf genug sind. Ticket oder Nebel? Der Test ist, ob sich die Frage jetzt schon präzise formulieren lässt, nicht ob sie jetzt schon beantwortbar ist.
Ablauf
Karte anlegen (einmalig, du startest mit einer losen Idee):
- Ziel benennen: grillen, um festzulegen, worauf diese Karte zusteuert.
- Nebel breitensuchend kartieren: nochmal grillen, diesmal in die Breite: was ist offen, was ist jetzt schon startbar. Ergibt sich dabei kein Nebel (der Weg ist schon klar genug für eine Sitzung), braucht es keine Karte.
- Dokument anlegen: Ziel und Notizen ausgefüllt, bisherige Entscheidungen leer, der Nebel unter "Noch nicht spezifiziert".
- Die Tickets, die sich schon spezifizieren lassen, als Abschnitt/Liste anlegen.
Karte abarbeiten (du startest mit einer bestehenden Karte, ein Ticket ist optional, ohne gewähltes Ticket wählt die KI selbst die nächste Frage aus der Karte):
- Karte laden (die Kurzfassung, nicht jedes Detail).
- Ticket wählen.
- Auflösen, bei Bedarf grillen und domain-modeling aufrufen.
- Auflösung als Ergänzung zu "Bisherige Entscheidungen" vorschlagen, du fügst sie ins Dokument ein.
- Neu sichtbar gewordene Tickets ergänzen; Nebel, der jetzt spezifizierbar ist, aus "Noch nicht spezifiziert" herauslösen.
Wo passt das rein?
On-Ramp für ein riesiges, neblig es Vorhaben. Wenn die Karte klar ist, mündet sie in to-spec, das
die verlinkten Entscheidungen zu einem umsetzbaren Plan zusammenfasst. Gesamtüberblick: ask-simon.
Was sich gegenüber dem Original geändert hat
- Die Karte ist ein von dir gepflegtes Markdown-Dokument statt eines lebenden Tracker-Issues mit nativen Blocking-Links.
- Der Claiming-Mechanismus für parallele Sessions entfällt ersatzlos, das Problem, das er löst, existiert ohne Agenten nicht.
- Recherche-Tickets laufen seriell im selben Chat statt parallel über Subagenten.
- Die eigentliche Planungsdisziplin (Ziel zuerst, breitensuchend, Ticket-Typen, Nebel-vs-Scope-Trennung, ein Ticket pro Sitzung) bleibt vollständig erhalten.