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.
インストール
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
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.
"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:
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).
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.
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:
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
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
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.
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
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.
Kein Curriculum-Review durch den User -- Direkt bauen.
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.
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.
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.
Bedarfsgerechte Tiefe -- Pipeline endet am Max-Level -- Jede Pipeline baut NUR die Levels die laut Tiefenprofil noetig sind:
Es werden KEINE leeren Levels erzeugt. Wenn eine ZG kein L2 braucht, wird kein L2-Ordner für sie angelegt.
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.
Max 10 Themen pro Ebene -- Wenn mehr als 10 Kandidaten existieren: nach HS sortieren, Top 10 nehmen, Rest als Absatz auf Eltern-Seite einarbeiten.
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.
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
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.
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)
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:
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"
"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:
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): --><ahref="authentication_en.html"class="nav-lang"title="English version">🇬🇧</a><!-- In der EN-Version (l1/authentication_en.html): --><ahref="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
"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.
Set PROJECT_ROOT to the current working directory.
Get the current git commit hash:
git rev-parse HEAD
Create the intermediate and temp output directories:
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.
Check for subdomain knowledge graphs to merge:
List all *knowledge-graph*.json files in $PROJECT_ROOT/.claude-learning/excludingknowledge-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:
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.
Check if $PROJECT_ROOT/.claude-learning/knowledge-graph.json exists. If it does, read it.
Check if $PROJECT_ROOT/.claude-learning/meta.json exists. If it does, read it to get gitCommitHash.
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.
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.
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:
<path> ( lines, fileCategory: <fileCategory>)
<path> ( lines, fileCategory: <fileCategory>)
...
After ALL batches complete, run the merge-and-normalize script bundled with this skill:
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:
Remove old nodes whose filePath matches any changed file from the existing graph
Remove old edges whose source or target references a removed node
Write the pruned existing nodes/edges as batch-existing.json in the intermediate directory
Run the same merge script -- it will combine batch-existing.json with the fresh batch-*.json files:
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:
Use the architecture-analyzer agent definition (at agents/architecture-analyzer.md).
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.
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>
[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:
Unwrap envelope: If the file contains { "layers": [...] } instead of a plain array, extract the inner array.
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.
Synthesize missing IDs: If any layer is missing an id, generate one as layer:<kebab-case-name>.
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>.
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:
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>
[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:
Unwrap envelope: If the file contains { "steps": [...] } instead of a plain array, extract the inner array.
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.
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>.
Drop dangling refs: Remove any nodeIds entries that do not exist in the merged node set.
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"]}]
{"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>]}
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.
Write the assembled graph to $PROJECT_ROOT/.claude-learning/intermediate/assembled-graph.json.
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 nodeconst 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 = newSet();
const seen = newMap();
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 = newSet(['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 = newMap();
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 = newSet([
...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); }
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
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
If issues array is empty: Proceed to Phase 7.
Phase 7 -- SAVE
Write the final knowledge graph to $PROJECT_ROOT/.claude-learning/knowledge-graph.json.
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.
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
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.
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?
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:
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:
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.
