Merge pull request 'fix: Erweitere /script-Skill mit besserer Fehlerbehandlung und Workflow-Klarheit' (#10) from fix/script-skill-improvements into main
This commit was merged in pull request #10.
This commit is contained in:
+83
-15
@@ -1,11 +1,14 @@
|
||||
---
|
||||
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.
|
||||
description: Bash-Script-Lifecycle nach Best Practices — Aufgabenklärung → Scope-Einschätzung → Schnell- oder Vollpfad → shellcheck → PR → Merge. Aktivieren für jede Bash-Script-Aufgabe: neues Script, Feature, Bugfix, Refactoring. Nicht verwenden für andere Shells (sh/zsh/fish), Python-/Node-Scripts oder einfache Einzeiler/Aliase.
|
||||
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.**
|
||||
**Nicht-verhandelbare Mindeststandards — gelten für beide Pfade:**
|
||||
- Feature-Branch
|
||||
- `shellcheck` (alle Befunde beheben)
|
||||
- PR erstellen, Approval abwarten, mergen
|
||||
|
||||
## Vorab: Repository-Check
|
||||
|
||||
@@ -13,15 +16,83 @@ Führe den Bash-Script-Lifecycle vollständig durch. **Warte nach jeder Phase au
|
||||
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:
|
||||
Scheitert der Befehl: **Abbruch**. Der Skill arbeitet ausschließlich innerhalb eines Repos. Meldung an den User:
|
||||
|
||||
> "Kein Git-Repository gefunden. Starte `/script` erst nach `git init` oder aus einem bestehenden Repo."
|
||||
|
||||
## Phase 1: Planung (Opus)
|
||||
---
|
||||
|
||||
## Phase 0: Aufgabenklärung + Scope-Einschätzung
|
||||
|
||||
### 0a: Aufgabe klären
|
||||
|
||||
Lies das betroffene Script (falls vorhanden) und den Request. Stelle offene Fragen, falls nötig — aber nur solche, die den Lösungsweg beeinflussen:
|
||||
|
||||
- **Bei Bugfixes:** Was ist das erwartete Verhalten? Was passiert stattdessen? Wie lässt sich der Fehler reproduzieren?
|
||||
- **Bei neuen Features:** Was soll das Script leisten, was es heute nicht kann? Gibt es Randbedingungen (Umgebung, Eingaben, Abhängigkeiten)?
|
||||
- **Bei neuen Scripts:** Welches Problem wird gelöst? Wer ruft das Script auf und in welchem Kontext?
|
||||
|
||||
Wenn der Request eindeutig genug ist, diese Fragen überspringen.
|
||||
|
||||
Warte auf Antwort des Users, bevor du mit 0b fortfährst.
|
||||
|
||||
### 0b: Scope einschätzen
|
||||
|
||||
Entscheide anhand dieser Heuristiken:
|
||||
|
||||
**Schnellpfad** wenn alle Punkte zutreffen:
|
||||
- Kein neues CLI-Interface (kein neues Flag, kein neuer Subcommand, keine neue Abhängigkeit)
|
||||
- Änderung betrifft nur internen Ablauf (Bugfix, Ausgabe, Logik)
|
||||
- Geschätzter Diff: < 20 Zeilen
|
||||
|
||||
**Vollpfad** wenn mindestens eines zutrifft:
|
||||
- Neues Script
|
||||
- Neues Flag, Subcommand oder externe Abhängigkeit
|
||||
- Strukturelle Änderung (Error-Handling, Trap, Exit-Codes, Logging-Schema)
|
||||
- Geschätzter Diff: ≥ 20 Zeilen
|
||||
|
||||
Präsentiere dem User in einem Satz: Pfad + Begründung. Warte auf Bestätigung oder Korrektur.
|
||||
|
||||
---
|
||||
|
||||
## Schnellpfad
|
||||
|
||||
### S1: Branch + Implementierung
|
||||
|
||||
```bash
|
||||
git checkout -b fix/script-<name> # oder feat/ je nach Typ
|
||||
```
|
||||
|
||||
Änderungen direkt implementieren. Bash-Leitplanken einhalten:
|
||||
- Quoting: `"$var"`, Arrays als `"${array[@]}"`
|
||||
- Keine neuen Magic Numbers ohne benannte Konstante
|
||||
- `set -euo pipefail` muss gesetzt bleiben
|
||||
|
||||
### S2: shellcheck (Pflicht)
|
||||
|
||||
```bash
|
||||
shellcheck <script>
|
||||
```
|
||||
|
||||
Alle Befunde beheben. Falls nicht installiert: User informieren (`sudo apt install shellcheck`) und in `bootstrap.sh` aufnehmen.
|
||||
|
||||
### S3: Test-Empfehlungen
|
||||
|
||||
Gib dem User konkrete Kommandos zum Verifizieren der Änderung. Warte auf Rückmeldung.
|
||||
|
||||
### S4: Abschluss via /ship
|
||||
|
||||
Rufe `/ship` auf (Commit → Push → PR → Merge → Cleanup).
|
||||
|
||||
---
|
||||
|
||||
## Vollpfad
|
||||
|
||||
### V1: 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:
|
||||
Wenn das Script auf spezifische Tools/Libraries aufsetzt (z.B. `jq`, `gh`, `yq`), Dokumentation via Context-7 abrufen — nur wenn inhaltlich nützlich:
|
||||
|
||||
```
|
||||
mcp__plugin_context7_context7__resolve-library-id
|
||||
@@ -41,9 +112,9 @@ Plan-Inhalt:
|
||||
|
||||
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.
|
||||
Präsentiere den Plan dem User. Warte auf Bestätigung bevor V2 startet.
|
||||
|
||||
## Phase 2: Implementierung (Sonnet)
|
||||
### V2: Implementierung (Sonnet)
|
||||
|
||||
Wechsle das Modell: `/model claude-sonnet-4-6`.
|
||||
|
||||
@@ -53,24 +124,22 @@ Feature-Branch anlegen:
|
||||
git checkout -b feat/script-<name>
|
||||
```
|
||||
|
||||
Bash-spezifische Leitplanken (globale CLAUDE.md deckt den Rest ab):
|
||||
Bash-spezifische Leitplanken:
|
||||
|
||||
- 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):**
|
||||
### V3: shellcheck (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.
|
||||
Alle Befunde beheben. Falls nicht installiert: User informieren (`sudo apt install shellcheck`) und in `bootstrap.sh` aufnehmen.
|
||||
|
||||
**Test-Empfehlungen:** Gib dem User konkrete Kommandos, mit denen er die neue Funktionalität prüft:
|
||||
### V4: Test-Empfehlungen
|
||||
|
||||
```
|
||||
# Hilfe
|
||||
@@ -88,12 +157,11 @@ Alle Befunde beheben. Falls `shellcheck` nicht installiert ist: User informieren
|
||||
|
||||
Warte auf Rückmeldung des Users. Bei Problemen: Fehler beheben, Tests erneut empfehlen.
|
||||
|
||||
## Phase 4: Abschluss via /ship
|
||||
### V5: Abschluss via /ship
|
||||
|
||||
Rufe `/ship` auf (Commit → Push → PR → Merge → Cleanup).
|
||||
|
||||
Abschlussmeldung:
|
||||
|
||||
- PR-URL
|
||||
- Script-Pfad
|
||||
- Kurze Zusammenfassung der implementierten Funktionen
|
||||
|
||||
Reference in New Issue
Block a user