Zum Inhalt springen

Kapitel 4 von 10

Die Module, die installiert sein solltenEchte Sitzung, echte Ausgabe — nichts nachgestellt.
Gesprochener Text zum Mitlesen

Code Guardian prüft Ihren Code nicht selbst. Es sorgt dafür, dass die Prüfwerkzeuge Ihrer Sprache wirklich laufen. Hier ein frisches Projekt: Laravel, eine package-Datei, sonst nichts. So fängt fast jedes an. Der Detektor nennt nicht nur, was fehlt, sondern warum. Ohne PHPStan haben PHP-Änderungen kein objektives Gate. Ohne ESLint haben JavaScript und Vue überhaupt keines. Beides ist Pflicht, beides fehlt. Zu jeder Lücke steht der Weg dabei — der Einrichtungs-Skill legt Konfiguration und Baseline an. Die letzte Zeile zählt: zwei Pflichtwerkzeuge fehlen. Solange diese Zahl nicht null ist, arbeitet Code Guardian hier mit einer Hand auf dem Rücken.

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.

Dieses Kapitel als Auftrag an Claude

Kopieren, die spitzen Klammern durch Ihre eigene Angabe ersetzen, in Claude Code einfügen.

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.