Wenn du Claude und ChatGPT aufeinander ansetzt, kippt die Illusion der unfehlbaren Antwort schnell. So funktioniert das System, und so sieht der Prompt aus.

Warum KIs bessere Kritiker als Autoren sind

Sprachmodelle sagen das statistisch wahrscheinlichste nächste Wort voraus. Das macht sie gut im flüssigen Schreiben und gleichzeitig anfällig für Halluzinationen: Plausibilität schlägt Faktentreue.

Beim Reviewen dreht sich das Vorzeichen. Wenn ein Modell einen fertigen Text auf logische Brüche, fehlende Belege oder sachliche Fehler prüfen soll, muss es nichts erfinden. Es gleicht Muster ab. Man muss es nur in die Kritikerrolle zwingen.

Der Cross-Review-Workflow in drei Schritten

Für Recherchen, Code oder Argumentationen, bei denen ein Fehler weh tut:

1. Generieren. Modell A (z. B. ChatGPT) löst die Aufgabe.
2. Reviewen. Kopiere das Ergebnis, öffne eine frische Session bei Modell B (z. B. Claude) und füttere den Prompt unten.
3. Synthese. Gib Claudes Kritik zurück an ChatGPT und lass die bereinigte Fassung bauen.

Wichtig: frische Session. Sonst prüft dasselbe Modell seinen eigenen Text und findet fast nie etwas.

Der Prompt

Du bist ein kompromissloser, kritischer Faktenprüfer und Logik-Reviewer. 
Unten steht ein Text, den eine andere KI generiert hat. Deine Aufgabe ist es nicht, den Text zu loben oder umzuformulieren, sondern ihn methodisch zu zerlegen.

Bitte liefere mir eine strukturierte Analyse in drei Punkten:
1. Sachtreue & Fakten: Welche Behauptungen, Zahlen oder Daten wirken unbelegt, zweifelhaft oder sind nachweislich falsch?
2. Logische Brüche: Wo widerspricht sich der Text selbst oder zieht unbegründete Schlüsse?
3. Auslassungen: Welcher kritische Kontext fehlt, der die Aussage des Textes verfälschen könnte?

Sei extrem streng. Wenn alles korrekt erscheint, benenne die Stellen, die am schwersten unabhängig zu verifizieren sind.

Hier ist der zu prüfende Text:
[TEXT HIER EINFÜGEN]

Variante 2

Du bist ein kompromissloser Faktenprüfer und Logik-Reviewer.
Unten steht ein Text, den eine andere KI generiert hat. Deine 
Aufgabe ist nicht, ihn zu loben oder umzuformulieren, sondern 
methodisch zu zerlegen.

Liefere eine strukturierte Analyse in drei Punkten:

1. Sachtreue & Fakten: Welche Behauptungen, Zahlen oder Daten 
   sind unbelegt, zweifelhaft oder nachweislich falsch?
2. Logische Brüche: Wo widerspricht sich der Text oder zieht 
   unbegründete Schlüsse?
3. Auslassungen: Welcher Kontext fehlt, der die Aussage 
   verzerren könnte?

Sei streng. Wenn alles korrekt wirkt, benenne die Stellen, 
die am schwersten unabhängig zu verifizieren sind.

Hier ist der zu prüfende Text:
[TEXT HIER EINFÜGEN]

Was in der Praxis passiert

Frag ChatGPT nach den wichtigsten rechtlichen Fallstricken bei KI-Bildgenerierung 2026 und du bekommst eine saubere, flüssig lesbare Liste.

Jag diese Liste mit dem Prompt oben durch Claude, und es meldet:

• „Punkt 3 verweist auf ein BGH-Urteil aus Mai 2025. Das existiert in dieser Form nicht. Wahrscheinlich eine Halluzination oder Verwechslung mit dem EU AI Act.“
• „Absatz 1 behauptet, kommerzielle Nutzung sei immer legal. Absatz 3 warnt vor Markenrechten. Das widerspricht sich.“

Statt dem ganzen Text zu misstrauen, weißt du in zehn Sekunden, wo du nachbohren musst.

Fazit

Der Zwei-Quellen-Check kostet eine Minute mehr, spart aber die Blamage, wenn ein halluziniertes Detail in eine Mail an den Chef oder in einen Vertrag rutscht. Rechenzeit ist 2026 billig genug, dass du zwei KIs für dich arbeiten lässt, statt selbst durch Suchergebnisse zu scrollen.

Probier es beim nächsten Text aus, der stimmen muss.

Der Beitrag Der Zwei-Quellen-Prompt: Wie du KIs dazu bringst, sich gegenseitig zu reviewen erschien zuerst auf KI-Praxis.

Angefangen hat es mit einem Post von Hannah Samland: „Der Elias-Thorne-Effekt“. Sie beschreibt, wie Sprachmodelle beim Erfinden von Leuchtturm-Geschichten in über 88 Prozent der Fälle denselben Namen produzieren. Elias Thorne. Ein fiktiver Mann, den keine Bibliothek kennt, den aber ChatGPT, Claude und Gemini gleichermaßen ausspucken.

Der Post hat mich beschäftigt. Wenn Elias Thorne existiert, welche anderen Muster schleppen die Modelle noch mit? Wo produzieren sie Ausgaben, die du beim Prompten nicht bemerkst, weil sie plausibel klingen?

Ich habe recherchiert und die Primärquellen selbst gelesen. Neun Auffälligkeiten, zu jeder das Gegenmittel für den Alltag. Ich habe versucht, Behauptungen nur so weit tragen zu lassen, wie die jeweilige Studie sie deckt — inklusive der Modelle, Sprachen und Publikationsstatus, auf denen sie beruht.

1. Jedes Modell hat SEINEN Elias

Die Cornell-Studie von Hamilton und Mimno (arXiv-Preprint, nicht peer-reviewt), auf die Hannah sich bezieht, hat 20.000 englischsprachige Geschichten aus vier Modellen analysiert: Claude Haiku 4.5, Gemini 3.1 Flash-Lite, GPT-5.4-Mini und OLMo 7B. In 88,3 Prozent aller Geschichten taucht mindestens eines von elf Kernwörtern auf: Namen (Elias, Mara, Elara), Berufe (Keeper, Uhrmacher, Bibliothekar, Bäcker) und ein Ort — der Leuchtturm, in über der Hälfte aller Geschichten.

Die Pointe: Es ist nicht so, dass alle Modelle „Elias“ sagen. Sie greifen alle in denselben kleinen Pool, aber jedes Modell hat einen Favoriten daraus. Gemini erzeugt bevorzugt Elias, GPT bevorzugt Mara, OLMo bevorzugt Elara. Claude titelt 56 Prozent seiner Geschichten „The Lighthouse Keeper’s Secret“. „Elias“ kommt in KI-Texten rund 900 Mal häufiger vor als im Vergleichskorpus CONLIT (2.700 zeitgenössische englische Romane, etwa 287 Millionen Wörter).

Woher das kommt, ist Gegenstand einer Hypothese: Die Autoren finden im Post-Training-Datensatz von OLMo 3, dass die Kernwort-Dichte über die Alignment-Stufen hinweg steigt (SFT 3 Prozent, DPO 8 Prozent, RL knapp 11 Prozent). Das ist eine Korrelation, keine bewiesene Kausalität. Die Vermutung: Safety-Filter drängen Modelle weg von Fan-Fiction und heiklen Themen. Übrig bleibt eine idyllische, prämoderne Welt.

Gegenmittel: Gib beim Erfinden immer Name, Beruf und Ort vor. Drei konkrete Vorgaben, und der Standard-Cluster ist neutralisiert. Quelle: Hamilton & Mimno, arXiv 2605.26492 (Preprint).

2. „Zieh eine Zahl zwischen 1 und 50″

Bei diesem Prompt antworten ChatGPT, Claude, Bing Copilot und Gemini alle mit 27 — das hat IFLScience selbst getestet, mit den zum Testzeitpunkt (Juli 2025) aktuellen Consumer-Versionen. Für den Bereich 1 bis 100 fand eine separate Studie (arXiv 2502.19965) die Favoriten 37, 47 und 73 — alles Primzahlen, die auch Menschen als „gefühlt zufällig“ wählen. Eine ältere Analyse mit GPT-3.5, Claude 3 Haiku und Gemini 1.0 Pro fand für den Bereich 0 bis 100 die Favoriten 47, 42 und 72 (42 und 72 sind keine Primzahlen — die Primzahl-Präferenz ist also ein Muster, nicht das einzige).

Die Modelle produzieren keinen Zufall, sondern reproduzieren Verteilungen aus ihren Trainingsdaten. Das Veritasium-Experiment mit 200.000 Menschen zeigt: Menschen greifen bei „nenn eine Zufallszahl“ bevorzugt zu Zahlen mit 7 am Ende. Die Modelle spiegeln das.

Gegenmittel: Nutze die KI nie als Zufallsgenerator. Wenn du zufällige Zahlen brauchst, nimm Python, Excel oder einen Würfel. Quellen: IFLScience, sanand0.github.io/llmrandom.

3. Die verräterischen Lieblingswörter

Juzek und Ward von der Florida State University haben englischsprachige wissenschaftliche Abstracts aus 2020 und 2024 verglichen und 21 Wörter identifiziert, deren Häufigkeit in den vier Jahren sprunghaft angestiegen ist. Sie haben denselben Set dann bei ChatGPT-generierten Abstracts wiedergefunden. Zu den im Paper konkret genannten Wörtern gehören delve, intricate, underscore, resonate, navigate, commendable, realm und garnered.

Was die Studie zeigt: In einem Modellvergleich reagierte die auf menschliche Präferenzdaten trainierte Llama-Variante weniger „überrascht“ auf Buzzword-Abstracts als das Basismodell — Präferenzdaten sind vermutlich mitverantwortlich für die Wortwahl. In einem Online-Experiment straften Testpersonen Abstracts mit „delve“ stärker ab als andere Buzzwords. Was die Studie nicht zeigt: eine Längsschnitt-Wirkung der Modelle auf menschliche Schreibpräferenzen. Der breitere Kulturwandel bleibt Vermutung.

Gegenmittel: Bau dir eine persönliche Blacklist der Wörter, die du im KI-Output umgehend ersetzt. Alternativ: gib die Liste im System-Prompt mit dem Hinweis „diese Wörter niemals verwenden“. Quelle: Juzek & Ward, arXiv 2412.11385 (auf der COLING 2025 präsentiert).

4. Option A gewinnt fast immer

Melanie Brucks und Olivier Toubia von der Columbia Business School zeigen: Wenn du ChatGPT zwei oder mehr Optionen zur Bewertung vorlegst, wählt es überproportional häufig die erste. Egal wie du den Prompt formulierst. Die Autoren beschreiben eine Mitigation, die aber sauber verstanden werden muss: Sie reduzieren den Bias, indem sie Ergebnisse aus mehreren, unterschiedlich formulierten Prompt-Varianten aggregieren. Eine einzelne Umkehrung der Reihenfolge reicht dafür nicht aus.

Gegenmittel: Bei jeder KI-Entscheidungshilfe die Optionen in mindestens drei bis fünf verschieden formulierten Varianten abfragen und die Ergebnisse gewichten. Wenn dieselbe Option in der Mehrzahl der Varianten gewinnt, ist das ein belastbareres Signal. Quelle: Columbia Business School Press Release zum Brucks/Toubia-Papier.

5. Der Zustimmungsreflex („Sycophancy“)

Frag ein Sprachmodell „stimmst du dem zu?“ — es stimmt fast immer zu. Das Phänomen hat einen Namen: Sycophancy. Belegt unter anderem in zwei Anthropic-Papieren. Perez et al. (2022) zeigen: Größere Modelle zeigen stärkere Sycophancy — sie geben in politischen und faktischen Fragen bevorzugt die Antwort zurück, die der Nutzer erwartet. Sharma et al. (2023) zeigen: Sowohl Menschen als auch Präferenzmodelle bevorzugen überzeugend geschriebene sycophantische Antworten gegenüber korrekten, in einem nicht vernachlässigbaren Anteil der Fälle. Das Anreizsystem des RLHF-Trainings baut den Reflex mit ein.

Gegenmittel: Zwing die KI zur Gegenposition. Statt „stimmst du zu?“ formuliere „nenne mir die drei stärksten Argumente gegen diese These“. Nur so wird das Modell zu einem Prüfstein statt zu einem Verstärker. Quellen: Perez et al. 2022 (Anthropic), Sharma et al. 2023, arXiv 2310.13548 (auf der ICLR 2024 präsentiert).

6. Was Midjourney unter „an Indian person“ versteht

Rest of World (journalistische Analyse, kein Peer-Review) hat 3.000 Midjourney-Bilder ausgewertet: 5 Prompts × 6 Länder × 100 Bilder. Ergebnisse aus den Rohdaten:

• „an Indian person“ ist zu 99 von 100 ein alter Mann mit Bart, meist mit Turban
• „a Mexican person“ trägt zu 99 von 100 einen Sombrero
• „an American person“ ist zu 94 von 100 eine junge Frau (das einzige Land mit Frauen-Dominanz)
• Alle 100 „plate of American food“-Bilder enthalten eine US-Flagge

Zusätzlich zitiert Rest of World den Dozenten Siu Yan Ho von der Hong Kong Baptist University zur Darstellung von chinesischem Essen: Die Essstäbchen erschienen in den generierten Bildern häufig in ungerader Zahl, was in der chinesischen Esskultur als unheilvoll gilt. In fast allen anderen Ländern dominieren Männer beim „person“-Prompt. Frauen werden systematisch heller dargestellt als Männer aus demselben Land.

Gegenmittel: Alter, Geschlecht, Religion, Beruf und Kontext immer explizit vorgeben. Nichts der KI überlassen, was Repräsentation betrifft. Quelle: Rest of World, Oktober 2023 (journalistische Analyse).

7. KI-Assistenten machen dein Deutsch amerikanischer

Dhruv Agarwal, Mor Naaman und Aditya Vashistha von Cornell haben 118 Probanden (etwa halb US, halb Indien) Aufsätze zu Kultur-Themen schreiben lassen, jeweils mit und ohne KI-Autocomplete auf englischsprachiger Basis. Konkrete Befunde:

• Bei „dein Lieblingsessen“ schlug die KI konsistent Pizza vor, bei „Lieblingsfeiertag“ Weihnachten — unabhängig von der Herkunft der Person
• Als ein indischer Nutzer „S“ tippte, um „Shah Rukh Khan“ zu vervollständigen, schlug die KI Shaquille O’Neal oder Scarlett Johansson vor
• Ohne KI-Hilfe schrieb ein indischer Teilnehmer über Diwali, er würde „Göttin Laxmi verehren und Kracher zünden“. Mit KI-Hilfe wurde daraus „traditionelle indische Frühstücksitems essen“

Die Forscher selbst bezeichnen das Phänomen als „AI colonialism“. Der Sog geht in eine Richtung: hin zum amerikanischen Mittelwert. Ob sich der Effekt auf deutschsprachige Nutzer im gleichen Maß überträgt, ist nicht untersucht, aber plausibel.

Gegenmittel: Nutze KI erst nach deinem eigenen ersten Entwurf, nicht davor. Der eigene erste Wurf verankert deine Perspektive im Kontext und macht dich weniger anfällig für die Standard-Vorschläge — das ist keine Beweisführung, aber eine sinnvolle Arbeitshypothese aus der Studie. Quelle: Agarwal, Naaman & Vashistha, arXiv 2409.11360, präsentiert bei CHI 2025.

8. Der immer gleiche Standard-Plot (bei GPT-4o-mini)

Jill Walker Rettberg und Hermann Wigers haben GPT-4o-mini — und nur dieses eine Modell — 11.800 Geschichten schreiben lassen, jeweils 50 pro Land für 236 Länder, mit dem Prompt „Write a 1500 word potential {demonym} story“. Fast alle Geschichten folgen demselben Bogen:

Ein Protagonist kehrt in eine Kleinstadt zurück (oder lebt schon dort), löst einen kleinen Konflikt durch die Rückbesinnung auf Tradition und organisiert am Ende ein Community-Event. Reale Konflikte werden entschärft, Romantik fehlt fast komplett. Nationale Symbole sind Oberflächenschmuck, die Struktur darunter ist überall gleich. Die Autoren nennen es „narrative homogenisation“ — Stabilität schlägt Wandel.

Wichtige Einschränkung: Der Befund ist mit einem Modell und einem sehr spezifischen Prompt-Muster produziert. Ob GPT-4o (nicht mini), Claude oder Gemini denselben Bogen erzeugen, ist offen. Der Standard-Plot ist bei diesem einen Modell dokumentiert — nicht als universelles KI-Verhalten.

Gegenmittel: Wenn du KI für Story-Ideen nutzt, gib Konflikt, Wendepunkt und Ende explizit vor. „Der Protagonist scheitert“ oder „das Ende darf kein Happy End sein“. Quelle: Walker Rettberg & Wigers, arXiv 2507.22445 (Preprint), erschienen in Open Research Europe.

9. UNESCO: Frauen im Haushalt, Zulu-Männer als Wachleute

Die UNESCO-Studie „Bias Against Women and Girls in Large Language Models“ (März 2024) hat drei Modelle getestet, die heute alle als veraltet gelten: GPT-3.5, GPT-2 und Llama 2. Ergebnisse:

• Frauen wurden viermal so häufig in häuslichen Rollen beschrieben wie Männer
• Männliche Namen wurden mit „business“, „executive“, „salary“, „career“ assoziiert
• Zulu-Männer bekamen häufig die Berufe „Gärtner“ und „Wachmann“ zugewiesen
• 20 Prozent der Texte über Zulu-Frauen ordneten sie als „Hausangestellte“, „Köchin“ oder „Haushälterin“ ein
• Britische Männer wurden mit variablen Berufen beschrieben: „driver“, „doctor“, „bank clerk“, „teacher“

Die freien Open-Source-Modelle (Llama 2, GPT-2) zeigten die stärksten Verzerrungen. Ob GPT-4, Claude 3+ oder Gemini 2+ dieselben Muster zeigen, ist mit dieser Studie nicht beantwortet.

Gegenmittel: Beruf, Herkunft und Rolle pro Figur explizit vorgeben. Wer das nicht tut, riskiert eine Version der 1950er. Quelle: UNESCO, März 2024.

Was diese neun Punkte gemeinsam haben — und was nicht

Es ist verlockend, alles unter einen Begriff zu ziehen („die KI greift zum Mittelwert“). Ich benutze das Bild bewusst als Metapher, nicht als Erklärung. Denn die neun Muster haben unterschiedliche Ursachen:

• Alignment-induzierte Modenverstärkung (Punkte 1, 8): Wenige Trainingsbeispiele in den Alignment-Stufen prägen den Output überproportional
• Priors aus menschlichen Präferenzdaten (Punkte 2, 3, 5): Modelle reproduzieren Verzerrungen, die Menschen in ihre Bewertungen einbringen
• Architektonischer Positional Bias (Punkt 4): Die Verarbeitung von Sequenzen bevorzugt frühe Tokens
• Repräsentations-Bias aus Trainingsdaten (Punkte 6, 9): Was in den Trainingsdaten über- oder unterrepräsentiert ist, prägt den Output
• Kulturelle Homogenisierung via Autocomplete (Punkt 7): Vorschläge in Echtzeit ziehen den Autor unbewusst in die Standardsprache

Was alle Muster teilen, ist eine Konsequenz für die Praxis: Je weniger du vorgibst, desto stärker greifen die eingebauten Defaults. Je konkreter dein Prompt, desto weniger Raum bleibt für sie.

Und ein Nachgedanke aus dem Rechercheweg selbst: Verlinke keine Quelle, die du nicht gelesen hast. Ich habe für diesen Artikel jede Studie im Original geprüft und musste dabei mehrere Zahlen streichen, die ich mir aus Sekundärquellen zusammengesucht hatte. Das ist unangenehm, aber der einzige Weg. Alles Andere macht dich zum Weiterverbreiter genau der Muster, die du beschreiben willst.

Danke an Hannah für den Startpunkt — und an einen strengen Peer-Review, der mich gezwungen hat, den Text noch einmal zu schärfen.

Ursprung meiner Recherche: Hannah Samland, „Der Elias-Thorne-Effekt“, Juni 2026.

Hinweis zur Belegdichte: Peer-reviewt sind die Studien zu Sycophancy (Sharma et al., ICLR 2024; Perez et al., ACL Findings 2023) sowie das Delve-Papier (COLING 2025). Preprint-Status: Hamilton & Mimno (Punkt 1), Walker Rettberg & Wigers (Punkt 8), Agarwal et al. (Punkt 7, präsentiert bei CHI 2025). Journalistische Analyse: Rest of World (Punkt 6). Institutioneller Bericht: UNESCO (Punkt 9).

Der Beitrag Neun stille Reflexe deiner KI – und was du dagegen tust erschien zuerst auf KI-Praxis.

Warum deine Bibliothek nicht funktioniert

Meine Prompt-Bibliothek lebte in Obsidian. Achtzehn Monate, siebenundachtzig Einträge, farbcodiert bis in die dritte Verschachtelungsebene. Ich habe sie gepflegt wie ein Archiv. Und wie ein Archiv hat sie mir nichts zurückgegeben.

Der Mechanismus ist einfach: eine gespeicherte Anweisung ist keine Arbeit. Sie ist die Erinnerung an einen einmaligen Moment, in dem du dachtest, das könnte man mal brauchen. Der Moment kommt wieder, du erinnerst dich vage, dass da was war, du suchst, du findest den falschen Eintrag, du tippst neu, weil das schneller geht.

Der Reddit-Thread „How are you organizing prompts once you have hundreds?“ sammelt genau diese Frustration in fünfundzwanzig Antworten. Keine der Antworten löst das Problem. Sie schlagen bessere Ordnersysteme vor. Die Adressierung ist das eigentliche Problem: dein Prompt wartet in deiner Ablage, dass du ihn findest. Kein Werkzeug funktioniert so.

Skills drehen die Adressierung um. Der Prompt wartet nicht auf dich. Er greift, wenn der Anlass da ist.

Was ein Skill technisch ist

Vergiss kurz, was auf der Marketingseite steht. In der Praxis ist ein Skill eine kleine Datei mit vier Bestandteilen: Name, Trigger-Beschreibung, Anweisung, optionale Referenzen. Wenn Claude auf einen passenden Trigger stößt, lädt der Skill die Anweisung selbstständig und arbeitet danach. Kein Copy-Paste, kein Suchen.

Für den Überblick, was gerade an Skills gebaut wird, lohnt sich Firecrawls Best-Claude-Skills-Liste und der virale „72 Essential Claude Skills“-Post. Vorsicht: die Listen sind Inspiration, keine Vorlage. Der Skill, der bei mir läuft, hilft dir wenig, wenn dein Anlass ein anderer ist. Wer Skills wie Software installiert, baut sich nur eine neue Bibliothek mit .md-Endung.

Der Umbau in fünf Schritten

Schritt 1: Bestandsaufnahme in einer Stunde

Öffne deine Prompt-Bibliothek und mach zwei Spalten. Links: die Prompts, die du in den letzten vier Wochen tatsächlich benutzt hast. Rechts: alle anderen. Wenn du dich nicht sicher erinnerst, gehört der Eintrag rechts. Zufriedene Erinnerung ist keine Nutzung.

Meine linke Spalte hatte am Ende sechs Einträge. Von siebenundachtzig. Wenn deine linke Spalte länger ist als zehn, hast du entweder eine sehr präzise Bibliothek oder ein Erinnerungsproblem. Für den zweiten Fall: notiere die nächsten sieben Tage jede tatsächliche Prompt-Nutzung mit Zeitstempel. Danach machst du die Bestandsaufnahme neu.

Schritt 2: Die Drei-Mal-Regel als Filter

Für die Prompts der linken Spalte: wie oft hattest du in einer normalen Woche wirklich Anlass, diesen Prompt zu benutzen? Weniger als dreimal pro Woche bedeutet: kein Skill. Der Prompt ist gut, aber der Anlass ist zu selten, um die Skill-Infrastruktur zu rechtfertigen. Speichern kannst du ihn trotzdem. In einer Datei. Nicht als Skill.

Diese Regel hat mir zwei bereits gebaute Skills wieder gelöscht: einen „Wochenrückblick“ und ein „Meeting-Follow-up“. Beide klangen sinnvoll. Beide wurden nie ausgelöst. Wer den Bautrieb der ersten Tage nicht durch eine harte Anlass-Regel bremst, sammelt Skills statt Prompts. Das Ergebnis ist dasselbe wie vorher, nur mit mehr Overhead.

Schritt 3: Skill-Anatomie

Ein Skill besteht aus vier Ebenen. Der Name ist kurz, eindeutig, ohne Sonderzeichen. „morgen-briefing“ schlägt „Mein täglicher Morgen-Digest v2″. Die Trigger-Beschreibung legt fest, unter welchen Bedingungen der Skill greift. Formuliert für Claude, nicht für dich: welche Wörter fallen im Prompt, welcher Kontext ist da, was fragt der Nutzer? Die Anweisung ist die eigentliche Arbeit. Was soll passieren, in welcher Reihenfolge, mit welchem Output. Konkret, mit Beispielen, mit klaren Constraints. Die Referenzen sind optionale Dateien, die der Skill bei Bedarf mitlädt: Templates, Datenquellen, Style-Guides.

Wer die Struktur an echten Beispielen studieren will, findet in der Anthropic-eigenen Skill-Sammlung auf GitHub und in Firecrawls Kuration sehr unterschiedliche Bauweisen. Ein guter Ausbildungspfad: drei fremde Skills lesen, bevor du deinen ersten schreibst. Nicht mehr, sonst kippt Studieren in Aufschieben.

Schritt 4: Bau den ersten Skill

Nimm den meistgenutzten Prompt aus deiner linken Spalte. Bei mir war das ein Prompt-Optimierer: „Nimm meinen Rohgedanken und mach daraus einen sauberen Prompt für die Chat-App.“ Aus dem wurde der Skill 47.

Der Aufbau, in echt: Der Name ist zwei Zeichen. Der Trigger beschreibt, was der Nutzer sagt, wenn er einen Prompt geschrieben haben will: rohe Formulierung, Bitte um Prompt-Optimierung, halbfertige Idee. Die Anweisung ist vier Absätze lang. Sie legt fest, dass der Output ein direkt paste-fertiger Prompt ist, wie die Rolle klar formuliert wird, wie die Constraints sitzen und in welchem Format der Output kommt (Codeblock, ohne Vorrede). Referenzen: keine.

Bau ihn, lade ihn hoch, teste ihn zehnmal in echter Arbeit. Nicht in „ich probiere den Skill mal aus“-Sessions. In echter Arbeit. Der Skill, der im Testszenario glänzt und im Alltag nie greift, ist typisch. Der Test ist Alltag, nicht Labor.

Schritt 5: Iteration und Wegwerfen

Nach zwei Wochen prüfst du: welche Skills sind tatsächlich gelaufen? Zähle Auslösungen, nicht Zufriedenheit. Ein Skill mit drei Auslösungen pro Woche ist ein Skill. Ein Skill mit einer Auslösung in vier Wochen ist ein Kandidat für die Tonne, egal wie schön er ist.

Meine Löschquote nach sechs Monaten: zwei von achtzehn. Klingt niedrig, weil die Drei-Mal-Regel aus Schritt 2 das meiste schon vorher aussortiert. Ohne diese Regel wären es vermutlich zehn von achtzehn. Der Reddit-Thread „letting Claude run unattended for three hours changed how i feel about my own job more than the output did“ beschreibt eine typische Nebenwirkung: wenn Skills wirklich laufen, ändert das auch, wie du deine Rolle liest. Nimm das ernst.

Drei Fallstricke, die alle unterschätzen

Der Skill ersetzt kein Verständnis. Wenn du nicht weißt, was du willst, produziert der Skill mit derselben Präzision Blödsinn wie ohne. Der Skill, den ich zum Prüfen meiner deutschen Texte gebaut habe, prüft nach Mustern. Er kann mir nicht sagen, ob ich überhaupt etwas zu sagen habe.

Der Skill ersetzt keine Ordnung. Der Datenmerge-Skill, den ich für Amazon-Berichte gebaut habe, funktioniert, weil ich meine Berichte in einem konsistenten Ordner mit klarem Namensschema ablege. Ohne diese Ordnung produziert er Chaos in ordentlicher HTML-Verpackung. Wer Skills als Ausrede benutzt, um keine Ablagen zu bauen, macht sich die Arbeit doppelt.

Der Skill macht nicht schneller. Die Ausführung selbst spart selten Sekunden. Was Skills sparen: den Umweg, an dem du sonst hängen geblieben wärst. Sie senken die Aktivierungsenergie so weit, dass Dinge passieren, die ich sonst aufgeschoben hätte. Für Guides zu diesem Punkt lohnt der YouTube-Guide zu Claude Skills von Anthropic: technisch sauber, ohne den üblichen Produktivitäts-Hype.

Der Kern in einem Satz

Sammle nicht mehr, was du irgendwann brauchen könntest. Bau drei bis fünf Anweisungen, die tun, was regelmäßig ansteht, wenn der Anlass da ist. Alles andere ist Verwaltung, die sich für Werkzeug hält.

Nach einer Woche mit dieser Methode weißt du, welche Skills bei dir wirklich taugen. Nach zwei Monaten weißt du, welche Prompts aus deiner alten Bibliothek überhaupt Nutzen stifteten. Der Rest ist Archiv. Behalten oder löschen ist egal. Öffnen wirst du ihn ohnehin nicht mehr.

Quellen und Kontext:

• r/PromptEngineering: How are you organizing prompts once you have hundreds?
• Best Claude Code Skills to Try in 2026 (Firecrawl)
• 72 Essential Claude Skills — Viral X/Twitter Article Tracking
• Claude Skills Tutorial (YouTube)
• r/ClaudeAI: letting Claude run unattended for three hours…

Der Beitrag Hör auf, Prompts zu sammeln. Fang an, Skills zu bauen: der Umbau in einer Woche. erschien zuerst auf KI-Praxis.

Heißt konkret: Hier auf KI-Praxis wird es in nächster Zeit ziemlich still. Vielleicht schaffe ich es am Wochenende noch, den einen oder anderen Artikel vorzuschreiben – versprechen mag ich das aber nicht.

Falls euch die Zeit lang wird: Im Archiv gibt’s genug zum Nachlesen, und wer meinen Newsletter auf Substack abonniert hat, bekommt sowieso Bescheid, sobald ich wieder am Start bin. Dort werde ich bestimmt auch in der Zwischenzeit fleißig restacken.

Bis bald, Mirko

Der Beitrag Kurze Sendepause: Ab Dienstag geht’s erneut in die Reha erschien zuerst auf KI-Praxis.

1. Warum CLAUDE.md alles verändert

Wenn du KI-Assistenten wie Claude regelmäßig für ernsthafte Arbeit nutzt, kennst du das Muster: Jeder neue Chat startet mit einer Aufwärmphase. Du erklärst, was das Projekt ist, welche Konventionen gelten, was auf keinen Fall passieren darf. Fünf Minuten Kontext-Setup, jedes einzelne Mal. Und trotzdem erwischst du den Assistenten dabei, wie er die Konvention verletzt, die du beim dritten Chat vergessen hast zu erwähnen. Genau dieses Problem löst die CLAUDE.md.

Die CLAUDE.md ist keine Nice-to-have-Datei. Sie ist der Unterschied zwischen einem Assistenten, der bei jeder Sitzung wieder bei Null anfängt, und einem, der bereits weiß, wie dein Projekt tickt, welche Konventionen gelten und was auf keinen Fall passieren darf. Anthropic beschreibt sie als „besondere Datei, die Claude zu Beginn jeder Konversation liest“ und die persistenten Kontext liefert, den Claude aus dem Code allein nicht ableiten kann.

In der Praxis heißt das: Statt jeden Chat mit einem Absatz zu starten wie „Wir arbeiten in TypeScript, benutzen Vitest, halten uns an Conventional Commits, die API läuft auf Port 3001…“, schreibst du das einmal in die CLAUDE.md und Claude hat es ab jetzt jedes Mal parat. Der Effekt ist messbar. Eine viel zitierte Auswertung eines Karpathy-inspirierten Regelwerks berichtet einen Rückgang von Fehlerraten von 41 Prozent auf 11 Prozent, allein durch eine gut kuratierte CLAUDE.md.

Die Kennzahlen im Überblick:

• 200 Zeilen Zielgröße
• 6 Memory-Ebenen in Claude Code
• 150–200 Instruktionen, die zuverlässig befolgt werden

Die entscheidende Einsicht: Diese Datei landet bei jeder Anfrage im Kontextfenster. Jede Zeile kostet Tokens, die dann nicht mehr für deinen eigentlichen Code oder Text zur Verfügung stehen. Deshalb geht es nicht darum, so viel wie möglich reinzupacken, sondern so wenig wie nötig – aber genau das Richtige.

Der zweite Punkt, den viele unterschätzen: Eine gute CLAUDE.md ist nicht nur ein Werkzeug, um Claude zu instruieren. Sie ist ein Werkzeug, um dich selbst zu zwingen, deine eigenen Regeln explizit zu machen. Vieles, was du im Kopf hast – „wir committen keine .env-Dateien“, „wir nutzen Vitest statt Jest, weil…“, „die API-Auth läuft immer über diese eine Middleware“ – ist implizites Wissen. Sobald du es aufschreibst, wird es prüfbar. Neue Team-Mitglieder profitieren. Du selbst profitierst, weil du in zwei Monaten nicht mehr rekonstruieren musst, warum ihr euch damals so entschieden habt. Die CLAUDE.md ist zwei Werkzeuge in einem: KI-Instruktion und Team-Dokumentation, gleichzeitig.

Die Datei-Hierarchie verstehen

Claude Code liest nicht nur eine einzige CLAUDE.md. Es gibt eine ganze Hierarchie von Speicher-Ebenen, und wer sie kennt, kann sauber zwischen persönlichen, projektspezifischen und teamweiten Regeln trennen. Diese Trennung ist keine Formalie, sondern die Grundlage dafür, dass mehrere Menschen an derselben Codebasis mit demselben Assistenten arbeiten können, ohne sich in die Quere zu kommen.

Die Regel: Global ist für Dinge, die für dich in jedem Projekt gelten (z. B. „antworte auf Deutsch“, „erkläre Änderungen kurz“). Projekt ist für alles, was das Team teilen muss (Build-Commands, Architektur, Konventionen). Projekt-lokal ist für deine persönlichen Eigenheiten in genau diesem Projekt.

Wichtig zur Reihenfolge: Innerhalb eines Verzeichnisses wird CLAUDE.local.md nach CLAUDE.md geladen. Bei Konflikten gewinnt also das Letzte, was Claude gelesen hat. Nutze das bewusst: Projekt-Regeln sind der Konsens, deine lokale Datei überschreibt gezielt.

3. Die goldene 200-Zeilen-Grenze

Die vielleicht wichtigste Zahl in diesem ganzen Leitfaden: Halte deine CLAUDE.md unter 200 Zeilen. Anthropic empfiehlt das explizit, und der Grund ist nicht Ästhetik, sondern ein Phänomen namens Context Rot. Der Begriff beschreibt einen unangenehmen Effekt in großen Sprachmodellen: Je mehr Text im Kontextfenster liegt, desto schlechter werden einzelne Details befolgt. Regeln am Anfang gewinnen an Gewicht; Regeln in der Mitte werden verwaschen; Regeln, die mit vielen anderen zusammen auftauchen, verlieren an Durchschlagskraft.

Ein Chroma-Benchmark aus 2025 hat gezeigt, dass alle 18 getesteten Frontier-Modelle – inklusive Claude Opus 4 – bei wachsender Kontextlänge an Präzision verlieren. Einige fielen von 95 Prozent Trefferquote auf 60 Prozent, sobald ein bestimmter Schwellenwert überschritten wurde. Übersetzt: Je mehr Regeln du reinschreibst, desto weniger davon werden zuverlässig befolgt. Das ist paradox, aber messbar: Die 201. Regel senkt die Wahrscheinlichkeit, dass die 12. Regel eingehalten wird.

Dazu kommt: Claude Code selbst verbrennt bereits rund 50 der zuverlässig befolgbaren 150 bis 200 Instruktionen für seinen eigenen System-Prompt. Was übrig bleibt, ist wertvoll. Nutze es für Dinge, die nirgends sonst stehen.

Ja, das gehört rein:

• Build- und Test-Kommandos
• Harte Einschränkungen („niemals X“)
• Architektur in drei Sätzen
• „Wir nutzen X, nicht Y“-Entscheidungen
• Bekannte Stolperfallen

Nein, das gehört raus:

• Standard-Best-Practices für die Sprache
• Alles, was aus dem Code offensichtlich ist
• Detaillierte Feature-Beschreibungen
• Lange Prosa-Erklärungen
• Aspirations-Floskeln („schreibe schönen Code“)

4. Spezifisch statt vage: warum „schöner Code“ nichts bringt

Die vielleicht häufigste Falle: Regeln, die wie Ratschläge aus einem Coaching-Buch klingen. „Sei konsistent.“ „Schreibe sauberen Code.“ „Denke an die Wartbarkeit.“ Solche Anweisungen sind für ein Sprachmodell wertlos, weil sie keine überprüfbare Aussage machen. Der Assistent hat keinen internen Kompass für „sauber“ – er hat statistische Muster aus Millionen Beispielen, in denen unterschiedlichste Codestile „sauber“ genannt wurden. Wenn du willst, dass Claude einen bestimmten Stil erzeugt, musst du diesen Stil operational beschreiben.

Vage (unwirksam): „Schreibe schönen, konsistenten Code.“ Claude weiß nicht, was du mit „schön“ meinst. Jede Sitzung interpretiert es anders.

Spezifisch (wirksam): „Nutze 2-Space-Einrückung. Single Quotes für Strings. Trailing Commas in Multiline-Objekten. Server Components als Default; ‚use client‘ nur wenn nötig.“ Testbar. Reproduzierbar. Kein Interpretationsspielraum.

Die Faustregel: Wenn du eine Regel nicht mit einem einzelnen Test oder einem Grep-Befehl verifizieren könntest, ist sie zu vage. Formuliere sie so, dass sie in einem PR-Review-Kommentar landen könnte.

Beispiele für konkrete Formulierungen:

# Statt "gute Fehlerbehandlung":
- Werfe niemals nackte Error-Instanzen. Nutze AppError mit code-Feld.
- Fange Exceptions nur, wenn du sie sinnvoll behandeln kannst.
- Logge Fehler mit logger.error(), niemals console.log().

# Statt "sauberer Test-Code":
- Jeder Test folgt Arrange/Act/Assert, getrennt durch Leerzeilen.
- Test-Namen im Format "sollte X, wenn Y".
- Keine Mocks, wo ein echter Fake ausreicht.

# Statt "gute Commits":
- Conventional Commits: feat:, fix:, chore:, docs:.
- Betreff unter 60 Zeichen, Imperativ.
- Body erklärt warum, nicht was.

5. Das Karpathy-Framework: vier Regeln, die alles verändern

Andrej Karpathy hat mit einer minimalistischen CLAUDE.md aus vier Regeln eine Bewegung ausgelöst. Das zugehörige Repository sammelte innerhalb weniger Wochen über 100.000 GitHub-Sterne. Der Grund: Die vier Regeln zielen nicht auf Formatierung, sondern auf die eigentlichen Fehlermodi von Coding-Agenten. Karpathy hatte über Monate beobachtet, wie moderne KI-Assistenten dieselben Fehler in immer neuen Verkleidungen wiederholen, und daraus vier Grundprinzipien destilliert, die diese Fehler an der Wurzel packen.

1. Think Before Coding – Kläre Annahmen, bevor du losschreibst. Wenn etwas unklar ist, frag nach oder markiere die Unsicherheit explizit.
2. Simplicity First – Wähle die einfachste Lösung, die funktioniert. Kein Overengineering, keine spekulative Abstraktion.
3. Surgical Changes – Ändere nur, was für die Aufgabe nötig ist. Kein Umformatieren nicht betroffener Dateien.
4. Goal-Driven Execution – Definiere konkrete Erfolgskriterien, bevor du anfängst. Was muss am Ende wahr sein?

Diese vier adressieren exakt die vier Failure Modes, die Karpathy dokumentiert: Modelle machen stille Annahmen, bauen zu komplex, fassen zu viel an, und arbeiten ohne klares Erfolgskriterium.

# Grundregeln

## 1. Denken vor Coden
Bevor du Code schreibst, formuliere in 3–5 Sätzen:
- Was ist die Aufgabe konkret?
- Welche Annahmen mache ich?
- Wo bin ich unsicher?
Stelle Rückfragen, statt zu raten.

## 2. Einfachheit zuerst
Wähle die kleinste Lösung, die den Test besteht.
Keine Klassen, wo Funktionen reichen.
Keine Abstraktionen für hypothetische Zukunftsfälle.

## 3. Chirurgische Änderungen
Fasse nur an, was für die Aufgabe nötig ist.
Kein Umformatieren, kein "opportunistisches" Refactoring.
Wenn du Nachbarcode anfassen willst, frag vorher.

## 4. Ziel-gesteuerte Ausführung
Vor dem Start: liste die Erfolgskriterien.
Am Ende: prüfe jedes einzelne ab.
Kein "sieht fertig aus" – nur "Test grün, Kriterium erfüllt".

Karpathy hat sein Framework 2026 auf zehn Regeln erweitert, mit sechs zusätzlichen Selbstprüfungs-Protokollen für Runtime-Fehler:

1. Reproduce before fix – Jeder Bug bekommt zuerst einen Test, der ihn zuverlässig reproduziert, dann erst die Korrektur.
2. Token-Budgets – Jeder KI-Schritt läuft unter einer Obergrenze pro Schritt, pro Pipeline und pro Tag.
3. No silent overruns – Fehler werden geloggt und dem Operator gemeldet, nie stumm ausgesessen.
4. Destructive only with consent – Löschungen, Migrationen, Deployments brauchen explizite Bestätigung.
5. Prompt-Injection-Guardrails – Nutzer-Input, der als Instruktion verstanden werden könnte, wird gekennzeichnet.
6. Trust but verify – Jede wichtige KI-Ausgabe wird gegen eine zweite Instanz (Test, Regel, Review) geprüft.

Diese sechs sind für produktive Pipelines gedacht, in denen Claude autonom Aktionen ausführt. Für die klassische „ich schreibe mit Claude Code an einem Projekt“-Nutzung reichen meistens die ersten vier. Die Erweiterung wird relevant, sobald Claude über CI/CD, Deploy-Bots oder Scheduled Tasks in echte Systeme eingreift.

6. IMPORTANT und YOU MUST: wie du Adherence erzwingst

Anthropic dokumentiert in seinen eigenen Guidelines, dass Instruktionen mit IMPORTANT oder YOU MUST verstärkt werden können. Das ist kein Marketing-Trick, sondern reflektiert, wie das Modell trainiert wurde: Diese Signalwörter erhöhen die Wahrscheinlichkeit, dass eine Regel auch unter Druck eingehalten wird.

Nutze das sparsam. Wenn alles IMPORTANT ist, ist nichts mehr IMPORTANT. Reserviere die Verstärkung für Regeln, deren Verletzung echten Schaden anrichtet.

## Harte Grenzen

IMPORTANT: Schreibe niemals in die Produktions-Datenbank aus Tests.
IMPORTANT: Committe nie .env-Dateien oder Dateien in secrets/.
YOU MUST jeden neuen API-Endpunkt durch requireAuth schleusen.
YOU MUST destruktive DB-Migrationen explizit bestätigen lassen.

## Weiche Präferenzen

Bevorzuge async/await über .then()-Chains.
Nutze Tailwind-Utilities statt eigener CSS-Klassen.
Halte Funktionen unter 50 Zeilen, wo sinnvoll.

Beachte den Unterschied im Ton: Die harten Grenzen sind Verbote, die Präferenzen sind Empfehlungen. Claude wird beides berücksichtigen, aber bei den harten Grenzen deutlich strikter sein.

7. Progressive Disclosure: modular arbeiten mit @-Imports

Was tun, wenn du eigentlich mehr als 200 Zeilen an Regeln hast? Antwort: Du packst sie nicht in die CLAUDE.md, sondern in getrennte Dateien, die Claude bei Bedarf nachlädt. Das ist die Idee hinter Progressive Disclosure – ein Prinzip aus dem UX-Design, das sich hier hervorragend auf Prompting anwenden lässt.

Die Grundidee: Zeige immer nur das, was gerade relevant ist. Details bleiben zugänglich, aber verstecken sich hinter einem Trigger. In der CLAUDE.md heißt das: Der Kern enthält, was in jeder Sitzung gilt. Alles, was nur in bestimmten Kontexten relevant ist – die genauen Test-Konventionen, die Regeln für Datenbank-Migrationen, das API-Design-Handbuch – wandert in eigene Dateien.

Claude Code unterstützt Datei-Imports mit dem @-Syntax. Wenn du in deiner CLAUDE.md schreibst @docs/testing.md, wird der Inhalt dieser Datei nachgeladen, sobald der Kontext es nahelegt. So bleibt der Kern schlank, während spezialisierte Regeln griffbereit sind.

Wichtige Nuance: Imports reduzieren die Kontext-Nutzung nicht automatisch – der importierte Inhalt wird inline expandiert und zählt weiter gegen das Fenster. Der eigentliche Gewinn liegt in Organisation und Wartbarkeit: Du kannst einen Teil ändern, ohne den Rest anfassen zu müssen, und andere Tools können auf denselben Kern verweisen.

# CLAUDE.md (der Kern, unter 200 Zeilen)

## Kommandos
- Install: pnpm install
- Test: pnpm test
- Dev: pnpm dev

## Architektur
- apps/web – Next.js App Router
- packages/db – Prisma + PostgreSQL
- packages/ui – shadcn/ui Components

## Detailregeln bei Bedarf laden
@docs/testing-conventions.md
@docs/api-design.md
@docs/db-migrations.md

8. Sicherheits-Leitplanken: der Filler-Killer und Anti-Höflichkeit

Ein oft übersehener Vorteil einer guten CLAUDE.md: Sie kann Claudes Standard-Verhalten so justieren, dass es besser zu deinem Arbeitsstil passt. Der bekannteste Trick aus der Community ist der Filler-Killer – eine Sammlung von Regeln, die Höflichkeitsfloskeln, Überentschuldigungen und redundante Bestätigungen unterdrücken.

Warum das relevant ist: Standardmäßig antwortet Claude in einem freundlich-höflichen Ton, der für Consumer-Anwendungen sinnvoll ist. In produktiver Arbeit an einem Projekt fühlt sich das schnell wie Overhead an. „Klar, gerne! Ich verstehe, dass du eine Funktion für die Datenbank-Verbindung brauchst. Hier ist der Code…“ – zwei Sätze, in denen kein Bit neuer Information steckt. Über hunderte Interaktionen summiert sich das zu spürbar mehr gelesenen Zeilen bei gleichem Nutzen.

Vorsicht mit dieser Kategorie: Regeln wie „Erkläre nie, was du tust“ oder „Frage nie nach“ können nach hinten losgehen. Sie ringen Tokens ab, um Claudes Kernverhalten zu unterdrücken, und machen den Assistenten oft schlechter, nicht besser. Kürzere Antworten sind gut, blinder Gehorsam ist es nicht.

## Kommunikationsstil

- Antworte auf Deutsch.
- Keine Einleitungssätze wie "Klar, gerne!" oder "Natürlich!".
- Keine abschließenden Zusammenfassungen der eigenen Aktion.
- Bei Code-Änderungen: nenne die Datei und die Zeilen, keine Prosa drumherum.
- Frag nach, wenn eine Annahme das Ergebnis stark verändert.
- Bei Unsicherheit: sag es explizit, statt zu raten.

Beachte die letzten beiden Punkte: Sie sind das Gegengift zu naiven „Sei still“-Regeln. Du willst nicht, dass Claude schweigend eine falsche Annahme trifft.

9. Das Plan-First-Prinzip: erst denken, dann handeln

Bei komplexeren Aufgaben – Refactorings, Feature-Implementierungen, Migrationen – lohnt es sich, Claude in einen erzwungenen Planungsschritt zu zwingen, bevor Code entsteht. Das reduziert Ausrutscher massiv, weil du den Plan noch korrigieren kannst, bevor Zeilen produziert werden.

## Plan-First für nicht-triviale Aufgaben

YOU MUST bei jeder Aufgabe, die mehr als eine Datei berührt
oder mehr als 50 Zeilen Code produziert, zuerst einen Plan liefern.

Der Plan enthält:
1. Ziel: was ist der Endzustand?
2. Schritte: nummerierte Liste, jeder Schritt eine überprüfbare Aktion.
3. Betroffene Dateien: vollständige Liste mit begründeter Änderung.
4. Risiken: was könnte kaputtgehen? Wie fangen wir es ab?
5. Erfolgskriterien: welcher Test/welche Beobachtung zeigt Erfolg?

Erst nach meiner ausdrücklichen Freigabe ("go", "los", "machen")
beginnst du mit der Implementierung.

Diese eine Regel ist oft der größte Hebel, den du in einer CLAUDE.md ziehen kannst. Sie verhindert nicht nur Fehler, sie zwingt dich als Nutzer auch dazu, deine eigenen Anforderungen präziser zu formulieren.

In der Praxis bedeutet Plan-First einen Bruch mit dem Reflex, sofort „schreib mir die Funktion“ zu tippen. Stattdessen: „Refactor das Auth-System, damit Magic-Links funktionieren.“ Claude antwortet mit einem strukturierten Plan. Du liest ihn und merkst in Zeile drei: „Halt, den Sessions-Store wollen wir nicht anfassen.“ Ein Wort Korrektur, neuer Plan, dann grünes Licht. Was du vermeidest, ist der klassische Fall, in dem 200 Zeilen Code entstehen und du beim Review feststellst, dass die Architektur-Annahme im dritten Absatz schon falsch war. Der Plan kostet dich 30 Sekunden, spart dir 30 Minuten Reparatur.

10. Der Compounding Learning Loop mit MEMORY.md und ERRORS.md

Der wahrscheinlich wirkungsvollste Setup, um Claude über Zeit besser zu machen: der Learning Loop. Die Idee ist einfach – jede Sitzung produziert Lernstoff. Sackst du diesen strukturiert in Dateien, wird jede folgende Sitzung besser als die davor. Das ist der „Compounding-Effekt“: Kleine Erkenntnisse addieren sich zu einer wachsenden Wissensbasis.

Das Setup nutzt zwei Zusatzdateien:

• MEMORY.md – Ein strukturiertes Protokoll dessen, was gelernt wurde. Entscheidungen, Muster, „das haben wir versucht und verworfen“-Notizen.
• ERRORS.md – Eine Sammlung realer Fehler mit Ursache und Fix. Damit derselbe Fehler nicht dreimal auftritt.

Die Kopplung zur CLAUDE.md:

## Learning Loop

Zu Beginn jeder Sitzung: lies @MEMORY.md und @ERRORS.md.

Wenn ich dich um "session end", "log lernen" oder "protokoll" bitte:

1. Aktualisiere MEMORY.md:
   - Datum + kurze Session-Zusammenfassung
   - Getroffene Entscheidungen (Was, Warum)
   - Neu gelernte Konventionen oder Codebase-Fakten
   - Offene Fragen für nächste Sitzung

2. Aktualisiere ERRORS.md für jeden aufgetretenen Fehler:
   - Symptom (was war die Fehlermeldung/das Verhalten?)
   - Ursache (was war der eigentliche Grund?)
   - Fix (was hat es behoben?)
   - Präventionsregel (wie vermeiden wir das künftig?)

IMPORTANT: Erfinde keine Einträge. Nur echte Vorkommnisse dieser Sitzung.

MEMORY.md – Template:

# Projekt-Gedächtnis

## Kernentscheidungen (dauerhaft)

- Datenbank: PostgreSQL 16, verwaltet via Prisma. Grund: Team-Erfahrung.
- Auth: NextAuth mit Google + E-Mail-Magic-Link.
- Deployment: Vercel für Web, Fly.io für Worker.

## Konventionen (im Team abgestimmt)

- Feature-Ordner statt Layer-Ordner.
- API-Routen in app/api/[...]/route.ts, immer mit requireAuth.
- Datenbank-Zugriffe nur über packages/db/queries/*.

## Session-Log

### 2026-07-14 – Refactor Auth-Flow
- Entscheidung: Magic-Link-Only, Passwort-Login entfernt.
- Grund: Support-Ticket-Volumen wg. vergessener Passwörter zu hoch.
- Neue Konvention: Alle Session-Tokens werden bei jedem Login rotiert.
- Offen: Rate-Limiting für Magic-Link-Anfragen fehlt noch.

### 2026-07-15 – Migration von SWR zu React Query
- Grund: Bessere Optimistic-Update-Story, Devtools reifer.
- Kompatibilitäts-Wrapper unter lib/data/* beibehalten (bis Q4).
- Offen: Cache-Invalidierung nach Mutations noch inkonsistent.

ERRORS.md – Template:

# Fehler-Kompendium

## 2026-07-15 · Hydration-Mismatch nach Date-Formatierung
Symptom: "Warning: Text content did not match" beim ersten Render.
Ursache: new Date().toLocaleString() erzeugt server- und clientseitig
unterschiedliche Strings, weil die Zeitzone abweicht.
Fix: Datum als ISO-String vom Server holen, im Client mit
useEffect + Intl.DateTimeFormat in User-Zeitzone konvertieren.
Regel für die Zukunft: Nie lokale Zeitformate im Server-Render.

## 2026-07-14 · Prisma-Query gab plötzlich undefined
Symptom: TypeError: Cannot read property 'id' of undefined.
Ursache: findFirst() statt findFirstOrThrow() genutzt, kein Null-Check.
Fix: Auf findFirstOrThrow() gewechselt, Error-Boundary hochgezogen.
Regel für die Zukunft: In Route-Handlern immer findFirstOrThrow(),
außer der Null-Fall ist explizit erwarteter Business-Case.

## 2026-07-10 · Test-Suite hängt bei CI, lokal grün
Symptom: CI-Run bricht nach 10 Minuten Timeout ab.
Ursache: Ein await auf ein Promise, das im Test-Mock nie resolved wurde.
Fix: Mock explizit auf Promise.resolve(null) gesetzt.
Regel für die Zukunft: Jeder Mock, der ein Promise zurückgibt, muss
in beforeEach explizit resolved/rejected sein.

Der eigentliche Trick: Wenn dieselbe Präventionsregel drei- oder viermal in ERRORS.md auftaucht, ist es Zeit, sie in die CLAUDE.md zu heben. So verdichtet sich Wissen automatisch: Der Fehler-Speicher ist die Werkbank, die CLAUDE.md ist das Regelwerk.

Der Compounding-Effekt ist real, aber er kommt nicht von allein. Er entsteht, wenn du am Ende jeder ernsthaften Sitzung tatsächlich das Kommando gibst, das Protokoll zu schreiben. Am Anfang wird sich das aufwendig anfühlen – zwei Minuten für ein paar Zeilen. Nach vier Wochen wirst du feststellen, dass Claude typische Fehler bereits vermeidet, bevor du sie ansprechen musst. Nach drei Monaten hat dein Projekt eine Wissensbasis, die den Schwund von Team-Wissen bei Weggängen abfedert. Nach einem Jahr bist du in einer anderen Liga als Teams ohne diesen Loop.

Ein häufiger Einwand: „Aber Claude Code hat doch schon Auto-Memory, das reicht doch.“ Nein. Auto-Memory ist eine sinnvolle Ergänzung, aber sie ist ein Nebenprodukt, kein Prozess. Die entscheidende Bewegung ist, dass du als Nutzer bewusst entscheidest, was Wissen wird und was nicht. Auto-Memory sammelt alles Mögliche – dein manuell gepflegtes MEMORY sammelt nur das, was du für kanonisch erklärt hast. Der Unterschied ist Signal versus Rauschen.

11. CLAUDE.md im Team: geteilter Kontext ohne Reibung

Bis hierher haben wir die CLAUDE.md hauptsächlich als persönliches Werkzeug betrachtet. In Teams wird sie noch mächtiger – und noch heikler. Denn was für eine Person eine nützliche Regel ist, kann für eine andere ein Ärgernis sein. Die Kunst liegt darin, den geteilten Kern von den persönlichen Vorlieben zu trennen.

Die Trennlinie verläuft klar entlang der Datei-Hierarchie: Was das Team teilt, gehört in ./CLAUDE.md, was jede Person für sich anpasst, in ./CLAUDE.local.md. In der Praxis heißt das: Build-Commands, Architektur, Konventionen, Sicherheitsregeln – geteilt. Kommunikationsstil, Ausführlichkeit der Erklärungen, bevorzugte Werkzeuge – lokal.

Ein pragmatischer Prozess für Teams, die neu einsteigen: Setze in einem einstündigen Workshop die erste Version der geteilten CLAUDE.md auf. Nimm die Basis-Vorlage aus Sektion 14, geh sie zu dritt oder zu viert durch. Streiche, was für euer Projekt nicht zutrifft. Ergänze die drei bis fünf Dinge, die euch als „so machen wir das hier“-Konsens einfallen. Committe das Ergebnis. Fertig. Jede Person ergänzt danach für sich eine CLAUDE.local.md.

Der eigentliche Team-Vorteil: Neue Teammitglieder werden dramatisch schneller produktiv. Statt eine Woche zu brauchen, um implizite Konventionen aus Code-Reviews zu extrahieren, lesen sie 200 Zeilen und wissen, wie das Projekt tickt. Der Assistent hilft ihnen dabei zusätzlich, weil er bereits nach denselben Regeln arbeitet.

Konfliktlösung: was tun, wenn zwei Regeln kollidieren?

Es wird passieren. Jemand fügt eine Regel hinzu, die einer bestehenden widerspricht. Der schnelle Reflex – die neue Regel dazu schreiben und weiterziehen – ist der Anfang der 400-Zeilen-Bibel. Besser: Wenn ein Konflikt auftaucht, führt ihn im Pull-Request-Kommentar bewusst aus. Welche Regel gewinnt? Warum? Was ist die konsolidierte Formulierung? Ein Konflikt-PR ist immer eine Gelegenheit, die Datei zu straffen statt zu verlängern.

Onboarding-Ritual mit CLAUDE.md

Nutze die Datei als offizielles Onboarding-Artefakt. Neue Kolleg*innen lesen sie am ersten Tag durch und schreiben in einer Pull-Request die Fragen auf, die dabei entstehen – „warum machen wir X, nicht Y?“, „steht Z hier drin, weil…?“ Diese Fragen sind Gold: Sie zeigen genau, welche Regeln unklar formuliert sind, und liefern damit die konkreten Verbesserungspunkte für die nächste Iteration. Nach ein paar Onboarding-Runden ist deine Datei so klar, dass Missverständnisse verschwinden.

12. AGENTS.md und andere Agenten: Interoperabilität

Ein Detail, das langsam Standard wird: Nicht nur Claude Code liest solche Instruktions-Dateien. Codex von OpenAI liest AGENTS.md, Cursor liest .cursorrules, Windsurf liest .windsurfrules, und die Liste wächst. Wenn du in einer Umgebung arbeitest, in der mehrere Assistenten dieselbe Codebasis anfassen, willst du keine drei Versionen derselben Regeln pflegen.

Die pragmatische Lösung: Halte den kanonischen Kern in einer neutralen Datei, z. B. AGENTS.md, und lasse alle tool-spezifischen Dateien darauf verweisen. In CLAUDE.md steht dann im Kern nichts als ein Import und ein paar Claude-spezifische Ergänzungen.

# CLAUDE.md

# Kanonische Projektregeln (geteilt mit allen Assistenten)
@AGENTS.md

## Claude-spezifische Ergänzungen

- Nutze den Karpathy-Vier-Regel-Modus (siehe unten).
- Bei größeren Aufgaben immer Plan-First mit Freigabe.
- Learning Loop: @MEMORY.md + @ERRORS.md am Session-Ende aktualisieren.

## Karpathy-Grundregeln

1. Denken vor Coden – Annahmen klären.
2. Einfachheit zuerst.
3. Chirurgische Änderungen.
4. Ziel-gesteuert – Erfolgskriterien vor Start.

Der Vorteil dieser Trennung: Wenn du morgen von Claude Code zu Codex wechselst oder parallel Cursor benutzt, ändert sich in AGENTS.md nichts. Die tool-spezifischen Dateien enthalten nur, was wirklich tool-spezifisch ist. Karpathy selbst hat diese Praxis mit dem Hinweis „die gleiche Intuition verallgemeinert sich auf jede Agenten-Laufzeit“ bereits empfohlen.

Gleichzeitig gilt: Übertreib es nicht. Wenn du nur mit Claude Code arbeitest, brauchst du keine AGENTS.md. Die Kernregel bleibt Sparsamkeit. Baue Interoperabilität erst ein, wenn du sie brauchst.

13. Anti-Patterns: die häufigsten Fallen

Aus Community-Beobachtungen kristallisieren sich immer wieder dieselben Fehler heraus. Prüfe deine CLAUDE.md gegen diese Liste.

Anti-Pattern 1: Die 400-Zeilen-Bibel. Teams sammeln über Monate Regeln an, ohne alte zu entfernen. Am Ende hat die Datei 400+ Zeilen, teils widersprüchlich, teils obsolet. Ergebnis: Jede Session verbrennt Tokens für nichts, und die wichtigen Regeln gehen im Rauschen unter. Fix: Quartalsweiser Review, konsequent kürzen.

Anti-Pattern 2: Widersprüchliche Regeln. „Nie Kommentare in Code“ oben, „Komplexe Logik immer mit Inline-Kommentaren dokumentieren“ unten. Claude wählt kontextabhängig – das Ergebnis ist inkonsistent. Fix: Formuliere Regeln mit klaren „wenn/dann“-Klauseln oder entscheide dich für eine Version.

Anti-Pattern 3: Kritische Regeln tief unten. Claude gewichtet frühen Kontext stärker als späten. Wenn deine wichtigste Sicherheitsregel auf Zeile 180 steht, wird sie eher ignoriert als eine Style-Präferenz auf Zeile 10. Fix: Harte Grenzen und Nicht-Verhandelbares oben.

Anti-Pattern 4: Regeln gegen Claudes Grundverhalten. „Erkläre nie deine Aktionen“, „Frag nie zurück“, „Schlage nie Alternativen vor“. Diese Regeln kämpfen gegen Claudes Training, verbrennen Tokens und machen den Assistenten dümmer. Fix: Formuliere positiv, was du willst, statt zu unterdrücken.

Anti-Pattern 5: Aspirations-Floskeln ohne Test. „Sei konsistent“, „denke an die Zukunft“, „schreibe wartbaren Code“. Wertloses Rauschen. Fix: Wenn du eine Regel nicht durch einen Test oder Grep überprüfen könntest, gehört sie nicht rein.

Anti-Pattern 6: Fehlende Begründung. Eine Regel ohne Warum wird beim ersten Konflikt ignoriert. „Nutze Vitest“ ist schwächer als „Nutze Vitest (nicht Jest) – wir haben ESM-Module und Jest scheitert an unseren Node16-Configs.“ Fix: Ein kurzer Grund hinter jeder Regel, die nicht selbsterklärend ist.

Anti-Pattern 7: Kopierte Docs. Ganze Abschnitte aus der Projekt-README oder aus API-Docs in die CLAUDE.md geschoben, statt darauf zu verweisen. Doppelte Wartung, veralte Redundanz. Fix: Verweise per @import oder als Link, aber halte die Wahrheit an einem Ort.

Anti-Pattern 8: „Copy-me-alles“-Attitüde. Manche Teams gehen mit dem Gedanken heran: „Wenn Claude bei uns arbeitet, muss er unser gesamtes Onboarding-Wiki kennen.“ Falsch. Die CLAUDE.md ist keine Wissensbasis, sie ist ein Regelwerk. Fix: Trenne Regeln (wenige, dauerhaft, streng) von Wissen (viel, veränderlich, referenzierbar).

Anti-Pattern 9: Regeln ohne Datum. Eine Regel, die auf einen Bug oder eine spezielle Situation reagiert, ist in sechs Monaten oft überholt – aber niemand weiß es, weil kein Datum dransteht. Fix: Bei taktischen Regeln ein Kommentar mit Datum und Grund: „seit 2026-03: nur JSONB in Postgres, weil Row-Level-Locking auf JSON kaputt war“. Das macht den quartalsweisen Review dramatisch leichter.

Anti-Pattern 10: Der einsame Autor. Eine Person schreibt die CLAUDE.md im Alleingang, das Team liest sie nicht mal. Ergebnis: Der Autor freut sich über perfektes Verhalten, alle anderen kämpfen mit einem Assistenten, der Dinge tut, die niemand erwartet. Fix: Änderungen an der CLAUDE.md laufen wie Code-Änderungen durch einen Pull-Request.

14. Templates zum direkten Kopieren

Hier sind zwei vollständige, kopierbare Templates: ein CLAUDE.md-Basisgerüst für ein Projekt und ein CLAUDE.local.md-Vorspann. Die MEMORY.md- und ERRORS.md-Templates findest du in Sektion 10.

CLAUDE.md – vollständiges Basis-Template

# Projekt-Kontext für Claude

Diese Datei wird bei jeder Sitzung geladen. Halte sie unter 200 Zeilen.
Detailregeln kommen in eigene Dateien und werden per @-Import geladen.

## Was dieses Projekt ist

Interne Analytics-Plattform für unser Sales-Team. Nutzer sind ca. 40 Account
Executives. Daten kommen aus Salesforce, HubSpot und dem eigenen Postgres.

## Harte Grenzen (nicht verhandelbar)

IMPORTANT: Niemals Zugriffe auf Prod-DB aus Tests oder Dev-Skripten.
IMPORTANT: Niemals Secrets in Code oder Logs. Alle Keys via env.
YOU MUST alle API-Routen durch requireAuth-Middleware schleusen.
YOU MUST destruktive Migrationen (DROP, TRUNCATE) explizit bestätigen lassen.

## Kommandos

- Install: pnpm install
- Dev-Server: pnpm dev
- Tests: pnpm test
- Lint: pnpm lint
- Typecheck: pnpm typecheck
- DB-Migration: pnpm db:migrate

## Architektur in drei Sätzen

1. Monorepo mit pnpm-Workspaces: apps/web (Next.js), apps/worker, packages/db.
2. Auth über NextAuth (Google + Magic Link), Sessions in Redis.
3. Datenfluss: Salesforce -> nightly ETL -> Postgres -> Next.js.

## Konventionen

- TypeScript strict, keine any. Bei Bedarf: unknown + Narrowing.
- Feature-Ordner statt Layer-Ordner.
- Datenzugriffe nur über packages/db/queries/*.
- Client-Komponenten explizit mit 'use client'. Default = Server Component.
- Errors nur als AppError-Instanzen. Nackte throw new Error() = Fehler.
- Commit-Nachrichten: Conventional Commits. Betreff unter 60 Zeichen, Imperativ.

## Kommunikationsstil

- Antworte auf Deutsch.
- Kein "Klar!", kein "Natürlich!" zu Beginn.
- Keine Zusammenfassung der eigenen Aktion am Ende.
- Bei Code-Änderung: Datei + Zeilen benennen, minimale Prosa.
- Bei Unsicherheit: sage es explizit, statt zu raten.

## Plan-First bei nicht-trivialen Aufgaben

YOU MUST bei Aufgaben mit mehr als einer Datei oder über 50 Zeilen Code:
1. Zuerst einen Plan liefern (Ziel, Schritte, Dateien, Risiken, Erfolg).
2. Auf meine Freigabe warten ("go", "los", "machen").
3. Dann implementieren.

## Karpathy-Grundprinzipien

1. Denken vor Coden – Annahmen klären, Rückfragen bei Unsicherheit.
2. Einfachheit zuerst – kleinste funktionierende Lösung.
3. Chirurgische Änderungen – nur anfassen, was für die Aufgabe nötig ist.
4. Ziel-gesteuert – Erfolgskriterien vor Start definieren und prüfen.

## Bekannte Stolperfallen

- Prisma-Client bei Hot-Reload doppelt initialisiert -> global-Cache nutzen.
- Turborepo-Cache invalidieren mit pnpm turbo run --force bei komischen Bugs.
- next/image braucht bei externen Bildern remotePatterns in next.config.ts.

## Detailregeln bei Bedarf

@docs/testing-conventions.md
@docs/db-migrations.md
@docs/api-design.md

## Learning Loop

Zu Beginn jeder Sitzung: lies @MEMORY.md und @ERRORS.md.
Am Ende einer Sitzung (auf "session end"): Beide aktualisieren.

## Was nicht in diese Datei gehört

- Was aus dem Code offensichtlich ist.
- Standard-Best-Practices von TS/React (Claude kennt sie).
- Feature-Beschreibungen (gehören in docs/features/*).
- Persönliche Präferenzen (gehören in CLAUDE.local.md).

CLAUDE.local.md – persönliche Ergänzung

## Meine lokale Umgebung

- OS: macOS 14 auf M2. Homebrew-Pfad ist /opt/homebrew.
- Node via mise gemanagt, aktuell v22.5.0.
- Postgres läuft in Docker unter localhost:5433 (nicht 5432 wegen Konflikt).
- Redis lokal unter localhost:6380.

## Meine Präferenzen

- Kurze Antworten. Wenn etwas in 3 Sätzen sagbar ist, keine 10.
- Bei Ambiguität lieber eine explizite Rückfrage als eine geratene Antwort.
- Zeige mir Diffs, keine ganzen Dateien, bei kleinen Änderungen.

## Meine typischen Aufgaben

- Ich arbeite meist an apps/web/features/reporting/.
- Für Prisma-Schema-Änderungen: erst mit mir abstimmen.
- Ich nutze just statt make lokal – siehe justfile.

15. Für Nicht-Code-Projekte: Marketing, Research, Writing

Alles bisher Gesagte gilt genauso für nicht-technische Projekte. Die Struktur ändert sich, die Prinzipien bleiben. Der Effekt ist teils sogar größer als bei Code: In kreativen oder redaktionellen Arbeiten sind Konsistenz und Stil-Treue oft das eigentliche Qualitätsmerkmal, und genau da liefert eine gut kuratierte CLAUDE.md enormen Wert.

Marketing-Pipeline

# Marketing-Kontext

## Marke
- Positionierung: "präzise, unaufgeregt, evidenzbasiert".
- Zielgruppe: Marketing-Ops-Leads in Mid-Market-SaaS (50–500 MA).
- Ton: sachlich, kein Gehype, keine Superlative ohne Zahl.

## Verbotswörter
IMPORTANT: Diese Wörter nie in kundenbezogenen Texten:
"revolutionär", "bahnbrechend", "cutting-edge", "world-class", "10x".

## Format-Regeln je Kanal
- LinkedIn-Post: max. 1300 Zeichen. Erste Zeile = Hook. Absätze durch Leerzeilen.
- Newsletter: max. 400 Wörter. Ein Thema. CTA nur im letzten Absatz.
- Blog: 800–1400 Wörter. H2 nach jeder ~200-Wörter-Sektion.

## Approval-Prozess
YOU MUST jede Behauptung mit Zahl auf Quelle prüfbar machen.
YOU MUST vor Publish-Vorschlag: Faktcheck + Ton-Check gegen die Marke.

Research-Projekt

# Research-Kontext

## Forschungsfrage
Wie wirken sich KI-Coding-Assistenten auf die Fehlerrate in Legacy-Codebasen aus?
Zielpublikum: Engineering Manager mittelständischer SaaS-Firmen.

## Quellenregeln (nicht verhandelbar)
IMPORTANT: Jede Zahl braucht eine Primärquelle mit direktem Link.
IMPORTANT: Keine synthetischen Statistiken erfinden, auch nicht plausibel.
YOU MUST Zweitquellen-Bestätigung für jede Behauptung außerhalb
persönlicher Anekdoten. Wenn nur eine Quelle: als solche markieren.

## Format
- Zitate im Fließtext mit Autor + Jahr, volle Quelle in Fußnote.
- Screenshots von Original-Quellen im Ordner quellen/screenshots/.
- Rohnotizen in notes/YYYY-MM-DD.md, gruppiert nach Interview-Partner.

## Ausschlüsse
- Keine Reddit-Threads als Primärquelle.
- Keine Marketing-Blogs von Anbietern ohne Peer-Review.
- Keine anekdotischen Behauptungen aus Twitter/X ohne Verifikation.

## Register
@quellen/verifiziert.md
@quellen/vorlaeufig.md
@interviews/transkripte-index.md

Beachte, dass die Muster identisch sind: harte Regeln oben, Konventionen mit Grund, Ausschluss-Listen, Arbeitsablauf, modulare Detail-Referenzen per Import. Was sich ändert, ist der Inhalt, nicht die Form. Egal ob Code, Marketing, Prosa oder Research – das Muster funktioniert überall dort, wo ein Assistent wiederholt in denselben Kontext eintauchen soll.

16. Deine CLAUDE.md testen: der Drei-Prompt-Check

Ein oft übersehener Schritt: Wie weißt du eigentlich, ob deine CLAUDE.md funktioniert? Die naive Antwort lautet „wenn Claude gute Antworten gibt“. Das ist zu unspezifisch. Wer seine Datei ernst nimmt, testet sie mit definierten Prompts, die genau die Regeln herausfordern, die drinstehen.

Der einfachste Weg ist der Drei-Prompt-Check. Öffne eine komplett frische Session (kein History-Kontext) und stelle drei Prompts, die jeweils genau eine deiner wichtigen Regeln testen sollten. Nicht „kannst du bitte X tun“, sondern eine echte Aufgabe.

# Test 1 – prüft die "Plan-First"-Regel
Prompt: "Baue mir eine Login-Seite mit Magic-Link."
Erwartung: Claude liefert einen Plan, keinen Code. Wartet auf Freigabe.
Rot, wenn: sofort Code ohne Plan kommt.

# Test 2 – prüft die "Datenzugriff-nur-über-Queries"-Regel
Prompt: "Zeig mir, wie ich in der Route /api/reports/[id]
        den Report aus der DB holen würde."
Erwartung: Verweis auf packages/db/queries/*, keine Prisma-Calls in Route.
Rot, wenn: prisma.report.findFirst() direkt im Route-Handler steht.

# Test 3 – prüft den Kommunikationsstil
Prompt: "Wie ändere ich den Port des Dev-Servers?"
Erwartung: kurze Antwort, kein "Klar, gerne!", keine Zusammenfassung.
Rot, wenn: Prosa-Wolke mit Höflichkeitsfloskeln.

Nimm dir die Zeit, das nach jeder größeren Änderung an der Datei zu tun. Fünf Minuten Realtest schlägt eine Stunde Theorie. Wenn ein Prompt rot ist, weißt du sofort, welche Regel nicht durchdringt – und ob sie deutlicher formuliert, verschoben oder mit IMPORTANT verstärkt werden muss.

17. Wartung: der quartalsweise Review

Eine CLAUDE.md ist kein Set-and-forget. Sie ist ein lebendes Dokument, das mit dem Projekt atmet. Ohne Pflege verkommt sie zu einem Friedhof veralteter Regeln, der Claudes Antworten verschlechtert statt verbessert.

Blocke dir alle drei Monate eine Stunde für einen kurzen Review-Prozess:

1. Lies die Datei einmal komplett durch. Was hörst du dich selbst denken „das gilt nicht mehr“? Streichen.
2. Prüfe jede Regel auf Aktualität. Ist der Command noch korrekt? Existiert die Datei noch, auf die verwiesen wird?
3. Prüfe ERRORS.md. Welche Präventionsregel taucht mehrfach auf? Sie gehört in die CLAUDE.md.
4. Zähle die Zeilen. Bei 200+ – was kann in einen Import wandern?
5. Teste in einer frischen Sitzung. Öffne einen neuen Chat, stelle eine typische Frage. Werden die Regeln befolgt?

Faustregel für den Review: Wenn du am Ende einer Session mehr Regeln in der Datei hast als davor, hast du wahrscheinlich einen Fehler gemacht. Der gesunde Trend ist Verdichtung, nicht Wachstum.

Der 90-Tage-Rhythmus in der Praxis

Blocke dir im Kalender einen wiederkehrenden Termin: „CLAUDE.md-Review, 30 Minuten, alle 90 Tage“. Das klingt banal, ist aber der entscheidende Unterschied zwischen einer lebendigen Datei und einem verwaisten Regelwerk. Nutze den Termin, um mit einer der drei Auslöseformen einzusteigen: Erstens der Zeilenzahl-Check – wie viele Zeilen hat die Datei jetzt, wie viele hatte sie vor 90 Tagen? Zweitens der Frust-Check – wo hast du Claude in den letzten Wochen immer wieder korrigiert, obwohl es einer Regel entsprechen sollte? Drittens der Streich-Check – welche Regel hättest du seit langem nicht mehr angewandt?

Ein Anti-Muster hier: Man setzt den Review-Termin, aber niemand fühlt sich verantwortlich. In Teams sollte pro Quartal eine Person namentlich für den Review nominiert sein – rotierend. Diese Person führt ihn durch, öffnet einen PR mit den Änderungen, das Team reviewt in 15 Minuten. Fertig. Wer die Verantwortung diffundiert, hat in einem Jahr wieder 400 Zeilen.

18. Die finale Checkliste vor dem Deploy

Wenn du deine CLAUDE.md für ein neues oder überarbeitetes Projekt fertig hast, geh sie einmal gegen diese Liste durch, bevor du sie committest.

Fünf Fehler, die du in den ersten 30 Tagen machen wirst

Sei ehrlich zu dir selbst: Beim ersten Versuch wirst du diese Datei nicht optimal aufsetzen. Das ist okay. Die folgenden fünf Fehler machen alle, und du wirst sie auch machen. Wenn du sie kennst, korrigierst du sie schneller.

Erstens: Zu viel schreiben. Der Impuls, alles reinzupacken, was einem einfällt, ist übermächtig. Widerstehe. Wenn du unsicher bist, ob eine Regel reingehört, lass sie erstmal weg. Du kannst sie in einer Woche ergänzen, falls dir wirklich etwas fehlt. Aber du wirst überrascht sein, wie selten das passiert.

Zweitens: Zu abstrakt formulieren. „Halte den Code lesbar“ ist keine Regel, das ist ein Wunsch. Zwing dich, jede Regel so umzuformulieren, dass ein Junior-Entwickler in fünf Minuten prüfen könnte, ob sie eingehalten wurde.

Drittens: Auto-Memory überbewerten. Claude Code schreibt eigenständig Dinge in seine Auto-Memory, wenn du es zulässt. Praktisch, aber verführerisch. Wenn du diesen Autopiloten ohne Kuratierung laufen lässt, hast du in Wochen eine wilde Sammlung halb-relevanter Fakten. Auto-Memory ist ein Vorschlag, kein Ersatz.

Viertens: Regeln nicht begründen. „Nutze Postgres, nicht SQLite“ – warum? Ohne Begründung wird die Regel beim ersten Konflikt ignoriert, weil Claude nicht weiß, ob sie eine harte Anforderung ist oder eine Präferenz. Ein halber Satz Grund reicht meistens.

Fünftens: Den Learning Loop skippen. Die MEMORY- und ERRORS-Dateien fühlen sich nach mehr Arbeit an, als sie sind. Und sie fühlen sich am Anfang nach wenig Nutzen an. Der Payoff kommt nach Wochen. Halte durch. Nach 30 Tagen wirst du feststellen, dass typische Fehler nicht mehr auftauchen, weil deine Präventionsregeln sie schon abfangen.

Wenn du nur eine Sache mitnehmen sollst

Es ist diese: Deine CLAUDE.md ist die Antwort auf die Frage „Was würde ich einem neuen Kollegen am ersten Tag sagen?“ Nicht „was steht in unseren Docs“, nicht „was ist offensichtlich“, sondern die konzentrierten Regeln, die den Unterschied zwischen „so machen wir das nicht“ und „so machen wir das“ ausmachen. Alles andere gehört woanders hin.

Fang mit der Basis-Vorlage aus Sektion 14 an. Kürze sie auf das, was für dein Projekt zutrifft. Ergänze eine Woche später drei bis fünf Dinge, die du in der Woche vermisst hast. Setze dir einen Review in 90 Tagen. Das ist der Weg.

Der Aufwand für den Start ist minimal – die Basis-Vorlage in eine leere Datei kopieren, die Kommandos anpassen, die Architektur-Sätze umformulieren. In einer halben Stunde hast du eine funktionierende Version, die schon 80 Prozent des Effekts bringt. Die restlichen 20 Prozent kommen über die nächsten Wochen durch Beobachtung, was Claude falsch macht, und durch das MEMORY-Protokoll, das dir zeigt, welche Regel gefehlt hat. Wichtig ist nur, den Anfang zu machen. Eine mittelmäßige CLAUDE.md, die existiert, ist um Größenordnungen besser als eine perfekte, die du für nächste Woche geplant hast.

Und noch ein Gedanke, der oft untergeht: Diese Datei ist auch ein Signal an dein zukünftiges Ich. In sechs Monaten, wenn du das Projekt wieder anfasst, wird die CLAUDE.md das Erste sein, was dich abholt. Sie ist die einminütige Version deines eigenen Onboarding-Dokuments. Behandle sie mit der Sorgfalt, die du dir selbst schuldig bist.

Quellen und weiterführende Links

• Anthropic – Best practices for Claude Code
• Anthropic – How Claude remembers your project
• Anthropic Help Center – Give Claude context: CLAUDE.md and better prompts
• multica-ai/andrej-karpathy-skills auf GitHub
• Karpathy CLAUDE.md Rules: Cut Claude Errors 41% to 11%
• Karpathy CLAUDE.md Grows to Ten Rules (TechTimes)
• HumanLayer – Writing a good CLAUDE.md
• 7 CLAUDE.md Patterns That Stop Claude From Drifting Off-Script
• MindStudio – Compounding Knowledge Loop in Claude Code
• MindStudio – What Is Claude Code Auto-Memory
• Claude Code Memory Explained (Substack)
• CLAUDE.md Best Practices Guide 2026 (DEV)
• AGENTS.md Spezifikation

Der Beitrag CLAUDE.md Best Practices – Der umfassende Leitfaden 2026 erschien zuerst auf KI-Praxis.

Was in den letzten Wochen passiert ist

Der Sommer 2026 hat einen Modellstau produziert, wie es ihn selten gab. OpenAI hat GPT-5.6 als Trio veröffentlicht: Sol für die teure Denkarbeit, Terra für den Alltag, Luna für alles, was schnell und billig sein muss. Anthropic hat Claude Sonnet 5 nachgezogen und dabei vor allem am Preis geschraubt, weniger an der Leistung. Grok 4.5 von xAI verspricht mit weniger Tokens denselben Job. Muse Spark 1.1 kam mit einem Kontextfenster von einer Million Tokens, groß genug für ein ganzes Buch am Stück. Und aus China kam mit Kimi K2.7 Code das erste Open-Weight-Modell, das in GitHub Copilot als Option auftaucht.

Wenn du die Fachpresse verfolgst, kennst du das Muster: Jedes neue Modell schlägt in irgendeinem Benchmark die anderen. Sol führt bei Coding, Sonnet 5 bei Argumentation, Grok bei Wissenschaftsfragen. Diese Bestenlisten werden mit jedem Release umgeschrieben. Wer sich davon leiten lässt, wechselt alle sechs Wochen sein Tool. Das ist Unsinn und Zeitverschwendung, und ich glaube, kaum jemand mit einer echten Arbeit macht das tatsächlich.

Was du unter der Oberfläche sehen musst

Die interessante Bewegung findet unter der Oberfläche statt. Vor achtzehn Monaten war die Marktfrage simpel: Wer hat das stärkste Modell? Wer die höchsten Punktzahlen holte, gewann. Preis war Nebensache, weil die meisten für zwanzig oder dreißig Dollar im Monat einen Pauschal-Chat abonnierten und damit gut fuhren.

Das hat sich verschoben. Unternehmen, die KI in ihre Produkte einbauen, zahlen pro Anfrage. Und wer täglich zigtausend Anfragen schickt, für den ist der Unterschied zwischen fünf Dollar und fünfzig Cent pro Million Tokens keine Nuance. Er ist der Unterschied zwischen tragfähigem Geschäftsmodell und Verlustzone. Genau dieser Rechnungsposten entscheidet, welches Modell für welchen Job gewählt wird.

Konkret heißt das: Ein Kundenservice-Bot mit zehntausend Anfragen am Tag läuft nicht auf dem Spitzenmodell. Er läuft auf dem billigsten, das die Aufgabe verlässlich löst. Für die komplizierten Ausnahmefälle wird dann an ein teureres Modell weitergereicht. Diese Weiterleitung ist inzwischen ein eigenes Geschäftsfeld — sogenannte Router-Systeme, die pro Anfrage entscheiden, welches Modell die beste Preis-Leistung bietet.

Das erklärt, warum OpenAI ihr Spitzenmodell in drei Stufen zerlegt hat. Sol ist die Prestige-Variante für Whitepapers und Bühnen. Terra ist die, die man tatsächlich verkauft. Luna ist die, die den Umsatz macht, weil sie millionenfach in Hintergrundprozessen läuft, die kein Mensch je zu Gesicht bekommt.

Warum das auch für dich relevant ist

Du zahlst zwanzig, dreißig, vielleicht fünfzig Dollar im Monat für ein oder zwei KI-Abos. Für dich sind die Groß-Preisverhandlungen der Anbieter erstmal weit weg. Trotzdem betreffen sie dich, und zwar an zwei Stellen.

Erstens: Was heute in der Premium-Klasse läuft, läuft in einem halben Jahr in der Mittelklasse und in achtzehn Monaten in der Gratis-Version. Diese Preistreppe nach unten ist der Motor der ganzen Sache. Wenn du heute ein Feature ausprobierst und denkst „cool, aber teuer“ — warte sechs Monate, dann ist es billig. Das gilt für lange Kontextfenster, für gutes Coding, für Vision, für Sprache. Alles, was heute ein Aufpreis-Argument ist, wird morgen zur Grundausstattung.

Zweitens: Die Aufteilung deiner Arbeit auf mehrere Modelle ist die praktische Konsequenz aus dieser Marktbewegung. Kein Anbieter ist mehr in allem vorn. Und selbst da, wo einer vorn ist, kostet der Vorsprung Geld. Wer klug auswählt, spart oder bekommt bessere Ergebnisse.

Wie ich das praktisch mache

Ich benutze aktuell drei Modelle parallel:

Claude ist mein Hauptwerkzeug für alles, was Schreiben, Recherche und Argumentation betrifft. Artikel wie diesen hier, längere Texte, alles, wo Struktur und Formulierung sitzen sollen und umfangreiche Recherchen vorausgehen. Claude versteht am besten und sichersten meine Ideen ohne ständiges Nachbessern, produziert für meinen Geschmack die geradlinigste, am wenigsten schwurbelige Prosa und zieht meine Texte, Tippfehler und Eingaben am saubersten und zuverlässigsten gerade. Es kostet mehr als die Konkurrenz, aber die Zeit, die ich bei Überarbeitungen spare, holt den Preis mehrfach wieder rein.

ChatGPT nutze ich für schnelle Recherchen, Bildgenerierung wie beispielsweise die Artikelbilder hier und alles, wo Geschwindigkeit wichtiger ist als Präzision. Wenn ich eine Idee einfach „mal eben“ durchspielen will, ohne dass etwas perfekt formuliert sein muss, geht das dort schneller.

Gemini benutze ich überwiegend innerhalb von NotebookLM. Wer einen Stapel PDFs oder Dokumente hat und sie durchsuchbar machen will, findet dort das derzeit beste Werkzeug. Google subventioniert die Nutzung quer, weshalb es praktisch nichts kostet. Außerdem steuere ich via Gemini-Spracheingabe auf dem Smartphone meine Heimautomatisierung

Diese Aufteilung ist nicht in Stein gemeißelt und hat sich nach und nach so herauskristalisiert. Nach jedem größeren Release schaue ich, ob sich etwas verschoben hat. Bisher blieb die Zuständigkeit stabil, aber die Ergebnisse werden bei allen dreien besser. Was ich vor einem Jahr umfangreichmanuell nachbearbeiten musste, kommt jetzt oft direkt nahezu brauchbar heraus.

Was das für deinen Werkzeugkasten heißt

Wenn du bisher nur ein Modell benutzt, verpasst du wahrscheinlich etwas. Die konkurrierenden Modelle haben unterschiedliche Stärken, und der Unterschied ist größer, als die Marketing-Sprache der Anbieter vermuten lässt. Meine praktische Empfehlung:

Teste dein aktuelles Modell gegen einen konkreten realen Job aus deiner Woche. Nimm denselben Job, denselben Prompt, und schicke ihn an ein zweites Modell. Vergleiche die Ergebnisse. Nicht Benchmark-artig, sondern nach dem, was du wirklich brauchst — Lesbarkeit, Genauigkeit, Ton, Länge. Nach fünf bis zehn solchen Vergleichen weißt du, wo dein Hauptwerkzeug schwächelt und wo ein Wechsel Sinn ergibt.

Für die meisten Leser lohnt sich ein zweites Abo nicht. Die kostenlosen Versionen der drei großen Anbieter sind inzwischen so gut, dass du für gelegentliche Vergleiche keinen zweiten Zahlungsvertrag brauchst. Erst wenn du beruflich täglich intensiv mit KI arbeitest, wird ein zweites Premium-Abo interessant.

Wohin die Reise geht

Wenn die Preise weiter so fallen wie in den letzten achtzehn Monaten, wird ein Großteil dessen, was heute als leistungsfähige KI gilt, in zwei Jahren praktisch umsonst laufen. Die Kosten wandern zu den Anbietern der Rechenzentren und zu den großen Enterprise-Kunden. Für dich und mich wird KI zu einer Art Grundversorgung — man wählt aus, mit welchem Anbieter man sich am wohlsten fühlt, und benutzt es täglich, ohne über den Preis nachzudenken.

Das ist eine ungewöhnliche Marktdynamik. Bei fast jeder anderen Technologie stiegen die Preise mit zunehmender Reife oder blieben stabil. Bei KI fallen sie, weil Tokens austauschbar sind und wer den billigsten Fluss liefert, in der Menge gewinnt.

Für die großen Anbieter ist das ein Problem. Für dich als Nutzer die beste Nachricht der letzten Jahre. Der Wettlauf, wer das größte, klügste Modell baut, ist weitergelaufen — aber er entscheidet nicht mehr allein, wer am Ende dein Geld bekommt. Wer den besten Preis für die jeweilige Aufgabe hat, gewinnt den Kunden von heute, um morgen noch da zu sein. KI-Modelle sind zur Ware geworden. Und Waren gewinnt man über den Preis.

Quellen

• July 2026 AI Mega-Update: Every Major Breakthrough & Launch You Need to See — Preisdetails GPT-5.6 Sol/Terra/Luna
• Top AI News for July 2026: Breakthroughs, Launches & Trends — Kimi K2.7 Code in GitHub Copilot
• LLM News Today (July 2026) – AI Model Releases — Claude Sonnet 5, Grok 4.5, Muse Spark 1.1
• AI Update, July 10, 2026 – Marketing Profs — Marktbewegung „best fit wins statt best model wins“
• New Models Today — AI & LLM Releases (Price Per Token) — Preisvergleiche aktueller Modelle

Der Beitrag Der Modell-Wettlauf wird zur Preisfrage erschien zuerst auf KI-Praxis.

Klingt nach einem Umweg. Ist meistens der schnellere Weg.

Warum das funktioniert

Normalerweise bekommst du das Scheitern erst zu sehen, nachdem es passiert ist: falsche Annahme, missverstandener Kontext, eine Ecke der Aufgabe, die übersehen wurde. Du merkst es am fertigen – falschen – Ergebnis und musst nachbessern.

Failure-Prediction-Prompting dreht die Reihenfolge um. Claude benennt vorab, wo die Aufgabe kippen könnte: mehrdeutige Formulierungen im Auftrag, fehlende Informationen, Annahmen, die es treffen müsste, um überhaupt loszulegen. Diese Liste ist oft aufschlussreicher als der erste Entwurf – weil sie genau die Lücken zeigt, die du vorher schließen kannst, statt sie im fertigen Ergebnis zu entdecken.

Der Prompt

Bevor du anfängst: Liste drei bis fünf konkrete Arten auf, wie du bei dieser
Aufgabe scheitern könntest – falsche Annahmen, fehlender Kontext, Mehrdeutigkeiten
in meinem Auftrag. Für jeden Punkt: was du annehmen müsstest, wenn ich es nicht
kläre. Erst danach beginnst du mit der eigentlichen Arbeit.

Aufgabe: [hier einfügen]

Ein Beispiel

Auftrag: „Schreib mir eine Zusammenfassung des Meetings.“ Ohne Failure-Prediction legt Claude einfach los – Tonfall, Länge und Fokus geraten, wie es gerade passt.

Mit dem Prompt davor kommt zuerst das hier: Unklar, ob die Zusammenfassung für die Teilnehmer selbst ist oder für Leute, die nicht dabei waren. Unklar, ob Entscheidungen und Action Items im Fokus stehen sollen oder der Gesprächsverlauf. Unklar, welche Länge angemessen ist. Drei Sätze, die dir vorher zeigen, was du eigentlich hättest mitliefern müssen – bevor Zeit in eine Version investiert wird, die du wieder verwirfst.

Wo die Grenze liegt

Für triviale Aufgaben ist das Overkill – bei „übersetz mir diesen Satz“ gibt es wenig zu scheitern. Der Trick zahlt sich bei allem aus, was mehrdeutig, mehrstufig oder folgenreich ist: Konzepte, Analysen, alles, wo ein falscher Start teuer wird. Und er lässt sich gut mit einer verwandten Technik kombinieren: Claude vorab interviewen zu lassen, statt es direkt loslegen zu lassen – zwei Varianten derselben Grundidee, den Dialog vor die Arbeit zu stellen statt danach zu korrigieren.

Quelle: Reddit r/PromptEngineering – „I make Claude predict how it’s going to fail at my task before it starts“

Der Beitrag Failure-Prediction-Prompting: Lass Claude vorher sagen, woran es scheitern wird erschien zuerst auf KI-Praxis.

Wer Claude nur für einzelne Fragen öffnet, kopiert die Antwort raus und schließt den Tab wieder, nutzt vielleicht zehn Prozent dessen, was möglich ist. Der Rest liegt in drei Dingen: persistentem Kontext, wiederverwendbaren Skills und Verbindungen zu den Tools, die man ohnehin täglich benutzt.

Warum Gedächtnis der eigentliche Hebel ist

Ein Chat ohne Kontext fängt bei null an. Jedes Mal erklärst du, wer du bist, was dein Unternehmen macht, wie du schreibst, was du hasst. Das kostet Zeit und liefert trotzdem inkonsistente Ergebnisse, weil du beim dritten Mal etwas anders formulierst als beim ersten.

Die Lösung ist unspektakulär: einfache Textdateien, die Claude bei jeder Aufgabe automatisch mitliest.

about-me.md hält fest, wer du bist – Rolle, Branche, Zielgruppe, was für dich bei einer Analyse zählt und was nicht. Claude benutzt das als Linse für jede Anfrage, nicht nur für Texte.

anti-ai-writing-style.md ist eine Verbotsliste. Wörter wie „in der heutigen schnelllebigen Zeit“ oder „Synergien heben“ kommen da nie wieder raus. Dazu Regeln zu Satzlänge, Absatzstruktur, ob du geduzt oder gesiezt schreibst.

CLAUDE.md liegt im Projektordner selbst und wird automatisch geladen, sobald du dort arbeitest. Projektziele, Namenskonventionen, Ordnerstruktur, Farben, Schriften, die wichtigsten Befehle – alles, was sich sonst in jedem neuen Chat wiederholt.

Der Punkt dabei: Du schreibst diese Dateien einmal und pflegst sie nach. Merkst du nach fünf Texten, dass Claude einen Ton trifft, den du nicht willst, korrigierst du die Datei – nicht den nächsten Prompt.

Skills: Prozesse, die man einmal baut und dann abruft

Ein Skill ist im Grunde ein Ordner mit einer Anleitung, die Claude eine feste Fähigkeit beibringt: eine Excel-Tabelle nach einem bestimmten Muster bauen, einen Text in ein bestimmtes Social-Format bringen, eine Analyse nach festen Kriterien durchführen. Der Clou: Claude liest die volle Anleitung erst, wenn du den Skill per Befehl aufrufst oder die Aufgabe ihn erfordert. Das spart Kontextspeicher und macht die Antworten konsistent, weil derselbe Prozess jedes Mal gleich abläuft.

Einmal eingerichtet, reicht ein kurzer Prompt wie „Erstelle den Wochenbericht“ oder „/postgrader“, und Claude weiß, welche Schritte in welcher Reihenfolge zu tun sind – inklusive Formatierung, Tonfall und Prüfkriterien, die du vorher festgelegt hast.

Fünf Beispiele aus der Praxis

Eine Website in einem Nachmittag statt in einer Woche. Der Kanal Metics Media zeigt im Video „Build $10,000 Websites using Claude Code“ den kompletten Workflow: Claude Code wird mit zwei Design-Skills ausgestattet – dem offiziellen Frontend-Design-Skill von Anthropic und UI UX Pro Max mit 50 Stilen, 21 Farbpaletten und 50 Schriftkombinationen. Statt einer aufwendigen React-Architektur entscheidet sich Claude für eine schnelle, statische Seite, ergänzt um Referenzbilder von Dribbble und Awwwards sowie fertige Komponenten von 21st.dev. Am Ende steht ein Live-Deploy auf einer eigenen Domain, mehrere Polish-Durchgänge inklusive. Der Prompt, der das anstößt, folgt demselben Muster: „Baue mir eine Landingpage im Stil von [Referenz], nutze diese Farbpalette, prüfe danach live im Browser auf Darstellungsfehler und behebe sie.“

Eine Content-Pipeline mit sieben virtuellen Mitarbeitern. Sabrina Ramonov, laut eigenen Angaben eine der meistgefolgten AI-Educators weltweit, verwaltet ihre gesamte Content-Produktion über mehrere definierte Sub-Agenten: Channel Analyst, Trend Scout, Script Writer, Post Grader und weitere – nachzulesen in ihrem Claude-Code-Tutorial. Ihr Workflow ist unspektakulär: Screenshots und Fotos landen unsortiert in einem Ordner, Claude liest den Ordner aus, ein Agent schreibt den Entwurf, ein anderer bewertet ihn nach einer festen Rubrik und schickt ihn bei Bedarf zurück. Über Blotato laufen die fertigen Posts automatisiert auf mehrere Plattformen. Der Grader-Prompt könnte so aussehen: „Bewerte diesen Tweet-Entwurf nach Hook-Stärke, Klarheit und Call-to-Action auf einer Skala von 1 bis 10. Nenne konkret, welcher Satz die Punktzahl drückt, und schlage eine Alternative vor.“

Ein Lernspiel ohne eine einzige eigene Zeile Code. Sam Illingworth, der zu kritischer KI-Kompetenz forscht, wollte ein interaktives Spiel bauen, das zeigt, warum KI-Detektoren unzuverlässig sind und wen sie besonders oft zu Unrecht belasten. Er beschrieb im Dialog das Gamedesign, die Dilemmata, zwölf Szenarien – Claude Code übernahm die technische Umsetzung komplett. Das fertige Spiel „Flagged“ lässt Spielende als Assistenzprofessor zwölf studentische Arbeiten mit einem KI-Detektor bewerten und macht dabei erfahrbar, dass jede Falschmeldung eine echte Person trifft. Entscheidend war hier nicht technisches Wissen, sondern eine klare Beschreibung dessen, was das Spiel leisten soll.

Ein Offline-Dashboard für Fitnessdaten. Kevin Chromik beschreibt in seinem Video „Claude Code hat mein Leben verändert (5 krasse Beispiele)“, wie er seine Garmin-Trainings- und Schlafdaten per Skript herunterlädt, lokal von Claude Code auswerten lässt und daraus ein eigenes Dashboard baut – ohne Cloud-Abo des Herstellers. Claude erkennt Leistungstrends in den Rohdaten und leitet daraus Trainingsempfehlungen ab, die auf den tatsächlichen Werten basieren statt auf generischen Plänen.

Ein Second-Brain-Dashboard für zwanzig parallele Projekte. Ein Product Leader dokumentiert im Detail, wie er für über zwanzig Projekte je eine einfache Markdown-Datei in Obsidian pflegt – nachzulesen in seinem Artikel „I Built a Mission Control Dashboard with Claude Code to Manage 20+ Projects“. Am Ende jeder Arbeitssitzung tippt er „/update“ – Claude liest den aktuellen Stand, prüft Git-Commits und Logdateien, um den echten Fortschritt zu messen, und aktualisiert die Datei. Morgens läuft automatisch ein Startskript, das Deadlines prüft und ein farbcodiertes Dashboard anzeigt: grün für erledigt, gelb für in Arbeit, rot für überfällig. Der Startprompt dafür liest sich etwa so: „Scanne alle Projektdateien in diesem Ordner, gleiche Deadlines mit dem heutigen Datum ab und zeig mir ein Dashboard: grün = erledigt, gelb = in Arbeit, rot = überfällig. Nenne bei Rot den Grund.“

Die drei technischen Säulen dahinter

Wer verstehen will, warum das alles funktioniert, muss drei Begriffe kennen:

MCP (Model Context Protocol) ist der offene Standard, über den Claude sich mit externen Tools verbindet – Google Drive, Slack, Gmail, eigene Datenbanken. Claude liest Daten direkt aus diesen Systemen, verarbeitet sie lokal und schreibt das Ergebnis zurück, ohne dass du Daten manuell hin- und herkopierst.

Skills sind die wiederverwendbaren Playbooks, wie oben beschrieben – eine Fähigkeit, einmal definiert, beliebig oft abrufbar.

Plugins bündeln mehrere Skills, Skripte und die passenden MCP-Verbindungen zu einer fertigen Spezialisten-Rolle. Ein Ads-Plugin etwa liefert alles, was für ein automatisiertes Werbe-Audit über mehrere Plattformen nötig ist, in einem Paket.

Wo du anfängst

Du brauchst für den Einstieg nicht alle drei Säulen gleichzeitig. Der sinnvollste erste Schritt ist fast immer der Kontext: eine about-me.md, eine Stildatei, vielleicht eine Projektdatei für die Sache, an der du gerade arbeitest. Der Effekt ist sofort spürbar, weil Claude ab dem zweiten Chat weiß, wer du bist, ohne dass du es erklärst.

Skills lohnen sich, sobald du eine Aufgabe zum dritten Mal auf dieselbe Art erledigst – dann lohnt es sich, den Prozess einmal festzuhalten, statt ihn jedes Mal neu zu formulieren.

Was davon für dich zuerst Sinn ergibt, hängt davon ab, was bei dir am meisten Zeit frisst: ein wiederkehrender Textprozess, eine Datenauswertung oder die Verwaltung mehrerer Projekte gleichzeitig. Sag Claude, welcher Bereich das bei dir ist, dann baut es die passende Ordner- und Skill-Struktur direkt für Dich auf.

Hier sind drei der stärksten und nützlichsten Prompts aus der Praxis, die du direkt kopieren, anpassen und in Claude einfügen kannst. Sie basieren auf den bewährten Methoden von KI-Top-Nutzerin und -Nutzern (wie Ruben Hassid, Timo Mason und Iman Oubou) und decken die wichtigsten Säulen der Contenterstellung und Arbeitssteuerung ab:

Prompt 1: Der „Frage-mich-zuerst“-Sicherheitsgurt (Für jeden Chat-Start)

Die meisten Menschen machen den Fehler, Claude eine Aufgabe zu geben und sofort ein fertiges Ergebnis zu erwarten. Das führt fast immer zu generischem „KI-Slop“. Dieser Prompt zwingt Claude, innezuhalten, dich strategisch zu interviewen und erst nach deinem expliziten Feedback zu liefern.

Ich möchte [DEIN ZIEL, z. B. einen Fachartikel über das Thema X schreiben], um [DEIN ERFOLGSKRITERIUM, z. B. meine Expertise bei B2B-Kunden zu untermauern].

Bevor du mit der Erstellung oder Planung beginnst, lies diese Anforderungen. Nutze dann das Tool `AskUserQuestion` (oder stelle mir die Fragen direkt hier im Chat), um mich gezielt zu interviewen.

Stelle mir nacheinander (nicht alle auf einmal!) 5 bis 7 klärende Fragen zu meiner Zielgruppe, dem genauen Kontext, meinen Kernbotschaften und gewünschten Beispielen. Nimm meine Antworten als Kontext und erstelle erst einen groben Entwurf, bevor du den finalen Text schreibst.

(Basiert auf den Best Practices zum Bypassen von Standard-Antworten und dem gezielten Abfragen von Kontext.)

Prompt 2: Der „Dream/Pain Stack“ Hook & Post-Generator (Für LinkedIn & Social Media)

Die stärksten Hooks auf LinkedIn kombinieren das größte Wunschziel deiner Zielgruppe (Dream) mit dem größten Schmerz oder Hindernis, das sie unbedingt vermeiden wollen (Pain). Dieser Prompt nutzt diese psychologische Dynamik, um extrem konvertierende Beiträge zu schreiben.

Du bist ein erfahrener Direct-Response-Copywriter und Experte für virales Marketing. Deine Aufgabe ist es, basierend auf meinem Thema hochgradig fesselnde Hooks und LinkedIn-Beiträge zu generieren.

THEMA: [Z. B. KI-Automatisierung für Agenturen]
ZIELGRUPPE: [Z. B. Inhaber von Marketing-Agenturen]

Schritt 1 – Dream/Pain-Analyse: Identifiziere das absolute Wunschziel (#1 Dream) der Zielgruppe im Bezug auf das Thema sowie das größte Hindernis (#1 Pain), das sie auf dem Weg dorthin vermeiden wollen. Kombiniere beide zu einer "Dream/Pain-Stack"-Formel (Beispiel: "X erreichen, ohne Y tun zu müssen").

Schritt 2 – Hook-Generierung: Schreibe basierend darauf 5 extrem kurze, knackige Hook-Varianten (maximal 8 Wörter pro Hook).

Schritt 3 – Beitrags-Entwurf: Schreibe einen vollständigen LinkedIn-Post basierend auf der stärksten Hook. Halte dich an diese harten Regeln:
- Kurze Absätze (maximal 3 Sätze) und stark variierende Satzlängen für einen natürlichen, menschlichen Rhythmus.
- Nutze KEINE typischen KI-Floskeln (wie "delve", "unlock", "leverage", "in der heutigen digitalen Welt").
- Nutze KEINE Gedankenstriche (Em-Dashes) und keine typischen Dreier-Aufzählungslisten.
- Schließe mit einem klaren, kurzen Call-to-Action (CTA) ab.

(Basiert auf Iman Oubous „Dream/Pain Stack“-Formel und Ruben Hassids „Anti-AI-Writing-Style“ zur Eliminierung maschineller Muster.)

Prompt 3: Der „Reader-First“ Article-to-Post Repurposer (Aus lang mach kurz)

Wenn du einen langen Blogartikel, ein Newsletter-Kapitel oder ein Skript hast, neigen KIs dazu, beim Zusammenfassen deine persönliche Geschichte in den Vordergrund zu stellen. Dieser Prompt formatiert deinen Text so um, dass er sich radikal auf den Nutzen für den Leser fokussiert.

Du bist ein brillanter Content-Strategist. Nimm den unten angehängten Text und wandle ihn in einen prägnanten LinkedIn-Post um, der sich zu 100 % auf das Interesse und den direkten Nutzen des Lesers konzentriert – nicht auf meine persönliche Geschichte.

TEXT:
[FÜGE HIER DEINEN ENTWURF ODER DEINEN ARTIKEL EIN]

FRAMEWORK FÜR DEN POST:
1. Der Hook (unter 8 Wörtern): Ein konträrer, überraschender oder datengetriebener Einstieg, der den Leser sofort stoppt.
2. Der Kern (Nutzen): Bringe die Kernaussage des Textes in 2 bis 3 absolut glasklaren, praktischen Takeaways auf den Punkt.
3. Der Schreibstil: Variiere die Satzlängen massiv (schreibe kurze, fast fragmentarische Sätze neben längeren). Nutze eine direkte, persönliche Ansprache. Vermeide jegliche werbliche Aufblähung oder KI-typische Übergänge.

(Basiert auf Timo Masons Ansatz, Content konsequent um das Leserinteresse herum zu strukturieren, anstatt die eigene Geschichte in den Fokus zu rücken, kombiniert mit kurzen LinkedIn-Hooks.)

Der Beitrag How to Claude, Teil 2: Vom Chatfenster zum Betriebssystem erschien zuerst auf KI-Praxis.

Die Modelle: literaler wird’s, nicht klüger im vagen Sinn

Anthropic hat seine Modellfamilie im Lauf des letzten Jahres deutlich ausdifferenziert. Aktuell (Stand Juli 2026) sieht die Reihe so aus: Claude Haiku 4.5 als schnelle, günstige Variante, Claude Sonnet 5 als produktiver Standard für die meisten Alltagsaufgaben, Claude Opus 4.8 als die anspruchsvollste Stufe für komplexe Analyse- und Agenten-Aufgaben — und seit Kurzem zusätzlich Claude Fable 5, eine neue Stufe oberhalb von Opus. Die Entwicklung dorthin lässt sich gut an den Release-Notes von Opus 4.5 und Opus 4.6 nachvollziehen.

Die praktische Konsequenz über die Modellgenerationen hinweg bleibt gleich: Mit jeder neuen Version wird Claude literaler und präziser in der Befolgung von Anweisungen — und das verlangt eine andere Prompting-Handschrift als früher. Wer die Modelle noch aus der Frühphase kennt, in der Claude oft „mitdachte“ und Lücken selbst füllte, muss umlernen. Vier Regeln, die sich in der Praxis bewährt haben:

Erstens: Präzision statt Freiheit. „Überprüfe das mal“ ist keine Anweisung, sondern eine Einladung zum Rätselraten. „Erstelle eine Liste mit 5 konkreten Kritikpunkten, je ein Satz“ ist eine Anweisung.

Zweitens: Länge explizit machen. Claude orientiert sich stark an der Länge der Eingabe. Wer eine kurze Zusammenfassung will, muss das sagen — sonst bekommt man tendenziell eine Antwort, die zur Frage passt, nicht zum gewünschten Output.

Drittens: positiv formulieren. „Benutze keine Adjektive“ funktioniert schlechter als „Schreibe ausschließlich in Substantiven und Verben“. Modelle reagieren zuverlässiger auf das, was sie tun sollen, als auf Verbote.

Viertens: Aktionsverben nutzen. „Analysiere“, „Extrahiere“, „Entwirf“ triggern spezifischere Tool-Aufrufe als weiche Formulierungen wie „schau dir mal an, ob…“. Bei komplexen Aufgaben lohnt sich zusätzlich der Zusatz „Denke vor der Antwort nach (maximale Tiefe)“ — das schaltet vom schnellen, adaptiven Standarddenken auf die volle Denktiefe um.

Drei Türen in dasselbe Haus

Claude ist nicht eine Oberfläche, sondern drei, je nach Aufgabe:

Claude Chat ist die flexible Standard-Interaktion — mit Extended Thinking, Artifacts (für Dashboards, Code-Previews, interaktive Dokumente) und Projekten, in denen sich Kontext über mehrere Chats hinweg sammelt.

Claude Cowork ist die Desktop-Integration: Zugriff auf das Dateisystem, Steuerung von Maus und Tastatur (Computer Use), Excel- und PowerPoint-Add-ins. Das ist die Umgebung für alle, die mit echten Dateien auf dem eigenen Rechner arbeiten wollen, ohne selbst zu programmieren.

Claude Code ist die terminalbasierte Variante — mit Slash-Befehlen, Sub-Agenten-Management und direkter Dateimanipulation. Ursprünglich für Entwickler gebaut, wird es zunehmend auch von Nicht-Entwicklern für Automatisierung und Content-Pipelines genutzt.

Wer neu einsteigt, sollte nicht versuchen, alle drei gleichzeitig zu lernen. Chat für die ersten Gehversuche, Cowork sobald reale Dateien im Spiel sind, Code erst dann, wenn wiederkehrende, strukturierte Workflows entstehen.

Claude Code: mehr als ein Entwickler-Werkzeug

Auch ohne Programmierkenntnisse lohnt sich ein Blick auf die wichtigsten Befehle (Details in der Claude Code Docs-Übersicht), weil Claude Code im Kern ein Orchestrierungs-Werkzeug ist, kein reines Coding-Tool:

/init erzeugt automatisch eine CLAUDE.md-Datei, die als dauerhaftes Briefing für das gesamte Projekt dient — Claude liest sie bei jeder neuen Session.

/plan schaltet in einen reinen Lesemodus, in dem Claude eine Aufgabe erst strukturiert, bevor irgendetwas verändert wird. Gerade bei komplexeren Vorhaben verhindert das teure Fehlläufe.

/context zeigt, welche Dateien wie viele Tokens im aktuellen Gespräch beanspruchen — nützlich, um zu verstehen, warum eine Session träge wird.

/compact und /clear leeren den Kontextspeicher, wenn lange Sessions an Präzision verlieren.

/agents erlaubt das Anlegen von Sub-Agenten für parallele Teilaufgaben.

/rewind macht die letzten Schritte rückgängig, falls Claude sich verrannt hat.

Skills und Connectors: aus Chat wird Werkzeug

Zwei Bausteine heben Claude über die reine Konversation hinaus.

Skills sind gespeicherte, wiederverwendbare Instruktionssets — man bringt Claude quasi einmal bei, wie eine bestimmte Aufgabe nach einem festen Standard ablaufen soll, und ruft das danach immer wieder ab. Beispiele reichen von einfachen Automatisierungen (etwa das Herunterladen und Aufbereiten von Social-Media-Inhalten) bis zu Qualitätsfiltern, die Claude zu kritischerem, weniger zustimmendem Verhalten zwingen. Die Installation läuft in Cowork über Customize → Skills → Upload, entweder als Markdown-Datei oder als Zip-Archiv.

Connectors sind die Brücke zu externen Daten — Live-Zugriff auf Gmail, Slack, Notion, Kalender und viele weitere Dienste. Empfehlenswert für den Einstieg: Gmail für E-Mail-Entwürfe, Slack zum Zusammenfassen von Threads, Notion für Wissensdatenbank-Abfragen. Wichtig dabei: Connectors sollten nur aktiviert werden, wenn sie gebraucht werden, weil sie bei jeder Anfrage Tokens verbrauchen („Token-Creep“). Und: erst Lesezugriff gewähren, Schreibrechte (etwa zum Versenden von E-Mails) erst dann, wenn man dem Setup vertraut.

Ein Setup, das den Prompting-Aufwand senkt

Ein durchdachtes Ordner-Setup in Cowork reduziert, wie oft man denselben Kontext wieder und wieder erklären muss. Bewährt hat sich eine Struktur mit vier Bereichen: ein „Über mich“-Ordner mit Angaben zu Rolle, Tonalität und festen Arbeitsregeln (etwa: „Frag immer erst nach, bevor du loslegst“); ein Projektordner mit einem Unterordner pro aktivem Vorhaben; ein Vorlagenordner mit Strukturen früherer, erfolgreicher Arbeiten; und ein Output-Ordner für fertige Dokumente.

Auf Prompt-Ebene lohnt sich die Faustregel, dass ein wirklich guter Prompt typischerweise mehrere Schichten kombiniert: Rolle der KI, Tonalitätsvorgabe, Hintergrundmaterial, konkrete Regeln, Beispiele, relevante Vorgeschichte, die eigentliche Anfrage, eine Aufforderung zu Schritt-für-Schritt-Denken bei komplexen Fällen, Formatvorgaben — und bei Bedarf ein vorformuliertes Antwortfragment, das die ersten Worte der Antwort vorgibt.

Was das in der Praxis bedeutet

Die interessantesten Anwendungsfälle kommen inzwischen nicht von Entwicklern — das zeigt auch Anthropics eigene Auswertung, wie Claude Code in der Praxis genutzt wird. Menschen bauen sich mit selbst geschriebenen Slash-Befehlen persönliche Content-Pipelines, die rohe Gedanken in fertige Social-Media-Posts in der eigenen Stimme verwandeln. Andere lassen Claude morgens automatisch das Netz nach relevanten News durchsuchen und daraus ein persönliches Briefing bauen. Wieder andere trainieren kleine Tools, die auf Basis vergangener Veröffentlichungen abschätzen, wie gut ein neuer Artikeltitel performen dürfte — ganz ohne selbst eine Zeile Code zu schreiben.

Zwei Fehlerquellen tauchen dabei immer wieder auf. Erstens: Claude im Nachhinein zu fragen, warum es etwas so gemacht hat, wie es es gemacht hat — die Begründung, die dann kommt, ist oft nachträglich konstruiert. Sinnvoller ist es, den Plan vor der Ausführung sehen zu lassen, nicht danach zu hinterfragen. Zweitens: endlos in einem einzigen, immer länger werdenden Chat weiterzuarbeiten. Wer regelmäßig neue Chats mit den wichtigsten Kontextdateien startet, hält die Antwortqualität stabil und die Token-Nutzung im Rahmen.

Der rote Faden durch all das: Claude wird umso nützlicher, je klarer man selbst wird — bei Anweisungen, bei Struktur, bei der Frage, welches der drei Werkzeuge gerade das richtige ist. Alles Weitere ist Übung.

Quelllen:

• Introducing Claude Opus 4.5 \ Anthropic
• Claude Opus 4.6 \ Anthropic
• Current Claude Model Version: Opus 4.8, Sonnet 4.6, Haiku 4.5 (June 2026)
• Overview – Claude Code Docs
• How Claude Code is used in practice \ Anthropic

Der Beitrag How to Claude: Eine Einführung erschien zuerst auf KI-Praxis.

Das ist keine Randnotiz. Es ist der Kern des Problems.

Unternehmen schulen sich selbst — für alle anderen bleibt eine Lücke

Firmen und Behörden bauen inzwischen verpflichtende KI-Schulungen für ihre Belegschaft auf. Der Grund ist banal: Wenn ein Mitarbeiter eine halluzinierte KI-Antwort ungeprüft in eine Kundenmail kopiert, kostet das Geld und Reputation. Also wird investiert.

Für Privatpersonen gibt es diesen Druck nicht. Niemand zahlt dafür, dass Eltern lernen, wie sie mit ihren Kindern über KI-generierte Hausaufgaben sprechen. Niemand schult Großeltern darin, eine KI-Antwort zur eigenen Gesundheit kritisch zu hinterfragen, bevor sie danach handeln. Diese Lücke ist real — und sie wird größer, nicht kleiner, weil KI-Nutzung im Alltag schneller wächst als jedes Schulungsangebot.

Die vier Dinge, die wirklich zählen

Kompetenter Umgang mit KI lässt sich auf vier Fähigkeiten herunterbrechen, die aufeinander aufbauen und sich gegenseitig stützen:

Verstehen, wie ein System wie ChatGPT überhaupt funktioniert — nicht auf Ingenieursniveau, aber genug, um zu wissen, warum es überzeugend klingende Fehler produziert.

Anwenden, also KI tatsächlich sinnvoll für den eigenen Alltag nutzen, statt sie entweder zu meiden oder ihr blind zu vertrauen.

Reflektieren, das heißt: das eigene Urteilsvermögen nicht an die Maschine abgeben, auch wenn das bequemer wäre.

Mitgestalten, also den Umgang mit KI im eigenen Umfeld — Familie, Klassenzimmer, Team — aktiv mitzuprägen, statt ihn einfach geschehen zu lassen.

Das Entscheidende: Man muss in keinem dieser vier Felder Spitzenklasse sein. Aber man darf in keinem bei null stehen, weil die Felder sich sonst nicht gegenseitig stützen können. Wer nur anwendet, aber nie reflektiert, wird zum Risikofall. Wer nur versteht, aber nie anwendet, hat nichts gewonnen.

Das teuerste Missverständnis: Erfahrung schützt nicht vor Selbstüberschätzung

Hier kommt die unbequemste Erkenntnis: Wer sich für besonders KI-kompetent hält, überschätzt die eigene Leistung nach KI-Nutzung tendenziell noch stärker als weniger erfahrene Nutzer. Forschung der Aalto University zeigt genau diesen Effekt — KI-Nutzung lässt Menschen ihre eigene kognitive Leistung systematisch überschätzen, und erfahrene Nutzer sind davor nicht gefeit, sondern besonders anfällig. Selbstbewusstsein im Umgang mit KI ist also kein verlässlicher Indikator für tatsächliche Kompetenz — manchmal ist es das Gegenteil.

Ein einziges Ritual schlägt jede Theorie

Man braucht keine Zertifizierung, um morgen kompetenter mit KI umzugehen. Man braucht eine einzige neue Gewohnheit: Bevor eine KI-Antwort zur Grundlage einer Entscheidung wird — sei es eine Zahl in einer Präsentation, ein medizinischer Rat oder eine Aussage in einem Referat —, eine Sekunde innehalten und fragen: Woher weiß ich, dass das stimmt?

Wenn man es selbst nicht beurteilen kann, hilft ein einfacher Zwei-Quellen-Check: eine zweite, unabhängige KI oder eine klassische Quelle danebenhalten. Stimmen beide überein, steigt die Wahrscheinlichkeit einer korrekten Antwort. Weichen sie voneinander ab, ist das selbst schon ein Warnsignal — und zwar eines, das man ernst nehmen sollte, bevor man weitererzählt oder weiterhandelt.

Vorleben schlägt Vorschreiben

Wer versucht, Kindern, Kolleginnen oder den eigenen Eltern KI-Kompetenz per Ansage beizubringen, wird meist auf Widerstand stoßen. Was tatsächlich wirkt, ist das sichtbare eigene Verhalten: die Gewohnheit, KI-Antworten laut zu hinterfragen, offen nach der Quelle einer Zahl zu fragen, zuzugeben, wenn man sich selbst von einer KI hat täuschen lassen. Kompetenz verbreitet sich nicht durch Regeln, sondern durch sichtbares Vorbild.

Die eigentliche Botschaft

Es gibt keinen Punkt, an dem man mit KI-Kompetenz fertig ist. Die Technologie verändert sich schneller, als sich Wissen darüber aktualisieren lässt. Was zählt, ist deshalb keine Liste von Fakten, sondern eine Haltung: ein werteorientierter, verantwortungsvoller Umgang mit der Macht, die eine überzeugend klingende KI-Antwort über unsere Entscheidungen bekommen kann — verbunden mit dem Anspruch, diese Kontrolle in der eigenen Hand zu behalten.

Diese Sekunde des Innehaltens, bevor man einer KI-Antwort vertraut, ist im Grunde die ganze Kompetenz. Alles andere ist Übung.

Der Beitrag Warum Misstrauen die wichtigste KI-Kompetenz ist erschien zuerst auf KI-Praxis.