linsaber1012-coder/pm-prd-to-demo

PM · PRD → Demo – Integrierter Workflow

Führe einen „Produktgedanken“ durch die gesamte Kette von „Abstimmung → Dokumentation → klickbarer Prototyp“ und erhalte einen entwicklungsfähigen PRD, eine eigenständig implementierbare Metrikdefinition sowie einen teilbaren Prototyp, der die echte Oberfläche eines Basis-Repositorys wiederverwendet. Dieser Workflow ist hostunabhängig (Claude Code / Codex / Cursor / Gemini – alle verwendbar); Hinweise zur Portabilität findest du im Abschnitt „Host-Adaption“.

Wann verwenden

• Der Nutzer agiert als Produktmanager und möchte Deliverables wie PRD / Metrikdefinition / Interaktionsentwurf erstellen.
• In der Regel handelt es sich um Verbesserungen an einem bestehenden Repository oder System, dessen reale Struktur wiederverwendet werden soll.
• Es wird gewünscht, gleichzeitig einen ersten, klickbaren, teilbaren Prototyp zur Unterstützung von Reviews zu sehen.

Nicht geeignet: reine Code-Implementierungsaufgaben, kleine Änderungen an ein oder zwei Zeilen, Arbeiten ohne Produktentscheidungskomponente.

Was wird produziert

1. PRD.md – die einzige Quelle der Wahrheit (Was wird gemacht / für wen / Umfang / Risiken / detaillierte Seiten- und Interaktionsbeschreibungen).
2. Metrikdefinition.md – ein vollständig in sich geschlossenes Metrikdokument; der Entwickler kann jede Metrik/Regel allein daraus implementieren.
3. Teilbarer, eigenständiger HTML-Prototyp – links = Zieloberfläche (echte UI des Basis-Repositorys + deine Änderungen, Mock-Daten müssen gekennzeichnet sein), rechts = vollständiges PRD-Panel.

---

Disziplinen, die durch alle drei Phasen gelten (nicht verhandelbar)

1. Null Erfindungen, alles basiert auf Belegen: Metriken müssen auf Quellcode / offiziellen Dokumenten / Benutzerbestätigungen basieren; wenn etwas nicht gefunden wird, wird es klar kommuniziert, nicht vorgetäuscht; Mock-Daten müssen explizit gekennzeichnet werden.
2. Null Emojis: Dokumente und Prototyp verwenden keinerlei Emojis / Status-Icons; Status werden ausschließlich als Text-Labels angegeben (z. B. beibehalten / aktualisiert / neu / nicht getestet / zu prüfen).
3. Schreiben → adversarialer Review-Zyklus: Jedes Deliverable wird zuerst geschrieben, dann aus der Perspektive eines „strengen Senior-PMs“ überprüft, gemäß den identifizierten Problemen überarbeitet, und der Zyklus wiederholt sich, bis es bestanden ist (Review-Prompt siehe prompts/reviewer-agent.md).
4. Konsistenz über alle Artefakte hinweg: PRD ↔ Metrikdefinition ↔ Prototyp müssen in allen Metriken und Aussagen übereinstimmen; verwaiste Elemente oder Widersprüche werden sofort behoben.
5. Anpassung an den Interaktionsstil des Nutzers: Manche Nutzer bevorzugen Dialoge, andere Optionen; nach einer Ablehnung wird die Methode gewechselt, nicht dieselbe Methode aufgezwungen.
6. Keine Umsetzung ohne festgelegte Entscheidungen: Vor der Erstellung von Dokumenten werden die Kernentscheidungen geklärt; bei unklaren Zielen wird die Diskussion gestoppt, nicht geraten.
7. Entfernen von KI-typischem Schreibstil (Humanisierung): Der Fließtext wird natürlich, direkt und wie von einem Menschen geschrieben formuliert; typische KI-Merkmale werden vermieden (übermäßige Gedankenstriche, „nicht nur X, sondern auch Y“, leere Parallelismen / Drei-Satz-Floskeln, übermäßige Absicherung, schwülstige Verzierungen, richtige Worthülsen). Es kann das lokale humanizer-Skill oder references/writing-style.md (Zusammenstellung von stop-slop / Humanizer-zh / blader-humanizer) herangezogen werden. Hinweis: Fachliche Präzision bleibt erhalten – Humanisierung bedeutet nicht, Genauigkeit zu opfern oder Floskeln einzubauen.

---

Phase 0 · Interaktive Anforderungsermittlung und Entscheidungsfestlegung

Ziel: Die echten Gedanken, Anforderungen und Randbedingungen des Nutzers erfassen und klar strukturieren, Kernentscheidungen festlegen – dieser Schritt erfolgt interaktiv zwischen KI und Mensch, die KI trifft keine Entscheidungen für den Nutzer.

1. Bestehende Assets durchforsten: Lies das vom Nutzer bereitgestellte Repository / die Dokumente / die reale Struktur des alten Systems (falls der Host paralleles Durchsuchen unterstützt, parallel; andernfalls einzeln). Verstehe, was es tatsächlich tut und welche wiederverwendbaren Komponenten es gibt.
2. Anforderungen interaktiv klären: Hilf dem Nutzer durch Fragen, vage Gedanken in klare Entscheidungen zu überführen – typische zu klärende Punkte: Auswahl des Basisrepositorys, Umfang (in/out), gewünschte Metriken/Funktionen, Darstellung/Informationsarchitektur, klare Nicht-Ziele. Stelle jeweils einige wenige Schlüsselfragen, nicht alles auf einmal.
3. Entscheidungsdokument erstellen: Halte die getroffenen Entscheidungen in einem kurzen „Entscheidungs-/Planungsdokument“ fest, das als Eingabe für Phase 1 dient.

Austrittskriterium: Alle Kernentscheidungen sind klar beantwortet und vom Nutzer bestätigt.

Phase 1 · PRD und Metrikdefinition erstellen

Ziel: Zwei entwicklungsfähige Dokumente.

1. Vorlage prüfen: Siehe references/prd-checklist.md (vollständige Liste für die Praxis in China + Anpassung nach Projekttyp). Bestimme, welche Abschnitte für dieses Projekt erstellt werden müssen und welche ausgelassen werden können.
2. Schreiben: Befolge prompts/writer-agent.md, um PRD und Metrikdefinition zu verfassen. Wesentliche Punkte:
   • PRD umfasst: Hintergrund/Ziele/Erfolgsmetriken/Umfang/Risiken/Funktionsstruktur + Informationsarchitektur + Flussdiagramme (Mermaid möglich)/Detaillierte Frontend-Darstellung und Interaktion jeder Seite (feldebene)/Glossar/Globale Regeln/Stakeholder.
   • Metrikdefinition vollständig in sich geschlossen: Der gesamte Metrik-Wortlaut wird inline angegeben; kein Verweis auf „siehe anderes Dokument“; der Entwickler kann es allein daraus umsetzen.
3. Review: Verwende die prompts/reviewer-agent.md mit der Persona „Senior-PM“ für einen adversarialen Check (Vollständigkeit / Ausführbarkeit / Konsistenz mit Quellcode / Umfang und Nicht-Ziele / Risiken / Null Emojis / Keine toten Links / Artefakt-übergreifende Konsistenz).
4. Überarbeitung abschließen: Ändere gemäß den zwingenden Punkten des Reviews, wiederhole bis bestanden.
5. Checkliste abarbeiten: Vor Auslieferung Punkt für Punkt gegen references/pitfalls.md selbst prüfen (dies sind die aus früheren Fehlern abgeleiteten Prüfpunkte).

Phase 2 · Teilbaren Prototyp erstellen

Ziel: Ein klickbarer Prototyp mit links = Zieloberfläche, rechts = vollständigem PRD; das Design folgt treu der festgelegten Quelle (Referenzentwurf / Basis-Repository / Wettbewerber, siehe unten). Harte Regeln siehe references/prototype-guardrails.md.

1. Designquelle bestimmen (nach Priorität):
   • ① Der Nutzer hat einen Referenzprototyp / Designentwurf bereitgestellt → Dieser dient als Grundlage; Design wird originalgetreu umgesetzt.
   • ② Es wird auf einem bestehenden Basis-Repository verbessert → Klone / lese dessen Frontend, extrahiere echte Design-Token und Layouts (Farben / Hell-Dunkel / Seitenleiste vs. Top-Leiste / Karten / echte Felder und Tabellenspalten der Ansichten), kopiere ohne eigene Erfindungen.
   • ③ Keines von beidem → Die KI erstellt selbstständig ein Design und wählt ähnliche Produkte / Wettbewerberseiten als Referenz, mit Erläuterung, worauf Bezug genommen wurde und warum.
2. Eigenständiges HTML erstellen: Einzeldatei, links = Zieloberfläche (Basis-Repository-Treue + deine Änderungen, Mock-Daten müssen gekennzeichnet sein), rechts = vollständiges PRD-Panel (verwende einen minimalistischen Markdown-Renderer, um den PRD inline einzubetten).
3. Eigenständig / CSP-sicher: Alle CSS/JS inline, keine externen CDN/Schriftarten/Symbole; Dinge, die nicht live gerendert werden können (z. B. bestimmte Bildbibliotheken), müssen ehrlich als Einschränkung gekennzeichnet werden und auf eine lesbare Darstellung zurückfallen.
4. Veröffentlichen und iterieren: Veröffentliche als teilbaren Link; bei Änderungswünschen des Nutzers ändere sowohl Prototyp als auch PRD synchron, veröffentliche erneuert unter demselben Link.

---

Checkliste vor Auslieferung (Zusammenfassung, vollständig in references/pitfalls.md)

• Null Emojis (auch in Knotenbeschriftungen von Diagrammen/Codeblöcken)
• Keine Erfindungen: Zahlen/Metriken sind auf Quellen rückführbar; Mocks gekennzeichnet
• Metrikdefinition in sich geschlossen, keine „siehe anderes Dokument“-Verweise
• Metriken und Aussagen konsistent über alle Artefakte, keine verwaisten Elemente oder Widersprüche
• Prototyp-Design folgt treu der festgelegten Quelle (Referenzentwurf falls vorhanden; bei Basis-Repository Token kopieren; sonst Wettbewerber als Referenz mit Erklärung), keine spontanen Erfindungen
• Zusammengesetzte/Gesamtpunktzahlen haben explizite Formeln und Bestandteile
• Alles, was nicht gerendert / nicht getestet / unbekannt ist, wird ehrlich gekennzeichnet, nicht als Tatsache dargestellt

---

Host-Adaption (Portabilität)

Der Haupttext dieser SKILL.md besteht aus hostunabhängigen, natürlichen Anweisungen, die jedes LLM befolgen kann. Drei Unterschiede werden außerhalb des Haupttextes gelöst:

• Laden/Triggern: Siehe README.md für Installations- und Aufrufmethoden jedes Hosts (Claude Code: Skill-Verzeichnis; Codex: über sein Skill-/AGENTS.md-Referenz; Cursor/Gemini: eigene Pfade).
• Fähigkeitsreduzierung: Wo von „Unter-Agent für Review/Erkundung“ gesprochen wird: Falls der aktuelle Host keine Unter-Agents unterstützt, führe das gleiche Review/Erkundung selbst durch, ohne die Disziplinen zu ändern.
• Tool-unabhängig: Der Haupttext beschreibt nur Aktionen (Internet suchen, Repository lesen, Dateien schreiben, Prototyp veröffentlichen), ohne konkrete Tool-Namen zu nennen; jeder Host bildet auf seine eigenen Werkzeuge ab.

Beiliegende Ressourcen

• references/prd-checklist.md – PRD-Komponentenliste + Anpassung nach Projekttyp
• references/prototype-guardrails.md – Harte Regeln für Prototypen
• references/pitfalls.md – Checkliste aus Fehlern
• references/writing-style.md – Regeln zur Humanisierung / KI-typischen Stil vermeiden (Zusammenstellung von stop-slop / Humanizer-zh / blader-humanizer + lokales humanizer-Skill)
• prompts/writer-agent.md – Prompt-Vorlage für den Schreib-Agent
• prompts/reviewer-agent.md – Senior-PM-Review-Agent-Persona + Prüfpunkte
• templates/prd-skeleton.md / templates/metric-spec-skeleton.md – Grundgerüst-Vorlagen