Master-Class

Was macht Master-Class?

Verwandelt Studienmaterial in einen Videokurs, den die Lernenden tatsächlich ansehen. Dieser Skill übernimmt die Pädagogik (Lesen, Kurslandkarte, Skripte). Das Rendering (Diagramme, Stimme, MP4, Obsidian-Notizen) wird vom Partner-Skill master-class-render erledigt.

Modell-Routing (die explizite Anweisung des Benutzers)

PEDAGOGY_MODEL: claude-sonnet-5.5    # Lesen, Kurslandkarte, Skripte (Schritte 1–4). Das günstigste Modell, das die Qualität hält; bei Bedarf hier ändern.

Die Qualität hängt fast vollständig von den Schritten 1–4 ab, daher müssen diese auf PEDAGOGY_MODEL laufen. Die Schritte 0, 5 und 6 sind mechanisch und laufen auf dem Modell, das diese Sitzung antreibt.

• Wenn du bereits als PEDAGOGY_MODEL läufst (oder der Benutzer sagt, du sollst die Delegation überspringen), führe die Schritte 1–4 selbst aus.
• Andernfalls delegiere. Starte einen general-purpose-Unteragenten mit model: PEDAGOGY_MODEL. Die Angabe des Modells hier ist die explizite Anforderung des Benutzers. Sein Prompt muss enthalten: den Quellpfad, die Ausgabesprache, den Pfad zum Quellordner, jeglichen Fokus/Kontext, den der Benutzer angegeben hat, und "Lies ~/.copilot/skills/master-class/SKILL.md und befolge die Schritte 1–2 genau; schreibe course-map.md, dann stoppe und gib die Karte zurück."
  • Zeige die zurückgegebene Karte dem Benutzer und warte auf Genehmigung (es sei denn, der Benutzer hat gebeten, ohne Genehmigungen zu laufen).
  • Sende dann die Genehmigung/Änderungen an denselben Agenten (write_agent): "Genehmigt [+ Änderungen]. Führe jetzt die Schritte 3–4 genau aus: schreibe jedes Skript, lint bis keine Fehler mehr, schreibe scripts/README.md, dann gib die Lint-Zusammenfassung zurück."
  • Fahre dann selbst mit Schritt 5 (Rendering) fort, der kein großes Modell benötigt.
• Wenn der Benutzer in der Anfrage ein anderes Modell für die Pädagogik nennt, verwende dieses.

Leseliste (bevor du etwas schreibst)

1. references/cheatsheet.md: eine Seite mit den wichtigen Regeln.
2. references/learner-profile.md: wer der Lernende ist, wie er denkt, welche Analogien ankommen.
3. references/lesson-template.md: die auszufüllende Vorlage für jede Lektion.
4. Genehmigte Beispiele, alle aus einem Kurs (Lab 02, Tool Use & MCP): examples/course-map.md, 01 (ein falscher Satz → Mechanismus), 05 (eine Geschichte → eine Regel), 08 (Abwägen von Optionen → warum ein Standard existiert). Ahme ihre Tiefe und Stimme nach, nicht ihre Formulierung.
5. Optional: references/teaching-research.md, die Belege und Quellen hinter den Regeln.

Nicht verhandelbare Lehrregeln

1. Problem vor Lösung. Jede Lektion beginnt mit einer konkreten Situation, in der etwas scheitert oder weh tut. Die Technologie wird erst genannt, nachdem das Problem und die offensichtlichen, verworfenen Alternativen beschrieben wurden.
2. Lehre die Absicht, nicht die Implementierung. Wenn das Material X vermittelt, muss der Lernende verstehen, was X ist, warum es existiert, wann es verwendet wird und wann nicht. Code ist Beleg für ein bereits erklärtes Konzept (≤ 6 Zeilen), niemals eine Komplettdurchführung.
3. Eine Fehlvorstellung pro Lektion auseinandernehmen, laut ausgesprochen.
4. Konkret → abstrakt, mit einem durchgehenden Beispiel, das den gesamten Kurs verbindet.
5. Die Denkweise des Lernenden: Kontext → reale Einschränkung → betrachtete Optionen und warum jede verworfen wurde → Entscheidung → Kosten/Kompromiss → wann man es nicht verwendet. Frage explizit „Gibt es etwas Besseres?"
6. Erinnerungspause in jeder Lektion: Frage → … (der Renderer fügt eine 4-sekündige Pause ein) → Antwort mit ihrer Begründung.
7. Brücke: Jede Lektion endet mit dem Problem, das die nächste löst.
8. Keine Längenbegrenzung, aber ein Lernziel pro Lektion (normalerweise 4–6 Min.).
9. Variiere Anfänge, Fäden und Abschlüsse; niemals eine feste Schablone.
10. Erfinde niemals Fakten oder Zahlen. Technische Behauptungen stammen aus den gelesenen Quellen oder verifizierten offiziellen Dokumenten; hypothetische Szenarien müssen klar als solche erkennbar sein.

Arbeitsablauf

0 · Zuerst fragen

• Ausgabesprache: immer fragen, es sei denn, der Benutzer hat sie bereits genannt.
• Quellpfad, falls fehlend. Standardwerte (nur bestätigen, wenn die Vault-Struktur abweicht):
  • Notizen → <Lab-Ordner>/Master class/
  • Videos → <Lab-Ordner>/_attachments/master-class/
  • Quellen → <Lab-Ordner>/_attachments/master-class/source/ (course-map.md, scripts/, scenes/)
• Wende das Modell-Routing oben an.

1 · Mit begrenzter Tiefe lesen

• Lese das Labor/die Notiz vollständig. Bei Notebooks lies das Markdown und die Konzepte, die der Code demonstriert; führe niemals Notebooks aus und lies niemals Geheimnisse oder .env.
• Folge [[Wikilinks]]/verlinkten Dokumenten bis zu 2 Ebenen tief, nur wenn sie für die Absicht des Materials relevant sind. Überspringe zukünftige Labs, bereits abgedeckte Voraussetzungen und Abschweifungen.
• Das Web ist erlaubt, um das Warum zu überprüfen oder zu vervollständigen (offizielle Dokumente und Spezifikationen). Zitiere es.
• Führe ein Protokoll: gelesen / verworfen + Grund.

2 · Kurslandkarte → Stopp für Genehmigung

Schreibe <source>/course-map.md wie examples/course-map.md:

• die Absicht in 2–3 Sätzen, als das, was der Lernende entscheiden können wird;
• das Leseprotokoll;
• eine Lektionstabelle: # · Lektion · Problem, mit dem sie beginnt · Fehlvorstellung · Analogie/Einstieg · löst → lässt offen, mit Lektion 00 als Überblick und der letzten Lektion als Synthese der Entscheidungen.

3 · Skripte, eine Lektion pro Durchlauf

Für jede Lektion der Reihe nach:

1. Lies das Cheatsheet, die Vorlage, die Zeile der Lektion in der Karte und ein Beispiel erneut.
2. Kopiere references/lesson-template.md nach <source>/scripts/NN - Kurzer Titel.script.md und fülle es aus. Das Suffix .script.md ist erforderlich, da Obsidian sonst Skripte mit Lektionsnotizen verwechselt.
3. Lint es (Schritt 4) und korrigiere es, bevor du zur nächsten Lektion übergehst.

Die Erzählung ist für das Ohr geschrieben: keine Listen, Tabellen oder URLs; Zahlen, wie man sie spricht; IDs/Code in Backticks (als Wörter gelesen). Der Erinnerungstakt heißt Erinnerungspause und hat … zwischen Frage und Antwort. Wenn sein Bildschirm die Frage selbst ist, schreibe es als *"Frage"*.

Schreibe abschließend <source>/scripts/README.md: Lektionstabelle + Rubrik-Selbstbewertung.

4 · Lint + Rubrik (muss vor dem Rendern bestanden sein)

python3 ~/.copilot/skills/master-class/scripts/lint_script.py "<source>/scripts" --sources "<Lab-Ordner>" <andere gelesene Notizen>

Behebe jeden FEHLER. Behebe jede WARNUNG, es sei denn, sie ist beabsichtigt (z. B. eine hypothetische Zahl in einem eindeutig hypothetischen Szenario). Der Linter kann diese nicht beurteilen, also überprüfe sie selbst:

• Warum vor Wie: Die Technologie erscheint erst nach den verworfenen Alternativen
• Ohne Code verständlich
• Die Fehlvorstellung wird genannt und explizit auseinandergenommen
• Die Frage des Einstiegs wird explizit beantwortet
• Der Bildschirm ergänzt die Erzählung (kein doppelter Text)
• Laut vorgelesen klingt es wie ein Lehrer, nicht wie Aufzählungspunkte
• Einstiege/Abschlüsse variieren zwischen aufeinanderfolgenden Lektionen

5 · Rendern → master-class-render

Lies ~/.copilot/skills/master-class-render/SKILL.md und befolge es: schreibe die Szenen, baue dann die MP4s, Lektionsnotizen und den MOC mit einem Befehl, dann verifiziere.

6 · Bericht

Pfade (MOC zuerst), Lektionsanzahl und Gesamtdauer, Lint-Ergebnis, alles Ungeprüfte und eine Zusammenfassung des Leseprotokolls.