martinandClaude Opus 4.6
228b618030
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>
3.7 KiB
3.7 KiB
description, model
| description | model |
|---|---|
| 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). | 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
- Lies das Zieldokument (bei Verzeichnis: alle
.md-Dateien darin). - Lies eine vorhandene
CLAUDE.mdim selben Verzeichnis oder Elternverzeichnis (falls vorhanden). - 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:
- Lies die relevanten Abschnitte nochmals gezielt
- Prüfe jeden der typischen Prüfpunkte
- 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