Learning Skill v2.0

---

🛑 IDENTITÄTS-REGEL — KEINE EXTERNEN PROJEKTNAMEN (HARD BLOCK)

Dieser Skill heißt "Learning Skill". Das ist der EINZIGE Name der in jeglichem Output verwendet wird.

VERBOTEN — in JEGLICHEM generierten Output (HTML, JSON, Markdown, Kommentare, Tooltips, Logs, Commit-Messages, Dateinamen, Variablennamen, Beschreibungen, Reports, README, Tiefenkarten):

❌ VERBOTEN	Warum
"Understand Anything"	Externer Projektname — darf NIEMALS erscheinen
"Understand-Anything"	Externer Projektname — darf NIEMALS erscheinen
"Understanding Skill"	Falscher Name — der Skill heißt NUR "Learning Skill"
"Claude Learning & Understanding Skill"	Falscher Name — der Skill heißt NUR "Learning Skill"
"claude-learning-understanding"	Falscher Slug — korrekt ist "learning-skill"
".understand-anything/"	Falscher Ordnername — korrekt ist ".claude-learning/"
Jeder Verweis auf die Herkunft der Verstehen-Pipeline	Die Pipeline ist TEIL dieses Skills, kein externes Projekt

KORREKTE Bezeichnungen:

Kontext	Korrekter Name
Skill-Name	"Learning Skill" oder "Learning Skill v2.0"
Skill-Slug (YAML, Ordner, Referenzen)	"learning-skill"
Output-Ordner für Knowledge Graphs	".claude-learning/"
Modus-Bezeichnungen	"Kurs-Modus", "Verstehen-Modus", "Kombiniert-Modus"
Agenten-Referenzen	"project-scanner", "file-analyzer" etc. — OHNE Projektpräfix

Selbst-Check vor JEDEM Output:

□ Enthält der Output den String "Understand Anything"? → ENTFERNEN
□ Enthält der Output den String "Understanding"? → Nur OK wenn generisches englisches Wort in einem Satz (z.B. "for understanding the code"), NICHT OK als Namensbestandteil
□ Enthält der Output ".understand-anything/"? → ERSETZEN durch ".claude-learning/"
□ Enthält eine Commit-Message einen Hinweis auf externe Projekte? → ENTFERNEN
□ Enthält der Output "aus Understand-Anything" oder "(aus ...)"? → ENTFERNEN

Diese Regel gilt IMMER — auch bei Tests, Selbstanwendung, Debug-Output, Logs und internen Zwischenergebnissen.

---

Dieser Skill vereint zwei leistungsstarke Analyse-Pipelines in einem einzigen, Claude-optimierten Werkzeug:

1. Kurs-Modus -- Verwandelt beliebige Codebases in interaktive Multi-Level-HTML-Kurse mit 4 Tiefenebenen (L0-L3), Zielgruppen-Segmentierung (Anwender/Entwickler/Entscheider), bilingual DE/EN, und Energiekonzern-Design (Tiefenblau #000099, Impuls-Orange #FE8F11, Warmgrau #E4DAD4).

2. Verstehen-Modus -- Erzeugt einen interaktiven Knowledge Graph (knowledge-graph.json) mit Multi-Agent-Pipeline (project-scanner, file-analyzer, architecture-analyzer, tour-builder, graph-reviewer) und interaktivem React Dashboard zur Code-Exploration.

3. Kombiniert-Modus (BEST OF BOTH) -- Führt zuerst die Verstehen-Pipeline aus, erzeugt den Knowledge Graph, und nutzt dessen Daten dann um BESSERE HTML-Kurse zu generieren. Der KG verbessert Phase 1 (Analyse) und das Helpfulness-Scoring.

---

MODUS-ERKENNUNG -- Automatische Weichenstellung

Wenn der User den Skill aufruft, wird der Modus anhand von Schlüsselwörtern bestimmt:

Modus	Schlüsselwörter	Was passiert
Kurs-Modus	"Kurs", "Tutorial", "Walkthrough", "interaktiv", "course", "teach", "lernen", "erklären", "HTML", "Kursseiten"	Nur die Kurs-Pipeline (Phasen 0-6)
Verstehen-Modus	"verstehen", "understand", "knowledge graph", "dashboard", "explore", "graph", "analyse", "analyze"	Nur die KG-Pipeline (Phasen 0-7)
Kombiniert-Modus	"beides", "komplett", "full", "alles", "combined", "kurs + graph", "everything"	Erst KG-Pipeline, dann KG-gestuetzte Kurs-Pipeline
Unklar	Keines der obigen	User fragen: "Welchen Modus möchtest du? (1) Kurs-Modus -- HTML-Kurse, (2) Verstehen-Modus -- Knowledge Graph + Dashboard, (3) Kombiniert-Modus -- beides"

---

UNUMGEHBARE VORBEDINGUNG -- VOR ALLEM ANDEREN LESEN

Gilt für: Kurs-Modus und Kombiniert-Modus (Phase B) Für Verstehen-Modus allein: Nur der Quellpfad wird benötigt.

BEVOR auch nur eine einzige Zeile Code, HTML oder Analyse erzeugt wird, MUSS der User zwei Fragen beantwortet haben:

1. Zielgruppen -- Für wen ALLES? (Anwender, Entwickler, Entscheider, Custom)
2. Integrationsmodus -- Standalone oder Eingebettet? (Bei eingebettet: GitHub-URL? Impressum? Datenschutz? Copyright?)

Es gibt KEINE Ausnahme von dieser Regel. Auch nicht bei:

• "Verprobe den Skill" / "Teste den Skill" / "Wende den Skill auf sich selbst an"
• "Mach einfach" / "Leg los" / "Ich brauch das schnell"
• "Nur für mich" / "Ist nur ein Test" / "Egal, Hauptsache es funktioniert"
• Impliziten Annahmen aus dem Kontext ("ist ja ein Dev-Repo, also wohl für Entwickler")
• Wenn der User eine Zielgruppe nennt aber den Integrationsmodus nicht ("für Entwickler" -- Integration ist TROTZDEM unklar!)
• Wenn der User den Integrationsmodus nennt aber die Zielgruppen nicht ("standalone" -- Zielgruppen sind TROTZDEM unklar!)

Was passiert wenn die Fragen nicht gestellt werden:

• Der gesamte Output ist FALSCH -- falsche Dateibenennung, falscher Tonfall, falscher Inhalt, fehlende/überflüssige Footer und Header-Links
• Jede Datei die ohne diese Antworten erzeugt wird, muss komplett neu geschrieben werden
• Der User verliert Vertrauen in den Skill

Die EINZIGE korrekte Reaktion wenn Zielgruppen ODER Integrationsmodus unklar sind:

• Die Rückfrage stellen (siehe Phase 0: "Die Rückfrage")
• WARTEN bis der User antwortet
• ERST DANN mit Phase 1 beginnen

Selbst-Check vor Phase 1:

[ ] Hat der User EXPLIZIT gesagt für welche Zielgruppen? -> Wenn nein: FRAGEN
[ ] Hat der User EXPLIZIT gesagt ob Standalone oder Eingebettet? -> Wenn nein: FRAGEN
[ ] Wenn Eingebettet: Hat der User GitHub-URL, Impressum, Datenschutz, Copyright angegeben? -> Wenn nein: NACHFRAGEN
[ ] Alle drei Checks bestanden? -> Erst jetzt Phase 1 starten

---

LEVEL-SYSTEM -- Die 4 Tiefenebenen

+---------------------------------------------------------------------------+
|  L0: UEBERBLICK (index_*.html)                                             |
|  +- 5-8 Module als Scroll-Seite                                           |
|  +- Jedes Modul = 1 Thema mit max 3 Sätzen + Visualisierung              |
|  +- Jedes Modul verlinkt auf seine L1-Seite                                |
|      |                                                                     |
|  L1: THEMENDETAIL (l1/thema-slug_*.html) -- max 10 pro L0                  |
|  +- Ein Thema aus L0 wird vertieft erklärt                                |
|  +- 4-8 Abschnitte mit je eigener Visualisierung                          |
|  +- Jeder Abschnitt kann auf L2-Seite verlinken                           |
|  +- Breadcrumb: L0 > L1                                                   |
|      |                                                                     |
|  L2: SUB-THEMEN (l2/sub-thema-slug_*.html) -- max 10 pro L1                |
|  +- Ein Abschnitt aus L1 wird zum eigenstaendigen Lernmodul                |
|  +- Tiefe Erklärungen, vollstaendige Code-Walkthroughs                    |
|  +- Kann auf L3-Seiten verlinken für ultimatives Detail                   |
|  +- Breadcrumb: L0 > L1 > L2                                              |
|      |                                                                     |
|  L3: TIEFENDETAIL (l3/detail-slug_*.html) -- max 10 pro L2                 |
|  +- Maximale Tiefe: Zeile-für-Zeile, Edge-Cases, Internals               |
|  +- Für Entwickler: Jede Zeile erklärt + Alternativen                    |
|  +- Für Anwender: Jedes UI-Detail + Fehlerbehebung                       |
|  +- Für Entscheider: Jede Zahl belegt + Szenarien                        |
|  +- Breadcrumb: L0 > L1 > L2 > L3                                         |
|                                                                            |
|  === TIEFERE EBENEN GIBT ES NICHT ===                                      |
|  L3 ist das Maximum. Dort steht ALLES.                                     |
+---------------------------------------------------------------------------+

Level-Charakter-Tabelle

Level	Zweck	Inhalt pro Seite	Interaktivitaet	Laenge
L0	Vogelperspektive -- "Was gibt es hier?"	5-8 Module, je 2-3 Sätze + 1 Visual	Quiz, Scroll-Nav	1 Scroll-Seite
L1	Themenvertiefung -- "Wie funktioniert das?"	4-8 Abschnitte, je 1 Absatz + Visual	Quiz, Code<->Klartext, Flow-Diagramme	1 Scroll-Seite
L2	Detailwissen -- "Zeig mir die Mechanik"	3-6 tiefe Abschnitte mit vollstaendigen Erklärungen	Interaktive Diagramme, Drag&Drop, Chat-Simulationen	1 Scroll-Seite
L3	Expertenwissen -- "Zeig mir ALLES"	2-5 ultra-detaillierte Sektionen	Zeile-für-Zeile-Walkthroughs, Edge-Case-Szenarien, Debugging-Challenges	1 Scroll-Seite

Zielgruppen-Tiefenprofile -- Bedarfsgerechte Level-Erzeugung

KERNPRINZIP: Nicht jede Zielgruppe braucht 4 Ebenen. Das Tiefenprofil bestimmt PRO ZIELGRUPPE, welche Level überhaupt erzeugt werden. Das spart Dateien, fokussiert Inhalte und verhindert kuenstlich aufgeblaehte Kurse.

Vordefinierte Tiefenprofile:

Zielgruppe	Default Max-Level	Typische Tiefe	HS-Schwelle eigene Seite	HS-Schwelle "noch tiefer"	Begründung
Anwender	L2	L0->L1, selten L2	HS >= 7 (strenger)	HS >= 9	Anwender wollen NUTZEN, nicht VERSTEHEN. Tiefe nur bei komplexen Workflows oder Troubleshooting
Entwickler	L3	L0->L1->L2->L3	HS >= 6 (Standard)	HS >= 8	Entwickler brauchen maximale Tiefe: Code, Edge-Cases, Internals
Entscheider	L1	L0->L1, selten L2	HS >= 8 (am strengsten)	HS >= 10 (praktisch nie)	Entscheider brauchen Überblick + Kerndetails. Mehr Tiefe = Zeitverschwendung
Custom	L2 (anpassbar)	Vom User definiert	HS >= 7	HS >= 9	User kann Max-Level bei der Weichenstellung überschreiben

Tiefenprofil-Logik:

FUER JEDE Zielgruppe Z:
  max_level = Tiefenprofil[Z].default_max_level
  hs_schwelle = Tiefenprofil[Z].hs_schwelle_eigene_seite
  hs_tiefer = Tiefenprofil[Z].hs_schwelle_noch_tiefer

  FUER JEDES Thema T auf Level L:
    WENN L >= max_level -> STOPP (kein tieferes Level für diese Zielgruppe)
    WENN HS(T, Z) < hs_schwelle -> Inhalt bleibt auf Eltern-Seite
    WENN HS(T, Z) >= hs_schwelle UND HS(T, Z) < hs_tiefer -> Eigene Seite, aber KEIN noch tieferes Level
    WENN HS(T, Z) >= hs_tiefer UND L < max_level -> Eigene Seite + prüfe nächstes Level

Beispiel-Ergebnis für 3 Zielgruppen, Thema "Authentifizierung":

                        Anwender       Entwickler       Entscheider
L0 (Überblick)         Modul          Modul            Modul
L1 (Themendetail)       HS=7           HS=9             HS=8
L2 (Sub-Themen)         HS=5 <7        HS=9             === MAX L1 ===
L3 (Tiefendetail)       === MAX L2 === HS=8             === MAX L1 ===

-> Anwender:    3 Dateien (L0-Modul + L1 DE/EN)
-> Entwickler:  7 Dateien (L0-Modul + L1 + L2 + L3, je DE/EN)
-> Entscheider: 3 Dateien (L0-Modul + L1 DE/EN)

Tiefenprofil-Überschreibung durch User:

Der User kann bei der Weichenstellung das Tiefenprofil überschreiben:

• "Für Entscheider, aber mit voller Tiefe" -> Max-Level wird auf L3 hochgesetzt
• "Für Entwickler, nur Überblick" -> Max-Level wird auf L1 runtergesetzt
• "Für Anwender bis L3" -> Max-Level wird auf L3 hochgesetzt

Die Überschreibung wird in der Tiefenkarte dokumentiert.

Dateistruktur & Naming-Konvention

output-verzeichnis/
+-- index_de.html                     <- L0 Überblick (Anwender oder allgemeinste Zielgruppe)
+-- index_en.html
+-- index_dev_de.html                 <- L0 Überblick (Entwickler)
+-- index_dev_en.html
+-- l1/
|   +-- authentifizierung_de.html     <- L1 Themendetail
|   +-- authentication_en.html
|   +-- authentifizierung_dev_de.html
|   +-- authentication_dev_en.html
|   +-- datenfluss_de.html
|   +-- dataflow_en.html
|   +-- ... (max 10 Themen x Zielgruppen x 2 Sprachen)
+-- l2/
|   +-- oauth-flow_de.html            <- L2 Sub-Thema
|   +-- oauth-flow_en.html
|   +-- oauth-flow_dev_de.html
|   +-- oauth-flow_dev_en.html
|   +-- ... (max 10 pro L1 x Zielgruppen x 2 Sprachen)
+-- l3/
    +-- token-refresh-mechanik_de.html <- L3 Tiefendetail
    +-- token-refresh-mechanics_en.html
    +-- ... (max 10 pro L2 x Zielgruppen x 2 Sprachen)

Naming-Regeln:

Sprache	Slug-Sprache	Beispiel
DE-Datei	Deutscher Slug	authentifizierung_de.html
EN-Datei	Englischer Slug	authentication_en.html
Zielgruppen-Suffix	Vor Sprach-Suffix	authentication_dev_en.html

Slug-Generierung:

• Lowercase, keine Umlaute (ae->ae, oe->oe, ue->ue, ss->ss)
• Bindestriche statt Leerzeichen
• Max 40 Zeichen
• Keine Stoppwörter (der, die, das, the, a, an)

---

HELPFULNESS-SCORING -- Autonome Tiefenentscheidung

KERNPRINZIP: Nicht jedes Thema verdient 3 weitere Ebenen. Der Skill bewertet AUTONOM, ob eine tiefere Seite dem Lernenden WIRKLICH hilft.

Helpfulness-Score (HS) -- Skala 1-10

Für JEDES potenzielle Unter-Thema wird ein Score berechnet:

HS = Komplexitaet(0-3) + Relevanz(0-3) + Lernwert(0-2) + Eigenstaendigkeit(0-2)

Dimension	0	1	2	3
Komplexitaet	Trivial, in 1 Satz erklärt	Braucht 1 Absatz	Braucht mehrere Abschnitte	Braucht eigene Seite mit Visuals
Relevanz	Nischen-Detail	Nice-to-know	Wichtig für Verständnis	Kern-Konzept, ohne das nichts geht
Lernwert	Nur Fakten-Auflistung	Erklärt ein "Warum"	Ermöglicht eigenes Handeln	Veraendert das Gesamtverständnis
Eigenstaendigkeit	Wiederholung von Eltern-Seite	50% neue Information	80% neue Information	Komplett eigenstaendiges Thema

Schwellenwerte -- Zielgruppenspezifisch

Die Schwellenwerte sind NICHT für alle Zielgruppen gleich. Jede Zielgruppe hat eigene Schwellen aus ihrem Tiefenprofil:

Score-Bereich	Anwender (streng)	Entwickler (Standard)	Entscheider (am strengsten)
1-4	Absatz auf Eltern-Seite	Absatz auf Eltern-Seite	Absatz auf Eltern-Seite
5-6	Erweiterter Absatz / Aufklapp	Eigene Seite	Erweiterter Absatz / Aufklapp
7-8	Eigene Seite (kein tieferes Level)	Eigene Seite + prüfe L+1	Eigene Seite (kein tieferes Level)
9-10	Eigene Seite + prüfe L+1 (bis Max-Level)	Eigene Seite + L+1 empfohlen	Eigene Seite + prüfe L+1 (bis Max-Level)

Zusaetzlicher Hard-Stop: Unabhängig vom HS wird KEIN Level jenseits des Max-Levels der Zielgruppe erzeugt.

Entscheidungsbaum pro Thema T, Zielgruppe Z, Level L:

  1. L >= max_level[Z]?           -> STOPP. Kein tieferes Level.
  2. HS(T,Z) < hs_schwelle[Z]?    -> Kein eigene Seite. Absatz/Aufklapp auf Eltern.
  3. HS(T,Z) >= hs_schwelle[Z]?   -> Eigene Seite erstellen.
  4. HS(T,Z) >= hs_tiefer[Z]      -> Prüfe ob L+1 < max_level[Z]. Wenn ja: L+1 planen.
     UND L+1 < max_level[Z]?

Zielgruppen-Gewichtung

Der HS wird PRO ZIELGRUPPE berechnet -- ein Thema kann für Entwickler HS=9 haben und für Entscheider HS=2:

Thema-Typ	Anwender HS-Tendenz	Entwickler HS-Tendenz	Entscheider HS-Tendenz
Implementierungsdetail	1-3 (irrelevant)	7-10 (Kern!)	1-3 (irrelevant)
UI-Workflow	7-10 (Kern!)	3-5 (nice-to-know)	2-4 (nice-to-know)
Kosten/ROI	2-4 (nice-to-know)	1-3 (irrelevant)	8-10 (Kern!)
Fehlerbehandlung	6-8 (Troubleshooting!)	8-10 (Kern!)	3-5 (Risiko-relevant)
Architektur-Entscheidung	1-3 (irrelevant)	7-9 (wichtig)	6-8 (strategisch!)
Sicherheit/Compliance	3-5 (was muss ich tun?)	7-9 (wie umgesetzt?)	8-10 (Pflicht!)

Transparenz-Regel

Am Ende jeder Generierung wird eine Tiefenkarte als Markdown-Tabelle ausgegeben, die zeigt:

• Das Tiefenprofil jeder Zielgruppe (Max-Level + HS-Schwellen)
• Welche Themen welchen HS bekommen haben
• Welche Seiten erstellt wurden und welche nicht
• Warum ein Thema NICHT tief genug für eine eigene Seite war
• Ob der Hard-Stop (Max-Level) oder der HS-Score die Grenze war

## Tiefenkarte -- Generierte Dateien

### Aktive Tiefenprofile
| Zielgruppe | Max-Level | HS-Schwelle (eigene Seite) | HS-Schwelle (noch tiefer) | Überschrieben? |
|---|---|---|---|---|
| Entwickler | L3 | >= 6 | >= 8 | Nein (Default) |
| Anwender | L2 | >= 7 | >= 9 | Nein (Default) |
| Entscheider | L1 | >= 8 | >= 10 | Nein (Default) |

### Detail-Tabelle
| Thema | Zielgruppe | HS | Level | Datei | Stopp-Grund |
|-------|------------|-----|-------|-------|-------------|
| Authentifizierung | Dev | 9 | L1->L2->L3 | 3 Dateien | L3 = Max-Level erreicht |
| Authentifizierung | User | 7 | L1 nur | 1 Datei | HS=7 < 9 (Schwelle "noch tiefer") |
| Authentifizierung | Exec | 8 | L1 nur | 1 Datei | L1 = Max-Level erreicht |
| Logging | Dev | 4 | -- | Absatz auf L1 | HS=4 < 6 (unter Schwelle) |
| UI-Theme | User | 9 | L1->L2 | 2 Dateien | L2 = Max-Level erreicht |
| UI-Theme | Exec | 3 | -- | Absatz auf L0 | HS=3 < 8 (unter Schwelle) |

Knowledge-Graph-gestuetztes Scoring (Kombiniert-Modus)

Wenn ein Knowledge Graph aus dem Verstehen-Modus existiert, wird das HS-Scoring mit KG-Daten angereichert:

HS-Dimension	KG-Datenanreicherung	Auswirkung
Komplexitaet	Node complexity Rating aus dem KG (simple/moderate/complex)	complex Nodes -> Komplexitaet +1 Bonus, simple Nodes -> -1
Relevanz	Fan-in/Fan-out Daten (Anzahl eingehender/ausgehender Edges)	Nodes mit >5 Fan-in -> Relevanz +1 (hochvernetzte Kern-Komponenten)
Lernwert	Layer-Zuordnung aus dem KG	Core-Layer Nodes -> Lernwert +1 gegenüber Utility-Layer Nodes
Eigenstaendigkeit	Edge-Dichte (Anzahl Cross-Referenzen zu anderen Nodes)	Nodes mit vielen ausgehenden Edges für Entwickler -> hoehere Eigenstaendigkeit

KG-gestuetztes Scoring-Verfahren:

FUER JEDES Thema T, basierend auf KG-Node N:
  base_HS = Komplexitaet(0-3) + Relevanz(0-3) + Lernwert(0-2) + Eigenstaendigkeit(0-2)
  
  kg_bonus = 0
  WENN N.complexity == "complex": kg_bonus += 1
  WENN fan_in(N) > 5: kg_bonus += 1
  WENN N in core_layer: kg_bonus += 1
  WENN edge_count(N) > 8 UND Zielgruppe == Entwickler: kg_bonus += 1
  
  final_HS = min(10, base_HS + kg_bonus)

Vorteile des KG-gestuetzten Scorings:

• Objektivere Bewertung: Basiert auf tatsaechlichen Code-Metriken statt nur auf Heuristiken
• Bessere Vernetzungs-Erkennung: Fan-in/Fan-out zeigt echte Abhängigkeiten
• Konsistentere Ergebnisse: KG-Daten sind reproduzierbar

---

ORCHESTRATOR -- Modi-übergreifende Phasensteuerung

Kurs-Modus (Learning-Skill Pipeline)

Phase 0: BOOTSTRAP -> Weichen klaeren
Phase 1: ANALYSE -> Codebase verstehen
Phase 2: CURRICULUM -> Modulstruktur + Tiefenkarte
Phase 3: FOUNDATION -> CSS/JS Design-System
Phase 4: BUILD -> Zielgruppen-Pipelines (parallel)
Phase 5: POLISH -> Cross-Level-Navigation
Phase 6: TIEFENKARTE -> Transparenz-Report

Verstehen-Modus (Verstehen-Pipeline)

Phase 0: PRE-FLIGHT -> Git-Status, Config
Phase 1: SCAN -> Projekt-Dateien entdecken (project-scanner Agent)
Phase 2: ANALYZE -> Strukturdaten extrahieren (file-analyzer Agents, 5 parallel)
Phase 3: ASSEMBLE REVIEW -> Graph zusammenbauen + validieren
Phase 4: ARCHITECTURE -> Layer-Analyse (architecture-analyzer Agent)
Phase 5: TOUR -> Lernpfade erstellen (tour-builder Agent)
Phase 6: REVIEW -> Graph validieren
Phase 7: SAVE -> knowledge-graph.json speichern
-> Auto-Launch Dashboard

Kombiniert-Modus (BEST OF BOTH)

=== PHASE A: VERSTEHEN ===
Phase A0-A7: Vollstaendige Verstehen-Pipeline
-> Erzeugt knowledge-graph.json + Dashboard

=== PHASE B: LEHREN ===
Phase B0: BOOTSTRAP (Weichen klaeren -- Zielgruppen + Integration)
Phase B1: KG-GESTUETZTE ANALYSE (nutzt Knowledge Graph statt roher Code-Analyse)
Phase B2: KG-GESTUETZTES CURRICULUM (HS-Scoring nutzt KG-Daten)
Phase B3-B6: Identisch mit Kurs-Modus
-> Erzeugt HTML-Kurs-Dateien

Orchestrator-Regeln

0. WEICHEN KLAEREN vor Phase 1 -- HARD BLOCK -- Zielgruppen (wer ALLE?) UND Integrationsmodus (Standalone/Eingebettet) muessen VOM USER EXPLIZIT BEANTWORTET sein. NICHT aus dem Kontext ableiten. NICHT stillschweigend annehmen. NICHT "für einen Test" überspringen. KEINE AUSNAHME. Wenn der User sagt "leg los" ohne die Fragen beantwortet zu haben -> Rückfrage stellen, NICHT losbauen. Siehe: "UNUMGEHBARE VORBEDINGUNG" am Anfang des Skills.
1. Kein Curriculum-Review durch den User -- Direkt bauen.
2. Ausführungsmodus -- Sequenziell ODER Parallel:
   • Sequenziell (Default / Chat-Kontext): Eine Zielgruppe nach der anderen, jeweils L0->L1->...->max_level.
   • Parallel (Claude Code mit Agent-Tool): Jede Zielgruppe bekommt eine eigene Pipeline als Subagent. Alle Pipelines laufen gleichzeitig. Siehe Abschnitt "PARALLELISIERUNGS-STRATEGIE".
   • In beiden Modi gilt: Qualitaetsgates pro Seite einhalten, Helpfulness-Score VOR dem Bauen.
3. Zielgruppen-Pipelines sind unabhängig -- Die Pipeline von Anwender wartet NICHT auf die Pipeline von Entwickler. Jede Zielgruppe hat ihren eigenen Tiefenpfad. Die EINZIGE Cross-Zielgruppen-Abhängigkeit ist der Zielgruppen-Switch auf L0 -- dieser wird in Phase 5 (Polish) nachtraeglich verlinkt.
4. Level-Reihenfolge INNERHALB einer Pipeline -- Pro Zielgruppe gilt: L0 -> L1 -> L2 -> L3. Nie L2 bauen bevor L1 dieser Zielgruppe fertig ist. Aber: Dev-L2 darf parallel zu User-L1 gebaut werden, da verschiedene Pipelines.
5. Bedarfsgerechte Tiefe -- Pipeline endet am Max-Level -- Jede Pipeline baut NUR die Levels die laut Tiefenprofil noetig sind:
   • Entscheider-Pipeline: L0 -> L1 -> STOPP (Max-Level L1)
   • Anwender-Pipeline: L0 -> L1 -> L2 -> STOPP (Max-Level L2)
   • Entwickler-Pipeline: L0 -> L1 -> L2 -> L3 -> STOPP (Max-Level L3)
   • Es werden KEINE leeren Levels erzeugt. Wenn eine ZG kein L2 braucht, wird kein L2-Ordner für sie angelegt.
6. Tiefenprofil-Check VOR dem Bauen -- Vor JEDER Seite zwei Prüfungen:
   • (a) Liegt das Level innerhalb des max_level der Zielgruppe? Wenn nein -> Pipeline-STOPP für dieses Level.
   • (b) Ist der HS >= der zielgruppenspezifischen Schwelle? Wenn nein -> Absatz/Aufklapp auf Eltern-Seite.
7. Max 10 Themen pro Ebene -- Wenn mehr als 10 Kandidaten existieren: nach HS sortieren, Top 10 nehmen, Rest als Absatz auf Eltern-Seite einarbeiten.
8. Deep-Dive-Links nur wenn Ziel existiert -- Ein Deep-Dive-Link auf L+1 wird NUR eingefügt, wenn das Tiefenprofil der Zielgruppe L+1 erlaubt UND der HS des Ziel-Themas die Schwelle erreicht. Kein "Deep Dive ->" ins Nichts.
9. Qualitaetsgates pro Seite (alle Level):
   • Mindestens 1 interaktives Element
   • Maximal 2-3 Sätze pro Textblock
   • Mindestens 50% visuelle Elemente pro Screen
   • Alle Fachbegriffe mit Tooltip versehen
   • Entwickler: Mindestens 1 Code<->Klartext-Übersetzungsblock pro Seite
   • Anwender: Mindestens 1 Workflow-Flow oder UI-Walkthrough pro Seite
   • Entscheider: Mindestens 1 KPI/Impact-Darstellung pro Seite
   • Zielgruppen-Switch: Auf ALLEN L0-Seiten vorhanden (wenn >1 Zielgruppe), verlinkt korrekt auf gleiche Sprache
   • Navigation: Breadcrumbs korrekt, Deep-Dive-Links funktional, Zurück-Links vorhanden
   • L1-L3 Hero: Page-Overview mit Abschnittsliste vorhanden (NICHT nur Titel + Zurück-Link!)
   • L1-L3 Module: Jede Sektion hat grosse gefadete Modulnummer (01, 02, ...) -- KEINE nackten <section>-Tags
   • L1-L3 Struktur: Identische CSS-Klassen wie L0 (.module, .module-content, .module-header, .module-number, .module-title, .module-body, .screen)
   • min-height: ALLE Module auf ALLEN Levels haben min-height: 100dvh
10. Fehler-Checkliste vor Abschluss:

• Pipeline-Vollstaendigkeit -- Jede ZG-Pipeline hat ALLE geplanten Levels erzeugt (und NUR diese)
• Bedarfsgerechte Tiefe -- Entscheider hat KEIN L2/L3, Anwender hat KEIN L3, Entwickler hat volle Tiefe bis L3
• Zielgruppen-Trennung -- Jede Zielgruppe hat eigene Dateien, kein Mischmasch
• Zielgruppen-Switch auf L0 -- Erst in Phase 5 verlinkt, zeigt auf ALLE anderen ZG-L0-Seiten (gleiche Sprache)
• Keine Cross-ZG-Abhängigkeiten im Build -- Keine Pipeline wartet auf eine andere Pipeline
• Integrationsmodus korrekt -- Standalone: kein Footer. Eingebettet: alle Links vorhanden
• Beide Sprachversionen -- DE + EN für JEDE Zielgruppe UND JEDES erzeugte Level
• Cross-Level-Links -- Alle Deep-Dive-Links zeigen auf existierende Dateien DIESER Zielgruppe
• Breadcrumbs korrekt -- Jede Seite hat vollstaendigen Pfad zurück zu L0 DIESER Zielgruppe
• Max 10 pro Ebene -- Keine Ebene hat mehr als 10 Kinder
• HS-Schwelle zielgruppenspezifisch -- Für jede ZG die EIGENE Schwelle geprüft (Anwender>=7, Entwickler>=6, Entscheider>=8), NICHT pauschal >=6
• Keine toten Deep-Dive-Links -- Kein Deep-Dive-Link zeigt auf ein Level das für diese ZG nicht existiert
• Tiefenkarte generiert -- User sieht Tiefenprofile + was pro Pipeline erstellt wurde und warum
• Tooltip-Clipping geprüft (position: fixed, body-append)
• Genug Tooltips (jeder Fachbegriff)
• Keine Textwaende (max 3 Sätze am Stueck)
• Keine recycelten Metaphern
• Code unveraendert aus der echten Codebase
• Quiz testet Anwendung, nicht Auswendiglernen
• scroll-snap-type: y proximity (NICHT mandatory)
• Jede Seite hat interaktive Elemente
• Farbraum korrekt -- Tiefenblau/Impuls-Orange/Warmgrau durchgaengig
• Ordnerstruktur korrekt -- l1/, l2/, l3/ Ordner existieren (nur wenn mindestens 1 ZG dieses Level hat)
• L1-L3 Hero nicht leer -- Jeder Hero auf L1-L3 enthält Page-Overview mit klickbaren Abschnittslinks
• L1-L3 Modulnummern -- Jede Inhaltssektion hat grosse gefadete Modulnummer (01, 02, ...)
• L1-L3 CSS-Klassen -- Identisch zu L0: .module, .module-content, .module-header, .module-number
• L1-L3 min-height -- Alle Module haben min-height: 100dvh für konsistentes Scroll-Snap

---

PARALLELISIERUNGS-STRATEGIE -- Zielgruppen-Pipeline-Architektur

Wann aktivieren: Wenn Claude Code verwendet wird UND das Agent-Tool verfügbar ist. Im normalen Chat-Kontext (kein Agent-Tool) wird sequenziell gearbeitet (eine ZG nach der anderen).

Kernprinzip: Jede Zielgruppe ist eine unabhängige Pipeline. Pipelines laufen parallel. Innerhalb einer Pipeline: Levels sequenziell, Themen+Sprachen parallel.

Architektur-Übersicht

Phase 0-3: SEQUENZIELL (alle ZG gemeinsam)
  Bootstrap -> Analyse -> Curriculum -> Foundation
  |
Phase 4: ZIELGRUPPEN-PIPELINES (PARALLEL)
  +----------------------------------------------------------+
  |                                                          |
  |  Pipeline Anwender --> L0 --> L1(HS>=7) --> L2(HS>=9) --> DONE |
  |       ||                                                 |
  |  Pipeline Entwickler --> L0 --> L1(HS>=6) --> L2(HS>=8) --> L3 --> DONE |
  |       ||                                                 |
  |  Pipeline Entscheider --> L0 --> L1(HS>=8) --> DONE       |
  |                                                          |
  +----------------------------------------------------------+
  | (Alle Pipelines fertig)
Phase 5-6: SEQUENZIELL (Cross-ZG-Verlinkung + Tiefenkarte)

Was parallelisiert werden KANN

Ebene	Parallelisierbar	Warum
Phase 0-3 (gemeinsam)	NEIN	Sequenziell -- jede Phase braucht das Ergebnis der vorherigen
Zielgruppen-Pipelines untereinander	JA	Anwender-Pipeline und Entwickler-Pipeline sind KOMPLETT unabhängig -- verschiedene Inhalte, Tiefen, Dateien
Levels INNERHALB einer Pipeline	NEIN	L1 braucht fertiges L0 (für Deep-Dive-Link-Ziele, Breadcrumbs)
Themen INNERHALB eines Levels einer Pipeline	JA	l1/auth_dev_de.html und l1/datenfluss_dev_de.html sind unabhängig
DE + EN des gleichen Themas	JA	l1/auth_dev_de.html und l1/authentication_dev_en.html können parallel entstehen
Phase 5-6 (Polish + Tiefenkarte)	NEIN	Braucht ALLE Pipelines fertig um Cross-ZG-Links zu setzen

Was NICHT parallelisiert werden darf

• Levels innerhalb einer Pipeline: L1 der Entwickler-Pipeline darf NICHT parallel zu L0 der Entwickler-Pipeline gebaut werden. L0 muss fertig sein bevor L1 startet -- sonst fehlen Deep-Dive-Link-Ziele und Breadcrumbs.
• Phase 3 -> Phase 4: Das CSS/JS-Foundation MUSS abgeschlossen sein bevor die erste Pipeline startet.
• Phase 5 (Polish): Erst wenn ALLE Pipelines komplett sind -- hier werden die Zielgruppen-Switches auf L0-Seiten verlinkt.
• ABER: Pipelines UNTEREINANDER sind frei! Dev-L2 darf parallel zu User-L0 gebaut werden, da verschiedene Pipelines.

Zwei-Ebenen-Subagent-Architektur

Ebene 1: Pipeline-Agents (1 pro Zielgruppe)

Jede Zielgruppe bekommt einen Pipeline-Agent, der den kompletten Tiefenpfad dieser Zielgruppe steuert. Der Pipeline-Agent:

• Kennt das Tiefenprofil seiner ZG (Max-Level, HS-Schwellen)
• Baut Level für Level sequenziell: L0 -> L1 -> ... -> Max-Level
• Startet pro Level Unter-Agents für einzelne Dateien (Ebene 2)
• Stoppt automatisch am Max-Level seiner ZG
• Gibt am Ende eine Pipeline-Zusammenfassung zurück

Ebene 2: Datei-Agents (N pro Level)

Innerhalb eines Levels kann der Pipeline-Agent Datei-Agents parallel starten:

• Jeder Datei-Agent erstellt EINE HTML-Datei (1 Thema x 1 Sprache)
• Alle Datei-Agents eines Levels laufen parallel
• Der Pipeline-Agent WARTET bis alle Datei-Agents eines Levels fertig sind, bevor das nächste Level beginnt

Pipeline-Agent-Prompt-Template:

Du bist der Pipeline-Agent für die Zielgruppe [EMOJI + NAME].

Tiefenprofil:
- Max-Level: [L1/L2/L3]
- HS-Schwelle eigene Seite: [>=6/>=7/>=8]
- HS-Schwelle noch tiefer: [>=8/>=9/>=10]

Integrationsmodus: [Standalone/Eingebettet]
Output-Verzeichnis: [PFAD]

Curriculum für deine Zielgruppe:
[THEMEN-BAUM MIT HS-SCORES NUR FUER DIESE ZG]

CSS/JS-Foundation: [REFERENZ AUF PHASE-3-OUTPUT]

Naming-Konvention:
- L0: index[_SUFFIX]_[de|en].html
- L1: l1/[slug][_SUFFIX]_[de|en].html
- L2: l2/[slug][_SUFFIX]_[de|en].html
- L3: l3/[slug][_SUFFIX]_[de|en].html

Deine Aufgabe:
1. Baue L0 (DE + EN parallel als Datei-Agents)
2. WARTE bis L0 fertig
3. Baue L1 -- NUR Themen mit HS >= [SCHWELLE] (alle Themen x DE+EN parallel)
4. WARTE bis L1 fertig
5. [Wenn Max-Level >= L2:] Baue L2 -- NUR Themen mit HS >= [SCHWELLE_TIEFER]
6. WARTE bis L2 fertig
7. [Wenn Max-Level = L3:] Baue L3 -- NUR Themen mit HS >= [SCHWELLE_TIEFER]
8. Gib Pipeline-Zusammenfassung zurück: erzeugte Dateien, übersprungene Themen, Stopp-Gründe

WICHTIG: Zielgruppen-Switch-Links auf L0 LEER lassen (werden in Phase 5 gesetzt).
Qualitaetsgates: [ALLE RELEVANTEN GATES FUER DIESE ZG]

Datei-Agent-Prompt-Template:

Erstelle die HTML-Datei [DATEINAME] im Verzeichnis [PFAD].

Kontext:
- Zielgruppe: [EMOJI + NAME]
- Sprache: [DE/EN]
- Level: [L0/L1/L2/L3]
- Thema: [THEMA]
- Integrationsmodus: [Standalone/Eingebettet]
- Helpfulness-Score: [SCORE]

Inhalt: [INHALTSBESCHREIBUNG AUS CURRICULUM]

CSS/JS: Verwende exakt das folgende Foundation: [FOUNDATION EINFUEGEN ODER REFERENZ]

Verlinkung:
- Breadcrumb-Pfad: [PFAD]
- Deep-Dive-Links: [LISTE DER ZIEL-DATEIEN DIESER ZG]
- Sibling-Seiten: [LISTE INNERHALB DIESER ZG]
- Sprach-Pendant: [DATEINAME]
- Zielgruppen-Switch (nur L0): PLATZHALTER (wird in Phase 5 befuellt)

Qualitaetsgates: [ALLE RELEVANTEN GATES]

Empfohlene Ausführungsreihenfolge

PRAXIS-MODUS (EMPFOHLEN -- zuverlaessig):

Die Dateierzeugung erfolgt sequenziell, eine Datei nach der anderen. Das ist langsamer aber zuverlaessig. Die Pipeline-Logik bestimmt trotzdem die REIHENFOLGE und TIEFE:

Schritt 1: Phase 0-3 sequenziell (Bootstrap -> Analyse -> Curriculum -> Foundation)
           -> Ergebnis: 1 Curriculum pro ZG + 1 Shared Foundation

Schritt 2: Kuerzeste Pipeline ZUERST abarbeiten
           Entscheider-Pipeline: L0(DE) -> L0(EN) -> L1(DE) -> L1(EN) -> DONE
           Anwender-Pipeline: L0(DE) -> L0(EN) -> L1(DE,EN...) -> L2(DE,EN...) -> DONE
           Entwickler-Pipeline: L0(DE) -> L0(EN) -> L1(DE,EN...) -> L2(DE,EN...) -> L3(DE,EN...) -> DONE

Schritt 3: Phase 5 -- Polish (alle Dateien fertig)
           -> Zielgruppen-Switch auf L0-Seiten verlinken
           -> Cross-Links verifizieren

Schritt 4: Phase 6 -- Tiefenkarte ausgeben

PARALLEL-MODUS (OPTIONAL -- nur wenn Agent-Tool zuverlaessig):

Wenn Subagents gewuenscht sind, maximal 2 parallele Agents gleichzeitig (nicht mehr!). Bevorzugt: DE + EN des gleichen Themas parallel. NICHT ganze Pipelines parallel starten -- das überfordert das System.

Parallelisierung nur auf Datei-Ebene:
  Agent A: auth_dev_de.html  ||  Agent B: authentication_dev_en.html
  -> Warten -> nächstes Paar

Effizienz durch bedarfsgerechte Tiefe (unabhängig vom Modus):

Dateizahl-Vergleich:
  Pauschal L0-L3 für alle: ~100+ Dateien
  Bedarfsgerecht:
    Entscheider: ~8 Dateien (nur L0+L1)
    Anwender: ~12 Dateien (L0+L1+L2)
    Entwickler: ~32 Dateien (L0+L1+L2+L3)
  = ~52 Dateien total -> ~48% weniger

Fehlerbehandlung

• Datei-Erzeugung schlägt fehl: NUR diese Datei neu generieren.
• Cross-ZG-Links: Werden erst in Phase 5 gesetzt -- funktioniert unabhängig von der Erzeugungsreihenfolge.
• Bei Problemen: Auf rein sequenziellen Modus zurückfallen (1 Datei nach der anderen, kein Agent-Tool).

---

Phase 0: BOOTSTRAP (MODUS-ABHAENGIG)

Kurs-Modus & Kombiniert-Modus (Phase B0)

Begruessung (wenn keine Codebase angegeben)

Ich kann jede Codebase in einen interaktiven Multi-Level-Kurs verwandeln -- von der Vogelperspektive bis zum tiefsten Detail.

Zeig mir einfach ein Projekt:

• Lokaler Ordner -- z.B. "mach einen Kurs aus ./mein-projekt"
• GitHub-Link -- z.B. "erstelle einen Kurs aus https://github.com/user/repo"
• Das aktuelle Projekt -- sag einfach "mach daraus einen Kurs"

Ich erzeuge automatisch:

• Das Wichtigste auf einen Blick -- Was gibt es hier?
• Vertiefungsseiten -- Wie funktioniert das im Detail?
• Detailseiten -- Zeig mir die Mechanik
• Alles Schritt für Schritt -- Für maximale Tiefe

Jede Ebene als eigene HTML-Datei, sauber verlinkt, in DE + EN.

Quell-Erkennung

• GitHub-Link -> git clone <url> /tmp/<repo-name> ausführen
• Lokaler Ordner -> Pfad direkt verwenden
• "Dieses Projekt" -> Aktuelles Working Directory verwenden

Weichenstellungen VOR Phase 1

STOPP-REGEL (HARD BLOCK -- keine Ausnahme, auch nicht bei Tests!): Bevor Phase 1 (Analyse) beginnt, MUESSEN zwei Dinge VOM USER EXPLIZIT BEANTWORTET sein: Zielgruppen und Integrationsmodus. Sprache ist KEINE Frage -- es werden IMMER beide Versionen generiert. Auch wenn der User sagt "teste den Skill", "verprobe das mal", "mach einfach" oder "ist nur ein Prototyp" -- die Fragen werden gestellt. KEIN EINZIGES Byte HTML wird geschrieben bevor beide Antworten vorliegen.

Die Weichen im Überblick:

Weiche	Typ	Default wenn unklar
Zielgruppen	Multi-Select: für WEN ALLES?	KEIN Default -- MUSS gefragt werden
Integrationsmodus	Standalone / Eingebettet	KEIN Default -- MUSS gefragt werden
Sprache	DE + EN IMMER BEIDES	Automatisch -- KEINE Frage

---

Weiche 1: Zielgruppen (Multi-Select)

Nicht "für wen" sondern "für wen ALLES" -- der Skill generiert für JEDE genannte Zielgruppe einen eigenen Kurs (x2 wegen DE+EN, x4 Level). Deshalb muss der User ALLE Zielgruppen auf einmal nennen.

Vordefinierte Zielgruppen:

Kuerzel	Emoji	Wer	Kernfrage
(kein Suffix)	👥 Anwender	Anwender -- Nutzer, Kunden, Fachabteilung	"Was kann ich damit tun?"
_dev	👨‍💻 Entwickler	Entwickler -- Devs, QA, neue Teammitglieder	"Wie ist das gebaut?"
_exec	📊 Entscheider	Entscheider -- Manager, Stakeholder, C-Level	"Was muss ich wissen?"
Custom	✨ Custom	Beliebig -- User kann eigene Zielgruppen definieren	User definiert die Kernfrage

Dateibenennung:

Die allgemeinste / erste Zielgruppe bekommt index_de.html / index_en.html (ohne Suffix). Weitere Zielgruppen bekommen den Kuerzel als Suffix:

Beispiel: User sagt "für Anwender und Entwickler"
-> Anwender = allgemeinste -> index_de.html / index_en.html
-> Entwickler              -> index_dev_de.html / index_dev_en.html

-> L1-Dateien:
  l1/authentifizierung_de.html        (Anwender)
  l1/authentication_en.html           (Anwender)
  l1/authentifizierung_dev_de.html    (Entwickler)
  l1/authentication_dev_en.html       (Entwickler)

Allgemeinste Zielgruppe bestimmen: Anwender > Entscheider > Entwickler > Custom. Wenn nur eine Zielgruppe -> die bekommt index_*. Wenn User die Reihenfolge explizit nennt -> seine Reihenfolge respektieren.

---

Weiche 2: Integrationsmodus

	STANDALONE	EINGEBETTET
Was	Dateien komplett eigenstaendig	Teil einer Website / Dokumentation
Typisch	Per E-Mail/Slack geteilt, lokal geoeffnet	Auf GitHub Pages, Firmen-Wiki, Doku-Site
Header	Kurstitel + Nav-Dots + Flaggen-Link + Level-Nav	+ Externe Links (GitHub, Doku, Home) + Buttons
Footer	Keiner noetig	Impressum, Datenschutz, Copyright

---

KEIN Weiche: Sprache -- IMMER BEIDES

ES WIRD NICHT GEFRAGT. Jeder Kurs wird IMMER in Deutsch UND Englisch generiert.

Sprachversions-Verlinkung:

Jede Datei enthält in der Nav-Bar einen Flaggen-Link zur jeweils anderen Sprachversion:

<!-- In der DE-Version (l1/authentifizierung_de.html): -->
<a href="authentication_en.html" class="nav-lang" title="English version">🇬🇧</a>

<!-- In der EN-Version (l1/authentication_en.html): -->
<a href="authentifizierung_de.html" class="nav-lang" title="Deutsche Version">🇩🇪</a>

WICHTIG: Sprachlinks verweisen immer auf die Datei IM GLEICHEN Ordner (relatives Linking innerhalb l1/, l2/, l3/).

---

Die Rückfrage (IMMER -- es sei denn der User hat BEIDES bereits explizit beantwortet)

Die Rückfrage ist der DEFAULT. Sie wird IMMER gestellt, es sei denn der User hat in seiner Nachricht BEIDE Weichen EXPLIZIT beantwortet. "Nicht eindeutig" ist der Normalfall -- nicht die Ausnahme. Sprache wird NIE gefragt.

Wann ist "explizit beantwortet"?

• "Für Entwickler und Anwender, standalone" -> Beides klar, KEINE Rückfrage noetig
• "Für Devs, eingebettet auf unserer GitHub Page, Impressum: example.com/impressum" -> Beides klar
• "Mach einen Kurs aus diesem Repo" -> BEIDES unklar -> Rückfrage!
• "Für Entwickler" -> Zielgruppe klar, Integration UNKLAR -> Rückfrage!
• "Standalone bitte" -> Integration klar, Zielgruppe UNKLAR -> Rückfrage!
• "Verprobe den Skill an sich selbst" -> BEIDES unklar -> Rückfrage!
• "Teste das mal" -> BEIDES unklar -> Rückfrage!

Bevor ich loslege, zwei Fragen:

1. Für wen ALLES soll der Kurs sein? (Mehrfachauswahl -- jede Gruppe bekommt einen eigenen Kurs mit bedarfsgerechter Tiefe, jeweils DE + EN)

• 👥 Anwender -- Leute die die App/das Produkt BENUTZEN wollen (Default: bis L2, Fokus auf Workflows)
• 👨‍💻 Entwickler -- Leute die den Code VERSTEHEN und AENDERN wollen (Default: bis L3, volle Tiefe)
• 📊 Entscheider -- Management, Stakeholder (Default: bis L1, kompakt + KPIs)
• ✨ Andere -- eigene Zielgruppe definieren (Default: bis L2, anpassbar)

Die Tiefe pro Zielgruppe wird automatisch bedarfsgerecht gesteuert. Falls du für eine Gruppe mehr oder weniger Tiefe willst, sag z.B. "Entscheider bis L2" oder "Anwender nur L0+L1".

2. Wie werden die Kurse genutzt?

• Standalone -- Dateien zum Teilen/Offline-Nutzen
• Eingebettet -- Teil einer Website (dann brauche ich: GitHub-Link? Impressum-URL? Copyright?)

(Sprache muss nicht gewählt werden -- es entstehen automatisch immer DE + EN Versionen.)

---

Verstehen-Modus: Phase 0 -- Pre-flight

Determine whether to run a full analysis or incremental update.

1. Set PROJECT_ROOT to