---
name: wayfinder
description: Kartiert ein riesiges, unklares Vorhaben als Landkarte aus Entscheidungs-Tickets. Nutze es bei einem Greenfield-Projekt oder Mega-Feature, dessen Weg noch nicht sichtbar ist, nicht für ein gut umrissenes Feature.
disable-model-invocation: true
kategorie: On-Ramp
---

# 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`.

```markdown
## 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):

1. **Ziel benennen**: grillen, um festzulegen, worauf diese Karte zusteuert.
2. **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.
3. **Dokument anlegen**: Ziel und Notizen ausgefüllt, bisherige Entscheidungen leer, der Nebel unter
   "Noch nicht spezifiziert".
4. 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):

1. Karte laden (die Kurzfassung, nicht jedes Detail).
2. Ticket wählen.
3. Auflösen, bei Bedarf grillen und domain-modeling aufrufen.
4. Auflösung als Ergänzung zu "Bisherige Entscheidungen" vorschlagen, du fügst sie ins Dokument ein.
5. 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.