Learning Opportunities – Ein Skill für Claude Code und Codex, der gezielte Kompetenzentwicklung unterstützt

• Ein Skill für Claude Code und Codex, der beim agentischen Codieren nicht nur Projekte voranbringt, sondern auch die Fachkompetenz der Nutzer erweitert
• Nach Architekturarbeiten wie dem Erstellen neuer Dateien, Schemaänderungen oder Refactoring schlägt Claude eine optionale Lernübung von 10–15 Minuten vor
• Die Übungen nutzen lernwissenschaftliche Methoden wie Vorhersage, Generierung, Abrufübungen und verteilte Wiederholung und erstellen halb gelöste Beispiele aus der tatsächlichen Projektarbeit der Nutzer
• Das Design soll Probleme abmildern, die durch AI-Coding-Tools entstehen können, etwa das unkritische Übernehmen generierten Codes, die Illusion von Gewandtheit, langes Durcharbeiten ohne Pause, mangelnde Metakognition und weniger Selbsttests
• Claude fragt etwa: „Sollen wir zu diesem Thema eine kurze Lernübung machen? Das dauert etwa 10–15 Minuten“, und startet bei Zustimmung eine interaktive Übung
• Ein zentrales Designprinzip ist, dass Claude seine eigenen Fragen nicht selbst beantwortet, sondern auf Eingaben der Nutzer wartet; damit soll neben schnellem agentischen Coding ein anderer Modus für Reflexion und Erkundung entstehen
• Zu den Übungsarten gehören Vorhersage → Beobachtung → Reflexion, Generierung → Vergleich, Nachverfolgung von Ausführungspfaden, Debugging-Vorhersagen, Erklären für neue Entwickler und Abrufkontrollen zu Inhalten aus früheren Sitzungen
• Derzeit wird vorgeschlagen, in einer Sitzung keine weiteren Lerngelegenheiten anzubieten, wenn eine Übung bereits abgelehnt wurde oder in derselben Sitzung schon 2 Übungen abgeschlossen wurden
• In Codex lässt sich der Skill mit codex plugin marketplace add https://github.com/DrCatHicks/learning-opportunities.git zum Marketplace hinzufügen; enthalten sind learning-opportunities, learning-opportunities-auto und orient
• In Claude Code wird er über den Claude Code plugin marketplace hinzugefügt, dann mit /plugin install learning-opportunities@learning-opportunities installiert und nach einem Neustart aktiviert
• learning-opportunities-auto ist ein optionaler Hook für Linux und macOS, mit dem Claude nach einem git commit eine Übungsempfehlung in Betracht zieht; unter Windows ist die Nutzung mit zusätzlicher Einrichtung ebenfalls möglich
• Der Skill orient erstellt beim Kennenlernen eines neuen Repositorys eine orientation.md und bietet empfohlene Lektionen auf Basis von Forschung zu Programmverständnis und Codebase-Erkundung
• Die Nutzung zusammen mit Learning-Goal wird empfohlen; dieser Skill wird als Hilfe für halbstrukturierte, interaktive Lernzielsetzung mit der MCII-Methode vorgestellt
• Für Team-Experimente kann auch MEASURE-THIS.md verwendet werden; es bietet validierte Umfragefragen, Leitlinien zur Interpretation der Ergebnisse, ein „team boast“-Template zum Teilen mit der Führungsebene sowie Hinweise in Claude.md für statistische Genauigkeit
• Lizenziert unter der Creative Commons Attribution 4.0 International License

[GN⁺]

Hacker-News-Kommentare

• Ich kenne mich mit Skills nicht besonders gut aus, aber wenn ich mir das Repository ansehe, wirkt es im Vergleich zu einem kurzen Prompt in einem Bash-Skript, das nach einem Commit läuft, ziemlich überladen mit ornamentalem Code und Text
  Im Kern geht es wohl darum, dass der Nutzer gerade committet hat und deshalb eine 10–15-minütige Lernübung vorgeschlagen werden soll, falls es neue Dateien, Schemaänderungen, Architekturentscheidungen, Refactorings oder unbekannte Muster gibt

  • Skills sind nützlich, um wiederholbare Workflows standardisiert zu beschreiben, durch schrittweise Offenlegung Kontext zu sparen, Prompts zu teilen und selten genutzte, aber nichtdeterministische Teile als deterministische Verfahren wie Skripte zu kapseln
    Konzeptionell sollte man sie nicht als fremde Magie sehen, die man einfach übernimmt, sondern als schrittweise ausbaubare Software https://alexhans.github.io/posts/series/evals/building-agent...
    In Coding-Harnesses gibt es oft einen SkillBuilder-Agent-Skill, sodass man sie leicht erstellen und weiterentwickeln kann
    Ich würde empfehlen, sie selbst passend zu den eigenen Problemen zu bauen; es gibt auch ein einfaches Beispiel dafür, wie man per Evaluation die Genauigkeit einer Automatisierung ausreichend steigern kann https://alexhans.github.io/posts/series/evals/sketch-to-text...
  • Die meisten dieser Tools sind letztlich nur eine weitere Markdown-Datei, die in den Prompt hineingesteckt wird, und angesichts der Funktionsweise großer Sprachmodelle ist das völlig normal
    Deshalb würde ich dazu raten, sich mit Claude selbst ein eigenes ähnliches Tool zu bauen. Am Anfang kostet das Tokens, aber später kann ein eigenes Tool die nötigen Tokens und Aufrufe für sinnvolle Arbeit deutlich reduzieren
    Man kann Tool-Aufrufe auch sicherer einschränken, Agentenarbeit besser wiederholbar machen und Fehlermodi verringern. So vermeidet man auch Situationen, in denen ein Laptop mitten in der Arbeit ausgeht und der Agent viele Tokens verbrennen muss, um wiederherzustellen, wie weit er war

• Ich war überrascht, dass manche Skills nicht einmal ein genaues Verfahren oder konkrete Aufgaben enthalten, sondern den Prompt eher wie eine Motivationsrede primen, damit das Modell bei bestimmten Aufgaben besseren Text erzeugt
  Selbst der frontend-design skill von Claude klingt fast nur wie die Bitte, gute Schriftarten zu wählen und das Design konsistent zu halten, ohne konkret zu sagen, welche Schriftarten man nutzen oder wie man Farbpalette und Layout gestalten soll
  https://github.com/anthropics/claude-code/blob/main/plugins/...

• Bei Code-Write-Agents kann sich eine wiederkehrende Schuld aufbauen. Wenn man die Ergebnisse von Coding-Assistenten übernimmt, ohne zu prüfen, ob sie stimmen, verliert man Wissen über die eigene Codebasis
  Kontextdateien wie CLAUDE.md, Migrationsprotokolle und Authentifizierungsprotokolle funktionieren nur dann gut, wenn man sie auch wirklich gut genug versteht, um sie korrekt zu aktualisieren
  Mir ist es schon passiert, dass ich zwei Stunden lang blind von einem Agenten erzeugten Code akzeptiert habe und danach so weit vergessen hatte, wie die Codebasis funktioniert, dass ich keine neue Kontextdatei mehr erstellen konnte. Solche Skill-Schulden tauchen in Diffs nicht auf, sondern werden erst sichtbar, wenn man den Agenten anleiten muss

  • Vielleicht ist das eher rekursiv als wiederkehrend
    Bei großen Feature-Änderungen ist es sinnvoll, sich zuerst im Chat mit dem Agenten auf das Business-Domain-Problem zu einigen, das man lösen will, bevor man ihn Code schreiben lässt. Es fühlt sich an, als würde man sich mit einem Ansprechpartner einer externen Entwicklungsfirma hinsetzen und ausformulieren, was man haben möchte
    Danach sollte man gemeinsam mit dem Agenten ein Designdokument mit hierarchischen Bullet Points als echte .md-Datei schreiben, wobei der Agent den Großteil erzeugt und bearbeitet, man aber Probleme und mehrdeutige Entscheidungen gründlich prüft, damit Entscheidungen auf Design-Ebene schon dort festgezogen werden
    Anschließend sollte er die Design-Spezifikation in das Gerüst eines BDD-Spezifikationstest-Sets umwandeln und dieses dann bei der Implementierung ausfüllen
    In der Implementierungsphase darf man Unit-Tests und Integrationstests hinzufügen, ändern oder löschen, aber die Design-Spezifikationsdatei und die daraus abgeleitete BDD-Teststruktur sollten fix bleiben. Vor Abschluss müssen die BDD-Tests mit zur Bezeichnung passender Logik gefüllt sein und alle erfolgreich durchlaufen
    Wenn das Projekt sehr groß ist, kann man Sprints fahren, in denen man Schritte wie die Definition neuer Business-Anforderungen, Design-Änderungen und das Hinzufügen von BDD-Sets erneut durchläuft. Oder man kann zwischen Schritt 2 und 3 das Design in Meilensteine aufteilen und nur für den aktuellen Meilenstein BDD-Punkte erstellen und lösen lassen
    Im Grunde heißt das: Für LLMs sollte man einen Waterfall-Ansatz verwenden. Wenn der ganze Prozess in unter einer Stunde abgeschlossen ist, kann sich selbst Waterfall ziemlich angenehm anfühlen
    Entscheidend ist, dass man den Agenten nach Abschluss des Projekts oder Meilensteins im Chat den von ihm geschriebenen Code erklären lässt, ihn aber anweist, nichts zu erläutern, was bereits im Design stand
    Dann kann man ihn Erklärungen zu überraschenden Stellen in Code-Kommentare umwandeln lassen, und das Ergebnis sind keine formelhaften Müll-Kommentare, sondern Kommentare, wie sie auch ein Mensch schreiben würde

• Wie will man ohne Benchmarks und Evaluierungen wissen, dass es bessere Ergebnisse liefert als /create-skill? Naive Tests schaffen kein Vertrauen

  • Hier scheint es eher um die Skill-Entwicklung von Menschen zu gehen. Es ist eine Funktion, die dem Nutzer Lerngelegenheiten bietet
    Es heißt dort, dass Claude nach Abschluss von Architekturarbeit selektive 10–15-minütige Übungen vorschlägt, die auf evidenzbasierter Lernwissenschaft beruhen. Dabei werden Techniken wie Vorhersage, Generierung, Abrufübungen und verteilte Wiederholung genutzt, indem halbfertige Beispiele aus der eigenen Projektarbeit gegeben werden
    Der Name ist verwirrend
  • Klingt, als wäre man so sehr von LLMs durchdrungen, dass schon beim Auftauchen verwandter Begriffe eine pawlowsche Reaktion ausgelöst wird
  • Gut, dass Evaluierungen angesprochen werden, aber mich interessiert, was man konkret nutzt oder wonach man sucht. Baut man das selbst oder verwendet man ein bestehendes Evaluierungs-Framework?

• Für Leute, die noch nicht in diesem Kaninchenbau gelandet sind: Skills sind strukturierte Markdown-Dateien, die beschreiben, wie eng umrissene Aufgaben erledigt werden sollen
  Wenn man zum Beispiel API-Endpunkte auf eine bestimmte Weise schreibt, hält man dieses Verfahren in einem Skill fest. Wenn der Agent später diesen Skill sieht und entscheidet, dass er für den aktuellen Chat-Kontext relevant ist, lädt er ihn und führt die beschriebenen Schritte aus
  Es ist ähnlich wie ein Tool-Call, nur dass es keine aufrufbare Funktion ist, sondern eine Anleitung dafür, wie dieser „Skill“ ausgeführt werden soll
  Zumindest in Cline, das ich benutze, kann man Skills global oder projektlokal definieren

  • Skills haben auch einen Header namens frontmatter, und ein Teil davon wird wie bei einer CLAUDE.md-Datei früh im Kontext mitgeteilt
    Soweit ich gehört habe, kann das Laden eines Skills den Kontext gesondert beeinflussen, etwa indem es auch nach einer Komprimierung erhalten bleibt
    Wenn man mehrere Skills lädt, könnten sie sogar dauerhaft in die Sitzung geladen bleiben
    Ich halte sie für gut kombinierbar mit Subagents. Wenn ein Subagent einen Skill lädt, die Arbeit erledigt und nur das Ergebnis präsentiert, muss der orchestrierende Agent die Details nicht kennen

• Ich weiß nicht genau, was mit dem adaptive dynamic textbook approach gemeint ist. Ich brauche ein Beispiel
  Dass man aktives Verarbeiten überspringt, wenn man generierten Code einfach übernimmt und dadurch selbst weniger Code schreibt, stimmt auf jeden Fall

• Ich verstehe nicht, warum man sich bei so einer coolen Idee die Mühe macht, keine Links zu Demos oder Beispielausgaben einzubauen. Das ist ein Muster, das ich auf HN jeden Tag sehe
  Gibt es wirklich keine andere Möglichkeit zu sehen, wie dieser Skill tatsächlich aussieht, als ihn selbst herunterzuladen und auszuführen? Das möchte ich nicht

  • Im Moment fühlt sich die Nutzung von Skills noch deutlich weniger zuverlässig an als klare Anweisungen in AGENTS.md
    Ich verstehe die Idee, Kontextaufblähung zu vermeiden, indem Skills nicht hinzugefügt werden, wenn sie irrelevant sind, aber ohne explizite Anweisung in AGENTS.md gibt es keine Garantie, dass der Agent den Skill überhaupt verwendet. Dann ist es kaum mehr als eine referenzierte Markdown-Datei an irgendeiner Stelle
    Beim Bau von https://www.agentkanban.io habe ich viel damit experimentiert, wo man Anweisungen für ein mit GitHub Copilot integriertes Arbeitsboard platzieren sollte
    Eine Struktur eine Ebene unter AGENTS.md hat ziemlich gut funktioniert. Weil der Agent aufgabenbezogene IDs zuverlässig aufgreifen musste, haben wir uns auf INSTRUCTION.md innerhalb einer vom Tool verwalteten Datei-Struktur eingependelt, was auch die Verschmutzung von AGENTS.md reduziert hat
    Ich habe auch Skills ausprobiert, aber sie wurden zu oft übersprungen, sodass es schwieriger war, das Tool so zuverlässig zum Laufen zu bringen wie mit dem aktuellen Ansatz
  • Es gibt ja direkt eine SKILL.md; man kann sie einfach lesen und sieht dann, was sie macht

• Mir gefällt die Idee wirklich sehr. Ich habe Claude schon einmal aus Open-Source-Lehrbüchern und Dokumentation spontan ein Lehrbuch erzeugen lassen
  Ich frage mich, ob sich dieser Skill auf allgemeinere Lern- und Anwendungsbereiche ausweiten lässt oder ob er auf Code spezialisiert ist

• Die Reaktionen hier sind interessant, aber die meisten scheinen den Kern zu verfehlen
  Für mich ist die wichtigste Erkenntnis, dass man lernt, indem man sieht, wie andere Skills einsetzen. Gestern habe ich Matt Pococks Kurs zur Nutzung von Agenten gesehen, und dort zeigte er Skills etwa so, dass er einen „grill-me“-Skill nutzte, um ein Product-Requirements-Dokument weiterzuentwickeln
  Ich werde nicht genau das tun, was er tut, aber ich habe dadurch eigene Ideen bekommen, wie ich Anforderungen erstelle und dann implementiere
  Wie Anthropic-Ingenieure es ausdrücken: Claude ist wie ein talentierter Ingenieur, dem aber Fachspezialisierung fehlt. Skills sind die Ordner und Dateien, in denen diese Spezialisierung aufgebaut wird
  Eine weitere Sache, die ich von Pocock gelernt habe, ist, dass Antworten tendenziell dümmer werden, je länger Kontext oder Token-Größe werden. Skills sind also noch ein weiterer Weg, Probleme dem LLM in komprimierter Form zu präsentieren und optimiertere Antworten zu erhalten
  Claude hat außerdem Verhaltensmerkmale. Wenn jemand wiederholt Skills erstellt, lassen sie sich womöglich nicht gut auf andere Nutzer übertragen, weil jeder anders mit Claude spricht
  Deshalb zögere ich, meinen Skill-Ordner mit Kollegen zu teilen. Stattdessen möchte ich als Demo zeigen, was ich gebaut habe, damit andere sehen, was möglich ist, und ihren eigenen Workflow finden
  Der Wert liegt darin, zu sehen, wie andere Dinge mit Claude bauen, und es dann auf eigene Weise nachzuahmen. Es ist ähnlich wie damals, als man Programmieren lernte, indem man Code aus dem C-Buch von Kernighan und Ritchie abtippte, ihn veränderte, um das Verhalten zu verstehen, und ihn später für den eigenen Zweck anpasste
  Ein weiterer Grund, warum ich Verhaltensmerkmale erwähne, ist, dass der Autor Psychologe ist, weshalb es interessant ist, dass seine Art der Interaktion mit Claude wahrscheinlich ziemlich anders ist als die eines Programmierers
  In dem Zusammenhang habe ich gehört, dass der Autor und mehrere Fachleute ihr Twitter schon vor langer Zeit verlassen haben; ich will mir also bsky oder Mastodon einrichten und ihnen folgen. Ich denke, es ist wichtig zu beobachten, wie fachkundige Nicht-Programmierer LLMs verwenden

• Gute Idee, deshalb habe ich heute Morgen etwas damit herumgespielt
  Ich hatte durch zu viel AI-Nutzung stark das Gefühl einer geistigen Erosion, und auch wenn das keine vollständige Lösung ist, könnten schon ein paar Übungen pro Tag ziemlich helfen