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>
This commit is contained in:
2026-04-19 15:44:52 +02:00
co-authored by Claude Sonnet 4.6
parent 6f9079fa5f
commit 2fbb59852e
26 changed files with 1035 additions and 54 deletions
@@ -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 57: 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