feat: /project-review Skill für domänenunabhängige Dokument-Reviews

Neuer Skill der Nicht-Software-Dokumente (Bauanleitungen, Hardware-Pläne,
Analysen) reviewt. Erkennt die Domäne automatisch, leitet Prüfkategorien
ab und lässt den User per MultiSelect wählen.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
2026-06-13 08:21:37 +02:00
co-authored by Claude Opus 4.6
parent cff9549617
commit 228b618030
2 changed files with 105 additions and 0 deletions
+1
View File
@@ -103,6 +103,7 @@ Kurzbefehl für den gesamten Ablauf: `/story`
| `/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) |
| `/project-review` | `skills/project-review/SKILL.md` | Domänenunabhängiges Review für Nicht-Software-Dokumente (Bau, Hardware, Analysen) |
## Agenten
+104
View File
@@ -0,0 +1,104 @@
---
description: Domänenunabhängiges Review für beliebige Projektdokumente — Bauanleitungen, Analysen, Hardware-Pläne, Konzepte. Erkennt die Domäne automatisch, leitet passende Prüfkategorien ab und lässt den User wählen. Aktivieren wenn ein nicht-Software-Dokument auf Vollständigkeit, Korrektheit und Risiken geprüft werden soll. Nicht verwenden für Software-Pläne (dafür /plan-review) oder Code-Reviews (dafür /code-review).
model: claude-opus-4-6
---
# /project-review — Domänenunabhängiges Dokument-Review
Argument: Pfad zu einer Datei oder einem Verzeichnis. Ohne Argument: User fragen.
## Phase 1 — Dokument einlesen und Domäne erkennen
1. Lies das Zieldokument (bei Verzeichnis: alle `.md`-Dateien darin).
2. Lies eine vorhandene `CLAUDE.md` im selben Verzeichnis oder Elternverzeichnis (falls vorhanden).
3. Bestimme die **Domäne** anhand des Inhalts. Beispiele:
| Signal im Dokument | Domäne |
|---|---|
| Schaltpläne, Verdrahtung, Sensoren, 230V, Relais | Elektrotechnik / Hardware |
| Heizlast, COP, Wärmepumpe, Pufferspeicher, Hydraulik | Haustechnik / Thermodynamik |
| Statik, Fundament, Beton, Bewehrung | Bau / Konstruktion |
| Rezepte, Zutaten, Garzeiten | Kochen |
| Workflow, Prozess, Organisation | Projektmanagement |
Nenne die erkannte Domäne dem User in einem Satz.
## Phase 2 — Prüfkategorien ableiten und zur Auswahl stellen
Leite **48 Prüfkategorien** aus Domäne und Dokumentinhalt ab. Jede Kategorie besteht aus:
- **Name** (kurz, z.B. "Elektrosicherheit")
- **Beschreibung** (ein Satz, was geprüft wird)
- **Typische Prüfpunkte** (24 konkrete Fragen)
Die Kategorien sollen das Dokument vollständig abdecken. Typische Muster:
**Immer dabei (domänenübergreifend):**
- Vollständigkeit — fehlen Abschnitte, Schritte, Angaben?
- Korrektheit — sind Fakten, Berechnungen, Angaben nachvollziehbar und widerspruchsfrei?
- Risiken — was kann schiefgehen, was fehlt als Fallback?
**Domänenspezifisch ableiten**, z.B.:
- Elektrotechnik: Sicherheit (Absicherung, Schutzleiter, Spannungsfreiheit), Komponentenwahl, Diagnose
- Haustechnik: Dimensionierung, Regelstrategie, Normen/Förderung
- Bau: Statik, Materialwahl, Bauvorschriften
Stelle die Kategorien dem User mit `AskUserQuestion` zur Auswahl (multiSelect). Vorauswahl: alle.
## Phase 3 — Review durchführen
Prüfe das Dokument anhand der gewählten Kategorien. Für jede Kategorie:
1. Lies die relevanten Abschnitte nochmals gezielt
2. Prüfe jeden der typischen Prüfpunkte
3. Bewerte: OK / Risiko / Blocker
**Bewertungsmaßstab:**
- **OK**: Korrekt und vollständig dokumentiert
- **Risiko**: Funktioniert vermutlich, aber Lücke oder Ungenauigkeit — bewusst abwägen
- **Blocker**: Fehler, fehlende sicherheitskritische Information, oder Widerspruch — vor Umsetzung klären
## Ausgabe-Format
```
## Project-Review: [Dokumenttitel]
**Domäne:** [erkannte Domäne]
**Dokument:** [Dateipfad(e)]
**Geprüfte Kategorien:** [Liste]
---
### [Kategorie 1]
#### ✅ OK
- [Befund mit Verweis auf Abschnitt/Zeile]
#### ⚠️ Risiko
- [Problem] — **Empfehlung:** [konkreter Vorschlag]
#### ❌ Blocker
- [Problem] — **Muss geklärt werden:** [was fehlt]
---
### [Kategorie 2]
[...]
---
## Gesamtbewertung
| Kategorie | Ergebnis |
|---|---|
| [Name] | ✅ / ⚠️ / ❌ |
**Empfehlung:** [Umsetzung freigeben / Dokument zuerst anpassen — mit konkreten Punkten]
```
## Regeln
- Nur echte Probleme als Blocker — keine "könnte man noch ergänzen"-Punkte
- Konkrete Empfehlungen statt vager Hinweise
- Bei Berechnungen: Nachrechnen und Ergebnis angeben
- Bei Normen/Vorschriften: nur nennen wenn du dir sicher bist, sonst als "prüfenswert" markieren
- Keine Lobhudelei — kurz bestätigen was stimmt, Fokus auf Findings