martin
f66af81da2
- 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
100 lines
3.6 KiB
Markdown
100 lines
3.6 KiB
Markdown
---
|
|
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
|