improve-codebase-architecture (mattpocock/skills)

Bewertung

Codex CLI 0.166 (gpt-6-astra, niedriges Reasoning) auf einem dedizierten Windows-Test-PC, einem frischen temporären Projekt und temporären HOME/TMPDIR/Caches pro Lauf; Skill installiert (Treatment) oder nicht vorhanden (Kontrolle) oder nicht vorhanden mit der Kernanforderung des Skills in einem an den Prompt angehängten Satz (One-Liner-Gruppe); 2 Läufe pro Gruppe und Aufgabe; Netzwerk aus; Schreiben nach /tmp blockiert. Die Prompts nennen den Skill nie (außer der unten genannten Formulierung). Drei Aufgaben an einem kleinen Python-Shop-Backend mit eingebauter Reibung (flache Validatoren/Geld-Helfer, ein Inventory-Service, der nur an sein Repo weiterleitet, ein einzelner Payment-Adapter, in Cart und Orders duplizierte Rabattlogik, Tests, die nur Helfer abdecken): ein Architektur-Review des gesamten Codebase als report.html, dasselbe begrenzt auf Payment und Inventory, und „warum ist place_order mühsam zu testen“ als Chat-Antwort. Die Prompts der Skill-Gruppe beginnen mit $improve-codebase-architecture (explizite Aufrufung); Kontrolle und Ein-Satz-Prompts nennen ihn nicht.

Drei-Arm-Vergleich

Gemessen mit Codex CLI über 18 Läufe, bewertet durch regelbasierte Prüfungen ohne LLM-Richter. Gesamt 23.0 / 30, Urteil Situativ.

Urteil: Situativ (23.0 / 30). Quelle: mattpocock/skills, skills/engineering/improve-codebase-architecture, skills/engineering/codebase-design, gepinnt auf Commit 4ae2317. Installation: npx skills@latest add mattpocock/skills --skill improve-codebase-architecture. Lizenz: MIT (Repo-LICENSE).

Was es ist

Der Skill improve-codebase-architecture aus mattpocock/skills. Er sucht „Vertiefungsmöglichkeiten“ in einer Codebasis: flache Module, deren Schnittstelle so komplex ist wie ihre Implementierung, Durchreich-Schichten, hypothetische Single-Adapter-Nahtstellen, duplizierte Logik, Verhalten, das nur über Helfer getestet wird. Er schreibt einen HTML-Bericht mit Vorher/Nachher pro Kandidat und einer Hauptempfehlung. Für das Vokabular stützt er sich auf den Schwester-Skill codebase-design. Nur Markdown, keine Skripte.

So haben wir getestet

Codex CLI 0.166 (gpt-6-astra, low reasoning) auf einem dedizierten Windows-Test-PC, pro Lauf ein frisches temporäres Projekt und temporäre HOME/TMPDIR/Caches, Skill installiert (Mit-Skill-Gruppe) oder nicht vorhanden (Kontrollgruppe) oder nicht vorhanden, aber mit der Kernanforderung des Skills als einem an den Prompt angehängten Satz (Ein-Satz-Gruppe), 2 Läufe pro Gruppe und Aufgabe, Netzwerk aus, Schreibzugriffe auf /tmp blockiert. Die Prompts nennen den Skill nie (außer der unten genannten Formulierung).

Drei Aufgaben an einem kleinen Python-Shop-Backend mit eingebauter Reibung (flache Validatoren/Geld-Helfer, ein Inventory-Service, der nur an sein Repo weiterleitet, ein einzelner Payment-Adapter, Rabattlogik, dupliziert in Cart und Orders, Tests, die nur Helfer abdecken): ein Architektur-Review der gesamten Codebasis als report.html, dasselbe beschränkt auf Payment und Inventory, und „warum ist place_order schwer zu testen“ als Chat-Antwort. Die Prompts der Skill-Gruppe beginnen mit $improve-codebase-architecture (expliziter Aufruf); Kontrolle und Ein-Satz-Prompts nennen ihn nicht.

1. Architektur-Scan des gesamten Repos — Prüfe dieses kleine Shop-Backend auf Architekturverbesserungen: Wo würde eine Umstrukturierung den Code leichter änderbar und leichter testbar machen? Schreibe deine Erkenntnisse als eigenständigen HTML-Bericht namens report.html in diesen Ordner (öffne keinen Browser und starte keinen Se…
2. Nur Payments und Inventory — Betrachte nur die Payment- und Inventory-Teile dieses Backends und sage mir, welche Umstrukturierungen sich lohnen würden. Schreibe deine Erkenntnisse als eigenständigen HTML-Bericht namens report.html in diesen Ordner (öffne keinen Browser und starte keinen Server) und ändere keine Co…
3. Warum ist place_order schwer zu testen? — Es fühlt sich mühsam an, für place_order in diesem Backend einen anständigen Test zu schreiben. Warum, und welche Umstrukturierung würde das beheben? Ändere keine Dateien; antworte in deiner letzten Nachricht.

Die Bewertung erfolgt programmatisch (versteckte Tests / Trefferquote bei eingebauten Problemen / Constraint-Prüfungen / Rendern+OCR, wo relevant), 0–5 pro Lauf. Kein LLM-Richter hat eine Punktzahl entschieden.

Ergebnisse

Der Ein-Satz-Prompt für die dritte Gruppe: "Suche nach Vertiefungsmöglichkeiten: flache Module, deren Schnittstelle so komplex ist wie ihre Implementierung (wende den Löschtest an: würde das Löschen Komplexität bündeln oder nur verschieben?), Durchreich-Schichten, Single-Adapter-Nahtstellen, die nur hypothetisch sind, über Module hinweg duplizierte Logik und Logik, die nur über Helfer statt über die echte Schnittstelle getestet wird; stelle jeden Kandidaten mit Dateien, Problem, Lösung, Nutzen und einem Vorher/Nachher dar und nenne eine Hauptempfehlung."

Durchschnitt: 3.2 ohne vs. 4.12 mit Skill (Delta +0.92). Token pro Lauf: 115k vs. 208k (1.80x); Zeit 112s vs. 135s. Ein-Satz-Gruppe: 3.91 (Zuwachs des Skills gegenüber dem Ein-Satz-Prompt: +0.2; Zuwachs des Ein-Satz-Prompts gegenüber ohne Skill: +0.72); Token des Ein-Satz-Prompts 120k pro Lauf, der Skill kostet also 1.73x so viel wie der Ein-Satz-Prompt.

Was dabei herauskam

• Beim Review der gesamten Codebasis zeigt der Skill seinen Wert: Skill und Ein-Satz-Version fanden 6/6 eingebaute Punkte mit Architekturvokabular, Vorher/Nachher und einer Hauptempfehlung in allen vier Läufen; reines Codex fand in einem Lauf 2/6 und im anderen 5 von 6 Prüfungen, und keiner der beiden Läufe hatte eine klare „Hauptempfehlung“.
• Das fokussierte Review (nur Payment und Inventory) ist für alle schwierig: Die beste Gruppe fand im Schnitt einen der zwei eingebauten Punkte. Kontrolle 2/4 Prüfungen, Ein-Satz 3/4, Skill 3/4. Der Skill war nicht besser als der Satz.
• Bei „warum ist place_order schwer zu testen“ fanden alle drei Gruppen die eingebauten Ursachen (versteckter PaymentAdapter, geteilter Stock auf Modulebene, duplizierte Rabattlogik, Tests, die bei Helfern aufhören). Die Antwort des Skills nutzte dessen Vokabular („interface“, „locality“); die der Kontrolle war in einfachen Worten ebenso richtig.
• Durchschnitt 3.20 Kontrolle, 3.91 Ein-Satz, 4.12 Skill. Der Skill legt 0.21 gegenüber dem Satz bei 1.7x Token (208k vs. 120k pro Lauf) drauf, weil er auch den Schwester-Skill liest; die Ein-Satz-Gruppe kostet so viel wie die Kontrolle (115k).
• Da der Skill zwei Skill-Ordner installiert, legten die Mit-Skill-Läufe zusätzliche Dateien im .agents-Ordner des Projekts an; sie wurden von der Prüfung „keine Codedateien geändert“ ausgenommen (ein erster Durchlauf ließ sie fälschlich durchfallen, und ein Windows-spezifischer Fehler in der Prüfung wurde vor den endgültigen Zahlen behoben).

Bewertung nach Dimensionen

Grenzen dieses Tests

• Ein kleines Python-Fixture mit Lehrbuchproblemen; ob der Bericht in einem großen echten Repo nützlich ist, wird nicht gemessen.
• Berichtsqualität, Fehlalarme und das HTML-Styling (es lädt Tailwind und Mermaid von CDNs, wenn es im Browser geöffnet wird) wurden nicht bewertet; das Subagenten-Verhalten, das der Skill beschreibt, wurde nicht ausgeführt.
• Der Ein-Satz-Prompt wiederholt die Checkliste des Skills selbst und ist damit eine Obergrenze für einen kurzen Prompt.
• n = 2 pro Gruppe und Aufgabe: Unterschiede unter etwa 1 Punkt sind Rauschen.
• Regelbasierte Bewertung misst nur, was die Prüfungen sehen können; Geschmack oder ob ein Ergebnis das bestmögliche ist, lässt sich so nicht beurteilen.

Sicherheit

Siehe security.md. Scan: 0 CRITICAL / 0 HIGH / 0 MEDIUM. Urteil: sicher ausführbar (Sandbox ohne Netzwerk). Ein sauberer Scan beweist nicht, dass ein Skill sicher ist.

Fazit

Verglichen mit gar nichts verbessert der Skill ein Review der gesamten Codebasis deutlich, vor allem indem er Berichtsstruktur und Vokabular erzwingt, und kostet 1.8x Token. Ein einzelner Satz, der dieselben Gerüche auflistet, holt den Großteil des Gewinns; die Installation lohnt sich vor allem, wenn Sie jedes Mal das identische Berichtsformat wollen.