Merge pull request 'fix: Erweitere /script-Skill mit besserer Fehlerbehandlung und Workflow-Klarheit' (#10) from fix/script-skill-improvements into main

skills/script/SKILL.md

@@ -1,11 +1,14 @@
 ---
-description: Bash-Script-Lifecycle nach Best Practices — Planung (Opus) → Implementierung (Sonnet) → Linting + Test-Empfehlungen → /ship. Aktivieren wenn ein neues Bash-Script erstellt oder ein bestehendes Bash-Script substanziell erweitert werden soll, auch wenn der User nur "schreib mir ein Script" oder "automatisier das per Bash" sagt. Nicht verwenden für andere Shells (sh/zsh/fish), Python-/Node-Scripts, einfache Einzeiler/Aliase, reine Refactorings oder Bug-Fixes an bestehendem Verhalten.
+description: Bash-Script-Lifecycle nach Best Practices — Aufgabenklärung → Scope-Einschätzung → Schnell- oder Vollpfad → shellcheck → PR → Merge. Aktivieren für jede Bash-Script-Aufgabe: neues Script, Feature, Bugfix, Refactoring. Nicht verwenden für andere Shells (sh/zsh/fish), Python-/Node-Scripts oder einfache Einzeiler/Aliase.
 model: claude-opus-4-6
 ---
 
 # /script — Bash-Script-Lifecycle
 
-Führe den Bash-Script-Lifecycle vollständig durch. **Warte nach jeder Phase auf Bestätigung.**
+**Nicht-verhandelbare Mindeststandards — gelten für beide Pfade:**
+- Feature-Branch
+- `shellcheck` (alle Befunde beheben)
+- PR erstellen, Approval abwarten, mergen
 
 ## Vorab: Repository-Check
 
@@ -13,15 +16,83 @@ Führe den Bash-Script-Lifecycle vollständig durch. **Warte nach jeder Phase au
 git rev-parse --show-toplevel
 ```
 
-Scheitert der Befehl: **Abbruch**. Der Skill arbeitet ausschließlich innerhalb eines Repos, damit Plan und Script gemeinsam versioniert werden. Meldung an den User:
+Scheitert der Befehl: **Abbruch**. Der Skill arbeitet ausschließlich innerhalb eines Repos. Meldung an den User:
 
 > "Kein Git-Repository gefunden. Starte `/script` erst nach `git init` oder aus einem bestehenden Repo."
 
-## Phase 1: Planung (Opus)
+---
+
+## Phase 0: Aufgabenklärung + Scope-Einschätzung
+
+### 0a: Aufgabe klären
+
+Lies das betroffene Script (falls vorhanden) und den Request. Stelle offene Fragen, falls nötig — aber nur solche, die den Lösungsweg beeinflussen:
+
+- **Bei Bugfixes:** Was ist das erwartete Verhalten? Was passiert stattdessen? Wie lässt sich der Fehler reproduzieren?
+- **Bei neuen Features:** Was soll das Script leisten, was es heute nicht kann? Gibt es Randbedingungen (Umgebung, Eingaben, Abhängigkeiten)?
+- **Bei neuen Scripts:** Welches Problem wird gelöst? Wer ruft das Script auf und in welchem Kontext?
+
+Wenn der Request eindeutig genug ist, diese Fragen überspringen.
+
+Warte auf Antwort des Users, bevor du mit 0b fortfährst.
+
+### 0b: Scope einschätzen
+
+Entscheide anhand dieser Heuristiken:
+
+**Schnellpfad** wenn alle Punkte zutreffen:
+- Kein neues CLI-Interface (kein neues Flag, kein neuer Subcommand, keine neue Abhängigkeit)
+- Änderung betrifft nur internen Ablauf (Bugfix, Ausgabe, Logik)
+- Geschätzter Diff: < 20 Zeilen
+
+**Vollpfad** wenn mindestens eines zutrifft:
+- Neues Script
+- Neues Flag, Subcommand oder externe Abhängigkeit
+- Strukturelle Änderung (Error-Handling, Trap, Exit-Codes, Logging-Schema)
+- Geschätzter Diff: ≥ 20 Zeilen
+
+Präsentiere dem User in einem Satz: Pfad + Begründung. Warte auf Bestätigung oder Korrektur.
+
+---
+
+## Schnellpfad
+
+### S1: Branch + Implementierung
+
+```bash
+git checkout -b fix/script-<name>   # oder feat/ je nach Typ
+```
+
+Änderungen direkt implementieren. Bash-Leitplanken einhalten:
+- Quoting: `"$var"`, Arrays als `"${array[@]}"`
+- Keine neuen Magic Numbers ohne benannte Konstante
+- `set -euo pipefail` muss gesetzt bleiben
+
+### S2: shellcheck (Pflicht)
+
+```bash
+shellcheck <script>
+```
+
+Alle Befunde beheben. Falls nicht installiert: User informieren (`sudo apt install shellcheck`) und in `bootstrap.sh` aufnehmen.
+
+### S3: Test-Empfehlungen
+
+Gib dem User konkrete Kommandos zum Verifizieren der Änderung. Warte auf Rückmeldung.
+
+### S4: Abschluss via /ship
+
+Rufe `/ship` auf (Commit → Push → PR → Merge → Cleanup).
+
+---
+
+## Vollpfad
+
+### V1: Planung (Opus)
 
 Aktiviere den Plan-Modus (`EnterPlanMode`).
 
-Wenn das Script auf spezifische Tools/Libraries aufsetzt (z.B. `jq`, `gh`, `yq`, Framework-CLIs), Dokumentation via Context-7 abrufen — nur wenn inhaltlich nützlich:
+Wenn das Script auf spezifische Tools/Libraries aufsetzt (z.B. `jq`, `gh`, `yq`), Dokumentation via Context-7 abrufen — nur wenn inhaltlich nützlich:
 
 ```
 mcp__plugin_context7_context7__resolve-library-id
@@ -41,9 +112,9 @@ Plan-Inhalt:
 
 Speichere den Plan unter `<repo-root>/plans/script-<name>.md` (Verzeichnis bei Bedarf anlegen).
 
-Präsentiere den Plan dem User. Warte auf Bestätigung bevor Phase 2 startet.
+Präsentiere den Plan dem User. Warte auf Bestätigung bevor V2 startet.
 
-## Phase 2: Implementierung (Sonnet)
+### V2: Implementierung (Sonnet)
 
 Wechsle das Modell: `/model claude-sonnet-4-6`.
 
@@ -53,24 +124,22 @@ Feature-Branch anlegen:
 git checkout -b feat/script-<name>
 ```
 
-Bash-spezifische Leitplanken (globale CLAUDE.md deckt den Rest ab):
+Bash-spezifische Leitplanken:
 
 - Shebang `#!/usr/bin/env bash`, direkt danach `set -euo pipefail` und `IFS=$'\n\t'`
 - Quoting konsequent: `"$var"`, Arrays als `"${array[@]}"`
 - `main()`-Funktion am Dateiende, aufgerufen mit `main "$@"`
 - Script ausführbar machen: `chmod +x <pfad>`
 
-## Phase 3: Linting + Test-Empfehlungen
-
-**Linting (Pflicht):**
+### V3: shellcheck (Pflicht)
 
 ```bash
 shellcheck <script>
 ```
 
-Alle Befunde beheben. Falls `shellcheck` nicht installiert ist: User informieren (`sudo apt install shellcheck`) und Tool in `bootstrap.sh` aufnehmen, bevor die Phase weitergeht.
+Alle Befunde beheben. Falls nicht installiert: User informieren (`sudo apt install shellcheck`) und in `bootstrap.sh` aufnehmen.
 
-**Test-Empfehlungen:** Gib dem User konkrete Kommandos, mit denen er die neue Funktionalität prüft:
+### V4: Test-Empfehlungen
 
 ```
 # Hilfe
@@ -88,12 +157,11 @@ Alle Befunde beheben. Falls `shellcheck` nicht installiert ist: User informieren
 
 Warte auf Rückmeldung des Users. Bei Problemen: Fehler beheben, Tests erneut empfehlen.
 
-## Phase 4: Abschluss via /ship
+### V5: Abschluss via /ship
 
 Rufe `/ship` auf (Commit → Push → PR → Merge → Cleanup).
 
 Abschlussmeldung:
-
 - PR-URL
 - Script-Pfad
 - Kurze Zusammenfassung der implementierten Funktionen