Entwickler pflegt Claude Code Regeln für WordPress in öffentlichem Repo
Ein öffentliches GitHub-Repository bündelt die Claude Code Standards für WordPress-Projekte und wird zu Sessionbeginn automatisch geladen. Das verhindert abweichende Regeln zwischen Projekten und spart unnötige Tokens.
Veröffentlicht am 15. Oktober • Zuerst erschienen auf matthummel.com
Ich halte meine Claude-Code-Regeln für WordPress in einem öffentlichen GitHub-Repository, und jede Maschine, die ich nutze, zieht sie zu Beginn der nächsten Sitzung. Ich habe es gebaut, weil meine Regeln zwischen Projekten immer wieder auseinandergedriftet sind und Tokens gekostet haben, die ich gar nicht ausgeben musste.
Dieser Beitrag behandelt, warum ich die AI Dev Standards & Playbook erstellt habe, was darin enthalten ist und wie sie meine Arbeitsweise mit Claude Code verändert haben.
Als ich die Regeln aus meinem matthummel.com-Theme herausgezogen habe, hatte ich zehn immer geladene Regeldateien. Zusammen waren sie etwa 60 KB groß und wurden in jede Sitzung geladen. Das meiste davon waren WordPress- und Sage-Details, die nur relevant sind, wenn ich eine PHP- oder Blade-Datei bearbeite. Claude Code lädt Regeln beim Sitzungsstart, sodass diese 60 KB immer mitgeschleppt wurden, selbst wenn ich einen Blogbeitrag schrieb.
Die Lösung war die Aufteilung nach Triggern. Die Kernregel ist jetzt 0,9 KB groß. Der Rest lädt nur, wenn Claude eine passende Datei berührt oder einen Skill auswählt. Dieselben Standards, ein Bruchteil des Kontexts.
Was mich endgültig überzeugt hat, war, dieselben Prompts immer wieder eintippen zu müssen. Jede neue Sitzung begann damit, dass ich dieselben Sicherheitsregeln, dieselben Accessibility-Prüfungen und dieselbe Notiz zur Reihenfolge der Antworten einfügte. Jeder dieser Prompts ging von meinen Credits ab.
Ich wollte, dass die Regeln bereits vorhanden sind, und ich wollte den immer geladenen Teil so klein wie möglich halten, damit jede Sitzung weniger kostet.
Claude Code liest Regeln, Skills und Befehle aus ~/.claude, und ein SessionStart-Hook kann vor jeder Sitzung ein Skript ausführen. Das Playbook nutzt beides.
install.sh kopiert das Repository einmalig nach ~/.claude und fügt den Hook hinzu. Von da an führt jede neue Sitzung sync.sh aus, das einen git pull --ff-only durchführt und die Dateien erneut kopiert. Hat sich nichts geändert, gibt es nichts aus.
Ich verwende absichtlich Kopien und keine Symlinks. Symlinks erfordern den Entwicklermodus unter Windows, und Claude Code lädt ~/.claude/rules/ ohne Genehmigungsaufforderung, wenn die Dateien einfache Kopien sind.
Ein Haken: Regeln werden beim Sitzungsstart geladen, daher zeigt sich ein Merge erst in der Sitzung nach derjenigen, die ihn gezogen hat. Wenn ich ihn sofort haben will, führe ich sync.sh manuell aus und starte neu.
Acht Ordner. Hier ist, was jeder einzelne macht und wann er lädt.
core.md ist die einzige immer geladene Datei. Sie umfasst:
Ein Skill ist ein Ordner mit einer SKILL.md, die Claude bei Bedarf lädt. Ich habe bisher sechs:
Ich habe fünf Slash-Befehle, mit Namensräumen versehen, damit sie niemals die eigenen eines Projekts überlagern:
Der wp-reviewer-Agent liest einen Diff gegen das WordPress Developer Handbook, bevor ich einen Pull Request eröffne.
Ein PostToolUse-Hook führt PHPCS auf jeder PHP-Datei aus, die Claude bearbeitet, und gibt die Fehler direkt zurück, sodass Claude sie behebt, bevor es weitergeht.
/pb:new-project legt ein Kit in einem Theme-Repository ab:
Ich rufe sie nicht selbst auf. Claude Code greift sie aus dem auf, was ich gerade tue und was ich eintippe.
Deshalb sind die Beschreibungen wichtiger als die Inhalte. Ein Skill mit einer vagen Beschreibung lädt nie, und einer mit einer präzisen Beschreibung lädt im richtigen Moment. Wenn ein Skill nicht ausgelöst wird, korrigiere ich die Beschreibung, nicht den Prompt.
Konsistenz. Jede Kundenseite bekommt dieselben Sicherheitsprüfungen, dieselbe Accessibility-Schwelle und dieselbe Überprüfung vor einem PR. Ich füge keine Regeln mehr jedes Mal in eine neue CLAUDE.md ein.
Weniger veraltete Antworten. Der doc-references-Skill weist Claude an, vor dem Schreiben zu einem Hook, einem Tailwind-v4-Feature oder einer Next.js-API die offizielle Seite abzurufen. Die Projekteinstellungen genehmigen diese Domains vorab, sodass der Abruf nie wegen einer Berechtigungsaufforderung stoppt.
Günstigere Sitzungen. Der immer geladene Kontext sank von etwa 60 KB auf unter 1 KB, und ich versende dieselben Regeln nicht mehr manuell zu Beginn jeder Sitzung. Kleinere Prompts, weniger Credits.
Ein zentraler Ort zum Beheben von Problemen. Wenn Claude etwas zweimal falsch macht, ändere ich die Regel einmal, eröffne einen Pull Request, und die Korrektur landet am nächsten Tag überall. Die CI-Prüfungen des Repos kontrollieren das Frontmatter, das Größenbudget der Kernregel und eine Blocklist für private Details, sodass ich aus Versehen keinen Kundennamen mergen kann.
Alles, was einen Kunden nennt. Hosts, Pfade, Plugin-Listen, Logins und Produktkataloge liegen in der CLAUDE.md und.claude/rules/ jedes Projekts.
Das Playbook ist öffentlich, daher scannt validate.py jede Datei nach Mustern wie Application Passwords, GitHub-Tokens und privaten Schlüsseln. Es lässt den Build fehlschlagen, wenn eines davon auftaucht.
Wenn du Claude Code in mehr als einem Repository verwendest, ja. Fang kleiner an als ich:
Du wirst innerhalb einer Woche wissen, ob sich ein Ausbau lohnt. Anthropics Anleitung dazu, wann man CLAUDE.md, Skills, Hooks und Subagents verwendet, bietet einen guten Überblick darüber, wie die Bausteine zusammenpassen.
Automatisch übersetzt. Das Original auf Englisch ist unten aufklappbar.
Original (Englisch) anzeigen
Posted on Oct 15 • Originally published at matthummel.com
I keep my Claude Code rules for WordPress in one public GitHub repo, and every machine I use pulls it at the start of the next session. I built it because my rules kept drifting between projects and costing tokens I didn't need to spend.
This post covers why I made the AI Dev Standards & Playbook, what's in it, and how it changed the way I work with Claude Code.
When I pulled the rules out of my matthummel.com theme, I had ten always-on rule files. Together they were about 60 KB, loaded into every session. Most of it was WordPress and Sage detail that only matters when I'm editing a PHP or Blade file. Claude Code loads rules at session start, so that 60 KB rode along even when I was writing a blog post.
The fix was to split by trigger. The core rule is now 0.9 KB. The rest only load when Claude touches a matching file or picks a skill. Same standards, a fraction of the context.
What tipped me over was typing the same prompts again and again. Every new session started with me pasting the same security rules, the same accessibility checks and the same "answer first" note. Each of those prompts counted against my credits.
I wanted the rules to already be there, and I wanted the always-on part as small as possible so each session cost less.
Claude Code reads rules, skills and commands from ~/.claude, and a SessionStart hook can run a script before each session. The playbook uses both.
install.sh copies the repo into ~/.claude once and adds the hook. From then on, every new session runs sync.sh, which does a git pull --ff-only and recopies the files. If nothing changed, it prints nothing.
I use copies, not symlinks, on purpose. Symlinks need Developer Mode on Windows, and Claude Code loads ~/.claude/rules/ without an approval prompt when the files are plain copies.
One catch: rules load at session start, so a merge shows up in the session after the one that pulled it. When I want it right away, I run sync.sh by hand and restart.
Eight folders. Here's what each one does and when it loads.
core.md is the only always-on file. It covers:
A skill is a folder with a SKILL.md that Claude loads on demand. I have six so far:
I have five slash commands, namespaced so they never shadow a project's own:
The wp-reviewer agent reads a diff against the WordPress Developer Handbook before I open a pull request.
A PostToolUse hook runs PHPCS on every PHP file Claude edits and sends the errors straight back, so Claude fixes them before moving on.
/pb:new-project drops a kit into a theme repo:
I don't call them. Claude Code picks them up from what I'm doing and what I type.
That's why the descriptions matter more than the bodies. A skill with a vague description never loads, and one with a sharp description loads at the right moment. When a skill isn't firing, I fix the description, not the prompt.
Consistency. Every client site gets the same security checks, the same accessibility bar and the same review before a PR. I don't paste rules into a new CLAUDE.md each time.
Fewer stale answers. The doc-references skill tells Claude to fetch the official page before writing against a hook, a Tailwind v4 feature or a Next.js API. The project settings pre-approve those domains, so the fetch never stops for a permission prompt.
Cheaper sessions. The always-on context went from about 60 KB to under 1 KB, and I stopped re-sending the same rules by hand at the start of each session. Smaller prompts, fewer credits.
One place to fix things. When Claude gets something wrong twice, I change the rule once, open a PR, and the fix lands everywhere the next day. The repo's CI checks frontmatter, the core rule's size budget and a blocklist for private details, so I can't merge a client host name by mistake.
Anything that names a client. Hosts, paths, plugin lists, logins and product catalogs live in each project's CLAUDE.md and.claude/rules/.
The playbook is public, so validate.py scans every file for patterns like application passwords, GitHub tokens and private keys. It fails the build if one shows up.
If you use Claude Code on more than one repo, yes. Start smaller than I did:
You'll know within a week whether it's worth growing. Anthropic's guide on when to use CLAUDE.md, skills, hooks and subagents is a good overview of how the pieces fit together.