linyindong/platform-product-skills

Platform PRD Builder

Nutzen Sie diese Fähigkeit, um grobe Eingaben in strukturierte, implementierungsreife Produktanforderungen umzuwandeln. Übersetzen Sie nicht einfach nur. Verstehen, reorganisieren, anreichern und bewahren Sie den präzisen Umfang.

Betriebsmodi

Wählen Sie den leichtesten Modus, der die Anfrage erfüllt:

• Full PRD Build: Erstellen Sie eine vollständige PRD für eine komplexe oder systemübergreifende Anforderung.
• Section Build: Schreiben Sie nur angeforderte Abschnitte wie Hintergrund, Umfang, Ablauf, API-/Datenänderungen oder Rollout.
• Rewrite / Polish: Verbessern Sie Struktur, Klarheit, Englisch oder zweisprachige Formulierungen, ohne Entscheidungen zu ändern.
• Input Normalization: Wandeln Sie verstreute Notizen in bestätigte Entscheidungen, Annahmen, fehlende Entscheidungen und technisch lesbare Sprache um, bevor Sie mit dem Entwurf beginnen.
• Template Fit: Wählen Sie den richtigen Artefakttyp, wenn die Anfrage nicht unbedingt eine vollständige PRD erfordert.
• Direction Alignment Draft: Erstellen Sie eine leichte Konzept-/Ausrichtungsversion, bevor Sie zu einer vollständigen PRD erweitern.

Erster Schritt

Identifizieren Sie kurz:

• Geschäftsszenario
• Plattformfähigkeit
• Beteiligte Systeme
• Aktuelle Phase und Ausschlüsse
• Artefakttyp: Vollständige PRD, PRD-Abschnitt, einseitiges BRD, zweisprachiger Entwurf, englische Neufassung, Tabelle oder Ablaufbeschreibung

Wenn der Benutzer nur nach Auswirkungen oder Machbarkeit fragt, erstellen Sie noch keine PRD; verwenden Sie zuerst eine Auswirkungsanalyse.

Wenn der Artefakttyp unklar ist, schlagen Sie das kleinste nützliche Artefakt vor und fahren Sie fort, es sei denn, diese Wahl würde ein Auslieferungsrisiko darstellen.

Schritt 0: Phasenerkennung

Klassifizieren Sie vor dem Entwurf die Phase des Benutzers:

• Nur Idee: Erstellen Sie zuerst einen Richtungsabstimmungsentwurf.
• Verstreute Notizen: Normalisieren Sie zuerst Entscheidungen, Annahmen und fehlende Entscheidungen.
• Umfang ungeklärt: Leiten Sie an platform-scope-checker weiter, bevor Sie Anforderungen für die aktuelle Phase entwerfen.
• Bereit zum Entwurf: Erstellen Sie die angeforderte PRD oder den Abschnitt.
• Vorhandener Entwurf: Verbessern Sie die Struktur oder leiten Sie an platform-prd-reviewer weiter, wenn der Benutzer Feedback wünscht.
• RFC-Detailanfrage: Behalten Sie die Produktsemantik in der PRD bei und leiten Sie Implementierungsdetails an das Engineering-Follow-up weiter.

Build-Challenge-Gate

Bevor Sie eine Anfrage in eine aufwändige PRD umwandeln, hinterfragen Sie kurz, ob dasselbe Geschäftsziel erreicht werden kann durch:

• vorhandene Plattformfähigkeit
• Konfiguration
• operativen Prozess oder temporäre manuelle Handhabung
• kleinere Workflow-Änderung
• gestaffelten Rollout
• Kompatibilitätsplatzhalter ohne vollständiges aktuelles Phasenverhalten

Wenn die Antwort unklar ist oder das Entwicklungsrisiko hoch ist, empfehlen Sie eine Scope-Prüfung, bevor Sie eine vollständige PRD schreiben.

Zweiphasen-Lieferung

Für mehrdeutige, 0-zu-1- oder große systemübergreifende Anforderungen bevorzugen Sie zwei Phasen:

1. Richtungsabstimmungsentwurf: Problem, Zielbenutzer/Ops, Plattformfähigkeit, Scope-Grenze, Kernablauf, Verantwortlichkeiten, Annahmen und offene Entscheidungen.
2. Detaillierte PRD: Anforderungen pro System, Feld-/API-/Datenänderungen, Zustände/Grenzfälle, Rollout/Operationen, Abnahmekriterien und Risiken.

Springen Sie nicht zur detaillierten PRD, wenn die Produktrichtung, die MVP-Grenze oder die Quelle der Wahrheit noch ungeklärt ist.

WANN NICHT VERWENDEN

Verwenden Sie diese Fähigkeit NICHT als ersten Schritt, wenn:

• das Geschäftsproblem oder der Zielbenutzer noch umstritten ist; klären Sie zuerst die Richtung mit platform-product-guide
• die Frage lautet: "Sollten wir das jetzt tun?"; verwenden Sie zuerst platform-scope-checker
• der Benutzer nur Feedback zu einem vorhandenen Artefakt wünscht; verwenden Sie platform-prd-reviewer
• die Anfrage eine reine Engineering-RFC, ein Codedesign oder ein Implementierungsplan ohne Produktanforderungsarbeit ist

PM-Eingabenormalisierer

Wenn die Eingabe vage, nicht-technisch oder als verstreute Notizen vorliegt, übersetzen Sie sie zuerst in technisch lesbare Produktentscheidungen, bevor Sie mit dem Entwurf beginnen. Verlangen Sie nicht, dass der Benutzer technisches Vokabular verwendet.

Verwenden Sie diese leichte Ausgabe, wenn Entscheidungen fehlen:

Bekannte Entscheidungen
- ...

Fehlende Entscheidungen
- ...

Technisch relevante Übersetzung
- "Benötigt Genehmigungsaufzeichnung" bedeutet, dass Entscheidungen zu Audit-Log-Feldern, Schreibzeitpunkt, Abfragezugriff und Aufbewahrung getroffen werden müssen.
- "Ein anderes System benachrichtigen" bedeutet, dass Entscheidungen zu Callback-Timing, Wiederholung, Timeout, Fehlerbehandlung und Statuskonsistenz getroffen werden müssen.

Stellen Sie geschäftssprachliche Fragen anstelle von technisch-labelnden Fragen:

• Statt "Was ist der Idempotenzschlüssel?", fragen Sie "Wenn dieselbe Anfrage zweimal eingereicht wird, soll das System einen neuen Datensatz erstellen, ihn ablehnen oder den vorhandenen zurückgeben?"
• Statt "Was ist die Callback-Wiederholungsstrategie?", fragen Sie "Wenn das empfangende System nicht benachrichtigt werden kann, was sollen Benutzer sehen, wer behebt es und wie lange kann es ungelöst bleiben?"
• Statt "Wer ist die Quelle der Wahrheit?", fragen Sie "Wenn zwei Systeme unterschiedliche Status anzeigen, welchem sollte vertraut werden?"
• Statt "Was ist die Kompatibilitätsstrategie?", fragen Sie "Werden vorhandene Datensätze oder laufende Prozesse nach dem Start beeinträchtigt?"
• Statt "Definieren Sie eine Zustandsmaschine", fragen Sie "Welche Status kann diese Anfrage von der Erstellung bis zum Abschluss haben und welche Aktionen sind in jedem Status erlaubt?"

Annahmen- und Nachweiskonto

Wenn wichtige Entscheidungen aus groben Notizen abgeleitet werden, legen Sie diese vor der Fertigstellung offen:

Annahmen
- A1: ...

Nachweis / Quelle
- E1: Aus Benutzernotiz / Prototyp / vorheriger PRD / Besprechungsnotiz / expliziter Anweisung

Benötigt Bestätigung
- C1: ...

Wandeln Sie Annahmen nicht stillschweigend in Anforderungen um. Wenn der Benutzer bittet, fortzufahren, behalten Sie ungelöste Punkte in Offenen Fragen mit Verantwortlichem/Abhängigkeit, falls bekannt.

Vorlagenauswahl

Wählen Sie die Vorlage nach Artefakttyp, anstatt eine schwere Struktur zu erzwingen.

Kurze Feature-PRD:

• Hintergrund
• Zielsetzung
• Umfang
• Anforderungen
• API-/Datenänderungen
• Grenzfälle
• Anhang / Links

API-/Feldänderungsnotiz:

• Hintergrund
• Geänderter Vertrag
• Feldtabelle
• Validierungs-/Standardverhalten
• Rückwärtskompatibilität
• Nachgelagerte Verbraucher
• Beispiele

Konfigurations-UI-PRD:

• Hintergrund
• Ziel
• Seitenpfad / Einstieg
• Listenfelder
• Filter-/Abfrageverhalten
• Erstellungs-/Bearbeitungsverhalten
• Validierungsregeln
• Berechtigung / Audit
• Anhang / Prototyp

Migrations-PRD:

• Hintergrund
• Umfang
• Quell-/Zielsysteme
• Migrationsablauf
• Datenzuordnung
• Validierungs-/Abgleichscheckliste
• Umschaltung / Rollback
• Offene Fragen

Formel-/Regellogik-PRD:

• Hintergrund
• Regelformat
• Felddefinitionen
• Verarbeitungslogik
• Beispiele
• Grenzfälle
• Rückwärtskompatibilität

Standard-PRD-Struktur

Verwenden Sie diese Struktur, es sei denn, der Benutzer gibt eine andere Vorlage an:

1. Hintergrund
2. Ziel
3. Umfang
4. Akteure / Systeme
5. Gesamtablauf
6. Ablaufdetails
7. Anforderungen pro System
8. API-/Datenänderungen
9. Szenarien & Grenzfälle
10. Rollout / Betrieb
11. Offene Fragen
12. Abhängigkeiten / Risiken

Für kurze Abschnitte behalten Sie nur die relevanten Überschriften, bewahren aber dieselbe Denkreihenfolge.

Verwenden Sie den Plattform-Ablaufmodellierer, wenn

Verwenden Sie platform-flow-modeler, bevor Sie Abschnitte zu Gesamtablauf, Ablaufdetails, Szenarien & Grenzfällen, Zustandsübergängen oder Betrieb schreiben, wenn die Anforderung 3+ Systeme, Lebenszyklus-/Statusänderungen, Callback/Wiederholung/Timeout, Rollback/Abbrechen/Erneutes Einreichen, Abgleich, Abrechnung, Migration oder manuelles Fallback umfasst.

Lassen Sie ihn zuerst Ablauf-Tabellen erstellen und konvertieren Sie dann diese Tabellen in PRD-Prosa, anforderung pro System, Szenarien, Abnahmekriterien und offene Fragen.

Ausgabevertrag

Jede PRD-artige Ausgabe sollte diese Dinge testbar machen:

• Problem und "Warum jetzt"
• Ziel der aktuellen Phase
• Scope-Grenzen
• Hauptablauf und wichtige Ausnahmeabläufe
• Noch offene Produktentscheidungen
• Abnahmekriterien oder Szenariomatrix
• Verantwortlicher/Quelle der Wahrheit für systemübergreifendes Verhalten
• Rollout, Rollback oder temporäre manuelle Handhabung, wenn relevant

Standardantwortform:

1. Kurzer Hinweis zum ausgewählten Artefakttyp, wenn nützlich
2. Entwurf des PRD-Inhalts oder des angeforderten Abschnitts
3. Annahmen und offene Entscheidungen, falls vorhanden
4. Vorgeschlagener nächster Überprüfungspfad: Scope-Prüfung, PRD-Review, RFC-Follow-up oder Stakeholder-Bestätigung

Diese Fähigkeit sollte ein Artefakt produzieren, nicht nur Beratung. Wenn das Artefakt nicht sicher produziert werden kann, geben Sie stattdessen das Konto der fehlenden Entscheidungen und die nächste Aktion aus.

Für detaillierte PRD-Vorlagen und artefaktspezifische Ausgabeverträge lesen Sie references/prd-output-contract.md, wenn die Aufgabe eine vollständige PRD, eine 0-zu-1-Plattform-PRD, eine Migrations-PRD, eine Konfigurations-UI-PRD oder eine API-/Datenänderungsnotiz umfasst.

Szenarien und Abnahmekriterien

Verwenden Sie für Abschnitte zu Szenarien und Grenzfällen Gegeben/ Wenn/ Dann-Abnahmekriterien, wenn dies die QA- und Engineering-Ausrichtung verbessert:

**Szenario: [Name]**
- Gegeben: [Vorbedingung: Systemzustand, Akteur, Daten, Konfiguration]
- Wenn: [Auslöseaktion]
- Dann: [Erwartetes Ergebnis: Endstatus, für Benutzer/Ops sichtbares Ergebnis, Downstream-Synchronisation, Audit-Aufzeichnung]

Decken Sie diese Szenariotypen ab, wenn relevant:

• Glückspfad
• Validierungsfehler: fehlendes Feld, ungültiger Wert, doppelte Einreichung
• Fehler des nachgelagerten Systems: Callback-Timeout, API-Fehler, Teilfehler
• Gleichzeitige oder doppelte Einreichung
• Grenzfall des Statusübergangs: erneute Einreichung aus Endzustand, Abbruch während des Ablaufs
• Rollback oder Rückgängigmachung
• Manuelles Fallback: Ops-Eingriff oder Ausnahme-Warteschlangeneintrag
• Berechtigungsgrenze: Akteur nicht berechtigt oder Quellsystemkonflikt

Machen Sie jede Dann-Klausel testbar. Benennen Sie den Endstatus, das für Benutzer/Ops sichtbare Ergebnis, ob nachgelagerte Systeme benachrichtigt werden und ob ein Audit-/Ereignisdatensatz erstellt wird.

Wenn die Szenariomatrix groß wäre, verwenden Sie eine kompakte Tabelle:

Szenario	Vorbedingung	Auslöser	Endstatus	Benutzer/Ops-Ergebnis	Downstream	Audit

API-/Datentabellenstil

Verwenden Sie für API- oder Datenänderungen standardmäßig Tabellen mit:

• Feld
• Datentyp / Typ
• Pflichtfeld
• Wert / Validierung
• Beschreibung
• Beispiel
• Änderungstyp: neu / vorhanden / entfernt, wenn relevant
• Verantwortlicher / Verbraucher, wenn die Zuständigkeit wichtig ist

Ergänzungen für 0-zu-1-Plattform-PRDs

Für neue Plattform-/Infrastrukturfähigkeiten fügen Sie hinzu:

• Plattformrichtung und Designprinzipien
• Konfigurationsobjekte vs. Laufzeitobjekte
• Tabelle der Verantwortlichkeiten/Quelle der Wahrheit
• Lebenszyklus/Zustandsmaschine
• Versionierungs- und Snapshot-Verhalten
• Callback-, Wiederholungs-, Timeout- und Idempotenzverhalten
• Audit-/Ereignisprotokollierung
• Berechtigung und Quellsystemisolierung
• MVP-Ausschlüsse und zukünftige Iterationen
• UI/Workspace-Modell nach Rolle, Datenbereich und Betriebsregion

Schreibregeln

• Konvertieren Sie grobe Notizen in professionelles Englisch, wenn eine englische Ausgabe angefordert wird.
• Bewahren Sie gemischte chinesisch/englische Terminologie, wenn sie reale Systemnamen oder Team-Artefakte widerspiegelt.
• Fügen Sie fehlende Erklärungen hinzu, die Leser zum Verstehen und Implementieren benötigen, aber erfinden Sie keine Geschäftsentscheidungen.
• Wenn die Eingabequalität uneinheitlich ist, normalisieren Sie sie in eine Geschäftsschicht und eine Engineering-Zusammenarbeitsschicht, bevor Sie die endgültige PRD schreiben.
• Verwenden Sie eine nummerierte Hierarchie für die Überprüfbarkeit.
• Verwenden Sie Tabellen für Felder, APIs, Verantwortlichkeiten, Szenarien, Berechnungen, Statusübergänge und offene Fragen.
• Trennen Sie Anforderungen nach System, wenn sich mehrere Systeme ändern.
• Halten Sie produktlesbare Abschnitte produktlesbar; verschieben Sie Low-Level-Details in API-/Datenabschnitte oder offene Fragen.
• Befolgen Sie bereitgestellte Prototypen oder vorhandene PRD-Strukturen, wenn der Benutzer sagt, dass die Arbeit darauf basieren soll.

Scope-Disziplin

Trennen Sie immer:

• Im Umfang
• Außerhalb des Umfangs
• In dieser Phase nicht unterstützt
• Zukünftige Iteration

Nehmen Sie Funktionen zukünftiger Phasen nicht in Anforderungen der aktuellen Phase auf, außer als explizite Ausschlüsse, Kompatibilitätshinweise oder zukünftige Iteration.

Ablauf- und Datenanforderungen

Für systemübergreifende Arbeit:

• Beschreiben Sie Erstellungs-/Abfrage-/Callback-/Aktualisierungs-/Abrechnungs-/Abgleichsabläufe getrennt, wenn relevant
• Identifizieren Sie Persistenzpunkte und Statusänderungen
• Definieren Sie Konfigurationszeitfelder getrennt von Laufzeitfeldern
• Unterscheiden Sie Snapshot-Felder von dynamisch aufgelösten Feldern
• Verwenden Sie Feldnamen sorgfältig; Singular-/Plural-Benennung kann den Umfang kodieren, wie z. B. portalCode vs. portalCodes

Leitplanken

• Behandeln Sie historische PRDs als Lern-/Referenzmaterial, es sei denn, der Benutzer bittet um eine Neufassung.
• Fügen Sie keinen irrelevanten Kontext aus früheren Projekten ein.
• Geben Sie keinen Code aus, wenn der Benutzer nach Anforderungen fragt.
• Überpolieren Sie nicht in Marketingsprache.
• Verstecken Sie keine offenen Entscheidungen; listen Sie sie klar mit Verantwortlichem/Abhängigkeit auf, wenn bekannt.

Häufige zu markierende Fehler

• Detaillierte Anforderungen entwerfen, bevor die Richtungsabstimmung bereit ist.
• Annahmen in Anforderungen umwandeln, ohne sie zu kennzeichnen.
• Aktuellen MVP mit zukünftigem Iterationsverhalten vermischen.
• Nur Seiten-/Schaltflächenverhalten schreiben, während Status, Verantwortlichkeiten und Ausnahmebehandlung implizit bleiben.
• Datenbank, Warteschlange, Wiederholungsjob oder Servicedesign in der PRD vorschreiben.
• Eine Implementierungsanfrage als produktbereit behandeln, ohne das Geschäftsziel und die Scope-Grenze zu überprüfen.

Weiterleitung

• Leiten Sie an platform-product-guide weiter, wenn Geschäftsrichtung, Plattformabstraktion oder Entscheidungsrahmen noch nicht bereit sind.
• Leiten Sie ablauflastige Abschnitte an platform-flow-modeler weiter, bevor Sie sie in PRD-Inhalt umwandeln.
• Leiten Sie an platform-scope-checker weiter, wenn die Einbeziehung der aktuellen Phase, die MVP-Größe oder die versteckte Komplexität ungelöst ist.
• Leiten Sie nach dem Entwurf an platform-prd-reviewer weiter, wenn der Benutzer Bereitschaft, Lücken oder eine Bewertung wünscht.
• Leiten Sie RFC-Level-Implementierungsfragen an das Engineering-Follow-up weiter, während Sie die Produktsemantik in der PRD behalten.

Qualitätscheckliste

Überprüfen Sie vor der Fertigstellung:

• Das Dokument erklärt, was gebaut werden soll und warum.
• Der Umfang ist explizit: im Umfang, außerhalb des Umfangs, jetzt nicht unterstützt, zukünftig.
• Anforderungen sind testbar genug für QA oder Engineering-Review.
• Systemübergreifende Verantwortlichkeiten und Quelle der Wahrheit sind sichtbar.
• Annahmen sind von bestätigten Entscheidungen getrennt.
• Technische Überlegungen werden offengelegt, ohne die Implementierung vorzuschreiben.
• Der nächste Pfad oder Überprüfungsschritt ist explizit.

Referenzen

• references/prd-output-contract.md: laden, wenn eine detaillierte Vorlage, ein artefaktspezifischer Vertrag oder eine Qualitätscheckliste benötigt wird.