Optimaler Entwicklungs-Workflow eingerichtet

- workflow/: Schnellreferenz, Modell-Strategie, Story-Lifecycle-Doku
- skills/: /go, /plan-review, /story als globale Skills
- hooks/: auto-format.sh (PostToolUse), verify-on-stop.sh (Stop)
- agents/: plan-reviewer (Opus 4.7) für unabhängigen Plan-Review
- Symlinks in ~/.claude/skills/ und ~/.claude/agents/
- settings.json um Hooks-Sektion erweitert

Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
2026-04-19 10:38:30 +02:00
co-authored by Claude Sonnet 4.6
parent d804417757
commit a07c436a7d
10 changed files with 595 additions and 0 deletions
+122
View File
@@ -0,0 +1,122 @@
# Story-Lifecycle
## Übersicht
```
Research → Plan → Review → Implement → Test → Security → PR
```
Kurzbefehl für alles: `/story`
---
## Phase 1: Research
Ziel: Verstehen was gebaut werden soll und was bereits existiert.
```
# Subagenten für parallele Exploration starten
Agent(Explore): Bestehende Implementierungen finden
Agent(Explore): Test-Patterns analysieren
```
Checkliste:
- [ ] Ähnliche bestehende Funktionen gefunden?
- [ ] Abhängige Modelle/Services identifiziert?
- [ ] Test-Setup verstanden?
- [ ] CLAUDE.md des Projekts gelesen?
---
## Phase 2: Planung
```
/model opus # Für beste Planqualität
EnterPlanMode
```
Checkliste:
- [ ] Context-7 für alle beteiligten Frameworks konsultiert?
- [ ] Akzeptanzkriterien definiert?
- [ ] Test-Typen festgelegt (Unit / Integration / E2E)?
- [ ] Migrations-Bedarf (Alembic) geprüft?
- [ ] Security-relevante Pfade markiert?
---
## Phase 3: Plan-Review
```
/plan-review # Startet Opus-basierten plan-reviewer-Agent
```
Der Agent prüft:
- Vollständigkeit der Akzeptanzkriterien
- Fehlende Test-Abdeckung
- Security-Risiken
- Abhängigkeiten zu anderen Features
- Migrations-Korrektheit
Erst nach ✅ des Reviews: Implementierung starten.
---
## Phase 4: Implementierung
```
/model sonnet # Zurück auf Sonnet
ExitPlanMode
```
Regeln:
- Feature-Branch (niemals direkt auf `main`)
- Commits mind. stündlich
- Kleine, fokussierte Commits
- Subagenten für isolierte Teilaufgaben nutzen
---
## Phase 5: Test + Simplify + PR
```
/go
```
Führt aus:
1. `test-runner`-Agent (Haiku): Tests + Coverage
2. `code-simplifier`-Agent: Code-Review + Refactoring
3. PR-Erstellung via Gitea-API
---
## Phase 6: Security-Audit
Wird automatisch nach jeder Story durch CLAUDE.md-Regel ausgelöst,
oder manuell:
```
# security-audit-Agent starten (Opus)
Agent(security-audit): Neuen Code auf Sicherheitslücken prüfen
```
---
## Phase 7: PR-Review & Merge
- Akzeptanzkriterien einzeln als Checkboxen im PR
- Review-Feedback als separater Commit (nicht amenden)
- Squash-Merge auf main
---
## Kontext-Strategie pro Phase
| Phase | Kontext-Empfehlung |
|---|---|
| Research | Subagenten (Explore) — schützt Haupt-Kontext |
| Planung | Haupt-Kontext, Opus |
| Review | Subagent (plan-reviewer) |
| Implementierung | Haupt-Kontext, bei > 200k: /compact |
| Test | Subagent (test-runner) |
| Security | Subagent (security-audit) |
| PR | Subagent oder Haiku direkt |