Claude Code CLAUDE.md Permission Recipe: Wiederholung und riskanten Zugriff reduzieren

Viele Claude-Code-Fehler kommen nicht von einem schwachen Modell. Sie entstehen, weil Projektregeln von Sitzung zu Sitzung wechseln. Ein klares CLAUDE.md plus Permission Recipe reduziert Kontextwiederholung, riskante Änderungen und fehlende Prüfung.

Dieser Artikel zeigt das erste Rezept für Anfänger. Ziel ist nicht, den Agenten einzufrieren, sondern read-only, ask-before, never-touch und proof commands zu trennen.

Weiterlesen: permission safety ladder, Obsidian to CLAUDE.md workflow, getting started guide.

Warum dieses Muster funktioniert

CLAUDE.md ist kein Gedächtnis, sondern ein Arbeitsvertrag. Mit Prüfkommandos, geschützten Ordnern und PDF-, Gumroad-, Beratungswegen hilft es bei Entwicklung und Veröffentlichung.

Das Permission Recipe macht daraus Verhalten. Die Trennung der Bereiche senkt die Chance, dass Claude Code vor dem Nutzer gefährliche Schritte nimmt.

Praktischer Ablauf

Ziel, Qualitätsgrenze, Prüfkommandos und Umsatzwege in CLAUDE.md schreiben
Dateibereiche in read-only, ask-before und never-touch teilen
Proof commands nennen, die ohne Extra-Freigabe laufen dürfen
Deploy, Löschen und irreversible Aktionen nur nach menschlicher Bestätigung
Nach Veröffentlichung h1, Einstieg, CTA und Gumroad-Links als Screenshot prüfen

Situation	Sicherer Schritt	Nachweis
Solo-Site	Artikeltext erlauben; Formulare und APIs ask-before	Build und öffentliche URL
Team-PR	Diff-Review erlauben; Push und Deploy bis zur Bitte stoppen	PR-Diff
Umsatzseite	Produktlinks, Preise und Anfrageformulare schützen	Klickprüfung

Kopierbarer Prompt und Code

Erstelle eine CLAUDE.md permission recipe für dieses Projekt. Enthalten sein sollen read-only, ask-before, never-touch, auto proof commands, öffentliche URL-Prüfungen und Schutzregeln für PDF, Gumroad-Produkte und Beratung.

const permissionRecipe = {
  readOnly: ["README.md", "package.json", "src/routes/"],
  askBefore: ["site/src/layouts/", "scripts/", "wrangler.toml"],
  neverTouch: [".env", "billing/", "customer-data/"],
  proofCommands: ["npm.cmd run build", "git diff --stat"]
};

function canRunWithoutAsking(command) {
  return permissionRecipe.proofCommands.includes(command);
}

console.log(canRunWithoutAsking("npm.cmd run build"));
console.log(canRunWithoutAsking("wrangler pages deploy"));

Das Beispiel ist keine echte Config. Es modelliert die Entscheidung kompakt. An Teamrechte, CI und Deployment anpassen.

Drei echte Beispiele

Erstes Setup

README und package.json lesen lassen, dann CLAUDE.md vor der ersten Änderung erstellen. Die erste Änderung auf eine Datei begrenzen.

Mehrsprachiger Artikel

Slug und frontmatter reichen nicht. Regel ergänzen: Einstieg und CTA müssen in der Zielsprache sein, mit Screenshot.

Vor Beratung

Permission-Tabelle, Sperrbereiche und Prüfkommandos mitbringen. Der Termin wird praktisch.

Fehler, die du vermeiden solltest

Nur Werte in CLAUDE.md schreiben, aber keine konkreten Sperrbereiche.
Deploy oder Löschen aus Bequemlichkeit erlauben.
Produktlinks und Formulare wie normale Inhalte behandeln.

Zu lange Regeln werden ignoriert. Kurz starten und nach jedem echten Fehler eine Regel ergänzen.

PDF, Gumroad und Beratung verbinden

Wenn Grundlagen noch wackeln, hilft das kostenlose Cheatsheet. Für CLAUDE.md, Permissions, hooks, MCP und CI ist die Setup Guide der schnellste bezahlte Weg.

Für standardisierte Review- und Debug-Anfragen nutze 50 Prompt Templates. Für Teamregeln oder Umsatzpfade nutze Beratung. Vergleich unter products.

Vor und nach dem Veröffentlichen prüfen

Vor Veröffentlichung prüfen, ob Artikel und neue CLAUDE.md-Regeln dem Recipe widersprechen. Danach mobil h1, Einstieg, CTA und Produktlinks je Sprache prüfen.

Nächste Kennzahlen

Setup-Guide-Klicks, PDF-Starts, Beratungsbesuche und Permission-Artikel beobachten. Steigt Beratung, suchen Leser Betriebsdesign.

30 Minuten Betriebsreview

Wenn der CLAUDE.md Permission Recipe in echte Arbeit geht, ist das Review am nächsten Tag am wertvollsten. Lies das Protokoll und notiere erlaubten Scope, geänderte Dateien, Prüfkommandos und geprüfte öffentliche Seiten. Nicht nur “geprüft” schreiben, sondern den Beleg: mobiles h1, Einstieg, CTA-Bereich, Gumroad-Link und Beratungspfad.

Trenne Sicherheit des Bearbeiters von Verhalten des Lesers. Bearbeiterseitig zählen Sperrbereiche, Build-Nachweis, gleicher öffentlicher Slug und keine englischen Alttexte in Übersetzungen. Leserseitig zählt der passende nächste Schritt: kostenloses PDF für Befehle, Gumroad bei wiederholbarem Engpass, Beratung bei Workflow-Design.

Mach aus dem Review eine künftige Regel. Nicht zehn Regeln nach jedem Problem hinzufügen. Eine Regel reicht: vor Layout-Änderungen fragen, jede Gumroad-URL in Produktion klicken oder den Texteinstieg je Sprache erfassen. Kleine tägliche Regeln sind stärker als lange Policies.