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

- CLAUDE.md: Klare Modell-Strategie (Opus für Planung/Review, Sonnet für Impl., Haiku für Tests)
- Agents und Skills: konsistente Modellangaben (n8n-architect, plan-reviewer, go/SKILL, plan-review/SKILL)
- Statusline: sichere Fehlerbehandlung bei fehlenden Befehlen (jq, secret-tool)
- pre-bash-checks.sh: robustere Validierungen (-n statt -z für Präsenzprüfung), vermeidung von edge cases
- phase-4-implementierung.md: Konsistenz in der Workflow-Beschreibung

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

CLAUDE.md

@@ -65,6 +65,7 @@ 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
 ```
 
@@ -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 |
+| `test-runner` | Haiku 4.5 | alle | Tests ausführen, Coverage prüfen |
-| `security-audit` | Sonnet | alle | OWASP-Analyse, Security-Tests schreiben |
+| `security-audit` | Opus 4.6 | alle | OWASP-Analyse, Security-Tests schreiben |
-| `n8n-architect` | Sonnet | alle | n8n-Workflow-Design und Refactoring |
+| `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 |
 

agents/n8n-architect.md

@@ -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

agents/plan-reviewer.md

@@ -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
 

dotfiles/settings.json

@@ -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": [
       {

dotfiles/statusline-command.sh

@@ -1,4 +1,5 @@
 #!/bin/bash
+set -eo pipefail
 
 input=$(cat)
 

hooks/pre-bash-checks.sh

@@ -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

skills/go/SKILL.md

@@ -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

skills/plan-review/SKILL.md

@@ -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?

skills/story/references/phase-4-implementierung.md

@@ -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 "..."`