feat: Ergänze /script-Skill für Bash-Script-Lifecycle

- Neuer Skill /script mit Repo-Check, Opus-Planung, Sonnet-Implementierung, Shellcheck-Pflicht, Test-Empfehlungen, /ship
- auto-format.sh lintet .sh-Dateien via shellcheck
- bootstrap.sh installiert shellcheck automatisch
- /story speichert Pläne jetzt unter <repo-root>/plans/ und bricht ohne Git-Repo ab
- CLAUDE.md-Tabellen für Skills, Hooks und Tools ergänzt

skills/script/SKILL.md

@@ -0,0 +1,99 @@
+---
+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.
+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.**
+
+## Vorab: Repository-Check
+
+```bash
+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:
+
+> "Kein Git-Repository gefunden. Starte `/script` erst nach `git init` oder aus einem bestehenden Repo."
+
+## Phase 1: 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:
+
+```
+mcp__plugin_context7_context7__resolve-library-id
+mcp__plugin_context7_context7__query-docs
+```
+
+Plan-Inhalt:
+
+- **Zweck:** Was das Script löst, ein bis zwei Sätze
+- **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 ]]`)
+- **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
+- **Test-Szenarien:** Konkrete Aufrufe für die spätere Verifikation
+
+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.
+
+## Phase 2: Implementierung (Sonnet)
+
+Wechsle das Modell: `/model claude-sonnet-4-6`.
+
+Feature-Branch anlegen:
+
+```bash
+git checkout -b feat/script-<name>
+```
+
+Bash-spezifische Leitplanken (globale CLAUDE.md deckt den Rest ab):
+
+- 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):**
+
+```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.
+
+**Test-Empfehlungen:** Gib dem User konkrete Kommandos, mit denen er die neue Funktionalität prüft:
+
+```
+# Hilfe
+<script> --help
+
+# Happy Path
+<script> <typische Argumente>
+
+# Dry-Run (falls implementiert)
+<script> --dry-run <typische Argumente>
+
+# Fehlerfall — erwartet Exit-Code ≠ 0 und klare Meldung
+<script> <ungültiger Aufruf>
+```
+
+Warte auf Rückmeldung des Users. Bei Problemen: Fehler beheben, Tests erneut empfehlen.
+
+## Phase 4: Abschluss via /ship
+
+Rufe `/ship` auf (Commit → Push → PR → Merge → Cleanup).
+
+Abschlussmeldung:
+
+- PR-URL
+- Script-Pfad
+- Kurze Zusammenfassung der implementierten Funktionen

skills/story/SKILL.md

@@ -7,6 +7,16 @@ model: claude-opus-4-6
 
 Führe den Story-Lifecycle vollständig durch. **Warte nach jeder Phase auf Bestätigung.**
 
+## Vorab: Repository-Check
+
+```bash
+git rev-parse --show-toplevel
+```
+
+Scheitert der Befehl: **Abbruch**. `/story` läuft nur innerhalb eines Git-Repositories, damit Plan und Implementierung gemeinsam versioniert werden. Meldung an den User:
+
+> "Kein Git-Repository gefunden. Starte `/story` erst nach `git init` oder aus einem bestehenden Repo."
+
 Lies die Detail-Datei jeweils erst wenn du die Phase erreichst — nicht vorher.
 
 | Phase | Detail-Datei |

skills/story/references/phase-2-planung.md

@@ -10,6 +10,6 @@ Erstelle einen detaillierten Implementierungsplan mit:
 - Testplan: Unit-, Integration- und Security-Tests
 - Risiken und Abhängigkeiten
 
-Speichere den Plan nach `/home/martin/.claude/plans/<story-name>.md`.
+Speichere den Plan unter `<repo-root>/plans/<story-name>.md` (Verzeichnis bei Bedarf anlegen). `<repo-root>` ist `git rev-parse --show-toplevel`.
 
 Präsentiere den Plan dem User. Warte auf Bestätigung bevor Phase 3 beginnt.