learning-skill

name	learning-skill
description	Kombiniert zwei Superkraefte: (1) Verwandelt Codebases in interaktive Multi-Level-HTML-Kurse (L0-L3) mit Zielgruppen-Segmentierung und Energiekonzern-Design, UND (2) erzeugt interaktive Knowledge Graphs mit Dashboard zur Code-Exploration. DREI MODI: "Kurs" für HTML-Kurse, "Verstehen" für Knowledge Graphs, "Kombiniert" für beides. Optimiert für Claude.

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 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 the current working directory.
2. Get the current git commit hash:

   git rev-parse HEAD
   

3. Create the intermediate and temp output directories:

   mkdir -p $PROJECT_ROOT/.claude-learning/intermediate
   mkdir -p $PROJECT_ROOT/.claude-learning/tmp
   

3.5. Auto-update configuration:

• If --auto-update is in $ARGUMENTS: write {"autoUpdate": true} to $PROJECT_ROOT/.claude-learning/config.json
• If --no-auto-update is in $ARGUMENTS: write {"autoUpdate": false} to $PROJECT_ROOT/.claude-learning/config.json
• These flags only set the config -- analysis proceeds normally regardless.

4. Check for subdomain knowledge graphs to merge: List all *knowledge-graph*.json files in $PROJECT_ROOT/.claude-learning/ excluding knowledge-graph.json itself (e.g. frontend-knowledge-graph.json, backend-knowledge-graph.json). If any subdomain graphs exist, run the merge script bundled with this skill:

   python <SKILL_DIR>/merge-subdomain-graphs.py $PROJECT_ROOT
   

   The script discovers subdomain graphs, loads the existing knowledge-graph.json as a base (if present), and merges everything into knowledge-graph.json (deduplicating nodes and edges). Report the merge summary to the user, then continue with the merged graph.

5. Check if $PROJECT_ROOT/.claude-learning/knowledge-graph.json exists. If it does, read it.

6. Check if $PROJECT_ROOT/.claude-learning/meta.json exists. If it does, read it to get gitCommitHash.

7. Decision logic:

   Condition	Action
   --full flag in $ARGUMENTS	Full analysis (all phases)
   No existing graph or meta	Full analysis (all phases)
   --review flag + existing graph + unchanged commit hash	Skip to Phase 6 (review-only -- reuse existing assembled graph)
   Existing graph + unchanged commit hash	Ask the user: "The graph is up to date at this commit. Would you like to: (a) run a full rebuild (--full), (b) run the LLM graph reviewer (--review), or (c) do nothing?" Then follow their choice. If they pick (c), STOP.
   Existing graph + changed files	Incremental update (re-analyze changed files only)

   Review-only path: Copy the existing knowledge-graph.json to $PROJECT_ROOT/.claude-learning/intermediate/assembled-graph.json, then jump directly to Phase 6 step 3.

   For incremental updates, get the changed file list:

   git diff <lastCommitHash>..HEAD --name-only
   

   If this returns no files, report "Graph is up to date" and STOP.

8. Collect project context for subagent injection:

   • Read README.md (or README.rst, readme.md) from $PROJECT_ROOT if it exists. Store as $README_CONTENT (first 3000 characters).
   • Read the primary package manifest (package.json, pyproject.toml, Cargo.toml, go.mod, pom.xml) if it exists. Store as $MANIFEST_CONTENT.
   • Capture the top-level directory tree:

     find $PROJECT_ROOT -maxdepth 2 -type f -not -path '*/node_modules/*' -not -path '*/.git/*' -not -path '*/dist/*' | head -100
     

     Store as $DIR_TREE.
   • Detect the project entry point by checking for common patterns (in order): src/index.ts, src/main.ts, src/App.tsx, index.js, main.py, manage.py, app.py, wsgi.py, asgi.py, run.py, __main__.py, main.go, cmd/*/main.go, src/main.rs, src/lib.rs, src/main/java/**/Application.java, Program.cs, config.ru, index.php. Store first match as $ENTRY_POINT.

---

VERSTEHEN-MODUS PHASEN (Knowledge Graph Pipeline)

Phase 1 -- SCAN (Full analysis only)

Dispatch a subagent using the project-scanner agent definition (at agents/project-scanner.md). Append the following additional context:

Additional context from main session:

Project README (first 3000 chars):

$README_CONTENT

Package manifest:

$MANIFEST_CONTENT

Use this context to produce more accurate project name, description, and framework detection. The README and manifest are authoritative -- prefer their information over heuristics.

Pass these parameters in the dispatch prompt:

Scan this project directory to discover all project files (including non-code files like configs, docs, infrastructure), detect languages and frameworks. Project root: $PROJECT_ROOT Write output to: $PROJECT_ROOT/.claude-learning/intermediate/scan-result.json

After the subagent completes, read $PROJECT_ROOT/.claude-learning/intermediate/scan-result.json to get:

• Project name, description
• Languages, frameworks
• File list with line counts and fileCategory per file (code, config, docs, infra, data, script, markup)
• Complexity estimate
• Import map (importMap): pre-resolved project-internal imports per file (non-code files have empty arrays)

Store importMap in memory as $IMPORT_MAP for use in Phase 2 batch construction. Store the file list as $FILE_LIST with fileCategory metadata for use in Phase 2 batch construction.

Gate check: If >100 files, inform the user and suggest scoping with a subdirectory argument. Proceed only if user confirms or add guidance that this may take a while.

---

Phase 2 -- ANALYZE

Full analysis path

Batch the file list from Phase 1 into groups of 20-30 files each (aim for ~25 files per batch for balanced sizes).

Batching strategy for non-code files:

• Group related non-code files together in the same batch when possible:
  • Dockerfile + docker-compose.yml + .dockerignore -> same batch
  • SQL migration files -> same batch (ordered by filename)
  • CI/CD config files (.github/workflows/*) -> same batch
  • Documentation files (docs/*.md) -> same batch
• This allows the file-analyzer to create cross-file edges (e.g., docker-compose depends_on Dockerfile)
• Non-code files can be mixed with code files in the same batch if batch sizes are small
• Each file's fileCategory from Phase 1 must be included in the batch file list

For each batch, dispatch a subagent using the file-analyzer agent definition (at agents/file-analyzer.md). Run up to 5 subagents concurrently using parallel dispatch. Append the following additional context:

Additional context from main session:

Project: <projectName> -- <projectDescription> Languages: <languages from Phase 1>

Before dispatching each batch, construct batchImportData from $IMPORT_MAP:

batchImportData = {}
for each file in this batch:
  batchImportData[file.path] = $IMPORT_MAP[file.path] ?? []

Fill in batch-specific parameters below and dispatch:

Analyze these files and produce GraphNode and GraphEdge objects. Project root: $PROJECT_ROOT Project: <projectName> Languages: <languages> Batch index: <batchIndex> Write output to: $PROJECT_ROOT/.claude-learning/intermediate/batch-<batchIndex>.json

Pre-resolved import data for this batch (use this for all import edge creation -- do NOT re-resolve imports from source):

<batchImportData JSON>

Files to analyze in this batch:

1. <path> ( lines, fileCategory: <fileCategory>)
2. <path> ( lines, fileCategory: <fileCategory>) ...

After ALL batches complete, run the merge-and-normalize script bundled with this skill:

python <SKILL_DIR>/merge-batch-graphs.py $PROJECT_ROOT

This script reads all batch-*.json files from $PROJECT_ROOT/.claude-learning/intermediate/, then in one pass:

• Combines all nodes and edges across batches
• Normalizes node IDs (strips double prefixes, project-name prefixes, adds missing prefixes)
• Normalizes complexity values (low->simple, medium->moderate, high->complex, etc.)
• Rewrites edge references to match corrected node IDs
• Deduplicates nodes by ID (keeps last occurrence) and edges by (source, target, type)
• Drops dangling edges referencing missing nodes
• Logs all corrections and dropped items to stderr

Output: $PROJECT_ROOT/.claude-learning/intermediate/assembled-graph.json

Include the script's warnings in $PHASE_WARNINGS for the reviewer.

Incremental update path

Use the changed files list from Phase 0. Batch and dispatch file-analyzer subagents using the same process as above (20-30 files per batch, up to 5 concurrent, with batchImportData constructed from $IMPORT_MAP), but only for changed files.

After batches complete:

1. Remove old nodes whose filePath matches any changed file from the existing graph
2. Remove old edges whose source or target references a removed node
3. Write the pruned existing nodes/edges as batch-existing.json in the intermediate directory
4. Run the same merge script -- it will combine batch-existing.json with the fresh batch-*.json files:

   python <SKILL_DIR>/merge-batch-graphs.py $PROJECT_ROOT
   

---

Phase 3 -- ASSEMBLE REVIEW

Dispatch a subagent using the assemble-reviewer agent definition (at agents/assemble-reviewer.md).

Pass these parameters in the dispatch prompt:

Review the assembled graph at $PROJECT_ROOT/.claude-learning/intermediate/assembled-graph.json. Project root: $PROJECT_ROOT Batch files are at: $PROJECT_ROOT/.claude-learning/intermediate/batch-*.json Write review output to: $PROJECT_ROOT/.claude-learning/intermediate/assemble-review.json

Merge script report:

<paste the full stderr output from merge-batch-graphs.py>

Import map for cross-batch edge verification:

$IMPORT_MAP

After the subagent completes, read $PROJECT_ROOT/.claude-learning/intermediate/assemble-review.json and add any notes to $PHASE_WARNINGS.

---

Phase 4 -- ARCHITECTURE

Build the combined prompt template:

1. Use the architecture-analyzer agent definition (at agents/architecture-analyzer.md).
2. Language context injection: For each language detected in Phase 1 (e.g., python, markdown, dockerfile, yaml, sql, terraform, graphql, protobuf, shell, html, css), read the file at ./languages/<language-id>.md (e.g., ./languages/python.md, ./languages/dockerfile.md) and append its content after the base template under a ## Language Context header. If the file does not exist for a detected language, skip it silently and continue. These files are in the languages/ subdirectory next to this SKILL.md file. Include non-code language snippets -- they provide edge patterns and summary styles for non-code files.
3. Framework addendum injection: For each framework detected in Phase 1 (e.g., Django), read the file at ./frameworks/<framework-id-lowercase>.md (e.g., ./frameworks/django.md) and append its full content after the language context. If the file does not exist for a detected framework, skip it silently and continue. These files are in the frameworks/ subdirectory next to this SKILL.md file.

Append the language/framework context and the following additional context to the agent's prompt:

Additional context from main session:

Frameworks detected: <frameworks from Phase 1>

Directory tree (top 2 levels):

$DIR_TREE

Use the directory tree, language context, and framework addendums (appended above) to inform layer assignments. Directory structure is strong evidence for layer boundaries. Non-code files (config, docs, infrastructure, data) should be assigned to appropriate layers -- see the prompt template for guidance.

Pass these parameters in the dispatch prompt:

Analyze this codebase's structure to identify architectural layers. Project root: $PROJECT_ROOT Write output to: $PROJECT_ROOT/.claude-learning/intermediate/layers.json Project: <projectName> -- <projectDescription>

File nodes (all node types -- includes code files, config, document, service, pipeline, table, schema, resource, endpoint):

[list of {id, type, name, filePath, summary, tags} for ALL file-level nodes -- omit complexity, languageNotes]

Import edges:

[list of edges with type "imports"]

All edges (for cross-category analysis -- includes configures, documents, deploys, triggers, etc.):

[list of ALL edges -- include all edge types]

After the subagent completes, read $PROJECT_ROOT/.claude-learning/intermediate/layers.json and normalize it into a final layers array. Apply these steps in order:

1. Unwrap envelope: If the file contains { "layers": [...] } instead of a plain array, extract the inner array.
2. Rename legacy fields: If any layer object has a nodes field instead of nodeIds, rename nodes -> nodeIds. If nodes entries are objects with an id field rather than plain strings, extract just the id values into nodeIds.
3. Synthesize missing IDs: If any layer is missing an id, generate one as layer:<kebab-case-name>.
4. Convert file paths: If nodeIds entries are raw file paths without a known prefix (file:, config:, document:, service:, pipeline:, table:, schema:, resource:, endpoint:), convert them to file:<relative-path>.
5. Drop dangling refs: Remove any nodeIds entries that do not exist in the merged node set.

Each element of the final layers array MUST have this shape:

[
  {
    "id": "layer:<kebab-case-name>",
    "name": "<layer name>",
    "description": "<what belongs in this layer>",
    "nodeIds": ["file:src/App.tsx", "config:tsconfig.json", "document:README.md"]
  }
]

All four fields (id, name, description, nodeIds) are required.

For incremental updates: Always re-run architecture analysis on the full merged node set, since layer assignments may shift when files change.

Context for incremental updates: When re-running architecture analysis, also inject the previous layer definitions:

Previous layer definitions (for naming consistency):

[previous layers from existing graph]

Maintain the same layer names and IDs where possible. Only add/remove layers if the file structure has materially changed.

---

Phase 5 -- TOUR

Dispatch a subagent using the tour-builder agent definition (at agents/tour-builder.md). Append the following additional context:

Additional context from main session:

Project README (first 3000 chars):

$README_CONTENT

Project entry point: $ENTRY_POINT

Use the README to align the tour narrative with the project's own documentation. Start the tour from the entry point if one was detected. The tour should tell the same story the README tells, but through the lens of actual code structure.

Pass these parameters in the dispatch prompt:

Create a guided learning tour for this codebase. Project root: $PROJECT_ROOT Write output to: $PROJECT_ROOT/.claude-learning/intermediate/tour.json Project: <projectName> -- <projectDescription> Languages: <languages>

Nodes (all file-level nodes -- includes code files, config, document, service, pipeline, table, schema, resource, endpoint):

[list of {id, name, filePath, summary, type} for ALL file-level nodes -- do NOT include function or class nodes]

Layers:

[list of {id, name, description} for each layer -- omit nodeIds]

Edges (all types -- includes imports, calls, configures, documents, deploys, triggers, etc.):

[list of ALL edges -- include all edge types for complete graph topology analysis]

After the subagent completes, read $PROJECT_ROOT/.claude-learning/intermediate/tour.json and normalize it into a final tour array. Apply these steps in order:

1. Unwrap envelope: If the file contains { "steps": [...] } instead of a plain array, extract the inner array.
2. Rename legacy fields: If any step has nodesToInspect instead of nodeIds, rename it -> nodeIds. If any step has whyItMatters instead of description, rename it -> description.
3. Convert file paths: If nodeIds entries are raw file paths without a known prefix (file:, config:, document:, service:, pipeline:, table:, schema:, resource:, endpoint:), convert them to file:<relative-path>.
4. Drop dangling refs: Remove any nodeIds entries that do not exist in the merged node set.
5. Sort by order before saving.

Each element of the final tour array MUST have this shape:

[
  {
    "order": 1,
    "title": "Project Overview",
    "description": "Start with the README to understand the project's purpose and architecture.",
    "nodeIds": ["document:README.md"]
  },
  {
    "order": 2,
    "title": "Application Entry Point",
    "description": "This step explains how the frontend boots and mounts.",
    "nodeIds": ["file:src/main.tsx", "file:src/App.tsx"]
  }
]

Required fields: order, title, description, nodeIds. Preserve optional languageLesson when present.

---

Phase 6 -- REVIEW

Assemble the full KnowledgeGraph JSON object:

{
  "version": "1.0.0",
  "project": {
    "name": "<projectName>",
    "languages": ["<languages>"],
    "frameworks": ["<frameworks>"],
    "description": "<projectDescription>",
    "analyzedAt": "<ISO 8601 timestamp>",
    "gitCommitHash": "<commit hash from Phase 0>"
  },
  "nodes": [<all nodes from assembled-graph.json after Phase 3 review>],
  "edges": [<all edges from assembled-graph.json after Phase 3 review>],
  "layers": [<layers from Phase 4>],
  "tour": [<steps from Phase 5>]
}

1. Before writing the assembled graph, validate that:

   • layers is an array of objects with these required fields: id, name, description, nodeIds
   • tour is an array of objects with these required fields: order, title, description, nodeIds
   • tour[*].languageLesson is allowed as an optional string field
   • Every layers[*].nodeIds entry exists in the merged node set
   • Every tour[*].nodeIds entry exists in the merged node set

   If validation fails, automatically normalize and rewrite the graph into this shape before saving. If the graph still fails final validation after the normalization pass, save it with warnings but mark dashboard auto-launch as skipped.

2. Write the assembled graph to $PROJECT_ROOT/.claude-learning/intermediate/assembled-graph.json.

3. Check $ARGUMENTS for --review flag. Then run the appropriate validation path:

---

Default path (no --review): inline deterministic validation

Write the following Node.js script to $PROJECT_ROOT/.claude-learning/tmp/ua-inline-validate.cjs:

#!/usr/bin/env node
const fs = require('fs');
const graphPath = process.argv[2];
const outputPath = process.argv[3];
try {
  const graph = JSON.parse(fs.readFileSync(graphPath, 'utf8'));
  const issues = [], warnings = [];
  if (!Array.isArray(graph.nodes)) { issues.push('graph.nodes is missing or not an array'); graph.nodes = []; }
  if (!Array.isArray(graph.edges)) { issues.push('graph.edges is missing or not an array'); graph.edges = []; }
  const nodeIds = new Set();
  const seen = new Map();
  graph.nodes.forEach((n, i) => {
    if (!n.id) { issues.push(`Node[${i}] missing id`); return; }
    if (!n.type) issues.push(`Node[${i}] '${n.id}' missing type`);
    if (!n.name) issues.push(`Node[${i}] '${n.id}' missing name`);
    if (!n.summary) issues.push(`Node[${i}] '${n.id}' missing summary`);
    if (!n.tags || !n.tags.length) issues.push(`Node[${i}] '${n.id}' missing tags`);
    if (seen.has(n.id)) issues.push(`Duplicate node ID '${n.id}' at indices ${seen.get(n.id)} and ${i}`);
    else seen.set(n.id, i);
    nodeIds.add(n.id);
  });
  graph.edges.forEach((e, i) => {
    if (!nodeIds.has(e.source)) issues.push(`Edge[${i}] source '${e.source}' not found`);
    if (!nodeIds.has(e.target)) issues.push(`Edge[${i}] target '${e.target}' not found`);
  });
  const fileLevelTypes = new Set(['file', 'config', 'document', 'service', 'pipeline', 'table', 'schema', 'resource', 'endpoint']);
  const fileNodes = graph.nodes.filter(n => fileLevelTypes.has(n.type)).map(n => n.id);
  const assigned = new Map();
  if (!Array.isArray(graph.layers)) { if (graph.layers) warnings.push('graph.layers is not an array'); graph.layers = []; }
  if (!Array.isArray(graph.tour)) { if (graph.tour) warnings.push('graph.tour is not an array'); graph.tour = []; }
  graph.layers.forEach(layer => {
    (layer.nodeIds || []).forEach(id => {
      if (!nodeIds.has(id)) issues.push(`Layer '${layer.id}' refs missing node '${id}'`);
      if (assigned.has(id)) issues.push(`Node '${id}' appears in multiple layers`);
      assigned.set(id, layer.id);
    });
  });
  fileNodes.forEach(id => {
    if (!assigned.has(id)) issues.push(`File node '${id}' not in any layer`);
  });
  graph.tour.forEach((step, i) => {
    (step.nodeIds || []).forEach(id => {
      if (!nodeIds.has(id)) issues.push(`Tour step[${i}] refs missing node '${id}'`);
    });
  });
  const withEdges = new Set([
    ...graph.edges.map(e => e.source),
    ...graph.edges.map(e => e.target)
  ]);
  graph.nodes.forEach(n => {
    if (!withEdges.has(n.id)) warnings.push(`Node '${n.id}' has no edges (orphan)`);
  });
  const stats = {
    totalNodes: graph.nodes.length,
    totalEdges: graph.edges.length,
    totalLayers: graph.layers.length,
    tourSteps: graph.tour.length,
    nodeTypes: graph.nodes.reduce((a, n) => { a[n.type] = (a[n.type]||0)+1; return a; }, {}),
    edgeTypes: graph.edges.reduce((a, e) => { a[e.type] = (a[e.type]||0)+1; return a; }, {})
  };
  fs.writeFileSync(outputPath, JSON.stringify({ issues, warnings, stats }, null, 2));
  process.exit(0);
} catch (err) { process.stderr.write(err.message + '\n'); process.exit(1); }

Execute it:

node $PROJECT_ROOT/.claude-learning/tmp/ua-inline-validate.cjs \
  "$PROJECT_ROOT/.claude-learning/intermediate/assembled-graph.json" \
  "$PROJECT_ROOT/.claude-learning/intermediate/review.json"

If the script exits non-zero, read stderr, fix the script, and retry once.

---

--review path: full LLM reviewer

If --review IS in $ARGUMENTS, dispatch the LLM graph-reviewer subagent as follows:

Dispatch a subagent using the graph-reviewer agent definition (at agents/graph-reviewer.md). Append the following additional context:

Additional context from main session:

Phase 1 scan results (file inventory):

[list of {path, sizeLines} from scan-result.json]

Phase warnings/errors accumulated during analysis:

• [list any batch failures, skipped files, or warnings from Phases 2-5]

Cross-validate: every file in the scan inventory should have a corresponding node in the graph (node types may vary: file:, config:, document:, service:, pipeline:, table:, schema:, resource:, endpoint:). Flag any missing files. Also flag any graph nodes whose filePath doesn't appear in the scan inventory.

Pass these parameters in the dispatch prompt:

Validate the knowledge graph at $PROJECT_ROOT/.claude-learning/intermediate/assembled-graph.json. Project root: $PROJECT_ROOT Read the file and validate it for completeness and correctness. Write output to: $PROJECT_ROOT/.claude-learning/intermediate/review.json

---

4. Read $PROJECT_ROOT/.claude-learning/intermediate/review.json.

5. If issues array is non-empty:

   • Review the issues list
   • Apply automated fixes where possible:
     • Remove edges with dangling references
     • Fill missing required fields with sensible defaults (e.g., empty tags -> ["untagged"], empty summary -> "No summary available")
     • Remove nodes with invalid types
   • Re-run the final graph validation after automated fixes
   • If critical issues remain after one fix attempt, save the graph anyway but include the warnings in the final report and mark dashboard auto-launch as skipped

6. If issues array is empty: Proceed to Phase 7.

---

Phase 7 -- SAVE

1. Write the final knowledge graph to $PROJECT_ROOT/.claude-learning/knowledge-graph.json.

2. Write metadata to $PROJECT_ROOT/.claude-learning/meta.json:

   {
     "lastAnalyzedAt": "<ISO 8601 timestamp>",
     "gitCommitHash": "<commit hash>",
     "version": "1.0.0",
     "analyzedFiles": <number of files analyzed>
   }
   

2.5. Generate structural fingerprints for all analyzed files and save to $PROJECT_ROOT/.claude-learning/fingerprints.json.

3. Clean up intermediate files:

   rm -rf $PROJECT_ROOT/.claude-learning/intermediate
   rm -rf $PROJECT_ROOT/.claude-learning/tmp
   

4. Report a summary to the user containing:

   • Project name and description
   • Files analyzed / total files (with breakdown by fileCategory: code, config, docs, infra, data, script, markup)
   • Nodes created (broken down by type: file, function, class, config, document, service, table, endpoint, pipeline, schema, resource)
   • Edges created (broken down by type)
   • Layers identified (with names)
   • Tour steps generated (count)
   • Any warnings from the reviewer
   • Path to the output file: $PROJECT_ROOT/.claude-learning/knowledge-graph.json

5. Only automatically launch the dashboard if final graph validation passed after normalization/review fixes. If final validation did not pass, report that the graph was saved with warnings and dashboard launch was skipped.

---

Reference: KnowledgeGraph Schema

Node Types (13 total)

Type	Description	ID Convention
file	Source code file	file:<relative-path>
function	Function or method	function:<relative-path>:<name>
class	Class, interface, or type	class:<relative-path>:<name>
module	Logical module or package	module:<name>
concept	Abstract concept or pattern	concept:<name>
config	Configuration file (YAML, JSON, TOML, env)	config:<relative-path>
document	Documentation file (Markdown, RST, TXT)	document:<relative-path>
service	Deployable service definition (Dockerfile, K8s)	service:<relative-path>
table	Database table or migration	table:<relative-path>:<table-name>
endpoint	API endpoint or route definition	endpoint:<relative-path>:<endpoint-name>
pipeline	CI/CD pipeline configuration	pipeline:<relative-path>
schema	Schema definition (GraphQL, Protobuf, Prisma)	schema:<relative-path>
resource	Infrastructure resource (Terraform, CloudFormation)	resource:<relative-path>

Edge Types (26 total)

Category	Types
Structural	imports, exports, contains, inherits, implements
Behavioral	calls, subscribes, publishes, middleware
Data flow	reads_from, writes_to, transforms, validates
Dependencies	depends_on, tested_by, configures
Semantic	related, similar_to
Infrastructure	deploys, serves, provisions, triggers
Schema/Data	migrates, documents, routes, defines_schema

Edge Weight Conventions

Edge Type	Weight
contains	1.0
inherits, implements	0.9
calls, exports, defines_schema	0.8
imports, deploys, migrates	0.7
depends_on, configures, triggers	0.6
tested_by, documents, provisions, serves, routes	0.5
All others	0.5 (default)

---

KURS-MODUS PHASEN (HTML-Kurs-Pipeline)

Phase 1: ANALYSE

Codebase tiefgehend verstehen. Alle Schlüsseldateien lesen, Datenfluesse nachvollziehen, "Hauptfiguren" identifizieren.

Zu extrahieren: Hauptakteure, primaere User-Journey, APIs/Datenfluesse, Engineering-Patterns, Tech-Stack.

Selbst herausfinden was die App tut -- README + Einstiegspunkte lesen. Modul 1 startet immer mit konkreter User-Aktion.

Tiefenanalyse für Level-System -- PRO ZIELGRUPPE

Zusaetzlich zur Basis-Analyse für L0 werden jetzt pro Zielgruppe getrennt Tiefenkandidaten identifiziert. Die Analyse geht NUR so tief wie das Tiefenprofil der jeweiligen ZG erlaubt:

Zielgruppe	Analysierte Tiefe	Was wird analysiert?
Entscheider (Max L1)	Themen für L1	Welche L0-Module brauchen Vertiefung? (KPI-Relevanz, Strategie-Impact)
Anwender (Max L2)	Themen für L1 + L2	Welche Workflows brauchen Detailseiten? Welche L1-Abschnitte brauchen L2?
Entwickler (Max L3)	Themen für L1 + L2 + L3	Volle Tiefe: Sub-Aspekte, Mechaniken, Edge-Cases, Debugging-Szenarien

KERNREGEL: Für Entscheider werden KEINE L2/L3-Kandidaten analysiert oder geplant. Das spart Analyse-Aufwand und verhindert Phantom-Themen die nie gebaut werden.

Analyse-Output (intern, nicht an User) -- GETRENNTE Themen-Baeume pro ZG:

## Themen-Baum Entwickler (Max-Level: L3, HS-Schwelle: >=6/>=8)

1. Authentifizierung [HS=9 -> L1]
   1.1. OAuth-Flow [HS=9 -> L2]
      1.1.1. Token-Refresh [HS=7 -> L3 <8]
      1.1.2. Error-Handling bei OAuth [HS=8 -> L3]
   1.2. Session-Management [HS=7 -> L2 <8, erweiterter Absatz]
   1.3. Berechtigungen (RBAC) [HS=8 -> L2]
2. Datenbank [HS=8 -> L1]
   2.1. Schema-Design [HS=8 -> L2]
   2.2. Migrations [HS=4 -> bleibt auf L1]

## Themen-Baum Anwender (Max-Level: L2, HS-Schwelle: >=7/>=9)

1. Erste Schritte [HS=8 -> L1]
   1.1. Anmeldung einrichten [HS=9 -> L2]
   1.2. Profil anpassen [HS=5 -> bleibt auf L1]
2. Hauptfunktionen [HS=9 -> L1]
   2.1. Dashboard nutzen [HS=9 -> L2]
3. Fehlerbehebung [HS=7 -> L1]
   (Keine L2-Kandidaten mit HS>=9)

## Themen-Baum Entscheider (Max-Level: L1, HS-Schwelle: >=8)

1. Executive Summary [HS=9 -> L1]
2. Architektur-Überblick [HS=8 -> L1]
3. Kosten & Ressourcen [HS=8 -> L1]
4. Risiken [HS=6 -> <8, bleibt auf L0]
(KEINE L2/L3-Planung -- Max-Level ist L1!)

---

Phase 2: CURRICULUM + TIEFENPLANUNG

L0-Curriculum (identisch zur Basisversion)

5-8 Module pro Zielgruppe. Der Bogen beginnt bei dem was der Lernende kennt -> was er nicht kennt.

Entwickler-Curriculum (L0)

Modul	Zweck
1	App + Kernaktion tracen
2	Akteure kennenlernen (Komponenten)
3	Kommunikation der Teile
4	Aussenwelt (APIs, DB, externe Dienste)
5	Clevere Tricks (Patterns)
6	Wenn etwas kaputt geht (Debugging)
7	Das grosse Ganze

Anwender-Curriculum (L0)

Modul	Zweck
1	Was ist das? Erster Eindruck
2	Die Hauptbereiche
3	Kern-Feature im Detail
4	Tipps, Tricks, Einstellungen
5	Haeufige Fragen & Problembehebung

Entscheider-Curriculum (L0)

Modul	Zweck
1	Executive Summary
2	Architektur-Überblick (vereinfacht)
3	Kosten & Ressourcen
4	Risiken & Abhängigkeiten
5	Nächste Schritte / Roadmap

L1-L3 Curriculum-Ableitung -- Bedarfsgerecht pro Zielgruppe

KERNPRINZIP: Jede Zielgruppe bekommt ihren EIGENEN Curriculum-Baum. Es werden NUR Levels geplant die das Tiefenprofil der ZG vorsieht. Kein Planungs-Overhead für Levels die nie gebaut werden.

L1-Themen werden pro ZG aus den L0-Modulen dieser ZG abgeleitet. HS-Schwelle ist zielgruppenspezifisch (Entwickler>=6, Anwender>=7, Entscheider>=8).

L2-Sub-Themen werden NUR für ZG mit max_level >= L2 geplant (Entwickler, Anwender). Für Entscheider wird KEIN L2-Curriculum erstellt. HS-Schwelle für "noch tiefer": Entwickler>=8, Anwender>=9.

L3-Details werden NUR für ZG mit max_level = L3 geplant (typischerweise nur Entwickler). Für Anwender und Entscheider wird KEIN L3-Curriculum erstellt.

Pipeline-Tiefenkarten erstellen (Phase 2 Output)

Vor dem Bauen wird pro Zielgruppe eine Pipeline-Tiefenkarte erstellt -- als Planungsdokument für den jeweiligen Pipeline-Agent:

=== Pipeline-Tiefenkarte Entwickler (Max: L3, Schwelle: >=6/>=8) ===
L0: Überblick (7 Module)
+-- Modul 1: App + Kernaktion tracen [HS=8 -> L1]
|   +-- L1: Erster Request-Lifecycle [HS=9 -> L2]
|   |   +-- L2: HTTP-Handler im Detail [HS=8 -> L3]
|   |   +-- L2: Middleware-Chain [HS=8 -> L3]
|   +-- L1: Einstiegspunkte [HS=5 -> <6, Absatz auf L0]
+-- Modul 2: Akteure [HS=9 -> L1]
|   +-- L1: Frontend-Komponenten [HS=8 -> L2]
|   |   +-- L2: State-Management [HS=8 -> L3]
|   +-- L1: Backend-Services [HS=8 -> L2]
...
-> Geplante Dateien: 2 (L0) + 10 (L1) + 12 (L2) + 8 (L3) = 32

=== Pipeline-Tiefenkarte Anwender (Max: L2, Schwelle: >=7/>=9) ===
L0: Überblick (5 Module)
+-- Modul 1: Erste Schritte [HS=8 -> L1]
|   +-- L1: Anmeldung einrichten [HS=9 -> L2]
+-- Modul 2: Hauptfunktionen [HS=9 -> L1]
|   +-- L1: Dashboard nutzen [HS=9 -> L2]
+-- Modul 3: Fehlerbehebung [HS=7 -> L1]
|   (Keine L2-Kandidaten mit HS>=9)
...
-> Geplante Dateien: 2 (L0) + 6 (L1) + 4 (L2) = 12
-> KEIN L3 (Max-Level ist L2!)

=== Pipeline-Tiefenkarte Entscheider (Max: L1, Schwelle: >=8) ===
L0: Überblick (5 Module)
+-- Modul 1: Executive Summary [HS=9 -> L1]
+-- Modul 2: Architektur-Überblick [HS=8 -> L1]
+-- Modul 3: Kosten [HS=8 -> L1]
+-- Modul 4: Risiken [HS=6 -> <8, Absatz auf L0]
...
-> Geplante Dateien: 2 (L0) + 6 (L1) = 8
-> KEIN L2/L3 (Max-Level ist L1!)

---

Phase 3: FOUNDATION -- Design-System

Shared CSS & JS

ALLE Level-Seiten teilen das identische Design-System. Es gibt KEINE separate CSS-Datei -- alles ist inline in jeder HTML-Datei (Self-Contained-Prinzip).

Aber: Um Konsistenz zu gewährleisten, wird das CSS einmal definiert und dann in jede Datei kopiert.

Google Fonts (in <head>)

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link href="https://fonts.googleapis.com/css2?family=Bricolage+Grotesque:opsz,wght@12..96,400;12..96,600;12..96,700;12..96,800&family=DM+Sans:ital,opsz,wght@0,9..40,300;0,9..40,400;0,9..40,500;0,9..40,600;0,9..40,700;1,9..40,400;1,9..40,500&family=JetBrains+Mono:wght@400;500;600&display=swap" rel="stylesheet">

FARBRAUM -- Energiekonzern-Palette (KRITISCH)

:root {
  /* === PRIMAERE BRAND-FARBEN === */
  --color-deep-blue:      #000099;
  --color-impulse-orange:  #FE8F11;
  --color-warm-gray:       #E4DAD4;

  /* === HINTERGRUENDE === */
  --color-bg:              #FFFFFF;
  --color-bg-warm:         #F3EFEB;
  --color-bg-code:         #000066;

  /* === TEXT === */
  --color-text:            #1A1A2E;
  --color-text-secondary:  #6B6560;  /* warm getönt statt kalt-violett #5C5A6B */
  --color-text-muted:      #7A7570;  /* warm getönt statt kalt-violett #6B6778, WCAG AA: 4.6:1 auf Weiss */

  /* === BORDERS & SURFACES === */
  --color-border:          #E4DAD4;
  --color-border-light:    #EDE8E4;
  --color-surface:         #FFFFFF;
  --color-surface-warm:    #F8F5F2;

  /* === AKZENT = Impuls-Orange === */
  --color-accent:          #FE8F11;
  --color-accent-hover:    #E57D00;
  --color-accent-light:    #FFF3E5;
  --color-accent-muted:    #FEB85C;

  /* === SEMANTISCHE FARBEN === */
  --color-success:         #84C041;
  --color-success-light:   #EFF7E5;
  --color-error:           #CC0000;
  --color-error-light:     #FFE5E5;
  --color-info:            #1195EB;
  --color-info-light:      #E5F2FC;
  --color-warning:         #FDC83A;
  --color-warning-light:   #FFF9E5;

  /* === AKTEUR-FARBEN === */
  --color-actor-1:         #000099;
  --color-actor-2:         #FE8F11;
  --color-actor-3:         #84C041;
  --color-actor-4:         #1195EB;
  --color-actor-5:         #5BE3D6;
  --color-actor-6:         #FDC83A;

  /* === DIAGRAMM-PALETTE === */
  --color-chart-1:         #000099;
  --color-chart-2:         #FE8F11;
  --color-chart-3:         #84C041;
  --color-chart-4:         #1195EB;
  --color-chart-5:         #FDC83A;
  --color-chart-6:         #E2C39A;

  /* === FONTS === */
  --font-display:  'Bricolage Grotesque', Georgia, serif;
  --font-body:     'DM Sans', -apple-system, sans-serif;
  --font-mono:     'JetBrains Mono', 'Fira Code', 'Consolas', monospace;

  /* === TYPOGRAFIE === */
  --text-xs:.75rem; --text-sm:.875rem; --text-base:1rem; --text-lg:1.125rem;
  --text-xl:1.25rem; --text-2xl:1.5rem; --text-3xl:1.875rem; --text-4xl:2.25rem;
  --text-5xl:3rem; --text-6xl:3.75rem;
  --leading-tight:1.15; --leading-snug:1.3; --leading-normal:1.6; --leading-loose:1.8;

  /* === ABSTAENDE === */
  --space-1:.25rem; --space-2:.5rem; --space-3:.75rem; --space-4:1rem;
  --space-5:1.25rem; --space-6:1.5rem; --space-8:2rem; --space-10:2.5rem;
  --space-12:3rem; --space-16:4rem; --space-20:5rem; --space-24:6rem;

  /* === LAYOUT === */
  --content-width:820px; --content-width-wide:1000px; --nav-height:50px;
  --radius-sm:8px; --radius-md:12px; --radius-lg:16px; --radius-full:9999px;

  /* === SCHATTEN === */
  --shadow-sm:  0 1px 2px rgba(0,0,60,.05);
  --shadow-md:  0 4px 12px rgba(0,0,60,.08);
  --shadow-lg:  0 8px 24px rgba(0,0,60,.10);
  --shadow-xl:  0 16px 48px rgba(0,0,60,.12);

  /* === ANIMATIONEN === */
  --ease-out:cubic-bezier(.16,1,.3,1); --ease-out-quart:cubic-bezier(.25,1,.5,1); --ease-in-out:cubic-bezier(.65,0,.35,1);
  --duration-fast:150ms; --duration-normal:300ms; --duration-slow:500ms; --stagger-delay:120ms;
}

/* === TRANSITIONS: ease-out-quart als Standard (NICHT generisches 'ease') === */
/* Verwende in allen transition-Deklarationen:
   transition: property Xms var(--ease-out-quart);
   NIEMALS: transition: property Xms ease;
   Das generische 'ease' ist ein Kompromiss der selten optimal ist.
   ease-out-quart (cubic-bezier(.25,1,.5,1)) erzeugt natuerliche Verzoegerung. */

Syntax-Highlighting (auf #000066)

.code-keyword  { color: #FEB85C; }
.code-string   { color: #84C041; }
.code-function { color: #5BE3D6; }
.code-comment  { color: #7B7BA0; }
.code-number   { color: #FDC83A; }
.code-property { color: #E2C39A; }
.code-operator { color: #1195EB; }
.code-tag      { color: #FE8F11; }
.code-attr     { color: #E2C39A; }
.code-value    { color: #84C041; }

Design-Regeln (NICHT VERHANDELBAR)

Regel	Detail
Primaerfarbe	Tiefenblau (#000099) für: Nav-Bar-Akzente, Modulnummern (15% Opacity), Hero-Sektionen
Akzentfarbe	Impuls-Orange (#FE8F11) für: Buttons, Links, Fortschrittsbalken, Deep-Dive-Links
Warmgrau	#E4DAD4 für: Borders, Hintergrund-Alternation, Bullet-Farben
Hintergründe	Gerade Module: Weiss. Ungerade: Warmgrau. Hero: Tiefenblau
Code-Bloecke	Auf #000066. NICHT Charcoal/Schwarz
Typografie	Bricolage Grotesque Headings. DM Sans Body. JetBrains Mono Code
Kein Logo	Keine Logos, keine Firmennamen
Kein Purple	KEINE Purple-Gradienten
Kein Glassmorphism	KEIN backdrop-filter:blur() -- ist ein AI-Slop-Tell. Solides rgba() verwenden
Easing	KEIN generisches ease in Transitions. IMMER var(--ease-out-quart) oder cubic-bezier(.25,1,.5,1)
Transitions	NUR transform und opacity animieren. NIEMALS width, height, padding, margin

BARRIEREFREIHEIT -- PFLICHT-BLOECKE (in JEDE HTML-Datei)

Diese beiden CSS-Blöcke MUESSEN in JEDER erzeugten HTML-Datei enthalten sein, direkt vor </style>:

/* === A11Y: Reduced Motion === */
@media(prefers-reduced-motion:reduce){
  *,*::before,*::after{
    animation-duration:0.01ms !important;
    animation-iteration-count:1 !important;
    transition-duration:0.01ms !important;
    scroll-behavior:auto !important;
  }
  html{scroll-snap-type:none !important;scroll-behavior:auto !important}
}

/* === A11Y: Focus Visible === */
*:focus-visible{