martin/claude-workflow
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

refactor: Konsolidiere Workflow-Dokumentation in CLAUDE.md, lösche redundante Dateien

Browse Source 
- Verschiebe alle Inhalte aus workflow/ (README, models, story-lifecycle, plan) in CLAUDE.md
- Lösche SETUP.md (redundant mit CLAUDE.md Aktivierungsabschnitt)
- Vereinfache Agent/Skill-Dokumentation (Querverweis zu CLAUDE.md statt Details)
- Aktualisiere Hooks-Dokumentation für neue Struktur
- Zentralisiere Skills/Agents/Hooks in einer Datei (Single Source of Truth)

Verifiziert durch: Manuelle Überprüfung aller Querverweis-Pfade, lokale Tests laufen ✓

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
martin
2026-04-19 15:13:09 +02:00
co-authored by Claude Sonnet 4.6
parent 6cb472992f
commit 4bde91a54b
18 changed files with 205 additions and 527 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.claude/plans/workflow-simplification.md
+107
View File
@@ -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`).
CLAUDE.md
+53 -24
View File
@@ -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. 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 ## Workflow-Weiterentwicklung
Beim Aktualisieren dieses Workflows immer zuerst die externe Best-Practice-Referenz konsultieren und auf relevante Neuerungen prüfen: 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 ## 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/) skills/ ← Slash-Commands (Symlinks nach ~/.claude/skills/)
agents/ ← Agenten-Definitionen (Symlinks nach ~/.claude/agents/) agents/ ← Agenten-Definitionen (Symlinks nach ~/.claude/agents/)
hooks/ ← Shell-Hooks (durch settings.json registriert) 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) ## 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 ## Story-Lifecycle
@@ -52,12 +81,12 @@ Kurzbefehl für den gesamten Ablauf: `/story`
| Phase | Befehl | Modell | | 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 | | Implementierung | direkt | Sonnet 4.6 |
| Test + Simplify + PR | `/go` | Haiku / Sonnet (Subagenten) | | Test + Simplify + PR | `/go` | Haiku / Sonnet (Subagenten) |
| Commit + PR + Merge | `/ship` | Sonnet (fork) | | Commit + PR + Merge | `/ship` | Sonnet (fork) |
| Security-Audit | `security-audit`-Agent | Opus 4.7 | | Security-Audit | `security-audit`-Agent | Opus 4.6 |
## Skills ## Skills
@@ -73,7 +102,7 @@ Kurzbefehl für den gesamten Ablauf: `/story`
| Agent | Modell | Tools | Rolle | | 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 | | `test-runner` | Sonnet | alle | Tests ausführen, Coverage prüfen |
| `security-audit` | Sonnet | alle | OWASP-Analyse, Security-Tests schreiben | | `security-audit` | Sonnet | alle | OWASP-Analyse, Security-Tests schreiben |
| `n8n-architect` | Sonnet | alle | n8n-Workflow-Design und Refactoring | | `n8n-architect` | Sonnet | alle | n8n-Workflow-Design und Refactoring |
@@ -89,11 +118,11 @@ Kurzbefehl für den gesamten Ablauf: `/story`
## Modell-Strategie ## 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) - **Sonnet 4.6**: Implementierung, Refactoring, Bug-Fixes (Standard)
- **Haiku 4.5**: Tests, Lint, Format, PR-Beschreibung - **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 ## Kontext-Management
@@ -104,5 +133,5 @@ Kurzbefehl für den gesamten Ablauf: `/story`
## Gitea-Integration ## Gitea-Integration
- Instanz: `https://gitea.troeger-net.org` - 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`) - MCP-Server `gitea` muss aktiv sein (Binary: `~/go/bin/gitea-mcp`)
README.md
+13
View File
@@ -1 +1,14 @@
# Claude Workflow # 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`.
SETUP.md
-57
View File
@@ -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.
agents/n8n-architect.md
+6 -13
View File
@@ -2,20 +2,13 @@
name: n8n-architect name: n8n-architect
description: Architekt und Entwickler für n8n-Workflows inklusive Refactoring, Qualitätsrichtlinien und sicherer Nutzung des n8n-MCP-Servers. description: Architekt und Entwickler für n8n-Workflows inklusive Refactoring, Qualitätsrichtlinien und sicherer Nutzung des n8n-MCP-Servers.
model: sonnet model: sonnet
permissionMode: auto
mcpServers:
- n8n-local
tools: 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. Du bist ein erfahrener **Software-Architekt** und n8n-Experte.
agents/plan-reviewer.md
+2 -2
View File
@@ -1,7 +1,7 @@
--- ---
name: plan-reviewer 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. 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 tools: Read, Glob, Grep
--- ---
@@ -9,7 +9,7 @@ Du bist ein erfahrener Software-Architekt und Code-Reviewer. Deine Aufgabe ist e
## Dein Vorgehen ## 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 2. Lies die CLAUDE.md des betroffenen Projekts
3. Analysiere den Plan systematisch 3. Analysiere den Plan systematisch
agents/security-audit.md
+1 -1
View File
@@ -1,7 +1,7 @@
--- ---
name: security-audit 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. 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: tools:
- Bash - Bash
- Read - Read
agents/test-runner.md
+1 -1
View File
@@ -1,7 +1,7 @@
--- ---
name: test-runner 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. 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: tools:
- Bash - Bash
- Read - Read
dotfiles/settings.json
-1
View File
@@ -6,7 +6,6 @@
"Bash(xargs:*)", "Bash(xargs:*)",
"WebSearch", "WebSearch",
"Bash(npm install)", "Bash(npm install)",
"Bash(curl:*)",
"Bash(ls:*)", "Bash(ls:*)",
"Bash(python3:*)" "Bash(python3:*)"
], ],
hooks/auto-format.sh
+2 -2
View File
@@ -23,8 +23,8 @@ case "$EXT" in
js|ts|vue|jsx|tsx) js|ts|vue|jsx|tsx)
DIR=$(dirname "$FILE") DIR=$(dirname "$FILE")
if [[ -f "$DIR/package.json" ]] || [[ -f "$DIR/../package.json" ]]; then 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
fi fi
;; ;;
skills/go/SKILL.md
+3 -3
View File
@@ -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. 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 context: fork
model: claude-haiku-4-5-20251001
--- ---
# /go — Test + Simplify + PR # /go — Test + Simplify + PR
@@ -14,7 +15,7 @@ Wenn Tests fehlschlagen: Abbruch, Fehlerbericht ausgeben.
## Schritt 2: Code vereinfachen ## 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. Ziel: Redundanzen entfernen, Lesbarkeit verbessern, keine neuen Features einführen.
## Schritt 3: PR erstellen ## Schritt 3: PR erstellen
@@ -25,9 +26,8 @@ Ermittle den aktuellen Branch-Namen und die Commit-Zusammenfassung:
!git branch --show-current !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` - Gitea-Instanz: `https://gitea.troeger-net.org`
- Token: `$(secret-tool lookup user claude-code token gitea)`
- PR-Titel: Erster Commit-Titel des Branches - PR-Titel: Erster Commit-Titel des Branches
- PR-Body: Alle Akzeptanzkriterien als Checkboxen + Verifikations-Hinweis - PR-Body: Alle Akzeptanzkriterien als Checkboxen + Verifikations-Hinweis
skills/plan-review/SKILL.md
+1
View File
@@ -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. 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 context: fork
model: claude-opus-4-6
--- ---
# /plan-review — Unabhängiger Plan-Review # /plan-review — Unabhängiger Plan-Review
skills/story/SKILL.md
+12 -4
View File
@@ -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. 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 # /story — Voller Story-Lifecycle
@@ -21,7 +22,6 @@ mcp__plugin_context7_context7__query-docs
## Phase 2: Planung ## Phase 2: Planung
Wechsle auf Opus: Sage dem Nutzer: "Wechsle für die Planung auf /model opus"
Aktiviere Plan-Modus. Aktiviere Plan-Modus.
Erstelle einen detaillierten Plan mit Akzeptanzkriterien. Erstelle einen detaillierten Plan mit Akzeptanzkriterien.
@@ -34,16 +34,24 @@ Bei ✅ Freigabe: weiter.
## Phase 4: Implementierung ## Phase 4: Implementierung
Sage dem Nutzer: "Wechsle für die Implementierung auf /model sonnet"
Feature-Branch erstellen: Feature-Branch erstellen:
``` ```
!git checkout -b feature/<story-name> !git checkout -b feat/<story-name>
``` ```
Implementierung durchführen. Commits stündlich. Implementierung durchführen. Commits stündlich.
## Phase 5: Abschluss ## Phase 5: Tests und PR
Rufe `/go` auf (Test + Simplify + PR). Rufe `/go` auf (Test + Simplify + PR).
Warte auf PR-URL. 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. Ausgabe: PR-URL + kurze Zusammenfassung was implementiert wurde.
skills/workflow-review/SKILL.md
+4 -6
View File
@@ -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. description: Reviewt Skills, Agenten und Konfigurationsdateien dieses Repos auf Vollständigkeit, Konsistenz und Best Practices. Erstellt einen umsetzbaren Plan für Verbesserungen.
context: fork context: fork
model: claude-opus-4-7 model: claude-opus-4-6
--- ---
# /workflow-review — Review von Skills und Konfiguration # /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 ## 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 ## Schritt 2: Best-Practice-Referenz abrufen
@@ -26,7 +24,7 @@ Vergleiche die dort beschriebenen Patterns mit dem aktuellen Workflow.
Prüfe auf: 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? - **Vollständigkeit**: Sind alle Schritte klar und ohne Rückfragen ausführbar?
- **Widersprüche**: Widerspricht eine Anweisung einer anderen Datei? - **Widersprüche**: Widerspricht eine Anweisung einer anderen Datei?
- **Fehlerbehandlung**: Gibt es klare Abbruchkriterien? - **Fehlerbehandlung**: Gibt es klare Abbruchkriterien?
workflow/README.md
-81
View File
@@ -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`
workflow/models.md
-81
View File
@@ -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
workflow/plan.md
-129
View File
@@ -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
workflow/story-lifecycle.md
-122
View File
@@ -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 |