rizqinrr/hole-PRD

PRD erstellen

Übersicht

get-prd verwandelt eine vage Anfrage in einem einzigen, kontinuierlichen Durchlauf in ein genehmigtes PRD. Es vereint drei Arbeitsabläufe, die normalerweise getrennt ausgeführt werden:

1. Design-Baum-Interview — Jede Entscheidung als Baum abbilden, den Baum Grenze für Grenze in Runden bearbeiten und zu jeder Frage eine Empfehlung geben. Das ist die Mechanik, die ein Interview konvergent und nicht abschweifend macht.
2. Absichtsextraktion — Erfassen, was der Benutzer tatsächlich will, nicht das, was er glaubt, wollen zu sollen, mit einer expliziten Konfidenzzahl bei jedem Schritt. Das ist die Disziplin, die verhindert, dass der Agent stillschweigend Lücken füllt.
3. Spezifikationserstellung — Die Anforderungen in einem strukturierten Artefakt mit Grenzen, Erfolgskriterien und einem Genehmigungsgate festhalten. Das ist das lieferbare Ergebnis, das die nachgelagerte Planung benötigt.

Der Grund für die Zusammenlegung ist, dass eine Trennung Kontext verliert. Wenn das Interviewen eine Fertigkeit und die Spezifikationserstellung eine andere ist, startet die zweite Fertigkeit kalt: Sie fragt erneut, was die erste bereits gelernt hat, oder sie nimmt stillschweigend Antworten an, die nie gegeben wurden. Ein PRD, das aus einer veralteten Zusammenfassung geschrieben wurde, ist schlimmer als gar kein PRD, weil es autoritativ aussieht.

Zwei Konsequenzen der Zusammenlegung, beide beabsichtigt:

• Diese Fertigkeit ist lang. Sie trägt die vollständige Methodik aller drei Phasen in sich, anstatt sie an andere Fertigkeiten zu delegieren. Befolge die Schritte in der Reihenfolge; überspringe nicht das Template.
• Diese Fertigkeit delegiert das Interview nie. Der Interviewmechanismus lebt hier. Rufe keine andere Fertigkeit auf, um die Befragung durchzuführen.

Das Ergebnis ist ein umfassendes PRD, das als docs/PRD.md (oder docs/prd/<name>.md) gespeichert, vom Benutzer genehmigt und bereit für get-tasks und get-design ist.

Für neue Benutzer oder Konzepte in der Frühphase integriert get-prd ideenschärfende Entdeckungslinsen, nicht-funktionale Randbedingungen und grundlegende Entitäts-/Datenbeziehungsdefinitionen direkt in das Dokument, sodass keine separaten Schema- oder Verfeinerungsfertigkeiten erforderlich sind.

Wann verwenden

Verwende diese Fertigkeit, wenn:

• Der Benutzer eine neue Anwendung, ein neues System, eine neue Funktion oder eine signifikante Änderung startet und noch kein Anforderungsdokument existiert
• Der Benutzer sagt „PRD erstellen“, „PRD bauen“, „neues System bauen“ oder „X entwickeln“
• Der Benutzer bittet um eine gründliche Befragung, ein Interview oder einen Stresstest im Hinblick auf eine Spezifikation
• Die Anfrage konventionell und unterbestimmt ist („Baue mir ein Dashboard“, „Mach es schneller“) und du nicht sagen kannst, was „fertig“ bedeutet
• Du planst oder baust etwas, das mehr als einen Tag dauern würde, und es gibt keine schriftlichen Anforderungen

Wann NICHT verwenden:

• Fehlerbehebungen, Tippfehlerkorrekturen, Umbenennungen und mechanische Operationen
• Ein PRD oder eine Spezifikation existiert bereits und der Benutzer möchte einen kleinen Teil davon ändern — das Dokument direkt ändern
• Reine Informationsanfragen („Wie funktioniert das?“)
• Der Benutzer möchte explizit die Dokumentation überspringen und einfach mit dem Bauen beginnen — respektiere das, aber weise einmal auf das Risiko hin
• Nicht-interaktive Kontexte (CI-Pipelines, geplante Ausführungen, autonome Schleifen). Diese Fertigkeit erfordert einen live und reaktionsbereiten Benutzer. Wenn die Anfrage in einem nicht-interaktiven Kontext unterbestimmt ist, markiere es als Blockierungspunkt, anstatt zu raten.

Der Prozess

get-prd läuft in acht Phasen. Jede Phase hat eine Abbruchbedingung. Gehe nicht über eine Phase hinaus, deren Abbruchbedingung nicht erfüllt ist.

0. Scope-Gate       -> Ist das eine Fähigkeit oder mehrere?
1. Hypothesensaat   -> Was, glaube ich, will der Benutzer, und wie sicher bin ich mir?
2. Baum aufbauen    -> Welche Entscheidungen gibt es, und welche liegen an der Grenze?
3. Rundenfragen     -> Die Grenze abfragen, eine Runde nach der anderen
4. Absichtsprüfung  -> Wollen vs. Sollen-Wollen
5. Rückversicherung -> Sag es zurück, in seinen Worten
6. Lückenprüfung    -> Was braucht das PRD, das das Interview nicht hervorgebracht hat?
7. Schreiben und Gate -> Das PRD, dann ein explizites Ja

Universelle Prinzipien für den Interviewer

1. Natürliche Sprachübereinstimmung: Führe das Gespräch immer in der bevorzugten Sprache des Benutzers. Wenn der Benutzer das Gespräch auf Englisch beginnt, führe das gesamte Interview auf Englisch und belasse branchenübliche Fachbegriffe unberührt (Akzeptanzkriterien, Schema, Endpunkt, Payload). Beginnt der Benutzer auf Deutsch, führe es auf Deutsch. Erzwinge niemals ein englisches Interview bei einem Benutzer, der in einer anderen Sprache gefragt hat.
2. Empathischer & nicht-einschüchternder Ton: Benutzer kommen oft mit rohen, ungeformten Ideen. Stelle sie nie zur Rede oder lasse sie sich wegen fehlender Fachbegriffe unzulänglich fühlen. Führe sie geduldig: Übersetze ihre Geschäftsprobleme in technische Entscheidungen und füge immer deine empfohlene Antwort bei („-> Empfehlung: ...“), sodass sie nur reagieren müssen, anstatt von Grund auf zu brainstormen.
3. Die 3 goldenen Fragen für vage/frühe Ideen: Wenn ein Benutzer eine kurze 1-Satz-Idee präsentiert (z.B. „Ich möchte ein SaaS wie Notion für Kochrezepte bauen“), verankere die Grenze um drei menschenzentrierte Säulen, bevor du über Technologie-Stacks sprichst:
   • Zielpersona & Kontext: Wer nutzt es, wo und in welcher Situation?
   • Die Nordstern-Benutzerreise: Was ist der eine wichtigste Aktionsablauf von Anfang bis Ende, der in dieser Anwendung unbedingt erfolgreich sein muss?
   • MVP-Abgrenzung: Welche Funktionen müssen unbedingt am ersten Tag da sein, und welche werden bewusst auf eine spätere Phase verschoben?

---

Phase 0: Scope-Gate

Die meisten Anfragen beschreiben eine Fähigkeit. Wenn diese es tut, sag es in einem Satz und gehe zu Phase 1. Diese Phase existiert für den Ausnahmefall.

Erkennung. Zerlege, bevor du etwas schreibst, wenn eine einzige Anfrage mehrere unabhängig testbare Fähigkeiten bündelt:

• Die Anfrage nennt verschiedene Fähigkeiten mit eigenen Nutzern oder Daten (Identität, Abrechnung, Benachrichtigungen, Berichte)
• Akzeptanzkriterien gruppieren sich in Cluster, die unabhängig voneinander ausgeliefert und verifiziert werden könnten
• Eine Fähigkeit könnte herausgeschnitten oder ersetzt werden, ohne die Anforderungen der anderen umschreiben zu müssen

Wenn erkannt, schlage eine Fähigkeitenkarte vor, bevor eine Interviewrunde beginnt. Klein und überprüfbar — eine Modultabelle plus eine Build-Reihenfolge, kein Projektplan:

# Fähigkeitenkarte: [Initiative Name]

| Modul-ID | Verantwortlichkeit | Abhängig von |
|---|---|---|
| identity | Konten, Sitzungen, SSO | - |
| billing | Pläne, Rechnungen, Zahlungen | identity |
| notifications | E-Mail- und Webhook-Verteiler | identity |
| reporting | Nutzungs-Dashboards | billing, notifications |

Build-Reihenfolge: identity -> billing, notifications -> reporting

Regeln für die Karte:

• Stabile Modul-IDs. Kebab-Schreibweise, einmal gewählt, nie umbenannt. Die nachgelagerte Planung wählt Arbeiten anhand dieser IDs aus.
• Abhängigkeitsrichtung, keine Zyklen. Pfeile zeigen in eine Richtung. Wenn zwei Module sich gegenseitig brauchen, sind sie ein Modul.
• Schnittstellen leben an der Grenze. Die Karte hält fest, dass billing von identity abhängt; der Vertrag zwischen ihnen gehört in das PRD des bereitstellenden Moduls.

Die Karte ist ein Gate. Bitte den Benutzer, Modulgrenzen, Abhängigkeitsrichtung und Build-Reihenfolge zu genehmigen, bevor du für ein einzelnes Modul interviewst. Eine falsche Karte ist teuer; zehn Zeilen zu überprüfen ist es nicht.

Führe dann die Phasen 1-7 einmal pro Modul, in Build-Reihenfolge aus, jeweils mit einem eigenen docs/prd/<modul-id>.md. Schreibe kein monolithisches PRD für eine Multi-Modul-Initiative.

Abbruchbedingung: entweder ist die Anfrage eine Einzelfähigkeit (explizit sagen), oder eine Fähigkeitenkarte ist genehmigt.

---

Phase 1: Hypothesensaat

Bevor du irgendetwas fragst, schreibe deine aktuelle Lesart der Anfrage und eine ehrliche Konfidenzzahl auf.

HYPOTHESE: Sie möchten eine Möglichkeit, im Standup die Frage „Wie läuft es?“ zu beantworten, und „Dashboard“ war die Konvention, die ihnen in den Sinn kam.
KONFIDENZ: ~30% - fehlt: für wen, was „Metriken“ hier bedeutet, und wie Erfolg aussieht

Regeln:

• Ein Satz für die Hypothese. Wenn du sie nicht in einem Satz schreiben kannst, hast du noch keine Lesart.
• Die Konfidenzzahl ist ein Prozentsatz von 0 bis 100. Sie erzwingt Ehrlichkeit: Wenn du die Reaktion des Benutzers auf die nächsten drei Fragen, die du stellen würdest, nicht vorhersagen kannst, ist die Zahl falsch.
• Unter ~70% füge einen kurzen Grund in derselben Zeile an, der benennt, was noch ungeklärt ist. Das sagt dem Benutzer genau, was das Interview ans Licht bringen muss.
• Aktualisiere die Hypothese und die Konfidenz nach jeder Runde.

Abbruchbedingung: eine Hypothese mit einer Konfidenzzahl ist dokumentiert.

---

Phase 2: Den Entscheidungsbaum aufbauen

Bilde den Entscheidungsraum ab, bevor du etwas fragst. Jede Entscheidung verzweigt sich in die Entscheidungen, die von ihr abhängen.

Ziel: persönlicher Experiment-Tracker
    |
    +-- Was zählt als Experiment?        (Einheit definieren)
    |       |
    |       +-- Welche Felder beschreiben eines?    (Schema abgrenzen)
    |
    +-- Woher kommen die Daten?           (Eingabequelle)
    |       |
    |       +-- Manuelle Eingabe oder Import?      (Interaktionsmodell)
    |
    +-- Wann ist ein Experiment „fertig“?        (Lebenszyklus)
            |
            +-- Welches Signal beendet es?         (Erfolgsdefinition)

Die Grenze ist jede Entscheidung, deren Voraussetzungen bereits geklärt sind: die Fragen, die du jetzt stellen kannst, ohne auf Antworten zu raten, die du noch nicht gehört hast.

Zwei Regeln, die das zum Funktionieren bringen:

1. Frage die gesamte Grenze in einer Runde ab. Stelle nicht eine Frage pro Zug, wenn mehrere unabhängig sind. Unabhängige Fragen werden gemeinsam schneller beantwortet, und der Benutzer sieht die Form des Entscheidungsraums.
2. Eine Frage, deren Antwort von einer anderen offenen Frage abhängt, gehört in eine spätere Runde. Sie jetzt zu stellen, legt den falschen Rahmen fest.

Fakten sind deine Aufgabe, niemals die des Benutzers. Wenn eine Grenzfrage einen Fakt aus der Umgebung benötigt (Dateisystem, vorhandener Code, API einer Bibliothek, ein Konfigurationswert), entsende einen Unter-Agenten, um ihn zu finden. Frage den Benutzer nicht nach etwas, das du selbst nachschlagen könntest. Blockiere die Runde nicht dafür: Die Erkundung ist eine ungeklärte Voraussetzung, also warten nur die nachgelagerten Fragen. Stelle jetzt den Rest der Grenze. Entscheidungen sind Sache des Benutzers; Fakten sind deine.

Abbruchbedingung: der Baum ist abgebildet und die erste Grenze ist identifiziert.

---

Phase 3: Rundenfragen

Frage die aktuelle Grenze ab. Formatiere jede Frage genau so:

**F1 - <Fragentitel>**: <Fragetext, möglicherweise mehrere Absätze, oft mit den dargelegten Optionen>

-> <deine empfohlene Antwort, mit der Begründung, die zu ihr geführt hat>

Regeln:

• Jede Frage nummerieren. F1, F2, ... Nummerierung pro Runde neu starten.
• Immer eine Empfehlung anhängen. Der Benutzer reagiert schneller auf eine falsche Empfehlung, als dass er eine Antwort von Grund auf generiert. Es verpflichtet dich auch zu einer Hypothese, bei der du sichtbar falsch liegen kannst.
• Auf die Antworten warten, bevor die nächste Runde gefragt wird.
• Die Grenze nach jeder Runde neu berechnen. Geklärte Entscheidungen verschieben die Grenze nach außen und entblocken Fragen, die von ihnen abhingen.
• Korrekturen notieren. Wenn der Benutzer eine Empfehlung überschreibt, dokumentiere sowohl die Entscheidung als auch die Begründung, da der Abschnitt „Technische Entscheidungen“ des PRD daraus schöpft.

Warum die Empfehlung wichtig ist, und ihre Fehlermodus:

• Der Benutzer kann in Sekunden auf eine falsche Vermutung reagieren, aber Minuten brauchen, um aus dem Nichts eine Antwort zu produzieren.
• Sie macht deine Annahmen sichtbar, was der Sinn des Interviews ist.
• Das Risiko ist Speichelleckerei — ein höflicher Benutzer stimmt deiner Vermutung zu, um gefällig zu sein. Mäßige dies, indem du sichtbar bereit bist, falsch zu liegen, und gelegentlich eine Richtung empfiehlst, von der du erwartest, dass der Benutzer widerspricht. Wenn jede Empfehlung beim ersten Versuch akzeptiert wird, vermute Speichelleckerei.

Warum eine Runde nach der anderen, nicht alles auf einmal:

• Die dritte Frage hängt oft von der Antwort auf die erste ab; alles auf einmal zu fragen legt den falschen Rahmen fest.
• Die Energie des Benutzers für sorgfältiges Denken ist begrenzt. Gib sie Runde für Runde aus.
• Ein Haufen von fünfzehn Fragen wirkt wie eine Umfrage, nicht wie ein Interview, und wird überflogen.

Abbruchbedingung: die Fragen der Runde sind beantwortet und die Grenze ist neu berechnet.

---

Phase 4: Absichtsprüfung (Wollen vs. Sollen-Wollen)

Die gefährlichsten Antworten sind die, bei denen der Benutzer sagt, was eine durchdachte Antwort klingt, anstatt was er tatsächlich will. Achte auf:

• Antworten, die auf Best-Practice-Gerede passen („Ich möchte, dass es skalierbar ist“, „saubere Architektur“) ohne Details
• Antworten, die auf Konvention verweisen („wie die meisten Apps es machen“, „der Standardansatz“)
• Formulierungen wie „Ich sollte wahrscheinlich …“, „Ich glaube, ich soll …“, „gute Ingenieurspraxis sagt …“
• Schlagwörter als Ziele – wenn „modern“, „skalierbar“ oder „robust“ die Antwort ist, anstatt eines spezifischen Ergebnisses

Wenn du eines davon hörst, frage:

„Wenn du dich vor niemandem rechtfertigen müsstest, was würdest du tatsächlich wollen?“

Diese eine Frage bewirkt oft mehr als die vorherigen fünf. Führe sie mindestens einmal durch, wenn eine sophistikationssignalisierende Antwort erscheint. Dokumentiere sowohl die genannte Antwort als auch die geprüfte Antwort – das PRD sollte die zweite widerspiegeln.

Abbruchbedingung: mindestens eine Prüfung wurde durchgeführt, wenn eine sophistikationssignalisierende Antwort erschien, und die wahre Antwort ist dokumentiert.

---

Phase 5: Absicht zurückmelden

Wenn der Baum sich fast gesetzt hat, schreibe zurück, was du jetzt denkst, was der Benutzer will. Halte es knapp, verwende seine Sprache und strukturiere es so, dass er Zeile für Zeile bestätigen oder korrigieren kann.

Hier ist, was ich jetzt glaube, was Sie wollen:

- Ergebnis:      <eine Zeile>
- Benutzer:      <eine Zeile - wer profitiert>
- Warum jetzt:   <eine Zeile - was hat sich geändert>
- Erfolg:        <eine Zeile - woher wissen wir, dass es funktioniert hat>
- Einschränkung: <eine Zeile - die bindende Grenze>
- Nicht im Fokus:<eine Zeile - was wir explizit nicht machen>

Ja / nein / verfeinern?

Regeln:

• „Nicht im Fokus“ ist nicht verhandelbar. Die Hälfte der Fehlausrichtung ist stille Uneinigkeit darüber, was nicht gebaut wird.
• Insgesamt fünf bis acht Zeilen. Wenn es länger wird, ist das Interview nicht abgeschlossen.
• Verwende nach Möglichkeit die Worte des Benutzers; sein Vokabular ist der gemeinsame Vertrag.

Abbruchbedingung: eine konkrete Rückmeldung in den Worten des Benutzers ist dokumentiert.

---

Die Stopp-Bedingung

Du bist mit dem Interviewen fertig, wenn beide dieser Bedingungen zutreffen:

1. Kannst du die Reaktion des Benutzers auf die nächsten drei Fragen vorhersagen, die du stellen würdest? Wenn ja, hast du ein gemeinsames Verständnis.
2. Ist die Grenze …

… [für die Übersetzung gekürzt]