RECIPE
Requirements → Spec (PRD in ausführbare Spezifikation)
Wandelt lose Anforderungen in eine klare, testbare Spezifikation mit Akzeptanzkriterien und Edge-Cases um.
Problem
warum das in der Praxis schief geht
Problem: Anforderungen sind unvollständig/mehrdeutig, wodurch Scope-Creep und Rework entstehen.
Prompt
Copy/Paste · Variablen in {...}
Du bist ein Staff-Produktingenieur. Erzeuge aus {REQUIREMENTS_RAW} eine strukturierte Spezifikation.
Kontext: {CONTEXT}
Ziele: {GOALS}
Nicht-Ziele: {NON_GOALS}
Constraints (Tech/Legal/Security/Time): {CONSTRAINTS}
Stakeholder: {STAKEHOLDERS}
Lieferumfang:
1) Problem Statement (1 Absatz)
2) User Stories + Akzeptanzkriterien (Given/When/Then)
3) Datenmodell/Domain-Objekte (falls relevant)
4) API/Interfaces (Inputs/Outputs, Errors)
5) Edge-Cases & Failure-Modes
6) Observability (Logs/Metrics/Tracing) + SLO-Annahmen
7) Testplan (Unit/Integration/E2E) inkl. Testdaten
8) Offene Fragen (priorisiert) + Annahmen
Regeln:
- Markiere jede Annahme explizit als 'Annahme:'
- Wenn etwas fehlt, stelle gezielte Rückfragen (max. {MAX_QUESTIONS}).
- Sei präzise, keine Marketing-Sprache.
Tipp: Ersetze {BRIEFING} / {FLOW} / {NOTES} durch deinen Kontext. Wenn etwas extern versendet werden soll, schreib explizit: "frag vorher".
Was der Prompt im System bewirkt
konkret & überprüfbar
- Reduziert Mehrdeutigkeit durch klare Akzeptanzkriterien
- Macht Scope und Nicht-Ziele sichtbar
- Erhöht Testbarkeit und Implementierungs-Tempo
Wozu das gut ist
wann du ihn nutzt
- Spezifikationen scheitern selten an Details, sondern an fehlenden Entscheidungen
- Explizite Annahmen verhindern spätere Überraschungen