Skills & Projektgedächtnis (CLAUDE.md)

Skills & Projektgedächtnis (CLAUDE.md)

0:00 Wer schon ein paar Sitzungen mit einem Coding-Agenten hinter sich hat, kennt das Gefühl: Man erklärt zum dritten Mal, dass in diesem Projekt keine Prints verwendet werden. Der Agent ist nicht vergesslich im menschlichen Sinne — er fängt schlicht jedes Mal bei null an. Genau dieses Problem lösen wir in diesem Kapitel, und zwar auf zwei Ebenen: Regeln, die dauerhaft gelten, und Können, das wiederverwendbar wird.

0:23 Der Grundgedanke dahinter ist einfach und lohnt sich zu merken: Alles, was Sie ein zweites Mal tippen, gehört nicht in den Prompt, sondern in eine Datei im Projekt.

Skills & Projektgedächtnis (CLAUDE.md)

0:32 Drei Stationen liegen vor uns. Zuerst die `CLAUDE.md` — die Datei, in der ein Projekt seine eigenen Spielregeln festhält. Danach die Frage, was passiert, wenn mehrere solcher Regelwerke aufeinandertreffen: Welche Ebene sticht welche? Und zum Schluss die Königsdisziplin, eigene Skills, mit denen Sie nicht nur Regeln, sondern ganze Arbeitsabläufe konservieren.

0:55 Der rote Faden ist überall derselbe: weg vom flüchtigen Prompt, hin zu dauerhaften Dateien.

Das Projektgedächtnis (CLAUDE.md)

1:01 Fangen wir mit dem einfachsten und zugleich wirkungsvollsten Werkzeug an. Eine einzige Textdatei im Projektordner verändert erstaunlich viel daran, wie gut ein Agent zu Ihrem Team passt — und sie ist in fünf Minuten geschrieben. Denken Sie an die Einarbeitungsmappe, die eine neue Kollegin am ersten Tag bekommt: Wie wird hier committet, welchen Style-Guide nutzen wir, was ist verboten.

1:23 Die `CLAUDE.md` ist genau das — nur dass sie bei jedem Sitzungsstart neu gelesen wird. Und hier liegt der wichtige Unterschied zu einer normalen README: Ihr Inhalt ist keine Hintergrundinformation, sondern eine verbindliche Arbeitsanweisung. Was dort steht, behandelt Claude Code als Vorgabe, nicht als Vorschlag. Deshalb gehört hinein, was tatsächlich gelten soll: Code-Style, Workflow-Regeln, Architekturentscheidungen.

1:49 Und deshalb gehört alles andere ausdrücklich nicht hinein — dazu gleich mehr. Der unmittelbare Gewinn ist Wiederholungsfreiheit: Was einmal notiert ist, gilt in jeder neuen Sitzung, ohne dass Sie es erwähnen. Der Google Style Guide für Python steht einmal in der Datei und wirkt ab dann still im Hintergrund. Der zweite Punkt geht darüber hinaus und wird oft unterschätzt: Architekturentscheidungen, die Sie hier festhalten, sind auch für Menschen dokumentiert — die Datei nützt dem Team, nicht nur dem Agenten.

2:18 Und weil sie im Repository liegt, wandert sie über die Versionsverwaltung zu allen. Alle arbeiten mit demselben Regelwerk, ohne dass jemand es weitergeben müsste. Das ist der eigentliche Hebel im Teamkontext. Das hier ist bewusst unspektakulär: normales Markdown, ein paar Überschriften, darunter Regeln in ganzen Sätzen. Sie brauchen kein Format zu lernen.

2:39 Achten Sie aber auf den Charakter der Formulierungen — es sind Anweisungen, keine Beschreibungen. „Keine Prints, nur `logging`" ist prüfbar; „wir legen Wert auf sauberes Logging" ist es nicht. Je konkreter die Regel, desto zuverlässiger wird sie befolgt. Und dann die Fußzeile, die im Alltag am häufigsten ignoriert wird: Halten Sie die Datei kurz, ungefähr zweihundert Zeilen.

3:02 Das klingt paradox, ist aber die Erfahrung — je länger das Regelwerk, desto schwächer die Befolgung jeder einzelnen Regel. Jetzt legen Sie eine eigene an, und zwar für ein echtes Projekt, nicht für ein Spielzeug. Der Hinweis ist der wichtigste Teil der Aufgabe: Beginnen Sie mit wenigen, wirklich verbindlichen Regeln. Die Versuchung ist groß, eine lange Wunschliste aufzuschreiben — widerstehen Sie ihr, denn genau daran scheitern diese Dateien in der Praxis.

3:29 Drei bis fünf Punkte, die Sie tatsächlich jedes Mal erklären würden, sind ein guter Anfang. Und dann kommt der Beweis: Starten Sie eine neue Sitzung und schauen Sie nach, ob die Regeln greifen, ohne dass Sie sie erwähnen. Erst dann hat die Datei ihren Zweck erfüllt.

Hierarchie von Anweisungen

3:45 Eine Datei ist einfach. Interessant wird es, sobald mehrere Regelwerke im Spiel sind — Ihre persönlichen Gewohnheiten, die Vorgaben des Projekts und möglicherweise Regeln, die das Unternehmen gesetzt hat. Wer sticht dann wen? Das Prinzip kennen Sie aus jeder Organisation: Es gibt Hausregeln, Abteilungsregeln und persönliche Gewohnheiten, und im Konfliktfall ist klar, was Vorrang hat.

4:09 Genauso ist es hier. Vier Ebenen greifen ineinander — eine unternehmensweite Managed Policy, Ihre nutzerweiten Vorgaben, die projektweite `CLAUDE.md` und persönliche lokale Ergänzungen. Der Normalfall ist dabei nicht der Konflikt, sondern die Ergänzung: Die Ebenen addieren sich, die spezifischere schärft die allgemeinere nach.

4:29 Nur eine Ebene ist wirklich hart, und das ist die Managed Policy — sie sticht alles andere. Genau dafür wurde sie geschaffen. Warum braucht es überhaupt vier Ebenen? Weil Regeln unterschiedliche Reichweiten haben. Ein Unternehmen muss bestimmte Vorgaben zentral durchsetzen können — Sicherheit, Compliance —, und zwar so, dass sie niemand versehentlich lokal aushebelt.

4:51 Umgekehrt soll Ihre persönliche Vorliebe für einen bestimmten Commit-Stil nicht im geteilten Projektregelwerk landen und dort alle anderen beschäftigen. Die Rangfolge löst also zwei Probleme auf einmal: Sie verhindert Widersprüche, und sie gibt jeder Regel einen Ort, an dem sie hingehört. Wenn Sie sich unsicher sind, wo etwas hingehört, hilft die Frage: Für wen soll das gelten?

5:13 Statt die Zeilen vorzulesen, achten Sie auf die Bewegung von oben nach unten: Die Reichweite wird immer kleiner, und die Verbindlichkeit nimmt ab. Ganz oben das ganze Team, erzwungen und im Systempfad abgelegt, damit sie eben nicht im Projekt liegt und dort geändert werden kann. Darunter Ihr Home-Verzeichnis — gilt für alle Ihre Projekte, aber nur für Sie. Dann die Projektdatei, die im Repository liegt und deshalb versioniert und geteilt ist.

5:39 Und ganz unten die lokale Variante, die per `.gitignore` bewusst niemand sonst sieht. Diese letzte Zeile ist Ihr Ventil: Alles Persönliche gehört dorthin und nirgendwo anders hin. Diese Übung ist Sortierarbeit — und sie ist schwieriger, als sie aussieht. Nehmen Sie drei Regeln, die Sie tatsächlich anwenden würden, und ordnen Sie jeder eine Ebene zu, mit Begründung. Die Begründung ist der Lerneffekt, nicht die Zuordnung selbst.

6:04 Fragen Sie sich bei jeder Regel: Würde ein Kollege das auch so wollen? Wenn die Antwort „vielleicht nicht" lautet, gehört sie nicht in die geteilte Projektdatei. Das ist die häufigste Grenzüberschreitung in der Praxis — persönliche Vorlieben, die als Projektregel getarnt im Repository landen und dann alle anderen irritieren.

Eigene Skills entwickeln

6:24 Bis hierhin ging es um Regeln — um das, was immer gilt. Jetzt kommt der zweite Teil des Gedächtnisses: Können. Also Arbeitsabläufe, die Sie nicht dauernd erklären wollen, aber auch nicht bei jedem Start im Kontext haben müssen. Wenn die `CLAUDE.md` die Hausordnung ist, dann ist ein Skill die Betriebsanleitung für eine bestimmte Aufgabe — sie liegt im Schrank und wird herausgeholt, wenn man sie braucht.

6:48 Technisch ist ein Skill schlicht ein Ordner unter `.claude/skills/` mit einer `SKILL.md` darin, in der Fachwissen und Arbeitsablauf beschrieben sind. Entscheidend ist das Wort „bei Bedarf": Anders als die `CLAUDE.md` wird ein Skill nicht bei jedem Start geladen, sondern erst, wenn er gebraucht wird. Ausgelöst wird er entweder direkt über einen Schrägstrich-Befehl oder automatisch, wenn Ihre Anfrage zu seiner Beschreibung passt.

7:13 Der offensichtliche Nutzen ist Wiederverwendung: Ein Ablauf, den Sie einmal sauber beschrieben haben, steht dauerhaft zur Verfügung. Der weniger offensichtliche ist ökonomischer Natur — Skills belasten den Kontext nicht dauerhaft, weil sie erst beim Aufruf geladen werden. Sie können also umfangreiches Fachwissen hinterlegen, ohne dass jede triviale Sitzung damit beginnt, es einzulesen.

7:35 Genau deshalb gehören lange Prozeduren in einen Skill und nicht in die `CLAUDE.md`. Dazu kommt die Teilbarkeit: Ein Skill ist ein Ordner im Repository, er wandert mit. Und der vierte Punkt ist die Stellschraube, über die man am meisten lernt — die Beschreibung entscheidet, wann Claude den Skill überhaupt zieht. Der Aufbau ist bewusst schlicht: oben ein kurzer Kopfbereich mit Name und Beschreibung, darunter der eigentliche Ablauf als normaler Text.

8:02 Was hier wie Formalie aussieht, ist in Wahrheit die wichtigste Zeile der ganzen Datei — die `description`. Sie ist nicht für Menschen gedacht, sondern das Kriterium, an dem Claude entscheidet, ob dieser Skill zur Anfrage passt. Deshalb steht dort im Beispiel nicht nur, was der Skill tut, sondern auch, wann er zu nutzen ist. Wer hier vage bleibt, bekommt einen Skill, der nie automatisch anspringt.

8:24 Der Ablaufteil darunter ist dann einfach das, was Sie einem Kollegen erklären würden. Zum Abschluss bauen Sie einen eigenen Skill — bewusst klein. Nehmen Sie einen Arbeitsschritt, den Sie ohnehin regelmäßig machen, und schreiben Sie ihn auf. Testen Sie dann beides: den direkten Aufruf und, interessanter, eine ganz normal formulierte Anfrage, die den Skill automatisch auslösen sollte.

8:48 Wenn er dabei nicht anspringt, liegt es fast immer an der Beschreibung — nachschärfen und erneut versuchen. Und ein Hinweis zum Weiterschauen: Das Foliogen-Repo, aus dem diese Präsentation stammt, ist selbst so gebaut. Ein Skill erzeugt diese Folien. Das ist keine Spielerei, sondern der Normalfall, wenn man einmal angefangen hat.

9:08 Halten wir die drei Bausteine fest. Die `CLAUDE.md` hält Regeln, die immer gelten, und wird bei jedem Sitzungsstart geladen — kurz halten ist dabei kein Detail, sondern die Bedingung dafür, dass sie wirkt. Die Rangfolge sorgt dafür, dass jede Regel dort liegt, wo sie hingehört, mit der Managed Policy als oberster Instanz.

9:27 Und Skills kapseln Können statt Regeln, laden erst bei Bedarf und lassen sich im Team teilen. Damit ist Ihr Projekt jetzt in der Lage, sein eigenes Wissen zu tragen. Im nächsten Kapitel wird es sichtbar: UI Design und Frontend-Entwicklung.

Wissen gehört ins Repo, nicht in den Prompt

9:42 Der Satz auf dieser Folie ist die Quintessenz — und er gilt weit über Claude Code hinaus. Wissen, das nur im Prompt lebt, ist bei der nächsten Sitzung weg; Wissen, das im Repository liegt, gehört dem Team. Regeln in die `CLAUDE.md`, Können in Skills — mehr müssen Sie sich aus diesem Kapitel nicht merken. Und noch ein Gedanke für die Pause: Beides wächst am besten nebenbei.

10:05 Immer wenn Sie sich beim zweiten Erklären ertappen, ist das der Moment, eine Zeile zu ergänzen. Fragen und das Material zum Nachlesen finden Sie unter www.HCO.de.