Technische Schulden abbauen. Jetzt. Automatisch.
Halte deinen Code unter ständigem Refactoring.
/continuous-refactoring
Verbessere deinen Code Schritt für Schritt – mit Leitplanken aus Tests und Prüfwerkzeugen, damit du deinem Agenten immer mehr vertrauen kannst.
Eine portable Agent-Skill-Suite – funktioniert mit Claude Code, OpenCode, Cursor und mehr.
Warum kontinuierlich?
Weil Schulden sich lautlos summieren
Jede Abkürzung im Code macht die nächste Änderung ein Stück riskanter – unauffällig, bis ein Refactoring fällig wird, das keiner mehr im Griff hat. Ein einmaliges Aufräumprojekt behebt das nur kurzfristig: Ohne dauerhafte Routine kehrt der alte Zustand zurück, sobald das Projekt endet. Was trägt, ist ein Prozess, der neben der normalen Weiterentwicklung mitläuft, statt als Ausnahme behandelt zu werden.
Weil Automatisierung sie günstig macht
Die Werkzeuge dafür – statische Analyse, automatisiertes Code-Rewriting, Testabdeckung – sind ausgereift. Der eigentliche Flaschenhals ist nicht das Tool, sondern es laufend statt punktuell einzusetzen. Und das geht nur sicher, wenn vor jeder strukturellen Änderung ein deterministisches Sicherheitsnetz steht: Tests, Coding-Standards, statische Analyse. Einer Automatisierung – ob Skript oder Agent – sollte man nicht blind vertrauen; erst das Netz macht jede Änderung mechanisch prüfbar. Wie dieses Netz aufgebaut wird, bevor überhaupt Struktur angefasst wird, zeigt die Methode unten.
Die Methode
Ein Aufruf ist ein Run: fünf Schritte bis zu einem geöffneten Merge Request. Autonom und immer wieder aufgerufen wird daraus ein Loop – jeder Run findet in deinem Tracker vor, was der vorige hinterlassen hat.
Tippen, um direkt dorthin zu springen – sonst dreht sich der Loop von selbst weiter.
Orientieren
Liest deinen Tracker: was aus den letzten Merge Requests geworden ist, wo Arbeit wartet – und wählt den Track.
Finden
Prüft, was im Track noch fehlt, und legt dafür Tickets an.
Planen
Nimmt das nächste bearbeitbare Ticket und schreibt einen Plan darauf.
Umsetzen
Baut den Plan testgetrieben auf einem eigenen Branch, bis alle Checks grün sind.
Merge Request
Öffnet den Merge Request zum Review – der nächste Run orientiert sich daran.
Beispiel
$ /continuous-refactoring mach das selbst
Verstanden: autonomer Run über alle Tracks.
Abgleich… MR !46 (PHPUnit) gemergt → Ticket #81 geschlossen
Track-Wahl: Safety Net hat 1 bearbeitbares Ticket → Empfehlung genommen
Auswahl: #82 „Introduce PHP CS Fixer“ – noch nicht eingerichtet
Plan auf #82 gepostet
Setze testgetrieben um auf Branch 82-php-cs-fixer… Checks grün
Merge Request !47 geöffnet
Status: !47 für #82 ist offen, CI grün.
Next: reviewen und mergen – oder erneut aufrufen.
- Jeder Schritt ist ein Entscheidungspunkt: Befund, Optionen, Empfehlung. Du entscheidest – oder sagst „mach das selbst“, und die Suite folgt ihrer Empfehlung.
- Testgetrieben, Schritt für Schritt – Tempo spielt keine Rolle.
- Flexibler Rhythmus: von gelegentlich, per Hand angestoßen, bis zum Loop rund um die Uhr – dein Scheduler ruft den Run immer wieder autonom auf, und eine Gegenstelle (Mensch oder Agent) reviewt die Merge Requests, zum Beispiel um übriges Token-Budget vor Monatsende sinnvoll zu nutzen.
Die Skills
/continuous-refactoring
Ein Run
Ein Aufruf, ein Run: vom offenen Ticket bis zum geöffneten Merge Request. Gleicht ab, wählt den Track, scannt, legt Tickets an, plant und setzt um – und fragt an jedem Entscheidungspunkt, außer du sagst „mach das selbst“. Auf einem neuen Projekt richtet zuerst ein kurzes Onboarding den Zugang zu deinem Tracker ein.
/continuous-housekeeping
Für den Zeitplan
Nur der Housekeeping-Track, ohne Track-Wahl – deshalb der Befehl, den du einplanst. Richtet beim ersten Aufruf Vorlage und erstes Ticket ein und arbeitet danach das jeweils fällige Housekeeping-Ticket ab.
Alles andere – Scan, Auswahl, Planung, Umsetzung, Onboarding – sind Referenzen, die diese beiden Skills laden, wenn ein Run dort ankommt. Hat dein Projekt eigene Skills fürs Planen und Umsetzen, empfiehlt die Suite diese und nutzt ihre eigenen Verfahren nur als Rückfall.
Ein Run, ein Track
Jeder Run bearbeitet ein Ticket aus einem von vier Tracks. Empfohlen wird der erste in fester Reihenfolge, der Arbeit hat – oder du nennst ihn im Aufruf.
Richtet die deterministischen Prüfungen ein – Testrunner, Coding-Standards, statische Analyse, CI –, bevor ein Agent Struktur anfasst. Ein autonomer Run geht erst weiter, wenn es steht.
Richtet weitere Qualitäts- und Sicherheits-Tools ein, sobald das Safety Net steht – Coverage-Floor, Mess-Erkennung, strengere statische Analyse und mehr.
Wiederkehrende Wartung als ein stehendes Ticket mit Fälligkeitsdatum – Dependency-Aktualität, Dependency-Audit, Deprecation-Cleanup, Secret-Scan, plus kleine Refactoring-Ideen, die als Kommentare darauf landen.
Strukturelles Refactoring – bearbeitet vorhandene Tickets oder erkundet den Code nach Hotspots und Deepening-Gelegenheiten und schlägt die stärksten Funde als Tickets vor.
Mehr zu Runs, Tracks, Tooling, Architektur und FAQ: Dokumentation.
Installation
Erst das aktuelle Release dieses Repos klonen, dann die beiden Skills per Symlink ins Zielprojekt einbinden:
git clone --branch 0.10.0 https://github.com/Art4/continuous-refactoring.git
mkdir -p <target>/.agents/skills
ln -s /path/to/continuous-refactoring/skills/* <target>/.agents/skills/
Der Kern ist sprachneutral, die Tools kommen in Packs: eines für jedes Projekt, eines für PHP-Projekte (Code-Style, Rector, PHPStan und mehr – mit Diagramm, was worauf folgt) und eines für Twig. Ein Tool, das die Suite nicht kennt, kommt als eigenes Pack dazu.
Das PHP-Pack basiert auf über 20 Jahren PHP-Erfahrung von Artur Weigandt und wird laufend an den aktuellen Stand der Technik angepasst. Lehnt ein Maintainer ein Tool ab, wird das mit Begründung festgehalten und nicht erneut vorgeschlagen. Die wiederkehrende Nachprüfung im Housekeeping schlägt immer weitere Schritte in Richtung Wartbarkeit, Testbarkeit und Sicherheit vor – inklusive eines sich selbst verschärfenden Test-Coverage-Bodens und, auf Anfrage, OWASP-Top-10-Abdeckung durch Semgrep oder Mutation Testing mit Infection.
Auf ein neueres Release wechseln: im Klon git fetch --tags && git checkout <tag> – die Symlinks zeigen danach automatisch auf den neuen Stand. Releases: GitHub.
Von 0.6.0 umsteigen? Symlinks der entfernten Skills löschen, die alten Zustandsdateien im Scratch-Ordner der Suite löschen und /continuous-refactoring einmal aufrufen – das Onboarding ergänzt, was fehlt. Details in der FAQ.
FAQ
Bleibt ein Mensch im Loop?
Standardmäßig an jedem Schritt: Ein Run legt an jedem Entscheidungspunkt Befund, Optionen und Empfehlung vor und schreibt nichts in Tracker, Forge oder Repository, was du nicht bestätigt hast. Sagst du „mach das selbst“, folgt er seinen eigenen Empfehlungen – gemergt wird aber nie selbstständig: Jeder Run endet bei einem Merge Request, den ein Mensch oder ein gegenprüfender Agent reviewt und mergt. Verlangt ein Ticket eine schwer umkehrbare Entscheidung oder würde es Verhalten ändern, hinterlässt die Suite eine offene Frage auf dem Ticket und wartet auf deine Antwort dort. Und eine Änderung an deiner AGENTS.md wartet immer auf dich.
Warum so viel Tooling, statt direkt mit dem Refactoring zu starten?
Weil man einem LLM nicht zutrauen kann, allein sicher tief in bestehenden Code einzugreifen. Der Tooling-Baum baut zuerst deterministische Prüfungen auf — statische Analyse, Coding-Standards, ein laufender Testrunner —, bevor ein Agent überhaupt Code anfasst, damit eine falsche oder übermütige Änderung mechanisch auffliegt, statt sich darauf zu verlassen, dass der Agent seinen eigenen Fehler bemerkt. Fast alles davon lässt sich ablehnen — das kostet dann aber Codequalität und Abwärtskompatibilität: weniger Gates heißt ein gröberes Sicherheitsnetz, das eine schlechte Änderung vor dem Merge abfängt. Und die Reihenfolge ist kein Zwang: Nenne im Aufruf den Track, den du willst.
Welche Tools schlägt die Suite vor?
Eine Auswahl der Tools, die die Suite vorschlägt, wenn sie in einem Projekt noch nicht eingerichtet sind — grundsätzlich kommt sie mit jedem bereits vorhandenen Tooling zurecht. Tools auf Anfrage bietet sie nie ungefragt an: nenne eines im Aufruf („richte Semgrep ein“).
- PHP CS Fixer — Automatisierte Code-Formatierung, damit spätere automatisierte Änderungen (z. B. von Rector) sauber formatiert ankommen.
- PHPUnit — Der Testrunner des Projekts, kombiniert mit einer selbst-verschärfenden Coverage-Untergrenze: die Testabdeckung darf nur steigen, nie sinken.
- PHPStan — Statische Typanalyse in 11 ansteigenden Strenge-Stufen (0–10) — der Standardpfad der Suite für neue Projekte.
- Psalm — Alternative zu PHPStan: wird erkannt und weitergeführt, wenn ein Projekt es bereits nutzt, aber nicht neu vorgeschlagen.
- Psalm Taint Analysis — Verfolgt Daten von nicht vertrauenswürdiger Eingabe bis zu gefährlichen Operationen (SQL-Injection, XSS & Co.) — auf Anfrage, auch für Projekte, die PHPStan nutzen.
- PHPMD — Misst zyklomatische Komplexität und weitere Code-Qualitäts-Kennzahlen — liefert Signale dafür, welche Stellen im Code als nächstes dran sind.
- Rector — Automatisiertes Umschreiben von PHP-Code: Sprachversion-Upgrades, toten Code entfernen, Typabdeckung erhöhen, Code-Qualität verbessern. Setzt auf PHPStan oder Psalm auf.
- Roave Backward Compatibility Check — Vergleicht den Code mit dem letzten Release und schlägt bei einem Bruch fehl — für Projekte mit SemVer-Versprechen, bevor eine Restrukturierung beginnt.
- Infection — Mutation Testing, auf Anfrage: baut kleine Fehler in den Code ein und prüft, ob die Tests sie fangen.
- Secret Detection — Ein CI-Gate gegen versehentlich eingecheckte Zugangsdaten/Tokens/Secrets, auf Anfrage — werkzeugunabhängig; die Git-Historie scannt Housekeeping ohnehin nach Secrets.
- Semgrep — Statische Codeanalyse mit vorgefertigten Regeln gegen die OWASP-Top-10-Sicherheitsrisiken (z. B. Injection, Fehlkonfiguration), auf Anfrage.
- Twig-CS-Fixer — Code-Style für Twig-Templates, sobald ein PHP-Projekt Twig nutzt.
- TwigStan — Statische Analyse für Twig-Templates, aufbauend auf PHPStan.
Alle Tools mit ihren Rollen und der Reihenfolge, in der sie kommen: Tooling-Übersicht.