# Code Guardian — Einstiegsleitfaden Beschreibt Code Guardian v16.164. Abgerufen am 21.09.2026 im Kundenportal auf provimedia.de. --- # In zehn Minuten startklar Code Guardian ist kein Programm, das Sie starten. Es ist ein Regelwerk, das Claude Code beim nächsten Sitzungsstart einliest — und eine Reihe von Riegeln, die ab dann jeden gefährlichen Befehl abfangen. Diese zehn Minuten richten beides ein. ## Vorher: zwei Programme prüfen ```bash python3 --version which jq ``` **Fehlt `python3`, bricht der Installer ab** und fasst nichts an. Das ist die freundliche Variante. **Fehlt `jq`, wird trotzdem alles installiert** — und der Installer endet mit einer Warnung und dem Rückgabewert 3. Die Riegel sind dann eingerichtet, aber sie prüfen nichts. Das ist der eine Fehler, der still bleibt: Sie sehen die Dateien liegen und halten sich für geschützt. Wenn Sie sich einen Satz aus diesem Leitfaden merken, dann diesen. Auf macOS: `brew install jq`. Auf Debian oder Ubuntu: `sudo apt install jq`. ## 1. Auspacken und installieren ```bash unzip code-guardian-v16.164-update.zip -d code-guardian cd code-guardian ./install.sh ``` Der Installer schreibt nach `~/.claude/` — global, nicht in Ihr Projekt. Ihre Projekte bleiben unberührt; es entstehen dort erst Dateien, wenn Sie tatsächlich arbeiten, und die sind alle gitignored. Unterwegs fragt er einmal, ob er die Code-Guardian-Statuszeile einrichten soll. Enter heißt ja. Haben Sie schon eine eigene, bleibt sie unangetastet. ## 2. Claude Code vollständig neu starten Nicht `/clear`. Beenden und neu öffnen. Hooks und Agenten-Definitionen liest Claude Code **nur beim Start** ein. Wer das überspringt, hat das Paket installiert und arbeitet trotzdem ohne einen einzigen Riegel — bis zum nächsten Start, und bis dahin denkt er, es läuft. ## 3. Nachsehen, ob es wirklich da ist In der neuen Sitzung: | Befehl | Was dastehen muss | |---|---| | `/hooks` | die Riegel-Einträge | | `/agents` | die Prüfagenten | | `/help` | `code-guardian` in der Skill-Liste | Die Zahl der registrierten Riegel lesen Sie nicht aus dem Text ab, sondern fragen sie: ```bash python3 -c "import json;d=json.load(open('$HOME/.claude/settings.json'));print(sum(len(v) for v in d.get('hooks',{}).values()),'Registrierungen')" ``` ## 4. Einen Riegel scharf schießen Die Probe steht ausführlich in der `README.md` des Pakets: ein vorbereitetes JSON in `decision-gate-check.sh` und in `deploy-gate-check.sh` schicken. Beide müssen mit einer `deny`-Zeile antworten. Antworten sie nicht, fehlt `jq` — siehe oben. ## 5. Eine Seite lesen, die im Paket liegt `README_IMPORTANT.md`, 181 Zeilen. Darin steht, was das Paket Sie je Anfrage an Kontext kostet und wann es sich lohnt, Ihre eigene `~/.claude/CLAUDE.md` auszudünnen. Das ist die einzige Datei des Pakets, die Sie wirklich von vorn bis hinten lesen sollten. ## In einem Satz Installieren, **Claude Code komplett neu starten**, `/hooks` prüfen — und wenn der Installer mit dem Rückgabewert 3 endet, fehlt `jq` und nichts wird geprüft. ## Prompt für Claude Code ``` Prüfe meine Code-Guardian-Installation und sag mir, was fehlt. Zeig mir dafür konkret: - ob python3 und jq auf diesem Rechner vorhanden sind - wie viele Hook-Registrierungen in ~/.claude/settings.json stehen - ob code-guardian in der Skill-Liste auftaucht Miss das, statt es zu vermuten, und nenne zu jedem Punkt das Kommando, mit dem du es festgestellt hast. Gib mir am Ende eine Liste dessen, was ich noch tun muss. Ändere nichts ohne meine Freigabe. ``` --- # Warum es funktioniert Ein Sprachmodell vergisst eine Regel, die nur in einem Text steht. Deshalb besteht Code Guardian aus drei Ebenen, und nur eine davon ist Text. Die beiden anderen laufen außerhalb des Modells. ## Ebene 1 — Skills: was das Modell liest Ein Skill ist eine Anweisung, die Claude beim passenden Anlass in den Kontext lädt. Er ändert, **wie** gearbeitet wird: erst einstufen, dann prüfen, dann bauen, dann belegen. Das ist die schwächste Ebene, und das Paket behandelt sie auch so. Ein Skill kann übersehen werden. Deswegen gibt es Ebene 2. ## Ebene 2 — Riegel: was gar nicht erst läuft Ein Riegel ist ein Hook: ein kleines Programm, das Claude Code **vor** einem Werkzeugaufruf fragt. Antwortet es mit `deny`, wird der Befehl nicht ausgeführt. Nicht gewarnt, nicht kommentiert — nicht ausgeführt. Das ist der Unterschied zwischen einem Ratschlag und einer Sperre: | Ohne Riegel | Mit Riegel | |---|---| | „Bitte prüfe vor dem Deploy, welche Dateien mitgehen." | `rsync` an den Produktivserver wird abgewiesen, bis die Klassifikation vorliegt. | | „Migrationen sollten umkehrbar sein." | `artisan migrate` läuft nicht, solange Umkehrbarkeit, Sperrprofil und Backfill nicht beurteilt sind. | | „Achte auf Geheimnisse im Commit." | `git commit` bricht ab, wenn ein Schlüssel im Diff steht. | Die Riegel greifen **unabhängig davon, ob ein Skill geladen ist**. Sie hängen am Befehl, nicht an der guten Absicht. Eine zweite Sorte sitzt am Ende: Stop-Riegel. Sie verweigern nicht einen Befehl, sondern den **Abschluss** — solange eine Behauptung unbelegt ist, ein Punkt offen steht oder eine Änderung an heiklem Code ohne kaltes Gegenlesen geblieben ist. ## Ebene 3 — Prüfagenten: wer nicht weiß, was Sie hören wollen Ein Modell, das seine eigene Arbeit noch einmal liest, findet Bestätigung. Das ist kein Charakterfehler, sondern Mechanik: es hat dieselben Annahmen wie beim Schreiben. Die Prüfagenten des Pakets bekommen deshalb **nicht** das Urteil des Autors. Sie bekommen das Artefakt und den Auftrag, Fehler zu finden. Keiner von ihnen hat ein Schreibwerkzeug — sie können nur lesen, messen und melden. Das ist der Grund, warum ein Befund aus dieser Richtung etwas wert ist: Er ist nicht die zweite Meinung desselben Kopfes. ## Was daraus folgt — für Sie **Beleg schlägt Behauptung.** „Ich habe es gelesen, es sieht richtig aus" gilt im ganzen Paket nicht als Prüfung. Was zählt, ist ein ausgeführter Befehl mit seiner Ausgabe, oder ein Prüfer von außen. Und die Grenze steht im Lizenzvertrag, Abschnitt 7.3, wörtlich: > Code Guardian prüft und meldet; jede Entscheidung über eine Änderung, eine > Freigabe oder eine Auslieferung trifft der Lizenznehmer. Das Paket hält Sie auf, wenn etwas unbelegt ist. Es nimmt Ihnen die Entscheidung nicht ab, und es will sie auch nicht. ## In einem Satz Skills ändern, wie gearbeitet wird; Riegel verhindern, was nicht laufen darf; Prüfagenten widersprechen — und die Entscheidung bleibt bei Ihnen. ## Prompt für Claude Code ``` Zeig mir, welche Code-Guardian-Riegel in diesem Projekt gerade scharf sind. Für jeden einzelnen: - wann er feuert - was genau er abweist - was ich liefern muss, damit er öffnet Nenne sie beim Dateinamen, nicht nur dem Zweck nach. Und sag mir zum Schluss, welcher davon bei meinem nächsten Vorhaben voraussichtlich zuschlagen wird. ``` --- # Der erste Auftrag Die häufigste Enttäuschung nach der Installation: Sie tippen etwas, und Claude fängt nicht sofort an zu programmieren. Das ist kein Fehler, das ist das Produkt. Dieses Kapitel zeigt, was in den ersten Minuten passiert — damit Sie es wiedererkennen statt dagegen zu arbeiten. ## Fangen Sie klein an Nehmen Sie ein echtes, kleines Vorhaben aus einem echten Projekt. Nicht „schreib mir eine App". Zum Beispiel: > Auf der Kontaktseite fehlt die Telefonnummer im Impressum-Block. Bau sie ein. ## Was Sie dann sehen — vier Stationen **1. Die Einstufungskarte.** Claude ordnet den Auftrag ein, bevor er etwas anfasst: wie groß, welcher Weg, womit wird bewiesen, dass es fertig ist. Sie steht als kleiner Kasten in der Antwort. **2. Die Schleuse.** Bei allem, was mehr als eine Datei berührt, geht Claude zuerst in den Plan-Modus: lesen, messen, einen Plan schreiben — und **nichts ändern**. Das ist die Station, die am meisten Geduld kostet und am meisten spart. **3. Die Rückfragen.** Jede offene Entscheidung wird Ihnen einzeln vorgelegt, mit einer Empfehlung an erster Stelle und einer Zeile, was die Wahl konkret bedeutet. Antworten Sie kurz. Wenn Ihnen keine Option passt, sagen Sie das — dann kommt eine bessere Frage. **4. Die Freigabe.** Erst wenn Sie den Plan freigeben, wird geschrieben. ## Wenn der erste Riegel zuschlägt Irgendwann wird ein Befehl abgewiesen. Meist beim ersten Mal `git commit`, `npm install` oder einem Deploy. Die Meldung nennt den Riegel beim Namen und sagt, was fehlt. **Tun Sie dann drei Dinge nicht:** den Riegel abschalten, den Befehl umformulieren, bis er durchrutscht, oder Claude bitten, „es einfach trotzdem zu machen". Alle drei funktionieren technisch, und alle drei nehmen Ihnen genau das weg, wofür Sie bezahlt haben. **Tun Sie stattdessen das:** lesen, was fehlt, und es liefern. Fast immer ist es eine Minute Arbeit — eine Klassifikation, eine Prüfung, ein Beleg. Der Riegel öffnet danach von selbst. ## Drei Sätze, die den Unterschied machen | Statt | Sagen Sie | |---|---| | „Mach das schnell." | „Was würdest du vorher prüfen wollen?" | | „Passt schon." | „Beleg das bitte mit einem ausgeführten Befehl." | | „Das ist zu klein für den ganzen Prozess." | Nichts. Genau dieser Satz ist im Paket ein Auslöser. | ## In einem Satz Der erste Auftrag ist ein kleiner — und wenn ein Riegel zuschlägt, liefern Sie nach, was er verlangt, statt ihn zu umgehen. ## Prompt für Claude Code ``` Nimm dir diese Aufgabe vor: Arbeite sie so ab, wie du es normalerweise tust. Aber ändere nichts, bevor ich den Plan freigegeben habe. Zeig mir vorher: - wie du die Aufgabe einstufst und warum - was du prüfen willst, bevor du etwas anfasst - woran wir am Ende erkennen, dass es wirklich fertig ist Wenn dabei eine Entscheidung offen ist, leg sie mir einzeln vor, statt sie selbst zu treffen. ``` --- # Die Module, die installiert sein sollten Code Guardian prüft Ihren Code nicht selbst. Es sorgt dafür, dass die etablierten Prüfwerkzeuge Ihrer Sprache **tatsächlich laufen** und dass ihr Ergebnis nicht übergangen wird. Fehlen sie, fehlt dem Paket eine Ebene — und das merkt man nicht, weil trotzdem alles grün aussieht. ## Der Installer installiert davon nichts Das ist Absicht und steht auch so in seiner Schlussmeldung: welches Werkzeug in Ihr Projekt kommt, ist Ihre Entscheidung, nicht die eines fremden Skripts. Stattdessen meldet Ihnen der Sitzungsstart die Lücken und nennt den passenden Einrichtungs-Skill. ## Was pro Sprache erwartet wird | Sprache | Pflicht | Empfohlen | Optional | |---|---|---|---| | **PHP** | `phpstan` (mit Larastan) | `phpunit`, `pest` | `infection`, `pint`, `rector` | | **JavaScript, TypeScript, Vue** | `eslint` | `tsc`, `vue-tsc`, `vitest` | `stryker`, `prettier`, `knip` | | **Python** | `ruff` | `mypy`, `pytest` | `mutmut`, `hypothesis` | | **Blade, HTML** | — | `html-validate` | — | „Pflicht" heißt: ohne dieses Werkzeug meldet der Detektor eine Lücke und das Statik-Gate für diese Sprache greift nicht. ## Einrichten lassen, nicht selbst zusammensuchen Vier Skills tun genau das — Konfiguration, sinnvolle Grundeinstellung und eine Baseline, damit ein Altbestand Sie nicht am ersten Tag unter 4.000 Meldungen begräbt: ``` /phpqa-onboard PHP: PHPStan/Larastan, Rector, Baseline, composer-Skripte /jsqa-onboard JS/Vue: ESLint, vue-tsc, Vitest, fast-check, Stryker, knip /pyqa-onboard Python: ruff, mypy, pytest, Hypothesis, mutmut, Baseline /htmlqa-onboard Blade/HTML: html-validate mit Blade-sicherer Konfiguration ``` Einmal je Projekt. Danach kennt der Sitzungsstart Ihre Werkzeuge. ## Die Grenze, die Sie kennen sollten Außerhalb von PHP, JavaScript, Python und Markup gibt es **kein Statik- und kein Mutations-Gate**. Riegel, Schleuse, Reflexe und der Slop-Scanner arbeiten dort weiter — die sprachspezifische Prüfebene nicht. Wenn Sie überwiegend Go, Rust oder Java schreiben, ist das die ehrliche Auskunft vor dem Kauf, nicht danach. ## Ein Werkzeug, das oft fehlt und teuer ist `infection` (PHP) beziehungsweise `stryker` (JS) sind als optional geführt und verdienen trotzdem einen Satz: Ohne sie bleibt **unbelegt, ob Ihre Tests überhaupt etwas prüfen**. Ein grüner Test, der auch grün bleibt, wenn man die Logik kaputt macht, beweist nichts — und das findet nur eine Mutationsprobe. ## In einem Satz PHP braucht `phpstan`, JavaScript `eslint`, Python `ruff` — einrichten lassen Sie das einmal je Projekt mit dem passenden `*qa-onboard`-Skill, denn der Installer tut es bewusst nicht. ## Prompt für Claude Code ``` Prüfe, welche statischen Analysewerkzeuge in diesem Projekt fehlen. Miss das, statt es zu vermuten: sieh in composer.json, package.json und in die vorhandenen Konfigurationsdateien, und sag mir zu jedem Werkzeug, woher du weißt, ob es da ist. Sag mir dann: - was fehlt und welche Prüfebene damit ausfällt - was es kostet, das nachzurüsten Auf meine Freigabe hin richte die fehlenden mit dem passenden qa-onboard-Skill ein und leg eine Baseline an, damit der Altbestand mich nicht am ersten Tag begräbt. ``` --- # Welcher Skill wann Das Paket liefert **26 Skills** (Stand v16.164). Die wichtigste Unterscheidung steht nirgends sonst: Ein Teil davon läuft von selbst. Den Rest rufen Sie. ## Die acht, die Sie nie aufrufen müssen Diese greifen, sobald ihr Anlass eintritt. Sie müssen nichts tun — es hilft nur zu wissen, wer da gerade arbeitet. | Skill | Anlass | |---|---| | `senior-dev` | jede Anfrage. Stuft ein, plant den Beweis, hält die Haltung bis zum Abschluss | | `code-guardian` | jede Codeänderung, jeder Fehlerbericht. Wählt den Modus und stellt die Riegel | | `todo` | sobald Arbeit entsteht. Führt die Liste und verweigert „fertig", solange etwas offen ist | | `entscheidungs-klartext` | vor jeder Optionsfrage. Übersetzt sie in Alltagssprache | | `grill-me` | in der Plan-Schleuse. Legt offene Entscheidungen einzeln vor | | `kernanalyse` | bei der Fehlersuche. Prüft, ob eine Maßnahme die Ursache anfasst oder nur das Symptom | | `llm-council` | nach dem zweiten Fehlschlag in der Fehlersuche, automatisch | | `session-retro` | am Sitzungsende. Sammelt, was gehakt hat | ## Die, die Sie rufen — Überblick behalten | Skill | Wofür | |---|---| | `clistatus` | „Wo stehen wir?" Ein Dashboard aus gemessenen Fakten, nie aus dem Gedächtnis | | `whatsnext` | „Was als Nächstes?" Die Projektleitungs-Sicht: was blockiert den Launch | | `session-observe` | ein nachträglicher, rein lesender Rückblick auf eine Sitzung | | `protokoll-durchsicht` | durchsehen, was die Riegel protokolliert haben — und Fehlalarme finden | ## Die, die Sie rufen — mehr Durchsatz | Skill | Wofür | |---|---| | `multitask` | mehrere Aufgaben gleichzeitig, jede in ihrer eigenen Arbeitskopie | | `session-orchestrator` | Arbeit an andere offene Claude-Sitzungen desselben Rechners verteilen | | `autopilot` | einen Auftrag ohne Rückfragen durchziehen, wenn Sie nicht am Rechner sind | | `llm-council` | eine teure Entscheidung von fünf Beratern durchleuchten lassen | ## Die, die Sie rufen — prüfen | Skill | Wofür | |---|---| | `test-architect` | Senior-Review Ihrer PHP-Tests. Berät, blockiert nicht | | `frontend-test-architect` | dasselbe für das Frontend | | `slop-audit` | Voll-Repo-Audit gegen KI-Wildwuchs. Nur Bericht, löscht nichts | | `design-beweis` | misst Kontrast in **jedem** Zustand und belegt WCAG 2.2 | | `rechts-beleg` | beschafft belegte Rechtsgrundlagen mit Quelle und Abrufdatum | ## Die, die Sie einmal je Projekt rufen | Skill | Wofür | |---|---| | `phpqa-onboard` | PHPStan, Rector, Baseline, composer-Skripte | | `jsqa-onboard` | ESLint, vue-tsc, Vitest, Stryker, knip | | `pyqa-onboard` | ruff, mypy, pytest, Hypothesis, mutmut | | `htmlqa-onboard` | html-validate, Blade-sicher konfiguriert | | `ritual-lernen` | macht aus einer erlebten Verzögerung eine Zeile Ihrer Projekt-Checkliste | | `senior-marketing` | SEO und Online-Marketing mit mitgelieferter, quellenbelegter Wissensbasis | ## Wie Sie einen Skill rufen Mit Schrägstrich und Namen: `/clistatus`, `/whatsnext`, `/multitask 3`. Oder einfach, indem Sie sagen, was Sie wollen — „wo stehen wir gerade", „verteil das auf die anderen Sitzungen". Die Auslöser sind auf normale Sätze ausgelegt, nicht auf Kommandos. ## Was Sie selbst dazustellen Was Sie an eigenen Skills in `~/.claude/skills/` legen, bleibt dort neben den 26 und wird von Updates nicht angefasst. Das Paket ersetzt Ihre eigenen Werkzeuge nicht, es kommt daneben. ## In einem Satz Acht Skills arbeiten ungefragt, den Rest rufen Sie — und die vier `*qa-onboard` genau einmal je Projekt. ## Prompt für Claude Code ``` Ich habe vor: Sag mir, bevor du anfängst: - welche Code-Guardian-Skills dabei von selbst greifen - welche ich zusätzlich rufen sollte, und was sie jeweils beitragen - welche hier nichts bringen und warum Begründe jede Zuordnung mit dem Auslöser des jeweiligen Skills, nicht mit deinem Eindruck. Danach fang an. ``` --- # Mehrere Aufgaben gleichzeitig `multitask` nimmt mehrere Aufgaben und gibt jeder eine eigene Arbeitskopie: eigener `git worktree`, eigener Branch, eigener vollständiger Guardian-Ablauf. Sie bekommen am Ende mehrere fertige Zweige statt einer fertigen Aufgabe. ## Aufrufen ``` /multitask 3 ``` Oder in Worten: „starte die nächsten drei Aufgaben parallel". Höchstens fünf gleichzeitig. Die Grenze ist nicht technisch, sondern eine Frage dessen, was ein Mensch danach noch prüfen kann. ## Das Gesetz dieses Skills > Eine Zelle arbeitet autonom bis zum grünen Branch — und keinen Schritt > weiter. Kein Werkzeug des Skills kennt `git merge`, `git push` oder `git update-ref`. Das ist keine Vorsichtsmaßnahme, die man abschalten könnte; die Fähigkeit ist schlicht nicht da. **Das Zusammenführen bleibt Ihre Entscheidung.** ## Wann es sich lohnt Wenn die Aufgaben **verschiedene Dateien** anfassen. Drei Tickets in drei Modulen: ideal. Vor dem Start misst ein Gatter, welche Dateien je Aufgabe im Spiel sind, und weist überlappende Paare ab. Das ist kein Übereifer: In einer Auswertung von 33.596 Agenten-Pull-Requests aus 2.807 Repositories kollidierten **19,8 Prozent der gleichzeitig aktiven Paare** desselben Repositories textuell miteinander. ## Wann es sich nicht lohnt - **Gekoppelte Arbeit.** Zwei Aufgaben an derselben Datei werden nicht schneller, sie werden zu einem Konflikt. - **Eine einzelne Aufgabe.** `multitask` macht keine Aufgabe schneller. Es macht mehrere gleichzeitig — und kostet entsprechend mehr. - **Wenn Sie zusehen wollen.** Fünf Zellen gleichzeitig kann niemand im Blick behalten. Dafür gibt es die Tafel. ## Die Tafel Am Ende liegt eine Übersicht vor: was jede Zelle getan hat, was grün ist, und welche Entscheidungen in Ihrer Abwesenheit gefallen sind. Diese Tafel ist der eigentliche Grund, warum man einen parallelen Lauf danach noch verantworten kann. ## Der Handgriff danach Jeder Zweig wird einzeln angesehen und einzeln übernommen. Reihenfolge nach Risiko: das Kleinste zuerst, damit ein Konflikt früh auffällt und nicht am fünften Zweig. ## In einem Satz `multitask` liefert bis zu fünf grüne Branches in eigenen Arbeitskopien — das Zusammenführen kann es nicht, und das ist der Punkt. ## Prompt für Claude Code ``` Starte die nächsten drei Aufgaben parallel, jede in ihrer eigenen Arbeitskopie. Prüfe vorher, ob sie sich Dateien teilen. Wenn ja, sag mir welche und häng sie hintereinander, statt sie gleichzeitig zu fahren. Führe nichts zusammen — kein merge, kein push. Ich will am Ende die Tafel sehen: was jede Zelle getan hat, was grün ist, und welche Entscheidungen in meiner Abwesenheit gefallen sind. ``` --- # Mehrere Sitzungen `session-orchestrator` verteilt Arbeit an die **anderen Claude-Code-Sitzungen, die auf Ihrem Rechner bereits offen sind**. Er startet nichts Neues — er findet, wer gerade frei ist, und gibt dorthin einen Auftrag. ## Der Unterschied zu `multitask` in einem Satz `multitask` **erzeugt** Arbeit in neuen Arbeitskopien. `session-orchestrator` **verteilt** Arbeit an Fenster, die ohnehin schon laufen. Wenn Sie mit drei Terminals an einem Projekt sitzen, ist dieser Skill gemeint. Wenn Sie ein Terminal haben und fünf Tickets, ist `multitask` gemeint. ## Aufrufen ``` /session-orchestrator board ``` Oder: „wer ist gerade frei?", „verteil das". ## Was die Tafel zeigt Eine Zeile je Sitzung: Kennung, Projekt, Zustand. Und darunter eine Zusammenfassung — wie viele Sitzungen laufen, wie viele davon in diesem Projekt, wie viele frei sind, wie viele schon einen Auftrag halten. Die Sitzungen bekommen stabile Kennungen (A, B, C). Die hängen an der Sitzungs-ID, nicht am Namen — Namen ändern sich im Lauf einer Sitzung, und ein Auftrag, der an einen veralteten Namen geht, kommt nie an. ## Die eine Regel, die zählt **Eine wartende Sitzung ist nicht frei.** `waiting` heißt: dort steht eine Frage, und ein Mensch muss antworten. Wer dorthin verteilt, legt einen Auftrag hinter eine geschlossene Tür. Der Orchestrator zählt sie deshalb nie als verfügbar — und wenn Sie von Hand verteilen, gilt dasselbe. ## Was er ausdrücklich nicht tut Er **sendet nicht selbst**. Das Werkzeug misst und bucht; zugestellt wird der Auftrag als sichtbare Nachricht. Sie können also jederzeit nachlesen, wer was bekommen hat — es gibt keinen stillen Kanal. ## Wenn mehrere Sitzungen im selben Projekt arbeiten Dann teilen sie sich einen Arbeitsbaum, und das ist die häufigste Quelle für Geisterfehler: Eine Sitzung ändert eine Datei, eine andere misst gerade gegen sie und meldet einen Defekt, den es nie gab. Zwei Handgriffe schützen davor: - **Die Aufgabenliste beachten.** Ein Punkt im Zustand `läuft` mit fremder Kennung gehört einer anderen Sitzung. Nicht anfassen. - **Gegen Commits messen, nicht gegen die Platte.** `git show :` liefert einen Stand, den niemand unter Ihnen wegzieht. ## In einem Satz `session-orchestrator` verteilt an offene Fenster desselben Rechners — und eine wartende Sitzung ist nie frei. ## Prompt für Claude Code ``` Zeig mir die Tafel der offenen Claude-Code-Sitzungen auf diesem Rechner. Sag mir, welche davon wirklich frei sind — wartende zählen nicht, dort steht eine Frage an einen Menschen. Verteile dann an die erste freie Sitzung in diesem Projekt und nenne mir, an welche sie gegangen ist. Wenn keine frei ist, sag mir das, statt eine zu belegen. ``` --- # Wenn Falschliegen teuer ist `llm-council` schickt eine Frage durch einen Rat von fünf Beratern. Jeder analysiert unabhängig, danach begutachten sie sich **anonym** gegenseitig, und ein Vorsitzender führt das Ergebnis zu einem Urteil zusammen. Die Idee stammt von Andrej Karpathys LLM Council. Umgesetzt ist sie hier nicht mit fünf verschiedenen Modellen, sondern mit fünf Denk-Linsen auf demselben Modell — der Gewinn kommt aus der Unabhängigkeit, nicht aus dem Anbieter. ## Warum anonym Wenn ein Berater weiß, wessen Vorschlag er begutachtet, begutachtet er die Person mit. Anonym bleibt nur das Argument übrig. Das ist derselbe Gedanke, aus dem die Prüfagenten das Urteil des Autors nicht kennen. ## Wann Sie ihn rufen Wenn Falschliegen teuer ist und es einen echten Zielkonflikt gibt: - Zwei Architekturwege, die beide vertretbar sind - Eine Migration, die sich schlecht zurücknehmen lässt - Eine Preis- oder Vertragsfrage mit Folgen für Bestandskunden - Eine Entscheidung, die Sie in sechs Monaten erklären müssen ## Wann ausdrücklich nicht | Nicht dafür | Sondern | |---|---| | Faktenfragen („wie heißt die Option?") | nachsehen | | Erstellungsaufgaben („schreib mir den Text") | direkt beauftragen | | Zusammenfassungen | direkt beauftragen | | Eine Frage, die eine Messung beantwortet | messen | Der letzte Punkt ist der teuerste Fehler. Ein Rat, der über eine Zahl berät, die man in dreißig Sekunden messen könnte, produziert fünf gut begründete Meinungen über eine unbekannte Tatsache. ## Er kommt auch ungerufen In der Fehlersuche eskaliert Code Guardian **nach dem zweiten Fehlschlag** bedingungslos an den Rat. Das ist der Moment, in dem sonst die dritte Variante derselben falschen Idee entsteht. Und im Autopilot geht **jede** Rückfrage an ihn — dort ist er der Ersatz für Sie. ## Was zurückkommt Kein Ja oder Nein, sondern: wo die Berater übereinstimmen, wo sie kollidieren, und was daraus folgt. Die Stellen, an denen sie sich uneinig sind, sind die wertvollsten — dort liegt das eigentliche Risiko Ihrer Entscheidung. ## In einem Satz Den Rat rufen Sie bei echten Zielkonflikten mit Einsatz — nicht bei Fragen, die eine Messung beantwortet. ## Prompt für Claude Code ``` Lass den llm-council über diese Entscheidung laufen: Prüfe aber ZUERST, ob eine Messung die Frage schon beantwortet. Wenn ja, miss, statt zu beraten — fünf Meinungen über eine unbekannte Tatsache sind teuer und wertlos. Sag mir am Ende nicht nur das Ergebnis, sondern auch, wo die Berater sich uneinig waren. Dort liegt mein eigentliches Risiko. ``` --- # Autopilot Der Autopilot führt einen Auftrag bis zum Ergebnis durch, **ohne Sie zu fragen**. Jede Rückfrage, die sonst an Sie ginge, geht an den `llm-council`, und jede so getroffene Entscheidung steht im Wortlaut im Protokoll. Sein Gesetz steht im Skill selbst: > Autopilot nimmt dem Menschen das Warten ab, nicht die Rechenschaft. ## Wann er richtig ist - Sie gehen aus dem Haus und der Auftrag ist klar umrissen - Eine lange, mechanische Strecke: viele gleichartige Dateien, eine Migration von Textstellen, ein Rückbau - Sie sagen ausdrücklich „ohne Rückfragen" oder „zieh das durch" ## Wann er falsch ist **Wenn der Auftrag `skills/`, `hooks/` oder den Installer berührt.** Dann bleibt der Lauf interaktiv — ein Autopilot baut nicht an den Riegeln, die ihn begrenzen. Und er ist falsch bei allem, wo Sie die Entscheidung tatsächlich selbst treffen wollen. Der Rat entscheidet gut, aber er entscheidet nicht wie Sie. ## Was er ausdrücklich nicht löst Das ist der Teil, den man wissen muss, bevor man ihn scharf stellt: **Die Riegel bleiben scharf.** Alle. | Riegel | Bleibt | |---|---| | Deploy | scharf | | Migration | scharf | | Abhängigkeiten | scharf | | Zerstörende Befehle | scharf | Sie hängen am Befehl, nicht am Modus — ein unbeaufsichtigter Lauf kann sie deshalb nicht überholen. Zusätzlich zündet der Modus einen **eigenen** Riegel, der genau für diesen Fall da ist: Schreibzugriffe auf besonders heikle Dateien — Zugangsdaten, die Riegel-Skripte selbst, Berechtigungen, Migrationen — werden abgewiesen, solange niemand da ist, der sie freigeben könnte. ## Er hält von selbst an Fünf Stoppbedingungen beenden den Lauf, darunter **jedes rote Ergebnis**. Ein Autopilot, der über einen roten Test hinwegläuft, wäre kein Autopilot, sondern ein Bagger. ## Ein- und ausschalten Scharf stellen gehört ausdrücklich in den Auftrag — aus einer Erwähnung folgt keine Freigabe. Abschalten mit einem Satz: „/autopilot aus". ## Das Protokoll ist der ganze Punkt Danach lesen Sie `.code-guardian-autopilot.md`: jede Frage, die aufkam, jeder Beschluss des Rats, jede Begründung. Wenn Sie mit einer Entscheidung nicht einverstanden sind, sehen Sie dort genau, worauf sie beruhte — und können sie umkehren. Ein unbeaufsichtigter Lauf ohne dieses Protokoll wäre nicht vertretbar. Mit ihm ist er es. ## In einem Satz Der Autopilot ersetzt Ihre Anwesenheit, nicht Ihre Verantwortung — die Riegel bleiben scharf, und jede Entscheidung steht nachlesbar im Protokoll. ## Prompt für Claude Code ``` Stell den Autopilot scharf für diesen Auftrag: Frag mich nicht zwischendurch. Jede Entscheidung, die du stattdessen selbst triffst, kommt mit Begründung ins Protokoll, BEVOR du handelst. Halt an, sobald etwas rot ist oder ein Riegel verweigert — und sag mir beim Anhalten genau, was fehlt. Prüfe vorher, ob der Auftrag skills/, hooks/ oder den Installer berührt. Wenn ja, bleib interaktiv und sag mir warum. ``` --- # Stand, Nächstes, Grenzen Drei Skills beantworten drei verschiedene Fragen, die man leicht verwechselt — und am Ende steht, was das Paket nicht tut. ## „Wo stehen wir?" — `clistatus` Ein Dashboard: was erledigt ist, was läuft, was offen ist, wie die Riegel stehen. Das Entscheidende daran ist die Regel, nach der es gebaut wird: **Rendere es nie aus dem Gedächtnis.** Bevor auch nur ein Kästchen erscheint, wird die Wahrheit eingesammelt — Aufgabenliste, laufende Hintergrundläufe, `git log`, `git status`, das Ledger. Deshalb ist das Erstellen des Dashboards selbst schon die Prüfung. Gut nach einer längeren Pause oder wenn der Kontext gerade zusammengefasst wurde. ## „Was als Nächstes?" — `whatsnext` Nicht der Entwicklerblick, sondern der der Projektleitung: Was bringt das Projekt dem Ziel näher, was blockiert den Start? Zwei Eigenschaften, die ihn brauchbar machen: - Er **schreibt ausschließlich** unter `docs/manager/`. Er fasst Ihren Code nicht an. Ein roter Build ist für ihn ein Befund, kein Arbeitsauftrag. - Ohne bestätigte Problemstellung gibt er keine Empfehlung: Wer hat das Problem, was kostet es heute, woran erkennt man die Lösung. Ohne Antwort auf diese drei Fragen gibt es keine Priorisierung, sondern eine Meinung. ## „Was ist noch offen?" — `todo` Die Liste des Laufs. Sie hat eine Einlass-Regel, und die ist der Grund, warum sie lesbar bleibt: Auf die Liste kommt nur, was eine Wirkung trägt. | | Wirkung | |---|---| | **S** | Sicherheit oder Datenverlust | | **K** | ein Kunde merkt es im normalen Gebrauch | | **R** | ein Release wird blockiert oder verfälscht | | **V** | Sie haben es beauftragt | Alles andere wird einmal genannt und **nicht** notiert. Wahr zu sein genügt nicht — in einem großen System findet ein Prüfer immer etwas Wahres, und eine Liste, die jeden wahren Befund aufnimmt, wächst schneller, als Arbeit sie leert. Abgehakt wird nur mit Beleg. „Eigentlich erledigt" ist keiner. ## Was Code Guardian nicht tut Damit Sie es von uns hören und nicht von einem enttäuschten Nachmittag: - **Es entscheidet nicht.** Lizenzvertrag 7.3: Änderung, Freigabe und Auslieferung entscheiden Sie. - **Es findet nicht jeden Fehler.** Es sorgt dafür, dass Behauptungen belegt werden und gefährliche Befehle nicht unbesehen laufen. Das ist etwas anderes als Fehlerfreiheit. - **Es hat außerhalb von PHP, JavaScript, Python und Markup kein Statik- und kein Mutations-Gate.** Riegel und Reflexe arbeiten dort weiter, die sprachspezifische Prüfebene nicht. - **Es verhindert keinen Vorsatz.** Die Riegel sind gegen Versehen gebaut. Wer sie umgehen will, kann es — er hat es dann nur bewusst getan. - **Es arbeitet lokal.** Keine Telemetrie, keine Datenübertragung an uns. ## Wenn etwas nicht stimmt Schreiben Sie an `dev@provimedia.de`. Ein Befund mit dem Befehl, der ihn erzeugt hat, ist uns lieber als ein höflicher Hinweis — genau das verlangt das Paket schließlich auch von sich selbst. ## In einem Satz `clistatus` sagt wo Sie stehen, `whatsnext` was als Nächstes kommt, `todo` was offen ist — und entschieden wird nichts davon ohne Sie. ## Prompt für Claude Code ``` Gib mir den Stand dieses Projekts in einem Zug: 1. Wo stehen wir gerade? Aus gemessenen Fakten — git, Tests, laufende Läufe —, nicht aus dem Gedächtnis. 2. Was ist noch offen, und was davon merkt ein Kunde im normalen Gebrauch? 3. Was wäre als Nächstes am meisten wert, und warum gerade das? Sag bei jedem Punkt dazu, woher du es weißt. Eine Zahl ohne ihr Kommando lass weg. ``` ---