feat: Erweitere Skill-Beschreibungen mit präziseren Nutzungsrichtlinien

- Verfeinere Description-Felder aller Skills für besseres Triggering - Neue skill-creator@claude-plugins-official Permission - /story mit neuer Reference-Struktur (phase-spezifische Detail-Dateien) - /go, /plan-review, /ship, /workflow-review: klarere Abgrenzungen - Vereinfachung im Vergleich zu vorigen Versionen Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2026-04-19 15:44:52 +02:00
parent 6f9079fa5f
commit 2fbb59852e
26 changed files with 1035 additions and 54 deletions
@@ -1,5 +1,5 @@
 ---
-description: Führt nach einer Implementierung Tests aus, vereinfacht den Code und erstellt einen PR in Gitea. Aktivieren wenn eine Feature-Implementierung abgeschlossen ist und ein PR erstellt werden soll.
+description: Kombinierter Test+Simplify+PR-Workflow nach einer Implementierung — startet den test-runner, vereinfacht geänderten Code und erstellt einen PR in Gitea, alles in einem Schritt. Aktivieren sobald eine Implementierung abgeschlossen ist und Tests + PR als nächstes anstehen. Nicht verwenden wenn nur Tests, nur ein PR ohne vorherige Tests, oder ein vollständiges Merge+Cleanup gewünscht ist (dafür /ship nutzen).
 context: fork
 model: claude-haiku-4-5-20251001
 ---
@@ -1,5 +1,5 @@
 ---
-description: Startet einen unabhängigen Opus-Agenten der den aktuellen Plan auf Vollständigkeit, Risiken und fehlende Tests prüft. Aktivieren nach der Planungsphase, bevor die Implementierung beginnt.
+description: Startet einen unabhängigen Opus-Agenten, der einen bereits erstellten Implementierungsplan auf Vollständigkeit, Risiken, fehlende Tests und Alembic-Migrationen prüft — bevor die Implementierung beginnt. Aktivieren wenn ein Plan bereits steht und ein zweiter unabhängiger Blick darauf geworfen werden soll. Nicht verwenden um einen Plan zu erstellen, zu erweitern, oder um Code, PRs oder Schemata zu reviewen.
 context: fork
 model: claude-opus-4-6
 ---
@@ -1,5 +1,5 @@
 ---
-description: Finales Commit → Push → PR erstellen → Mergen → Aufräumen. Explizit vom User aufzurufen wenn ein Feature abgeschlossen ist.
+description: Finaler Abschluss eines Features: Commit → Push → PR erstellen → PR mergen → Branch löschen → main pullen. Aktivieren wenn alles fertig ist und der Branch vollständig in main überführt werden soll. Unterschied zu /go: /ship merged den PR und räumt auf. Nicht aufrufen wenn der User nur committen, nur pushen, nur einen PR erstellen oder die Tests noch laufen lassen möchte.
 context: fork
 model: claude-haiku-4-5-20251001
 ---
@@ -1,57 +1,18 @@
 ---
-description: Orchestriert den vollständigen Story-Lifecycle von Planung bis PR. Aktivieren wenn eine neue User Story oder ein neues Feature implementiert werden soll.
+description: Vollständiger Lifecycle für neue Features und User Stories: Research → Planung → Plan-Review → Implementierung → Tests → PR → Security-Audit. Aktivieren wenn ein neues Feature oder eine neue Story vollständig umgesetzt werden soll — von der ersten Analyse bis zum fertigen PR. Nicht verwenden für Bug-Fixes, Refactorings, einzelne Optimierungen oder wenn nur ein Teilschritt (nur planen, nur implementieren, nur PR) gewünscht ist.
 model: claude-opus-4-6
 ---

 # /story — Voller Story-Lifecycle

-Führe den Story-Lifecycle vollständig durch. Warte nach jeder Phase auf Bestätigung.
+Führe den Story-Lifecycle vollständig durch. **Warte nach jeder Phase auf Bestätigung.**

-## Phase 1: Research
+Lies die Detail-Datei jeweils erst wenn du die Phase erreichst — nicht vorher.

-Starte bis zu 3 Explore-Subagenten parallel für:
- Bestehende Implementierungen im relevanten Bereich finden
- Test-Patterns und -Setup analysieren
- Abhängige Services/Modelle identifizieren
-
-Hole Context-7-Dokumentation für alle beteiligten Frameworks:
-```
-mcp__plugin_context7_context7__resolve-library-id
-mcp__plugin_context7_context7__query-docs
-```
-
-## Phase 2: Planung
-
-Aktiviere Plan-Modus.
-Erstelle einen detaillierten Plan mit Akzeptanzkriterien.
-
-## Phase 3: Plan-Review
-
-Rufe `/plan-review` auf.
-Warte auf das Ergebnis.
-Bei ❌-Punkten: Plan anpassen, dann erneut reviewen.
-Bei ✅ Freigabe: weiter.
-
-## Phase 4: Implementierung
-
-Feature-Branch erstellen:
-```
-!git checkout -b feat/<story-name>
-```
-Implementierung durchführen. Commits stündlich.
-
-## Phase 5: Tests und PR
-
-Rufe `/go` auf (Test + Simplify + PR).
-Warte auf PR-URL.
-
-## Phase 6: Security-Audit
-
-Starte den `security-audit`-Agenten.
-Warte auf das Ergebnis. Bei kritischen Befunden: Beheben, dann erneut prüfen.
-
-## Phase 7: Abschluss
-
-Rufe `/ship` auf (Commit → Push → PR → Merge → Cleanup).
-
-Ausgabe: PR-URL + kurze Zusammenfassung was implementiert wurde.
+| Phase | Detail-Datei |
+|---|---|
+| 1 · Research | `references/phase-1-research.md` |
+| 2 · Planung | `references/phase-2-planung.md` |
+| 3 · Plan-Review | `references/phase-3-plan-review.md` |
+| 4 · Implementierung | `references/phase-4-implementierung.md` |
+| 5–7 · Tests, Security, Abschluss | `references/phase-5-7-abschluss.md` |
@@ -0,0 +1,18 @@
+# Phase 1: Research
+
+Starte bis zu 3 Explore-Subagenten parallel für:
+- Bestehende Implementierungen im relevanten Bereich finden
+- Test-Patterns und -Setup analysieren
+- Abhängige Services/Modelle identifizieren
+
+Hole Context-7-Dokumentation für alle beteiligten Frameworks:
+```
+mcp__plugin_context7_context7__resolve-library-id
+mcp__plugin_context7_context7__query-docs
+```
+
+Warte auf alle Subagenten, fasse die Ergebnisse zusammen und präsentiere dem User:
+- Relevante Dateien und Module
+- Vorhandene Test-Patterns
+- Abhängigkeiten die beachtet werden müssen
+- Offene Fragen vor der Planung
@@ -0,0 +1,15 @@
+# Phase 2: Planung
+
+Aktiviere den Plan-Modus (`EnterPlanMode`).
+
+Erstelle einen detaillierten Implementierungsplan mit:
+- Akzeptanzkriterien (als Checkboxen)
+- Betroffene Dateien und Module
+- Reihenfolge der Implementierungsschritte
+- Benötigte Alembic-Migrationen (falls Schema-Änderungen)
+- Testplan: Unit-, Integration- und Security-Tests
+- Risiken und Abhängigkeiten
+
+Speichere den Plan nach `/home/martin/.claude/plans/<story-name>.md`.
+
+Präsentiere den Plan dem User. Warte auf Bestätigung bevor Phase 3 beginnt.
@@ -0,0 +1,10 @@
+# Phase 3: Plan-Review
+
+Rufe `/plan-review` auf — ein unabhängiger Opus-Agent prüft den Plan.
+
+Warte auf das Ergebnis:
+- Bei **❌ Fehlt**: Plan anpassen, dann erneut `/plan-review` aufrufen
+- Bei **⚠️ Risiko**: Abwägen — entweder Plan anpassen oder Risiko bewusst akzeptieren und dokumentieren
+- Bei **✅ Freigabe**: Weiter mit Phase 4
+
+Erst nach Freigabe mit der Implementierung beginnen.
@@ -0,0 +1,15 @@
+# Phase 4: Implementierung
+
+Feature-Branch erstellen:
+```bash
+git checkout -b feat/<story-name>
+```
+
+Implementierung nach Plan durchführen:
+- Schritte aus dem Plan der Reihe nach abarbeiten
+- Nach jedem logischen Abschnitt committen (mind. stündlich)
+- CLAUDE.md-Konventionen einhalten: Ruff, Type Hints, async, Pydantic-Schemas
+- Keine generischen `try/except`, kein toter Code, Logging statt print
+- Alembic-Migration erstellen falls nötig: `alembic revision --autogenerate -m "..."`
+
+Bei unerwarteten Problemen: User informieren und Lösungsvorschlag präsentieren, nicht stumm abweichen.
@@ -0,0 +1,21 @@
+# Phase 5–7: Tests, Security-Audit und Abschluss
+
+## Phase 5: Tests und PR
+
+Rufe `/go` auf (test-runner → code-simplifier → PR in Gitea).
+Warte auf die PR-URL.
+
+## Phase 6: Security-Audit
+
+Starte den `security-audit`-Agenten für alle geänderten Dateien.
+Warte auf das Ergebnis.
+- Bei **kritischen Befunden**: Beheben, dann erneut prüfen
+- Bei **Warnungen**: Mit User abstimmen
+
+## Phase 7: Abschluss
+
+Rufe `/ship` auf (Commit → Push → PR → Merge → Cleanup).
+
+Abschlussmeldung:
+- PR-URL
+- Kurze Zusammenfassung: was implementiert wurde, welche Dateien geändert wurden
@@ -1,5 +1,5 @@
 ---
-description: Reviewt Skills, Agenten und Konfigurationsdateien dieses Repos auf Vollständigkeit, Konsistenz und Best Practices. Erstellt einen umsetzbaren Plan für Verbesserungen.
+description: Prüft alle Skills, Agenten, Hooks und Konfigurationsdateien dieses Repos auf Konsistenz, Widersprüche, veraltete Modelle und Abweichungen von Best Practices — vergleicht mit externer Referenz und erstellt einen priorisierten Umsetzungsplan. Aktivieren wenn der Workflow selbst (Skills, Agenten, Konfiguration) geprüft oder verbessert werden soll. Nicht verwenden für Code-Reviews, PR-Reviews, Security-Audits oder Fragen zu einzelnen Skill-Details.
 context: fork
 model: claude-opus-4-6
 ---