CLAUDE.md

@@ -24,6 +24,7 @@ Das Bootstrap-Skript installiert alle Tools, erstellt alle Symlinks und richtet
 | `jq` | Statusline-Parsing | `apt install jq` |
 | `ruff` | Python-Formatter (Hook) | `pipx install ruff` |
 | `eslint` | JS/TS/Vue-Formatter (Hook) | Projektabhängig |
+| `shellcheck` | Bash-Linter (Hook + /script) | `apt install shellcheck` |
 | `secret-tool` | Gitea-Token abrufen | `apt install libsecret-tools` |
 | `gh` | GitHub CLI | `apt install gh` |
 | `go` + `gitea-mcp` | Gitea-MCP-Binary | `go install gitea.com/gitea/gitea-mcp@latest` |
@@ -95,6 +96,7 @@ Kurzbefehl für den gesamten Ablauf: `/story`
 | `/go` | `skills/go/SKILL.md` | test-runner → code-simplifier → Gitea-PR |
 | `/ship` | `skills/ship/SKILL.md` | Commit → Push → PR → Merge → Cleanup (finales Kommando) |
 | `/plan-review` | `skills/plan-review/SKILL.md` | Startet plan-reviewer-Agent (Opus, fork) |
+| `/script` | `skills/script/SKILL.md` | Bash-Script-Lifecycle: Planung (Opus) → Implementierung (Sonnet) → Shellcheck + Test-Empfehlungen → /ship |
 | `/story` | `skills/story/SKILL.md` | Voller Lifecycle von Research bis PR |
 | `/workflow-review` | `skills/workflow-review/SKILL.md` | Opus reviewt alle Skills/Konfig → Umsetzungsplan für Sonnet |
 
@@ -111,7 +113,7 @@ Kurzbefehl für den gesamten Ablauf: `/story`
 
 | Event | Trigger | Skript | Aktion |
 |---|---|---|---|
-| `PostToolUse` | Edit / Write | `hooks/auto-format.sh` | `ruff` (Python) oder `eslint --fix` (JS/TS/Vue) |
+| `PostToolUse` | Edit / Write | `hooks/auto-format.sh` | `ruff` (Python), `eslint --fix` (JS/TS/Vue) oder `shellcheck` (Bash) |
 | `Stop` | Session-Ende | `hooks/verify-on-stop.sh` | Uncommittete Änderungen anzeigen |
 
 `auto-format.sh` liest den Dateipfad aus `$CLAUDE_TOOL_INPUT_FILE_PATH` und erkennt den Typ anhand der Dateiendung.

bootstrap.sh

@@ -66,6 +66,15 @@ else
     echo "✓ ruff installiert"
 fi
 
+# --- shellcheck (Bash-Lint-Hook + /script) ---
+if command -v shellcheck &>/dev/null; then
+    echo "✓ shellcheck $(shellcheck --version | awk '/^version:/ {print $2}')"
+else
+    echo "  shellcheck fehlt – installiere via apt..."
+    sudo apt-get install -y shellcheck
+    echo "✓ shellcheck installiert"
+fi
+
 # --- gitea-mcp Binary ---
 if [[ -x ~/go/bin/gitea-mcp ]]; then
     echo "✓ gitea-mcp vorhanden"

hooks/auto-format.sh

@@ -28,6 +28,11 @@ case "$EXT" in
       fi
     fi
     ;;
+  sh)
+    if command -v shellcheck &>/dev/null; then
+      shellcheck "$FILE" || true
+    fi
+    ;;
 esac
 
 exit 0

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.