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:
@@ -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
|
||||
|
||||
|
||||
@@ -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 **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
|
||||
Reference in New Issue
Block a user