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:
Claude Sonnet 4.6
@@ -0,0 +1,81 @@
|
||||
# Claude Code Workflow — Schnellreferenz
|
||||
|
||||
## Story-Lifecycle
|
||||
|
||||
| Phase | Befehl / Agent | Modell |
|
||||
|---|---|---|
|
||||
| 1. Planung | `EnterPlanMode` | Sonnet |
|
||||
| 2. Plan-Review | `/plan-review` | **Opus 4.7** |
|
||||
| 3. Implementierung | Claude direkt | **Sonnet 4.6** |
|
||||
| 4. Test + Simplify + PR | `/go` | Haiku / Sonnet |
|
||||
| 5. Security-Audit | `security-audit`-Agent | **Opus 4.7** |
|
||||
|
||||
Kurzform für den kompletten Lifecycle: `/story`
|
||||
|
||||
---
|
||||
|
||||
## Modell-Matrix
|
||||
|
||||
| Aufgabe | Modell | Warum |
|
||||
|---|---|---|
|
||||
| Planung, Review | Opus 4.7 | Qualität entscheidend |
|
||||
| Implementierung | Sonnet 4.6 | Bestes Preis-Leistungs-Verhältnis |
|
||||
| Tests, Lint, Format | Haiku 4.5 | Schnell + günstig |
|
||||
| Security-Audit | Opus 4.7 | Sicherheit hat Priorität |
|
||||
| PR-Erstellung | Haiku 4.5 | Mechanische Aufgabe |
|
||||
|
||||
---
|
||||
|
||||
## Skills (Slash-Commands)
|
||||
|
||||
| Befehl | Beschreibung | Datei |
|
||||
|---|---|---|
|
||||
| `/go` | Tests + Simplify + PR in einem Schritt | `skills/go.md` |
|
||||
| `/plan-review` | Opus reviewt aktuellen Plan | `skills/plan-review.md` |
|
||||
| `/story` | Voller Story-Lifecycle | `skills/story.md` |
|
||||
|
||||
---
|
||||
|
||||
## Aktive Hooks
|
||||
|
||||
| Event | Aktion | Skript |
|
||||
|---|---|---|
|
||||
| `PostToolUse` (Edit/Write) | Auto-Format (ruff / eslint) | `hooks/auto-format.sh` |
|
||||
| `Stop` | Offene Tasks prüfen | `hooks/verify-on-stop.sh` |
|
||||
|
||||
---
|
||||
|
||||
## Agenten
|
||||
|
||||
| Agent | Modell | Aufgabe |
|
||||
|---|---|---|
|
||||
| `test-runner` | Sonnet | Tests ausführen, Coverage prüfen |
|
||||
| `security-audit` | Sonnet | OWASP-Analyse, Security-Tests |
|
||||
| `plan-reviewer` | **Opus 4.7** | Plan auf Lücken/Risiken prüfen |
|
||||
| `n8n-architect` | Sonnet | n8n-Workflow-Design |
|
||||
|
||||
---
|
||||
|
||||
## MCP-Server
|
||||
|
||||
| Server | Wann nutzen |
|
||||
|---|---|
|
||||
| `context7` | Bei jeder Bibliothek/Framework-Frage |
|
||||
| `n8n-local` | n8n-Workflow-Inspektion |
|
||||
|
||||
---
|
||||
|
||||
## Kontext-Management
|
||||
|
||||
- **< 200k Tokens**: Normal weiterarbeiten
|
||||
- **200–350k Tokens**: `/compact` mit konkretem Hinweis ausführen
|
||||
- **> 350k Tokens**: Neue Session, Subagenten für Isolation nutzen
|
||||
- Nie auf automatisches Compacting verlassen — manuell mit Hints ist besser
|
||||
|
||||
---
|
||||
|
||||
## Weitere Details
|
||||
|
||||
- Modell-Strategie: `models.md`
|
||||
- Story-Lifecycle: `story-lifecycle.md`
|
||||
- Installation/Setup: `../SETUP.md`
|
||||
@@ -0,0 +1,81 @@
|
||||
# Modell-Strategie
|
||||
|
||||
## Grundprinzip
|
||||
|
||||
Teures Modell nur dort, wo Qualität den Unterschied macht.
|
||||
Günstiges Modell für mechanische, wiederholbare Aufgaben.
|
||||
|
||||
## Modell-Übersicht (Stand April 2026)
|
||||
|
||||
| Modell | ID | Stärke | Relative Kosten |
|
||||
|---|---|---|---|
|
||||
| Opus 4.7 | `claude-opus-4-7` | Höchste Reasoning-Qualität, adaptives Thinking | ●●●●● |
|
||||
| Sonnet 4.6 | `claude-sonnet-4-6` | Ausgewogen, sehr gute Codequalität | ●●●○○ |
|
||||
| Haiku 4.5 | `claude-haiku-4-5-20251001` | Schnell, kostengünstig | ●○○○○ |
|
||||
|
||||
## Zuordnung nach Phase
|
||||
|
||||
### Planung & Review → Opus 4.7
|
||||
Warum: Ein schlechter Plan kostet mehr Zeit als das teurere Modell.
|
||||
```
|
||||
/model opus
|
||||
```
|
||||
Einsatz:
|
||||
- `EnterPlanMode`
|
||||
- `/plan-review`
|
||||
- Architektur-Entscheidungen
|
||||
- Risiko-Analysen
|
||||
|
||||
### Implementierung → Sonnet 4.6
|
||||
Warum: Ausreichende Qualität bei deutlich niedrigeren Kosten als Opus.
|
||||
```
|
||||
/model sonnet (Standard / Default)
|
||||
```
|
||||
Einsatz:
|
||||
- Feature-Implementierung
|
||||
- Refactoring
|
||||
- Bug-Fixes
|
||||
- Frontend-Entwicklung
|
||||
|
||||
### Tests / Lint / Format → Haiku 4.5
|
||||
Warum: Mechanische Aufgaben brauchen kein Reasoning.
|
||||
```
|
||||
/model haiku
|
||||
```
|
||||
Einsatz:
|
||||
- `test-runner`-Agent
|
||||
- Auto-Format-Hook
|
||||
- PR-Beschreibung generieren
|
||||
- Einfache Datei-Operationen
|
||||
|
||||
### Security-Audit → Opus 4.7
|
||||
Warum: Sicherheitslücken zu übersehen kostet mehr als das Modell.
|
||||
```
|
||||
/model opus
|
||||
```
|
||||
Einsatz:
|
||||
- `security-audit`-Agent
|
||||
- Permission-Scan im PreToolUse-Hook
|
||||
|
||||
## Kontext-Degradation
|
||||
|
||||
Bei langen Sessions sinkt die Qualität aller Modelle:
|
||||
- **Sonnet**: Degradation ab ~300k Tokens
|
||||
- **Opus**: Robuster, aber ab ~400k Tokens trotzdem besser compacten
|
||||
|
||||
Strategie:
|
||||
1. `/compact "aktueller Stand: [Zusammenfassung]"` bei 200–350k
|
||||
2. Neue Session + Subagenten bei > 350k
|
||||
3. Subagenten schützen Haupt-Kontext generell (immer bevorzugen für isolierte Aufgaben)
|
||||
|
||||
## Fast Mode
|
||||
|
||||
`/fast` aktiviert Opus 4.7 mit schnellerer Ausgabe (kein Downgrade).
|
||||
Sinnvoll bei: Langen Implementierungen mit Opus, wo Wartezeit stört.
|
||||
|
||||
## Kosten-Faustregeln
|
||||
|
||||
- 10 Story-Punkte Implementierung: ~80% Sonnet, ~20% Opus
|
||||
- Security-Audit pro Story: immer Opus (< 5% der Gesamtkosten, schützt vor Regressionen)
|
||||
- Test-Runner: immer Haiku (< 2% der Gesamtkosten)
|
||||
- Faustregel: Opus nur für Entscheidungen, Sonnet für Umsetzung, Haiku für Verifikation
|
||||
@@ -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 |
|
||||
Reference in New Issue
Block a user