claude-workflow/skills/script/SKILL.md

description, model

description

model

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.

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

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:

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

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