Merge pull request 'refactor: Konsolidiere Workflow-Dokumentation in CLAUDE.md' (#6) from feat/workflow-simplification into main
This commit was merged in pull request #6.
This commit is contained in:
@@ -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
|
||||
# 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`).
|
||||
Nach System-Neuinstallation `bootstrap.sh` ausführen (erstellt alle Symlinks automatisch).
|
||||
|
||||
## Story-Lifecycle
|
||||
|
||||
@@ -52,12 +81,12 @@ Kurzbefehl für den gesamten Ablauf: `/story`
|
||||
|
||||
| Phase | Befehl | Modell |
|
||||
|---|---|---|
|
||||
| Planung | `EnterPlanMode` | Opus 4.7 |
|
||||
| Plan-Review | `/plan-review` | Opus 4.7 (Subagent) |
|
||||
| Planung | `EnterPlanMode` | Opus 4.6 |
|
||||
| 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.
|
||||
+6
-13
@@ -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
|
||||
- terminal
|
||||
- git
|
||||
- editor
|
||||
maxTurns: 40
|
||||
skills:
|
||||
- "software-architecture"
|
||||
- "workflow-design"
|
||||
- "api-integration"
|
||||
memory: enabled
|
||||
- Bash
|
||||
- Read
|
||||
- Write
|
||||
- Edit
|
||||
- Glob
|
||||
- Grep
|
||||
---
|
||||
|
||||
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
|
||||
npx --yes eslint --fix --quiet "$FILE" 2>/dev/null || true
|
||||
if [[ -x "$DIR/node_modules/.bin/eslint" ]] || [[ -x "$DIR/../node_modules/.bin/eslint" ]]; then
|
||||
npx eslint --fix --quiet "$FILE" 2>/dev/null || true
|
||||
fi
|
||||
fi
|
||||
;;
|
||||
|
||||
+3
-3
@@ -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
|
||||
|
||||
+12
-4
@@ -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:
|
||||
```
|
||||
find . -name "*.md" -not -path "./.git/*"
|
||||
```
|
||||
Lies alle Konfigurationsdateien im Repo mit dem Glob-Tool (`**/*.md`).
|
||||
Schließe `.git/` aus.
|
||||
|
||||
## 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 |
|
||||
Reference in New Issue
Block a user