chore: Workflow-Aktualisierungen — Bootstrap, Skill-Defs, Gitea-Wrapper

Aktualisiert Bootstrap-Logik, Modellangaben in Workflow-Defs und Gitea-MCP-Wrapper-Robustheit. Konsistenzverbesserungen bei Skill-Dokumentation und Hook-Definitionen.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

skills/script/SKILL.md

@@ -76,11 +76,20 @@ shellcheck <script>
 
 Alle Befunde beheben. Falls nicht installiert: User informieren (`sudo apt install shellcheck`) und in `bootstrap.sh` aufnehmen.
 
-### S3: Test-Empfehlungen
+### S3: Review-Checkliste
+
+Auch bei kleinen Änderungen prüfen:
+
+- Vertauschte oder irreführende Variablennamen
+- Unmögliche Shell-Operationen (z.B. `tar -rf` auf `.gz`)
+- Gleiche Daten mehrfach abfragen statt Variable wiederverwenden
+- Ausgaben die Erfolg suggerieren obwohl nichts passiert ist
+
+### S4: Test-Empfehlungen
 
 Gib dem User konkrete Kommandos zum Verifizieren der Änderung. Warte auf Rückmeldung.
 
-### S4: Abschluss via /ship
+### S5: Abschluss via /ship
 
 Rufe `/ship` auf (Commit → Push → PR → Merge → Cleanup).
 
@@ -105,9 +114,13 @@ Plan-Inhalt:
 - **CLI-Interface:** Positionsargumente und Flags (`--help`, `--dry-run` Pflicht bei destruktiven Aktionen, `--verbose`, ggf. `--yes`)
 - **Abhängigkeiten:** Externe CLI-Tools, werden am Script-Start per `command -v` geprüft
 - **Error-Handling:** Cleanup-Strategie (`trap`), definierte Exit-Codes (0 Erfolg, 1 Fehler, 2 Usage, weitere dokumentiert)
-- **Log-/Konsolenausgabe:** `log_info`/`log_warn`/`log_error`, Fehler nach `stderr`, TTY-Farben (`[[ -t 1 ]]`)
+- **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
 - **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
+- **Randfälle:** Für jeden Hauptschritt: "Was kann hier schiefgehen oder sinnlos sein?"
 - **Test-Szenarien:** Konkrete Aufrufe für die spätere Verifikation
 
 Speichere den Plan unter `<repo-root>/plans/script-<name>.md` (Verzeichnis bei Bedarf anlegen).
@@ -139,7 +152,21 @@ shellcheck <script>
 
 Alle Befunde beheben. Falls nicht installiert: User informieren (`sudo apt install shellcheck`) und in `bootstrap.sh` aufnehmen.
 
-### V4: Test-Empfehlungen
+### V4: Review-Checkliste
+
+Prüfe Sonnets Implementierung auf typische Fehler:
+
+- Vertauschte oder irreführende Variablennamen
+- Unmögliche Shell-Operationen (z.B. `tar -rf` auf `.gz`)
+- Syntax die `bash -n` nicht findet aber zur Laufzeit crasht
+- Gleiche Daten mehrfach abfragen statt Variable wiederverwenden
+- Variablen die geschrieben aber nie gelesen werden
+- Funktionen die nur einmal aufgerufen werden und keinen Mehrwert bieten
+- Ausgaben die Erfolg suggerieren obwohl nichts passiert ist
+
+Alle Befunde beheben, dann erneut `shellcheck` laufen lassen.
+
+### V5: Test-Empfehlungen
 
 ```
 # Hilfe
@@ -157,7 +184,7 @@ Alle Befunde beheben. Falls nicht installiert: User informieren (`sudo apt insta
 
 Warte auf Rückmeldung des Users. Bei Problemen: Fehler beheben, Tests erneut empfehlen.
 
-### V5: Abschluss via /ship
+### V6: Abschluss via /ship
 
 Rufe `/ship` auf (Commit → Push → PR → Merge → Cleanup).