---
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