# Routing Table — klarheit-mit-idea2self

Maps user-intent trigger phrases to the responsible Sub-Skill or to the router's internal review workflow. Used in Phase 1 (intent recognition) and Phase 2 (precondition check) of the router.

## Trigger -> Sub-Skill -> Precondition

| Routing path | Trigger phrases (German + indirect) | Target | Precondition section in idea2self-file |
|---|---|---|---|
| 1 | "neue Idee", "starten", "Idea2Self starten", "Idee strukturieren", "Discovery", "ich habe da eine Idee", "ich will was ausprobieren" | `i2s-discovery` | none — entry point |
| 2 | "Problem-Statement", "HMW formulieren", "Problem formulieren", "Wie koennen wir ..." | `i2s-problem-statement` | `## Idee` |
| 3 | "Persona", "Zielgruppe", "Wer ist die Zielgruppe", "JTBD", "Verhaltensbasierte Persona" | `i2s-persona` | `## Problem-Statement` |
| 4 | "Recherche", "Problemraum recherchieren", "Web-Recherche zur Idee", "Marktrecherche", "Interview-Orte" | `i2s-recherche` | `## Problem-Statement` + `## Persona` |
| 5 | "Experiment", "Hypothese", "Experiment-Card", "MVE-Design", "Minimum Viable Experiment" | `i2s-experiment-card` | `## Recherche-Report` |
| 6 | "Prototyp", "Prototyp-Konzept", "Loesungsidee", "Ideen-Werkstatt", "User Flow" | `i2s-prototyp-konzept` | `## Experiment-Card` |
| 7 | "Action-Plan", "WOOP", "Umsetzungsplan", "naechste Schritte", "Obstacle-Plan" | `i2s-action-plan` | `## Prototyp-Konzept` |
| 8 | "ueberarbeiten", "iterieren", "review", "Konsistenz-Check", "neuer Input", "Erkenntnisse einarbeiten" | `workflows/review-iterate.md` (router-internal) | any existing idea2self-Datei |

## Precondition check rules

1. Lade die idea2self-Datei (Pfad steht meist im Nutzer-Prompt oder ist Standardpfad `./idea2self-<idee>.md` im aktuellen Verzeichnis).
2. Pruefe per Markdown-Heading-Match (`^## <Sektionsname>`), ob die Precondition-Sektion existiert UND nicht leer ist.
3. Vorbedingung erfuellt -> Hand-off ausfuehren (Phase 3).
4. Vorbedingung fehlt -> Nutzer informieren:
   - Form: "Voraussetzung `## <Sektion>` fehlt in `idea2self-<idee>.md`. Trigger zuerst `<voraussetzungs-skill>` oder bestaetige, dass du die Info anderweitig vorhaeltst."
   - Falls Nutzer bestaetigt -> trotzdem Hand-off, Sub-Skill wird die Info via Dialog erfragen.

## Hand-off message format (paths 1-7)

Nach Phase 2 (Vorbedingung OK):

```
Naechster Schritt: <Sub-Skill-Name>.
Trigger-Phrase: "<eine der Trigger-Phrasen aus Spalte 2>".
Vorhandene Sektionen in idea2self-Datei: <Liste>.

Nach Abschluss kannst du mit "Weiter" zum naechsten Sub-Skill in der Sequenz wechseln.
```

Beispiel:

```
Naechster Schritt: i2s-persona.
Trigger-Phrase: "Persona erstellen".
Vorhandene Sektionen in idea2self-Datei: ## Idee, ## Problem-Statement.
```

## Sequence recommendation (default flow)

```
1. i2s-discovery
   |
   v
2. i2s-problem-statement
   |
   v
3. i2s-persona
   |
   v
4. i2s-recherche
   |
   v
5. i2s-experiment-card
   |
   v
6. i2s-prototyp-konzept
   |
   v
7. i2s-action-plan
```

Schritt 8 (`review-iterate`) lebt im Router und kann **zu jedem Zeitpunkt** aufgerufen werden — z.B. nach Schritt 4 wenn die Recherche Erkenntnisse fuer das Problem-Statement liefert (Rueckwaerts-Update).

## Anti-trigger guards

Falls der Nutzer eine Trigger-Phrase aus Spalte 2 **ohne Router-Aktivierung** sagt (z.B. direkt "Persona erstellen"), aktiviert sich der jeweilige Sub-Skill von selbst per eigener `description:`. Der Router bleibt aus. Das ist by design.

Falls Trigger zweifelhaft (z.B. "Idee strukturieren" matcht Router-Pfad 1 UND koennte als Sub-Skill-Trigger gelesen werden): Router gewinnt, Sub-Skill bleibt aus. Trigger-Specificity ist in der `description:` jedes Skills entsprechend kalibriert.

## Tiebreaker-Regeln

Wenn ein Nutzer-Input plausibel **zwei** Routing-Pfade trifft, wird in dieser Reihenfolge entschieden:

1. **Explicit > Semantic.** Eine woertliche Trigger-Phrase aus Spalte 2 schlaegt eine semantische Naehe. Beispiel: "Persona erstellen" -> Pfad 3 (explicit), nicht Pfad 1 (auch wenn der Nutzer noch keine idea2self-Datei hat — die fehlende Vorbedingung wird in Phase 2 abgefangen).
2. **Earlier pipeline position > later.** Wenn zwei Pfade gleichermassen explizit getriggert sind, gewinnt der **frueher in der Sequenz** stehende. Begruendung: die spaeteren Workflows brauchen die frueheren als Vorbedingung; den frueheren zuerst zu bedienen ist immer ein Quick Win.
3. **Specific Sub-Skill > Router.** Wenn ein Sub-Skill-Trigger UND ein Router-Trigger gleichzeitig matchen: Sub-Skill gewinnt. Der Router aktiviert sich nur, wenn KEIN spezifischer Sub-Skill-Trigger im Input vorkommt.
4. **review-iterate (Pfad 8) gewinnt bei expliziten Iterations-Verben.** "Ueberarbeiten", "iterieren", "Konsistenz-Check" schlaegt jeden anderen Pfad — auch wenn der Nutzer im selben Satz "Persona" oder "Action-Plan" erwaehnt. Begruendung: das Update-Intent ist staerker als der Artefakt-Begriff.

### Klaerungsfrage bei echter Mehrdeutigkeit

Wenn nach den 4 Regeln immer noch zwei Pfade gleichwertig sind: **eine** Klaerungsfrage mit **maximal zwei** Optionen.

Format:
```
Zwei Pfade matchen deine Anfrage:
A) [Sub-Skill 1] — [1-Satz-Zweck]
B) [Sub-Skill 2] — [1-Satz-Zweck]

Welcher passt besser?
```

**Nie** drei oder mehr Optionen in einer Klaerungsfrage. **Nie** mehrere Klaerungs-Runden — wenn die Antwort weiter unklar bleibt, in Phase 1b (No-Match) wechseln.

### Beispiel — angewendete Tiebreaker

| Input | Match-Kandidaten | Anwendung | Resultat |
|-------|------------------|-----------|----------|
| "Persona ueberarbeiten" | Pfad 3 (Persona) + Pfad 8 (review-iterate) | Regel 4: Iterations-Verb gewinnt | Pfad 8 (review-iterate, Persona-Sektion) |
| "Discovery starten" | Pfad 1 (Discovery) + Router (Entry) | Regel 3: Sub-Skill gewinnt | `i2s-discovery` direkt, Router bleibt aus |
| "Validierung planen" | Pfad 4 (Recherche, semantisch) + Pfad 5 (Experiment, semantisch) | Regel 2: frueherer Pfad | Pfad 4 (`i2s-recherche`) |
| "ich brauche Klarheit zur Persona" | Pfad 3 (Persona, semantisch) + Router (Klarheit-Trigger) | Regel 1 + 3: Sub-Skill explicit gewinnt | `i2s-persona` |