fix: Workflow-Konsistenz — Modellangaben, Skill-Definitionen und Hook-Robustheit #13

Merged
martin merged 1 commits from fix/workflow-review-inkonsistenzen into main 2026-05-05 07:18:58 +02:00
9 changed files with 28 additions and 17 deletions
Showing only changes of commit f9f16fd397 - Show all commits
+11 -8
View File
@@ -61,11 +61,12 @@ Vorgehen: URL via `WebFetch` abrufen → mit aktuellem Workflow vergleichen →
## Struktur
```
skills/ ← Slash-Commands (Symlinks nach ~/.claude/skills/)
agents/ ← Agenten-Definitionen (Symlinks nach ~/.claude/agents/)
hooks/ ← Shell-Hooks (durch settings.json registriert)
dotfiles/ ← ~/.claude/CLAUDE.md, settings.json, statusline-command.sh
bootstrap.sh ← Einrichtungsskript
skills/ ← Slash-Commands (Symlinks nach ~/.claude/skills/)
agents/ ← Agenten-Definitionen (Symlinks nach ~/.claude/agents/)
hooks/ ← Shell-Hooks (durch settings.json registriert)
dotfiles/ ← ~/.claude/CLAUDE.md, settings.json, statusline-command.sh
skills-optimization/ ← Eval-Datensätze für Skill-Performance-Messung
bootstrap.sh ← Einrichtungsskript
```
## Aktivierung (nach Neuinstallation)
@@ -99,20 +100,22 @@ Kurzbefehl für den gesamten Ablauf: `/story`
| `/script` | `skills/script/SKILL.md` | Bash-Script-Lifecycle: Planung (Opus) → Implementierung (Sonnet) → Shellcheck + Test-Empfehlungen → /ship |
| `/story` | `skills/story/SKILL.md` | Voller Lifecycle von Research bis PR |
| `/workflow-review` | `skills/workflow-review/SKILL.md` | Opus reviewt alle Skills/Konfig → Umsetzungsplan für Sonnet |
| `/implement` | `skills/implement/SKILL.md` | Implementierung direkt aus bestehendem Plan (überspringt Research/Planung) |
## Agenten
| Agent | Modell | Tools | Rolle |
|---|---|---|---|
| `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 |
| `test-runner` | Haiku 4.5 | alle | Tests ausführen, Coverage prüfen |
| `security-audit` | Opus 4.6 | alle | OWASP-Analyse, Security-Tests schreiben |
| `n8n-architect` | Opus 4.6 | alle | n8n-Workflow-Design und Refactoring |
## Hooks
| Event | Trigger | Skript | Aktion |
|---|---|---|---|
| `PreToolUse` | Bash | `hooks/pre-bash-checks.sh` | Git-main-Schutz, apt -y Blockade |
| `PostToolUse` | Edit / Write | `hooks/auto-format.sh` | `ruff` (Python), `eslint --fix` (JS/TS/Vue) oder `shellcheck` (Bash) |
| `Stop` | Session-Ende | `hooks/verify-on-stop.sh` | Uncommittete Änderungen anzeigen |
+1 -1
View File
@@ -1,7 +1,7 @@
---
name: n8n-architect
description: Architekt und Entwickler für n8n-Workflows inklusive Refactoring, Qualitätsrichtlinien und sicherer Nutzung des n8n-MCP-Servers.
model: sonnet
model: claude-opus-4-6
tools:
- Bash
- Read
+1 -1
View File
@@ -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 `.claude/plans/` des aktuellen Projekts)
1. Lies den aktuellen Plan (neueste Datei in `plans/` des Repo-Roots, ermittelt via `git rev-parse --show-toplevel`)
2. Lies die CLAUDE.md des betroffenen Projekts
3. Analysiere den Plan systematisch
+1 -1
View File
@@ -10,7 +10,6 @@
"Bash(python3:*)",
"Read(/home/martin/.claude/**)",
"Bash(find *)",
"Bash(cat *)",
"Bash(git log*)",
"Bash(git diff*)",
"Bash(git status*)",
@@ -63,6 +62,7 @@
],
"defaultMode": "default"
},
"model": "claude-opus-4-6",
"hooks": {
"PreToolUse": [
{
+1
View File
@@ -1,4 +1,5 @@
#!/bin/bash
set -eo pipefail
input=$(cat)
+7 -3
View File
@@ -1,9 +1,10 @@
#!/bin/bash
# Globale Sicherheitsprüfungen vor jedem Bash-Tool-Aufruf.
set -euo pipefail
cmd=$(jq -r '.tool_input.command // ""')
# Git-Branch-Schutz: kein direkter Commit auf main
if echo "$cmd" | grep -q 'git commit'; then
if echo "$cmd" | grep -qE '^\s*git\s+commit\b'; then
branch=$(git rev-parse --abbrev-ref HEAD 2>/dev/null || echo "")
if [ "$branch" = "main" ]; then
printf '{"continue":false,"stopReason":"BLOCKIERT: Direkter Commit auf main verboten (globale Regel). Bitte zuerst Feature-Branch erstellen: git checkout -b session/YYYY-MM-DD-titel"}\n'
@@ -12,6 +13,9 @@ if echo "$cmd" | grep -q 'git commit'; then
fi
# apt -y verboten
if echo "$cmd" | grep -qE '\bapt\b' && echo "$cmd" | grep -q -- ' -y'; then
if echo "$cmd" | grep -qE '\bapt(-get)?\b' && echo "$cmd" | grep -qE '\bapt(-get)?\b.*\s-y\b'; then
printf '{"continue":false,"stopReason":"BLOCKIERT: apt -y ist verboten. Bitte ohne -y ausfuehren, damit du die Zusammenfassung selbst bestaetigen kannst."}\n'
exit 0
fi
exit 0
+4 -1
View File
@@ -20,12 +20,15 @@ Ziel: Redundanzen entfernen, Lesbarkeit verbessern, keine neuen Features einfüh
## Schritt 3: PR erstellen
Ermittle den aktuellen Branch-Namen und die Commit-Zusammenfassung:
Ermittle den aktuellen Branch-Namen, Owner/Repo und die Commit-Zusammenfassung:
```
!git log --oneline origin/main..HEAD
!git branch --show-current
!git remote get-url origin
```
Leite **Owner** und **Repo** aus der Remote-URL ab (z.B. `https://gitea.troeger-net.org/martin/mein-repo.git` → Owner: `martin`, Repo: `mein-repo`).
Erstelle den PR via `mcp__gitea__pull_request_write`:
- Gitea-Instanz: `https://gitea.troeger-net.org`
- PR-Titel: Erster Commit-Titel des Branches
+1 -1
View File
@@ -8,7 +8,7 @@ model: claude-opus-4-6
Starte den `plan-reviewer`-Agenten mit folgendem Auftrag:
1. Lies den aktuellen Plan aus `/home/martin/.claude/plans/` (neueste Datei)
1. Lies den aktuellen Plan aus `plans/` im Repo-Root (neueste Datei, Repo-Root via `git rev-parse --show-toplevel`)
2. Lies die CLAUDE.md des aktuellen Projekts
3. Prüfe den Plan auf:
- **Vollständigkeit**: Sind alle Akzeptanzkriterien abgedeckt?
@@ -7,7 +7,7 @@ git checkout -b feat/<story-name>
Implementierung nach Plan durchführen:
- Schritte aus dem Plan der Reihe nach abarbeiten
- Nach jedem logischen Abschnitt committen (mind. stündlich)
- Nach jedem logischen Abschnitt committen (mind. nach jeder abgeschlossenen Komponente)
- CLAUDE.md-Konventionen einhalten: Ruff, Type Hints, async, Pydantic-Schemas
- Keine generischen `try/except`, kein toter Code, Logging statt print
- Alembic-Migration erstellen falls nötig: `alembic revision --autogenerate -m "..."`