Eine Projektanweisungsdatei wird zu Beginn jeder Sitzung gelesen, also wird jede Zeile darin bei jeder Anfrage bezahlt, solange die Datei existiert. Diese eine Tatsache entscheidet, was hineingehört und was nicht. Alles, was aus dem Code ersichtlich ist — die Sprache, das Framework, die Ordnerstruktur — wird einem Leser wiederholt, der es bereits sieht. Ihren Platz verdient das Gegenteil: der Testbefehl, der ein Flag braucht, die Node-Version, die den Build zerlegt, die Konvention, die jemand Neues falsch raten würde, das, was schon einmal jemanden einen Nachmittag gekostet hat. Dieser Builder ist um diese Kategorien herum gebaut, schätzt die Kosten der Datei und markiert die Zeilen, die dem Repository etwas über sich selbst erzählen.
Funktionen
Abschnitte, geführt von dem, was hineingehört, nicht von einer leeren Seite
Laufende Token-Schätzung: die Kosten je Anfrage, nicht einmalig
Markiert Zeilen, die wiederholen, was der Code ohnehin zeigt
Markiert leere Appelle, die nichts ändern
Warnt, wenn die Datei die Größe erreicht, ab der sie überflogen wird
Weist darauf hin, wenn es keine Überschriften zum Ausdünnen gibt
Leere Abschnitte entfallen, statt leer geschrieben zu werden
Lädt als CLAUDE.md herunter
So verwendest du Projektanweisungen
Benennen Sie das Projekt
Füllen Sie nur Abschnitte, zu denen Sie etwas Nichtoffensichtliches sagen können
Beobachten Sie die Token-Schätzung beim Wachsen
Lesen Sie die Warnungen und laden Sie die Datei
Beispiel
Eingabe
This project is a React app.
Ausgabe
Warning: the language and framework are visible from the manifest
Der Test für jede Zeile: Fände ein Leser das in zehn Sekunden heraus?
Häufige Fehler & Fehlerbehebung
Die Datei wird als zu groß markiert. — Verschieben Sie alles nur gelegentlich Relevante in ein eigenes Dokument, das die Sitzung bei Bedarf liest. Die Anweisungsdatei ist für das, was immer gilt.
Eine Zeile, die ich wollte, gilt als auffindbar. — Ignorieren Sie die Warnung, wenn sie wirklich trägt. Die Prüfung ist eine Aufforderung zur Frage, ob ein Leser es ohnehin herausfände — keine Regel.
Es ändert sich nichts, wenn ich Anweisungen ergänze. — Konkrete, überprüfbare Anweisungen wirken weit besser als allgemeine. „Nutze die Primitive in components/ui“ schlägt „schreibe sauberen Code“.
Sollte das CLAUDE.md heißen oder anders? — Der Inhalt ist derselbe. Speichern Sie unter dem Namen, den Ihr Werkzeug liest; Struktur und Disziplin ändern sich nicht.
Häufig gestellte Fragen
Was gehört wirklich in eine Anweisungsdatei?
Was aus dem Code nicht ersichtlich ist und sonst falsch geraten würde: der Befehl mit dem nötigen Flag, die Version, die den Build zerlegt, die Konvention, die in keiner einzelnen Datei sichtbar ist, und ausdrückliche Verbote. Alles Übrige wird einem Leser wiederholt, der bereits lesen kann.
Wie lang sollte sie sein?
Kurz genug, um noch gelesen zu werden. Die Schätzung erscheint beim Tippen; jenseits einiger tausend Token lohnt die Frage, welche Zeilen wirklich immer gelten, denn der Rest kann in einem Dokument leben, das bei Bedarf gelesen wird.
Warum wird „schreibe sauberen Code“ markiert?
Weil es nichts ändert. Ein allgemeiner Appell kostet in jeder Anfrage Token und gibt keine Entscheidungsgrundlage; eine konkrete Konvention — wo Logik hingehört, welche Primitive zu nutzen sind — schon.
Spielt es eine Rolle, dass das bei jeder Anfrage bezahlt wird?
Es ist genau der Grund, die Datei auszudünnen. Eine Seite Anweisungen ist einmal ein kleiner Betrag und über Tausende Anfragen ein erheblicher, und deshalb steht die Schätzung neben dem Text statt versteckt.
Darf ich Geheimnisse hineinschreiben?
Nein — sie wird in jeder Sitzung in den Kontext geladen und meist versioniert. Halten Sie Zugangsdaten in Ihrer Umgebung und verweisen Sie nur auf ihren Namen, falls die Anweisungen sie erwähnen müssen.
Verwandte Tools
Skill-Builder — Schreiben Sie eine SKILL.md, deren Frontmatter beim Tippen geprüft wird.
Subagent-Builder — Erstellen Sie die Definitionsdatei eines Subagenten samt Tools und Modell.
Slash-Befehl-Builder — Bauen Sie einen eigenen Befehl, mit Argumenten und einer Tool-Liste.
Kontextfenster-Planer — Teilen Sie das Fenster auf Prompt, Tools, Verlauf und Antwort auf.
Prompt-Cache-Planer — Ordnen Sie die Blöcke so, dass das cachebare Präfix möglichst lang wird.
System-Prompt-Linter — Finden Sie Widersprüche, tote Anweisungen und ungefüllte Platzhalter.
Weitere KI & Agenten-Tools
Skill-Builder — Schreiben Sie eine SKILL.md, deren Frontmatter beim Tippen geprüft wird.
Skill-Linter — Fügen Sie eine SKILL.md ein und sehen Sie, was ihre Zuordnung verhindert.
Subagent-Builder — Erstellen Sie die Definitionsdatei eines Subagenten samt Tools und Modell.
Slash-Befehl-Builder — Bauen Sie einen eigenen Befehl, mit Argumenten und einer Tool-Liste.
Plugin-Manifest — Erzeugen Sie eine plugin.json und sehen Sie den erwarteten Ordneraufbau.
Hooks-Builder — Bauen Sie settings.json-Hooks und finden Sie Matcher, die nie auslösen.