From cff954961783a216db85793c3baa58bb5e7e13ee Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Martin=20Tr=C3=B6ger?= Date: Mon, 8 Jun 2026 07:30:16 +0200 Subject: [PATCH] feat: Clean-Code-Kommentarregel in Implementierungsphasen verankern MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Explizite No-Comment-Regel in /story Phase 4, /implement Phase 4 und /script V1+V2, damit Sonnet bei der Implementierung keine überflüssigen Kommentare generiert. Co-Authored-By: Claude Opus 4.6 --- skills/implement/SKILL.md | 1 + skills/script/SKILL.md | 3 ++- skills/story/references/phase-4-implementierung.md | 1 + 3 files changed, 4 insertions(+), 1 deletion(-) diff --git a/skills/implement/SKILL.md b/skills/implement/SKILL.md index 37f825e..9a49cc1 100644 --- a/skills/implement/SKILL.md +++ b/skills/implement/SKILL.md @@ -61,6 +61,7 @@ Implementiere die im Plan beschriebene Phase Schritt für Schritt: - Nach jedem logischen Abschnitt committen (mindestens alle 30 Minuten) - CLAUDE.md-Konventionen einhalten: Ruff, Type Hints, async, Pydantic-Schemas, Logging statt print - Keine generischen `try/except`, kein toter Code +- Keine Kommentare — Code muss selbsterklärend sein. Nur kommentieren wenn das WARUM nicht aus dem Code hervorgeht - Alembic-Migration: `alembic revision --autogenerate -m ""` falls nötig Bei unerwarteten Problemen: User informieren, konkreten Lösungsvorschlag präsentieren, nicht stumm abweichen. diff --git a/skills/script/SKILL.md b/skills/script/SKILL.md index 51b1cee..7c546b1 100644 --- a/skills/script/SKILL.md +++ b/skills/script/SKILL.md @@ -116,7 +116,7 @@ Plan-Inhalt: - **Error-Handling:** Cleanup-Strategie (`trap`), definierte Exit-Codes (0 Erfolg, 1 Fehler, 2 Usage, weitere dokumentiert) - **Konsolenausgabe:** Eine Zeile pro Hauptschritt (` Schritt ... ok (Details)`). Keine Farben außer Gelb (Warnungen) und Rot (Fehler). Keine Querlinien, Tabellen oder Raw-Ausgabe. Ergebnis in die Hauptzeile, nicht als separater Block. "Erfolgreich" nur wenn tatsächlich etwas passiert ist — keine irreführenden Meldungen - **Output-Beispiel:** Exakte Zeile-für-Zeile-Ausgabe für den typischen Ablauf, so wie der User sie sehen soll -- **Code-Skelett:** Hauptfunktion als Ablauf von Funktionsaufrufen, Hilfsfunktionen als Signatur mit Kommentar. Sonnet füllt die Funktionskörper +- **Code-Skelett:** Hauptfunktion als Ablauf von Funktionsaufrufen, Hilfsfunktionen als Signatur mit kurzem Einzeiler nur wenn das WARUM nicht offensichtlich ist. Sonnet füllt die Funktionskörper - **Dry-Run:** Welche Aktionen werden durch Log-Ausgabe ersetzt - **User-Einbindung:** Rückfragen bei irreversiblen Operationen (`read -p`), `--yes` für nicht-interaktive Ausführung - **Explizite Verbote:** Bekannte Pitfalls, Redundanzen und Stilfehler benennen, die Sonnet vermeiden muss @@ -143,6 +143,7 @@ Bash-spezifische Leitplanken: - Quoting konsequent: `"$var"`, Arrays als `"${array[@]}"` - `main()`-Funktion am Dateiende, aufgerufen mit `main "$@"` - Script ausführbar machen: `chmod +x ` +- Keine Kommentare — Code muss selbsterklärend sein. Nur kommentieren wenn das WARUM nicht aus dem Code hervorgeht ### V3: shellcheck (Pflicht) diff --git a/skills/story/references/phase-4-implementierung.md b/skills/story/references/phase-4-implementierung.md index 629b8cd..c6468e3 100644 --- a/skills/story/references/phase-4-implementierung.md +++ b/skills/story/references/phase-4-implementierung.md @@ -10,6 +10,7 @@ Implementierung nach Plan durchführen: - Nach jedem logischen Abschnitt committen (mind. nach jeder abgeschlossenen Komponente) - CLAUDE.md-Konventionen einhalten: Ruff, Type Hints, async, Pydantic-Schemas - Keine generischen `try/except`, kein toter Code, Logging statt print +- Keine Kommentare — Code muss selbsterklärend sein. Nur kommentieren wenn das WARUM nicht aus dem Code hervorgeht - Alembic-Migration erstellen falls nötig: `alembic revision --autogenerate -m "..."` Bei unerwarteten Problemen: User informieren und Lösungsvorschlag präsentieren, nicht stumm abweichen.