2026-04-19 15:13:28 +02:00
18 changed files with 205 additions and 527 deletions
@@ -0,0 +1,107 @@
 # Plan: Workflow-Vereinfachung — Single Source of Truth
 **Ziel:** `CLAUDE.md` ist die einzige normative Quelle. Alle redundanten Dokumentations-Dateien werden entfernt. Einzigartiger Inhalt aus `SETUP.md` wird vorher in `CLAUDE.md` integriert.
 ---
 ## Phase 1 — CLAUDE.md erweitern (vor dem Löschen)
 Folgende Inhalte aus `SETUP.md` in `CLAUDE.md` einbauen, die dort noch fehlen:
 - **Einrichtung (2 Schritte):**
  ```
  git clone https://gitea.troeger-net.org/martin/claude-workflow.git /mnt/projekte/claude-workflow
  /mnt/projekte/claude-workflow/bootstrap.sh
  ```
 - **Voraussetzungen-Tabelle** (tatsächliche aus `bootstrap.sh`, nicht die veraltete aus `SETUP.md`):
  - `jq` — Statusline-Parsing (`apt install jq`)
  - `ruff` — Python-Formatter (`pip install ruff` / `pipx`)
  - `eslint` — JS/TS/Vue-Formatter (projektabhängig)
  - `secret-tool` — Token abrufen (`apt install libsecret-tools`)
  - `gh` — GitHub CLI (aus bootstrap.sh)
  - `go` + `gitea-mcp` — Gitea-MCP-Binary (aus bootstrap.sh)
 - **Gitea-Token einrichten:**
  ```
  secret-tool store --label="Gitea claude-code Token" user claude-code token gitea
  ```
 - **Sync-Workflow** (Pull/Push zwischen Rechnern) — falls gewünscht
 Empfohlener Platz in `CLAUDE.md`: neuer Abschnitt `## Einrichtung` direkt nach dem bestehenden `## Zweck`-Block.
 ---
 ## Phase 2 — Dateien löschen
 ```bash
 # Gesamten workflow/-Ordner entfernen
 rm -rf /mnt/projekte/claude-workflow/workflow/
 # Root-README entfernen (nur 1 Zeile "# Claude Workflow")
 rm /mnt/projekte/claude-workflow/README.md
 # SETUP.md entfernen (Inhalt wurde in CLAUDE.md integriert)
 rm /mnt/projekte/claude-workflow/SETUP.md
 ```
 ---
 ## Phase 3 — CLAUDE.md-Verweise bereinigen
 Nach dem Löschen folgende Stellen in `/mnt/projekte/claude-workflow/CLAUDE.md` anpassen:
 - **Zeile "## Struktur"** (`workflow/` im Verzeichnisbaum): Eintrag entfernen
 - **Zeile "workflow/ ← Referenzdokumentation (täglich lesen)"**: entfernen
 - **Zeile "workflow/README.md ← Schnellreferenz"**: entfernen
 - **Zeile "workflow/models.md ← Modell-Strategie + Kostenmatrix"**: entfernen
 - **Zeile "workflow/story-lifecycle.md ← Story-Phasen im Detail"**: entfernen
 - **Abschnitt "Workflow-Weiterentwicklung"** (Zeile mit `https://github.com/shanraisshan/...`): WebFetch-Anweisung bleibt, aber Verweis auf `workflow/`-Vergleich entfernen
 - **`SETUP.md` → `bootstrap.sh`** im Aktivierungs-Block: bereits korrekt, nur Verweis auf "siehe `SETUP.md`" entfernen
 ---
 ## Phase 4 — Weitere bekannte Inkonsistenzen beheben (aus workflow-review)
 ### Priorität 1 (kritisch)
 - [ ] **`CLAUDE.md`, Abschnitt "Aktivierung (nach Neuinstallation)"**: Veralteten Symlink-Block komplett ersetzen durch:
  ```
  Nach System-Neuinstallation `bootstrap.sh` ausführen (erstellt alle Symlinks automatisch).
  ```
 - [ ] **`skills/go/SKILL.md`, Schritt 3**: Gitea-API via `secret-tool`+curl ersetzen durch `mcp__gitea__pull_request_write`. Den Token-Hinweis in `CLAUDE.md` Zeile 107 auf "Token für Gitea-MCP" umformulieren.
 - [ ] **`skills/story/SKILL.md`, Phase 4**: Branch-Präfix `feature/` → `feat/` (konsistent mit `/ship`).
 - [ ] **`skills/story/SKILL.md`, Phase 5**: Nach `/go` fehlen Security-Audit und `/ship`. Ergänzen:
  - Phase 6: `security-audit`-Agent starten
  - Phase 7: `/ship` aufrufen
 - [ ] **`skills/go/SKILL.md`, Schritt 2**: Verweis auf `code-simplifier`-Agent präzisieren → "`simplify`-Skill (Plugin) aufrufen".
 - [ ] **`agents/test-runner.md`**: Frontmatter `model:` auf `claude-haiku-4-5-20251001` setzen.
 - [ ] **`agents/security-audit.md`**: Frontmatter `model:` auf `claude-opus-4-7` setzen.
 - [ ] **`agents/n8n-architect.md`**: Veraltete Frontmatter-Keys (`mcpServers`, `tools: [fs, terminal, git, editor]`, `skills:`, `memory:`, `permissionMode:`) ersetzen durch Standard-Schema: `tools: Bash, Read, Write, Edit, Glob, Grep`.
 - [ ] **`dotfiles/settings.json`, `permissions.allow`**: `Bash(curl:*)` entfernen (widerspricht globaler Regel gegen curl-Workarounds).
 - [ ] **`skills/workflow-review/SKILL.md`, Schritt 1**: `find`-Befehl ersetzen durch Glob-Tool-Anweisung (`**/*.md`).
 ### Priorität 2 (Konsistenz)
 - [ ] **`agents/plan-reviewer.md`, Schritt 1**: Pfad `/home/martin/.claude/plans/` → `.claude/plans/` des aktuellen Projekts (oder Kontext aus `EnterPlanMode`).
 - [ ] **`skills/go/SKILL.md`, Frontmatter**: `model: claude-haiku-4-5-20251001` setzen.
 - [ ] **`skills/story/SKILL.md`, Frontmatter**: `model: claude-opus-4-7` setzen; manuelle "/model opus"-Anweisung in Phase 2 entfernen.
 - [ ] **`skills/plan-review/SKILL.md`, Frontmatter**: `model: claude-opus-4-7` ergänzen (konsistent mit `workflow-review`-Skill).
 - [ ] **`hooks/auto-format.sh`, Zeile 26**: Vor `npx eslint` prüfen ob `node_modules/.bin/eslint` existiert, sonst überspringen.
 ---
 ## Abschluss
 Nach allen Änderungen: `/ship` aufrufen (Feature-Branch `feat/workflow-simplification`).
@@ -6,6 +6,49 @@ This file provides guidance to Claude Code (claude.ai/code) when working with co
 Dieses Repository enthält die globale Claude-Code-Workflow-Konfiguration für alle Projekte von Martin Tröger. Es definiert Skills, Agenten, Hooks und Dokumentation — kein ausführbarer Anwendungscode.
 ## Einrichtung
 ### Neuer Rechner (2 Schritte)
 ```bash
 git clone https://gitea.troeger-net.org/martin/claude-workflow.git /mnt/projekte/claude-workflow
 /mnt/projekte/claude-workflow/bootstrap.sh
 ```
 Das Bootstrap-Skript installiert alle Tools, erstellt alle Symlinks und richtet den Gitea-Token ein.
 ### Voraussetzungen
 | Tool | Zweck | Installieren |
 |---|---|---|
 | `jq` | Statusline-Parsing | `apt install jq` |
 | `ruff` | Python-Formatter (Hook) | `pipx install ruff` |
 | `eslint` | JS/TS/Vue-Formatter (Hook) | Projektabhängig |
 | `secret-tool` | Gitea-Token abrufen | `apt install libsecret-tools` |
 | `gh` | GitHub CLI | `apt install gh` |
 | `go` + `gitea-mcp` | Gitea-MCP-Binary | `go install gitea.com/gitea/gitea-mcp@latest` |
 ### Gitea-Token einrichten
 ```bash
 secret-tool store --label="Gitea claude-code Token" user claude-code token gitea
 ```
 ### Sync zwischen Rechnern
 **Pushen (Rechner 1):**
 ```bash
 cd /mnt/projekte/claude-workflow
 git add -p && git commit -m "..." && git push
 ```
 **Übernehmen (Rechner 2):**
 ```bash
 cd /mnt/projekte/claude-workflow && git pull
 ```
 Da alles über Symlinks verbunden ist, sind Änderungen sofort aktiv.
 ## Workflow-Weiterentwicklung
 Beim Aktualisieren dieses Workflows immer zuerst die externe Best-Practice-Referenz konsultieren und auf relevante Neuerungen prüfen:
@@ -17,30 +60,16 @@ Vorgehen: URL via `WebFetch` abrufen → mit aktuellem Workflow vergleichen →
 ## Struktur
 ```
 workflow/        ← Referenzdokumentation (täglich lesen)
  README.md      ← Schnellreferenz: Welcher Befehl für welche Phase
  models.md      ← Modell-Strategie + Kostenmatrix
  story-lifecycle.md ← Story-Phasen im Detail
 skills/          ← Slash-Commands (Symlinks nach ~/.claude/skills/)
 agents/          ← Agenten-Definitionen (Symlinks nach ~/.claude/agents/)
 hooks/           ← Shell-Hooks (durch settings.json registriert)
-SETUP.md         ← Einrichtung nach System-Neuinstallation
+dotfiles/        ← ~/.claude/CLAUDE.md, settings.json, statusline-command.sh
 bootstrap.sh     ← Einrichtungsskript
 ```
 ## Aktivierung (nach Neuinstallation)
-```bash
+Nach System-Neuinstallation `bootstrap.sh` ausführen (erstellt alle Symlinks automatisch).
 # Skills und Agent verlinken
 ln -sf /mnt/projekte/claude-workflow/skills/go.md ~/.claude/skills/go.md
 ln -sf /mnt/projekte/claude-workflow/skills/plan-review.md ~/.claude/skills/plan-review.md
 ln -sf /mnt/projekte/claude-workflow/skills/story.md ~/.claude/skills/story.md
 ln -sf /mnt/projekte/claude-workflow/agents/plan-reviewer.md ~/.claude/agents/plan-reviewer.md
 # Hook-Skripte ausführbar machen
 chmod +x /mnt/projekte/claude-workflow/hooks/*.sh
 ```
 Die `hooks`-Sektion in `~/.claude/settings.json` manuell eintragen (siehe `SETUP.md`).
 ## Story-Lifecycle
@@ -52,12 +81,12 @@ Kurzbefehl für den gesamten Ablauf: `/story`
 | Phase | Befehl | Modell |
 |---|---|---|
-| Planung | `EnterPlanMode` | Opus 4.7 |
+| Planung | `EnterPlanMode` | Opus 4.6 |
-| Plan-Review | `/plan-review` | Opus 4.7 (Subagent) |
+| Plan-Review | `/plan-review` | Opus 4.6 (Subagent) |
 | Implementierung | direkt | Sonnet 4.6 |
 | Test + Simplify + PR | `/go` | Haiku / Sonnet (Subagenten) |
 | Commit + PR + Merge | `/ship` | Sonnet (fork) |
-| Security-Audit | `security-audit`-Agent | Opus 4.7 |
+| Security-Audit | `security-audit`-Agent | Opus 4.6 |
 ## Skills
@@ -73,7 +102,7 @@ Kurzbefehl für den gesamten Ablauf: `/story`
 | Agent | Modell | Tools | Rolle |
 |---|---|---|---|
-| `plan-reviewer` | Opus 4.7 | Read, Glob, Grep | Prüft Pläne auf Vollständigkeit, Risiken, fehlende Tests |
+| `plan-reviewer` | Opus 4.6 | Read, Glob, Grep | Prüft Pläne auf Vollständigkeit, Risiken, fehlende Tests |
 | `test-runner` | Sonnet | alle | Tests ausführen, Coverage prüfen |
 | `security-audit` | Sonnet | alle | OWASP-Analyse, Security-Tests schreiben |
 | `n8n-architect` | Sonnet | alle | n8n-Workflow-Design und Refactoring |
@@ -89,11 +118,11 @@ Kurzbefehl für den gesamten Ablauf: `/story`
 ## Modell-Strategie
- **Opus 4.7**: Planung, Plan-Review, Security-Audit — überall wo Fehlentscheidungen teuer sind
+- **Opus 4.6**: Planung, Plan-Review, Security-Audit — überall wo Fehlentscheidungen teuer sind
 - **Sonnet 4.6**: Implementierung, Refactoring, Bug-Fixes (Standard)
 - **Haiku 4.5**: Tests, Lint, Format, PR-Beschreibung
-`/fast` aktiviert Opus 4.7 mit schnellerer Ausgabe — sinnvoll bei langen Implementierungen.
+`/fast` aktiviert Opus 4.6 mit schnellerer Ausgabe — sinnvoll bei langen Implementierungen.
 ## Kontext-Management
@@ -104,5 +133,5 @@ Kurzbefehl für den gesamten Ablauf: `/story`
 ## Gitea-Integration
 - Instanz: `https://gitea.troeger-net.org`
- Token für `/go`-Skill: `$(secret-tool lookup user claude-code token gitea)`
+- Token für Gitea-MCP: `$(secret-tool lookup user claude-code token gitea)`
 - MCP-Server `gitea` muss aktiv sein (Binary: `~/go/bin/gitea-mcp`)
@@ -1 +1,14 @@
 # Claude Workflow
 Globale Claude-Code-Konfiguration für alle Projekte von Martin Tröger.
 Enthält Skills (`/go`, `/ship`, `/story`, `/plan-review`, `/workflow-review`), Agenten (`plan-reviewer`, `test-runner`, `security-audit`, `n8n-architect`), Hooks und Dotfiles — kein ausführbarer Anwendungscode.
 ## Einrichtung
 ```bash
 git clone https://gitea.troeger-net.org/martin/claude-workflow.git /mnt/projekte/claude-workflow
 /mnt/projekte/claude-workflow/bootstrap.sh
 ```
 Weitere Details in `CLAUDE.md`.
@@ -1,57 +0,0 @@
 # Setup-Anleitung
 ## Einrichtung auf neuem Rechner (2 Schritte)
 ```bash
 git clone https://gitea.troeger-net.org/martin/claude-workflow.git /mnt/projekte/claude-workflow
 /mnt/projekte/claude-workflow/bootstrap.sh
 ```
 Das Bootstrap-Skript erstellt alle Symlinks und setzt die korrekten Berechtigungen.
 ## Voraussetzungen
 | Tool | Zweck | Installieren |
 |---|---|---|
 | `jq` | Statusline-Parsing | `apt install jq` |
 | `ruff` | Python-Formatter (Hook) | `pip install ruff` |
 | `eslint` | JS/TS/Vue-Formatter (Hook) | Projektabhängig |
 | `secret-tool` | Gitea-Token abrufen | `apt install libsecret-tools` |
 ### Gitea-Token einrichten
 ```bash
 secret-tool store --label="Gitea claude-code Token" user claude-code token gitea
 # Passwort: Gitea-Token eingeben
 ```
 ## Sync-Workflow
 **Änderungen pushen (Rechner 1):**
 ```bash
 cd /mnt/projekte/claude-workflow
 git add -p && git commit -m "..." && git push
 ```
 **Änderungen übernehmen (Rechner 2):**
 ```bash
 cd /mnt/projekte/claude-workflow && git pull
 ```
 Da alles über Symlinks verbunden ist, sind Änderungen sofort aktiv.
 ## Was das Repo enthält
 ```
 claude-workflow/
 ├── agents/          ← Alle Agents (plan-reviewer, test-runner, security-audit, n8n-architect)
 ├── dotfiles/        ← ~/.claude/CLAUDE.md, settings.json, statusline-command.sh
 ├── hooks/           ← auto-format.sh (PostToolUse), verify-on-stop.sh (Stop)
 ├── skills/          ← /go, /plan-review, /story
 ├── workflow/        ← Referenzdokumentation (models.md, story-lifecycle.md)
 └── bootstrap.sh     ← Einrichtungsskript
 ```
 ## Nach System-Neuinstallation
 Nur die zwei Befehle aus "Einrichtung auf neuem Rechner" ausführen.
@@ -2,20 +2,13 @@
 name: n8n-architect
 description: Architekt und Entwickler für n8n-Workflows inklusive Refactoring, Qualitätsrichtlinien und sicherer Nutzung des n8n-MCP-Servers.
 model: sonnet
 permissionMode: auto
 mcpServers:
  - n8n-local
 tools:
-  - fs
+  - Bash
-  - terminal
+  - Read
-  - git
+  - Write
-  - editor
+  - Edit
-maxTurns: 40
+  - Glob
-skills:
+  - Grep
  - "software-architecture"
  - "workflow-design"
  - "api-integration"
 memory: enabled
 ---
 Du bist ein erfahrener **Software-Architekt** und n8n-Experte. 
@@ -1,7 +1,7 @@
 ---
 name: plan-reviewer
 description: Unabhängiger Plan-Reviewer. Prüft Implementierungspläne auf Vollständigkeit, fehlende Tests, Security-Risiken und Migrations-Korrektheit. Wird durch /plan-review aktiviert.
-model: claude-opus-4-7
+model: claude-opus-4-6
 tools: Read, Glob, Grep
 ---
@@ -9,7 +9,7 @@ Du bist ein erfahrener Software-Architekt und Code-Reviewer. Deine Aufgabe ist e
 ## Dein Vorgehen
-1. Lies den aktuellen Plan (neueste Datei in `/home/martin/.claude/plans/`)
+1. Lies den aktuellen Plan (neueste Datei in `.claude/plans/` des aktuellen Projekts)
 2. Lies die CLAUDE.md des betroffenen Projekts
 3. Analysiere den Plan systematisch
@@ -1,7 +1,7 @@
 ---
 name: security-audit
 description: Prueft neuen oder geaenderten Code auf Sicherheitsluecken. Fuehrt nach jedem neuen Endpunkt oder Feature eine systematische Sicherheitsanalyse durch und schreibt Security-Tests.
-model: sonnet
+model: claude-opus-4-6
 tools:
  - Bash
  - Read
@@ -1,7 +1,7 @@
 ---
 name: test-runner
 description: Fuehrt Tests aus, prueft Coverage und meldet fehlende Tests. Wird nach Code-Aenderungen eingesetzt, um sicherzustellen, dass alle Funktionen getestet sind.
-model: sonnet
+model: claude-haiku-4-5-20251001
 tools:
  - Bash
  - Read
@@ -6,7 +6,6 @@
      "Bash(xargs:*)",
      "WebSearch",
      "Bash(npm install)",
      "Bash(curl:*)",
      "Bash(ls:*)",
      "Bash(python3:*)"
    ],
@@ -23,8 +23,8 @@ case "$EXT" in
  js|ts|vue|jsx|tsx)
    DIR=$(dirname "$FILE")
    if [[ -f "$DIR/package.json" ]] || [[ -f "$DIR/../package.json" ]]; then
-      if command -v npx &>/dev/null; then
+      if [[ -x "$DIR/node_modules/.bin/eslint" ]] || [[ -x "$DIR/../node_modules/.bin/eslint" ]]; then
-        npx --yes eslint --fix --quiet "$FILE" 2>/dev/null || true
+        npx eslint --fix --quiet "$FILE" 2>/dev/null || true
      fi
    fi
    ;;
@@ -1,6 +1,7 @@
 ---
 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.
 context: fork
 model: claude-haiku-4-5-20251001
 ---
 # /go — Test + Simplify + PR
@@ -14,7 +15,7 @@ Wenn Tests fehlschlagen: Abbruch, Fehlerbericht ausgeben.
 ## Schritt 2: Code vereinfachen
-Starte den `code-simplifier`-Agenten für alle in dieser Session geänderten Dateien.
+Rufe den `simplify`-Skill (Plugin) für alle in dieser Session geänderten Dateien auf.
 Ziel: Redundanzen entfernen, Lesbarkeit verbessern, keine neuen Features einführen.
 ## Schritt 3: PR erstellen
@@ -25,9 +26,8 @@ Ermittle den aktuellen Branch-Namen und die Commit-Zusammenfassung:
 !git branch --show-current
 ```
-Erstelle den PR via Gitea-API:
+Erstelle den PR via `mcp__gitea__pull_request_write`:
 - Gitea-Instanz: `https://gitea.troeger-net.org`
 - Token: `$(secret-tool lookup user claude-code token gitea)`
 - PR-Titel: Erster Commit-Titel des Branches
 - PR-Body: Alle Akzeptanzkriterien als Checkboxen + Verifikations-Hinweis
@@ -1,6 +1,7 @@
 ---
 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.
 context: fork
 model: claude-opus-4-6
 ---
 # /plan-review — Unabhängiger Plan-Review
@@ -1,5 +1,6 @@
 ---
 description: Orchestriert den vollständigen Story-Lifecycle von Planung bis PR. Aktivieren wenn eine neue User Story oder ein neues Feature implementiert werden soll.
 model: claude-opus-4-6
 ---
 # /story — Voller Story-Lifecycle
@@ -21,7 +22,6 @@ mcp__plugin_context7_context7__query-docs
 ## Phase 2: Planung
 Wechsle auf Opus: Sage dem Nutzer: "Wechsle für die Planung auf /model opus"
 Aktiviere Plan-Modus.
 Erstelle einen detaillierten Plan mit Akzeptanzkriterien.
@@ -34,16 +34,24 @@ Bei ✅ Freigabe: weiter.
 ## Phase 4: Implementierung
 Sage dem Nutzer: "Wechsle für die Implementierung auf /model sonnet"
 Feature-Branch erstellen:
 ```
-!git checkout -b feature/<story-name>
+!git checkout -b feat/<story-name>
 ```
 Implementierung durchführen. Commits stündlich.
-## Phase 5: Abschluss
+## 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.
@@ -1,7 +1,7 @@
 ---
 description: Reviewt Skills, Agenten und Konfigurationsdateien dieses Repos auf Vollständigkeit, Konsistenz und Best Practices. Erstellt einen umsetzbaren Plan für Verbesserungen.
 context: fork
-model: claude-opus-4-7
+model: claude-opus-4-6
 ---
 # /workflow-review — Review von Skills und Konfiguration
@@ -10,10 +10,8 @@ Reviewe die Workflow-Konfiguration dieses Repos. Falls ein Argument übergeben w
 ## Schritt 1: Dateien einlesen
-Lies alle Konfigurationsdateien im Repo:
+Lies alle Konfigurationsdateien im Repo mit dem Glob-Tool (`**/*.md`).
-```
+Schließe `.git/` aus.
 find . -name "*.md" -not -path "./.git/*"
 ```
 ## Schritt 2: Best-Practice-Referenz abrufen
@@ -26,7 +24,7 @@ Vergleiche die dort beschriebenen Patterns mit dem aktuellen Workflow.
 Prüfe auf:
- **Konsistenz**: Stimmen Modell-Angaben mit `workflow/models.md` überein?
+- **Konsistenz**: Stimmen Modell-Angaben mit den Frontmatter-Feldern der Skills/Agenten überein?
 - **Vollständigkeit**: Sind alle Schritte klar und ohne Rückfragen ausführbar?
 - **Widersprüche**: Widerspricht eine Anweisung einer anderen Datei?
 - **Fehlerbehandlung**: Gibt es klare Abbruchkriterien?
@@ -1,81 +0,0 @@
 # 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`
@@ -1,81 +0,0 @@
 # 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
@@ -1,129 +0,0 @@
 # Plan: Optimaler Entwicklungs-Workflow
 ## Kontext
 Ziel ist ein vollständig eingerichteter, kostenoptimierter Entwicklungsworkflow für Claude Code.
 Aktueller Stand: 3 Agenten (test-runner, security-audit, n8n-architect), 5 Plugins, kein `skills/`- oder
 `commands/`-Verzeichnis, kein Hooks-Setup. Alles soll in `/home/martin/.claude/workflow/` dokumentiert
 und in den Standard-Verzeichnissen (`skills/`, `agents/`, `hooks/`) aktiviert werden.
 ---
 ## Zu erstellende Struktur
 ```
 /home/martin/.claude/
 ├── workflow/                        ← Neue Dokumentations-Zentrale
 │   ├── README.md                    ← Gesamtübersicht + Schnellreferenz
 │   ├── models.md                    ← Modell-Strategie + Kostenmatrix
 │   └── story-lifecycle.md           ← Story-Workflow von Plan bis PR
 ├── skills/                          ← NEU: Global auto-discoverable Skills
 │   ├── go.md                        ← /go: Test + Simplify + PR
 │   ├── plan-review.md               ← /plan-review: Opus reviewt Plan
 │   └── story.md                     ← /story: Voller Story-Lifecycle
 ├── hooks/                           ← NEU: Hook-Skripte
 │   ├── auto-format.sh               ← PostToolUse: Format nach Edit/Write
 │   └── verify-on-stop.sh            ← Stop: Test-Erinnerung
 └── agents/                          ← Ergänzung: neuer Agent
    └── plan-reviewer.md             ← Opus-basierter Plan-Reviewer
 ```
 Zusätzlich: `settings.json` um Hooks-Sektion erweitern.
 ---
 ## Modell-Strategie (kostenoptimiert)
 | Phase              | Modell        | Begründung                              |
 |--------------------|---------------|-----------------------------------------|
 | Planung / Review   | Opus 4.7      | Qualität > Kosten                       |
 | Implementierung    | Sonnet 4.6    | Optimales Preis-Leistungs-Verhältnis    |
 | Test / Lint / Fmt  | Haiku 4.5     | Schnell + günstig                       |
 | Security-Audit     | Opus 4.7      | Sicherheit hat Priorität                |
 | PR-Erstellung      | Haiku 4.5     | Mechanische Aufgabe                     |
 ---
 ## Detaillierter Umsetzungsplan
 ### Schritt 1: Verzeichnisse anlegen
 - `/home/martin/.claude/workflow/`
 - `/home/martin/.claude/skills/`
 - `/home/martin/.claude/hooks/`
 ### Schritt 2: workflow/README.md
 Schnellreferenz: Welcher Befehl für welche Phase, Modell-Matrix, Link zu den Detail-Docs.
 ### Schritt 3: workflow/models.md
 Vollständige Modell-Strategie mit Beispielen und Kostenschätzungen.
 ### Schritt 4: workflow/story-lifecycle.md
 Story-Lifecycle dokumentiert: Research → Plan → Review → Implement → Test → Security → PR.
 ### Schritt 5: skills/go.md
 `/go`-Skill kombiniert:
 1. test-runner-Agent starten
 2. code-simplifier-Agent starten
 3. Gitea-PR via `secret-tool`-Token erstellen
 Kontext: `fork` (isolierter Subagent).
 ### Schritt 6: skills/plan-review.md
 `/plan-review`-Skill:
 - Startet Opus 4.7-basierten plan-reviewer-Agent
 - Dieser reviewt den aktuellen Plan auf Vollständigkeit, Risiken, fehlende Tests
 - Gibt strukturierten Review-Bericht zurück.
 ### Schritt 7: skills/story.md
 `/story`-Skill orchestriert den vollen Lifecycle:
 1. Plan-Modus (EnterPlanMode)
 2. Plan-Review via plan-reviewer-Agent (Opus)
 3. Implementierung (Sonnet)
 4. /go (Test + Simplify + PR)
 ### Schritt 8: hooks/auto-format.sh
 PostToolUse-Hook nach Edit/Write:
 - Erkennt Dateityp (Python → ruff format, JS/Vue → eslint --fix)
 - Verhindert CI-Fehler durch Formatierungs-Abweichungen.
 ### Schritt 9: hooks/verify-on-stop.sh
 Stop-Hook:
 - Prüft ob unbeendete Tasks vorhanden sind
 - Gibt kurze Erinnerung aus (kein Blockieren).
 ### Schritt 10: agents/plan-reviewer.md
 Neuer Agent `plan-reviewer`:
 - Modell: Opus 4.7
 - Aufgabe: Plan auf Lücken/Risiken/fehlende Tests prüfen
 - Tools: Read, Glob, Grep (read-only)
 - Gibt strukturierten Bericht: ✅ OK / ⚠️ Risiko / ❌ Fehlt.
 ### Schritt 11: settings.json Hooks ergänzen
 ```json
 "hooks": {
  "PostToolUse": [{
    "matcher": "Edit|Write",
    "hooks": [{"type": "command", "command": "bash ~/.claude/hooks/auto-format.sh"}]
  }],
  "Stop": [{
    "hooks": [{"type": "command", "command": "bash ~/.claude/hooks/verify-on-stop.sh"}]
  }]
 }
 ```
 ---
 ## Nicht verändert
 - Bestehende Agenten: `test-runner.md`, `security-audit.md`, `n8n-architect.md` → bleiben unverändert
 - Globale `CLAUDE.md` → keine Änderung (bereits vollständig)
 - Projektspezifische Konfigurationen → keine Änderung
 ---
 ## Verifikation
 1. `claude /go` im Testprojekt → PR in Gitea erscheint
 2. `claude /plan-review` nach EnterPlanMode → Review-Bericht erscheint
 3. Datei editieren → auto-format.sh läuft (keine Fehler)
 4. Session beenden → verify-on-stop.sh gibt Status aus
 5. `cat ~/.claude/workflow/README.md` → Schnellreferenz lesbar
@@ -1,122 +0,0 @@
 # 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 |