claude-regelwerk/.claude/skills/plan-executer-pruefung/SKILL.md

---
name: plan-executer-pruefung
description: Die Standardschleife für nicht triviale Umsetzungsaufgaben — klären, planen, vom Executer-Subagent umsetzen lassen, selbst gegenprüfen, Befunde im Plan korrigieren, nachziehen lassen. Nutze diesen Skill, wenn ein Feature gebaut, ein Refactoring umgesetzt, eine mehrteilige Änderung ausgeführt oder ein bestehender Plan abgearbeitet werden soll, und immer dann, wenn von Executer, Subagent, Delegieren, Plan abarbeiten oder Gegenprüfen die Rede ist. Nicht für Einzeiler und nicht für offene Recherche.
---

# Standardschleife: Planen — Ausführen — Gegenprüfen

Rollen sind fest verteilt: **du (Opus) denkst und prüfst, der Executer tippt.** Vertausche das
nicht. Du schreibst keinen Produktivcode, solange die Schleife läuft; er trifft keine
Entscheidungen.

```
1 Klären  →  2 Planen  →  3 Ausführen  →  4 Gegenprüfen  →  5 Korrigieren  →  6 Abschließen
   du          du          Executer          du                du                du
                                                  ↑                 │
                                                  └───── Befund ────┘
```

## Bevor du startest

**Lies `AI/Regelwerk/codeworkflow.md`, Abschnitt „Standardschleife", vollständig.** Dort steht
die verbindliche Fassung jedes Schritts: Planaufteilung ab drei Tasks, Modellwahl je Taskdatei,
das Pflichtprogramm der Gegenprüfung, fortsetzen oder frisch starten bei der Nachbesserung.

Diese Datei wiederholt das bewusst nicht. Eine zweite Fassung derselben Regel läuft aus dem
Ruder, sobald eine von beiden gepflegt wird — und die Kopie gewinnt, weil sie zuerst geladen
wird.

Für die Plankritik in Schritt 2, die Welle in Schritt 3 und die Prüfung in Schritt 4 gibt es
gespeicherte Workflows mit eingebauten Rollenparametern: `plankritik`, `executer-welle` und
`pruefung` unter `.claude/workflows/`, dazu `welle-mit-pruefung` für Schritt 3 und 4 in einem
Aufruf und `planung` für die Erstplanung vieler Taskdateien. Aufruf und Argumente stehen jeweils
in `whenToUse` im Kopf der Datei. Wie viele Opus-Agenten sie gleichzeitig starten, regelt
`codeworkflow.md`, „Verbrauch und Opus-Plätze". Sie ersetzen deine eigene Gegenprüfung nicht.

Danach je nach Aufgabe zusätzlich:

- `AI/Regelwerk/codedoku.md`, sobald Produktivdateien entstehen oder angefasst werden.
- `AI/Regelwerk/pruefwerkzeuge.md`, sobald ein Skript entsteht, das etwas **beurteilt** statt
  etwas zu tun — und zwar vor der ersten Zeile Code.

**Nur für Claude Fable 5.1:** Läuft diese Sitzung auf Fable 5.1, lies dazu die Abschnitte 3, 8 und
15 in `AI/Regelwerk/fable-5-1.md`. Andere Modelle entscheiden selbst.

## Die zwei Dinge, die du nie delegierst

1. **Die Gegenprüfung in Schritt 4.** Ein Agentenbericht ist eine Behauptung, kein Beleg. Du
   wiederholst den Testlauf selbst, liest die zentralen Artefakte selbst und fährst einen
   eigenen Lauf mit echten Daten und eigenem Prüfcode. Der `pruefer`-Subagent (`opus`)
   verdoppelt das, er ersetzt es nicht. Du fährst sie, während er läuft, nur lesend
   (`codeworkflow.md`, Schritt 4).
2. **Den Commit.** Subagenten committen nie — paralleles `git commit` kollidiert am Index-Lock.

## Grenzen

- Einzeiler, Tippfehler, offensichtliche Korrekturen: selbst machen. Der Auftragstext kostet
  mehr als die Änderung.
- Offene Recherche, Architekturentscheidungen, Debugging ohne Hypothese: kein Executer. Erst
  klären und planen.

Melde nichts als fertig, was du nicht selbst hast laufen sehen. Was offen bleibt, wird offen
benannt — nicht weggelassen.