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>
105 lines
3.7 KiB
Markdown
105 lines
3.7 KiB
Markdown
---
|
||
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 **4–8 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** (2–4 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
|