Sprache: Deutsch
14 Tage kostenlos testen

Offizieller Skill · Produkt

Spec-Review vor dem Bauen

v1.0.1 · Aktualisiert am

Prüft ein PRD oder eine Spec vor dem Bauen auf Mehrdeutigkeit, fehlende Zustände (leer, lädt, Fehler, Berechtigung), Metriken, Rollout und einen Durchgang als neue Nutzerin.

Zum Pod meines Teams hinzufügen SKILL.md herunterladen

Funktioniert in Claude, ChatGPT und Coding-Agents. In Team und Business aktualisiert sich der offizielle Skill in deinem Pod von selbst, wenn wir ihn verbessern.

Wann du ihn nutzt

Was du ihm gibst

Was du bekommst

Ein Urteil, ein Durchgang als neue Nutzerin oder neuer Nutzer, blockierende und zu behebende Befunde mit Zitaten, eine Zustandstabelle und Prüfungen zu Metrik und Rollout.

So funktioniert er

  1. Geh den Ablauf als neue Nutzerin oder neuer Nutzer durch Fang dort an, wo die Person ankommt (Link in einer E-Mail, Menüpunkt, leeres Konto), und erzähl jeden Schritt: was sie sieht, was sie entscheiden muss, was sie klickt. Wo die Spec nicht sagt, was als Nächstes erscheint, notier eine Lücke. Wo ein Label oder eine Frage neue Leute verwirren würde, notier das.
  2. Prüf die Zustände jedes Screens Such für jeden Screen und jede Komponente: leer (erste Nutzung, keine Ergebnisse), lädt, Fehler, unvollständige Daten, keine Berechtigung und Erfolg. Die NN/g rät, dass ein leerer Zustand den Systemstatus zeigt, erklärt, wie man anfängt, und einen direkten Weg zur Aufgabe bietet, und dass eine Meldung „keine Einträge“ nie erscheint, solange noch Daten laden. Fehlermeldungen sollen sichtbar, in klarer Sprache und konstruktiv sein und die Eingaben der Person erhalten.
  3. Finde mehrdeutige Wörter Markiere „schnell“, „einfach“, „simpel“, „intuitiv“, „sollte“, „usw.“, „und/oder“, „einige“ und „nach Bedarf“. Jedes braucht eine Zahl, eine Liste oder eine Entscheidung. Markiere jede Anforderung, die zwei Lesende unterschiedlich testen könnten.
  4. Prüf Regeln und Grenzen Wer darf das? Wie viele? Was passiert an der Grenze? Was ist mit bestehenden Daten und Nutzern, wenn das live geht? Fehlende Antworten sind blockierend, wenn sie das Datenmodell ändern.
  5. Prüf die Metriken Es muss eine primäre Metrik geben, die am Problem hängt, dazu einen Ausgangswert, einen Zielwert und wie gemessen wird. Gibt es das zu zählende Event noch nicht, fehlt der Spec genau diese Anforderung.
  6. Prüf Rollout und Rollback Liegt es hinter einem Feature-Flag? Wer sieht es zuerst (intern, ein Prozentsatz, ein Segment)? Welche Metrik löst einen Rollback aus, und lässt es sich ohne Release abschalten? Martin Fowlers Leitfaden zu Feature Toggles unterscheidet Release Toggles, schrittweise prozentuale Rollouts und Kill Switches; ein Kill Switch muss sich schnell umlegen lassen, ohne neues Release.
  7. Ordne und schreib die Befunde Blockierend = das Team kann es nicht bauen oder testen, oder es gefährdet Daten oder Vertrauen. Sollte behoben werden = es führt zu Nacharbeit oder Verwirrung. Kleinigkeit = Formulierung. Jeder Befund zitiert die Spec, sagt, warum er zählt, und schlägt eine Lösung oder eine Frage vor.

Die SKILL.md

Die ganze Datei, so wie deine KI sie liest. Herunterladen

---
name: spec-review
description: Prüft ein PRD, eine Produktspezifikation oder ein Feature-Briefing, bevor das Team es baut – findet mehrdeutige Formulierungen, fehlende Zustände (leer, lädt, Fehler, keine Berechtigung), fehlende Erfolgsmetriken, einen fehlenden Rollout- und Rollback-Plan und geht den Ablauf Schritt für Schritt als neue Nutzerin oder neuer Nutzer durch. Liefert blockierende Punkte und Fragen, nach Schwere geordnet. Nutze den Skill, wenn jemand ein PRD oder eine Spec teilt und um ein Review, einen Plausibilitätscheck, Feedback oder Lücken bittet oder fragt: „Ist das bereit zum Bauen?“
---

# Spec-Review

Eine Spec ist bereit, wenn Entwicklung, Design und Test daraus jeweils dasselbe bauen und testen würden. Das Review sucht die Stellen, an denen sie auseinanderlaufen würden, und die Zustände, die niemand aufgeschrieben hat. Geh den Ablauf als neue Nutzerin oder neuer Nutzer durch, bevor du die Anforderungsliste liest: Die Lücken zeigen sich beim Durchgehen.

## Wann du sie nutzt

- Bevor die Entwicklung aus einem PRD oder einer Spec schätzt oder mit dem Bauen anfängt.
- Wenn eine Spec überarbeitet wurde und einen zweiten Blick braucht.
- Wenn ein Feature mit Überraschungen live ging und du die nächste Spec gründlicher prüfen willst.
- Nicht, um die Spec aus Notizen zu schreiben: Dafür gibt es prd-from-notes. Nicht für fertige Screens oder Texte: Dafür gibt es landing-copy-review oder ein Design-Review.

## Was du brauchst

- Den Text der Spec oder des PRD, einschließlich Beschreibungen von Mockups.
- Wer die Zielnutzer sind, falls die Spec es nicht sagt. Fehlt das, prüf aus Sicht einer neuen Person ohne Einarbeitung und notier „[Annahme]“.
- Optional: Deadline und Team, damit du den Umfang einschätzen kannst.

## Schritte

1. **Geh den Ablauf als neue Nutzerin oder neuer Nutzer durch.** Fang dort an, wo die Person ankommt (Link in einer E-Mail, Menüpunkt, leeres Konto), und erzähl jeden Schritt: was sie sieht, was sie entscheiden muss, was sie klickt. Wo die Spec nicht sagt, was als Nächstes erscheint, notier eine Lücke. Wo ein Label oder eine Frage neue Leute verwirren würde, notier das.
2. **Prüf die Zustände jedes Screens.** Such für jeden Screen und jede Komponente: leer (erste Nutzung, keine Ergebnisse), lädt, Fehler, unvollständige Daten, keine Berechtigung und Erfolg. Die NN/g rät, dass ein leerer Zustand den Systemstatus zeigt, erklärt, wie man anfängt, und einen direkten Weg zur Aufgabe bietet, und dass eine Meldung „keine Einträge“ nie erscheint, solange noch Daten laden. Fehlermeldungen sollen sichtbar, in klarer Sprache und konstruktiv sein und die Eingaben der Person erhalten.
3. **Finde mehrdeutige Wörter.** Markiere „schnell“, „einfach“, „simpel“, „intuitiv“, „sollte“, „usw.“, „und/oder“, „einige“ und „nach Bedarf“. Jedes braucht eine Zahl, eine Liste oder eine Entscheidung. Markiere jede Anforderung, die zwei Lesende unterschiedlich testen könnten.
4. **Prüf Regeln und Grenzen.** Wer darf das? Wie viele? Was passiert an der Grenze? Was ist mit bestehenden Daten und Nutzern, wenn das live geht? Fehlende Antworten sind blockierend, wenn sie das Datenmodell ändern.
5. **Prüf die Metriken.** Es muss eine primäre Metrik geben, die am Problem hängt, dazu einen Ausgangswert, einen Zielwert und wie gemessen wird. Gibt es das zu zählende Event noch nicht, fehlt der Spec genau diese Anforderung.
6. **Prüf Rollout und Rollback.** Liegt es hinter einem Feature-Flag? Wer sieht es zuerst (intern, ein Prozentsatz, ein Segment)? Welche Metrik löst einen Rollback aus, und lässt es sich ohne Release abschalten? Martin Fowlers Leitfaden zu Feature Toggles unterscheidet Release Toggles, schrittweise prozentuale Rollouts und Kill Switches; ein Kill Switch muss sich schnell umlegen lassen, ohne neues Release.
7. **Ordne und schreib die Befunde.** Blockierend = das Team kann es nicht bauen oder testen, oder es gefährdet Daten oder Vertrauen. Sollte behoben werden = es führt zu Nacharbeit oder Verwirrung. Kleinigkeit = Formulierung. Jeder Befund zitiert die Spec, sagt, warum er zählt, und schlägt eine Lösung oder eine Frage vor.

## Ausgabeformat

```markdown
# Spec-Review: [Name der Spec]

**Urteil:** [Bereit / Bereit nach den blockierenden Fixes / Nicht bereit] — [ein Satz, warum]

## Durchgang als neue Nutzerin oder neuer Nutzer
1. [Schritt: was die Person sieht und tut] — [Lücke oder „klar“]

## Blockierend
| # | Die Spec sagt | Problem | Lösung oder Frage |
|---|---|---|---|
| B1 | „[Zitat]“ | [warum es blockiert] | [Vorschlag] |

## Sollte behoben werden
| # | Die Spec sagt | Problem | Lösung oder Frage |
|---|---|---|---|

## Fehlende Zustände
| Screen | Leer | Lädt | Fehler | Keine Berechtigung | Hinweise |
|---|---|---|---|---|---|
| [Screen] | [abgedeckt / fehlt] | ... | ... | ... | [Hinweis] |

## Metriken und Rollout
- Primäre Metrik: [vorhanden / fehlt] — [Hinweis]
- Rollout: [vorhanden / fehlt] — [Hinweis]
- Rollback-Auslöser und Kill Switch: [vorhanden / fehlt] — [Hinweis]

## Kleinigkeiten
- [Formulierung]
```

## Beispiel

**Eingabe (Auszug):** „Nutzer können ihr Steuerbüro mit Lesezugriff einladen. Einladungen sollten einfach sein. Nutzer mit Lesezugriff können nichts bearbeiten. Wir messen die Nutzung. Launch für alle am 1.“

**Ausgabe:**

```markdown
# Spec-Review: Lesezugang

**Urteil:** Nicht bereit — keine definierten Zustände, eine nicht messbare Metrik und ein Launch ohne Weg zurück.

## Durchgang als neue Nutzerin oder neuer Nutzer
1. Inhaberin sucht, wo sie einladen kann — Spec sagt nicht, auf welcher Seite; Lücke.
2. Inhaberin gibt eine E-Mail-Adresse ein — Spec sagt nicht, was passiert, wenn die Adresse schon Mitglied ist; Lücke.
3. Steuerbüro öffnet die Einladungsmail — kein Inhalt der Mail festgelegt; Lücke.
4. Steuerbüro landet in der App — was sieht es zuerst? Ein leeres Dashboard würde wie „kaputt“ wirken; Lücke.

## Blockierend
| # | Die Spec sagt | Problem | Lösung oder Frage |
|---|---|---|---|
| B1 | „können nichts bearbeiten“ | Ist Export eine Bearbeitung? Kommentare? Zwei Entwickler werden das verschieden beantworten. | Erlaubte Aktionen auflisten: ansehen, exportieren [zu bestätigen], sonst nichts. |
| B2 | „Launch für alle am 1.“ | Kein Flag, kein Rollback-Auslöser. Ein Berechtigungsfehler würde jedes Konto offenlegen. | Hinter einem Flag zuerst für interne Konten, dann 10 % [Vorschlag, Standard dieses Skills]; einen Kill Switch ergänzen. |
| B3 | „Wir messen die Nutzung“ | Kein Event, kein Ausgangswert, kein Zielwert. | Konten mit 1 oder mehr angenommenen Lesezugangs-Einladungen pro Woche zählen; Zielwert noch festzulegen. |

## Sollte behoben werden
| # | Die Spec sagt | Problem | Lösung oder Frage |
|---|---|---|---|
| S1 | „Einladungen sollten einfach sein“ | Nicht testbar. | „Eine Inhaberin kann von der Team-Seite aus mit höchstens 3 Klicks eine Einladung senden.“ [unser Vorschlag] |
| S2 | (keine) | Keine Grenze für Lesezugänge. | Eine Obergrenze festlegen oder „keine Obergrenze“ schreiben. |

## Fehlende Zustände
| Screen | Leer | Lädt | Fehler | Keine Berechtigung | Hinweise |
|---|---|---|---|---|---|
| Einladen auf der Team-Seite | entfällt | fehlt | fehlt | fehlt | Was sieht jemand, der nicht Inhaber ist? |
| Erster Screen des Steuerbüros | fehlt | fehlt | fehlt | entfällt | Braucht einen Hinweis „Du hast nur Lesezugriff“ |

## Metriken und Rollout
- Primäre Metrik: fehlt — siehe B3.
- Rollout: fehlt — siehe B2.
- Rollback-Auslöser und Kill Switch: fehlt — siehe B2.

## Kleinigkeiten
- „Steuerbüro“ und „Nutzer mit Lesezugriff“ stehen für dieselbe Rolle; entscheide dich für eins.
```

## Prüfen vor dem Senden

- [ ] Der Durchgang beginnt dort, wo echte Nutzer ankommen, und deckt jeden Schritt bis zum Erfolg ab.
- [ ] Jeder Befund zitiert die Spec oder sagt „(keine)“ bei einer Auslassung.
- [ ] Jeder blockierende Befund hat einen Lösungsvorschlag oder eine direkte Frage.
- [ ] Die Zustandstabelle deckt jeden Screen ab, den die Spec nennt.
- [ ] Metriken, Rollout und Rollback sind jeweils als vorhanden oder fehlend markiert.
- [ ] Standardwerte, die du vorschlägst (Prozentsätze, Anzahl Klicks), sind als Vorschläge markiert, nicht als Teil der Spec.

## Häufige Fehler

- Nur die Anforderungsliste prüfen. Die meisten Lücken liegen zwischen den Schritten, also geh zuerst den Ablauf durch.
- 40 Kleinigkeiten auflisten. Fang mit den blockierenden Punkten an; höchstens 5 Kleinigkeiten.
- Die Spec neu schreiben. Zeig auf die Lücke und mach einen Vorschlag; die Lösung gehört der Person, die die Spec geschrieben hat.

Teile ihn mit deinem Team

Füge ihn einem AI Skill Pod hinzu, und alle im Team, auch Freelancer, nutzen dieselbe Version aus ihrer eigenen KI. Lies, wie Teams KI-Skills am besten teilen

Zum Pod meines Teams hinzufügen

Änderungen

Quellen

  1. Designing Empty States in Complex Applications: 3 Guidelines - NN/G (gelesen am 2026-11-04)
  2. Error-Message Guidelines - NN/G (gelesen am 2026-11-04)
  3. Feature Toggles (aka Feature Flags) (Martin Fowler) (gelesen am 2026-11-04)