r3xsean/design-process

Designprozess

Der Benutzer bestimmt die Richtung und den Geschmack. Modelle bewerten die Ausführung: ob die Aufgabe machbar ist, ob die Zahlen stimmen, ob etwas kaputt geht, versteckt oder in die Irre führt. Eine Bewertung, ein Review oder ein Modellkonsens wählt niemals zwischen Richtungen, führt sie zusammen oder hebt eine protokollierte Entscheidung auf.

Wenn das Projekt eine eigene Design-Skill-Datei hat, folgen Sie dieser; sie könnte Sie für eine Phase hierher zurückschicken.

Die Dateien des Projekts

In docs/design/, sofern die AGENTS.md des Projekts keinen anderen Ort für diese Dateien benennt:

• product-brief.md: Die Produktwahrheit. Wer es nutzt, was jede Oberfläche ihnen ermöglichen muss (ihre Leitfrage und ihr Modus: Operate, Read oder Persuade), Daten und Zustände, Text und Vertrauensgrenzen. Wenn das Projekt bereits eine PRODUCT.md hat, verlinkt das Briefing darauf, anstatt es zu wiederholen.
• DESIGN.md: Die Entscheidungen des Benutzers, Ausnahmen, genehmigte Referenzbildschirme und das Reaktionsprotokoll. Eine protokollierte Entscheidung hat Vorrang vor Ihrer Präferenz. Wo keine protokolliert ist, ist das Aussehen offen; die aktuelle Benutzeroberfläche ist ein Beleg, keine Entscheidung.
• harness.md: Wie Bildschirme und Prototypen ausgeführt und erfasst werden: Befehle, Szenarien, Viewports, die Konkurrenz-Apps, wo die Aufnahmen landen.
• runs/<YYYY-MM-DD-Name>/run.md: Die Frage eines Runs, was festgelegt und was offen ist, bekannte Einschränkungen, Mitglieder des Reviews und Ziel, der Standpunkt-Schlüssel, das Ergebnis.

Vorlagen für alle vier Dateien befinden sich in templates/. Wenn eine der ersten drei Dateien fehlt, führen Sie zuerst das Bootstrap durch. Jeder Run, auch einer, der das Bootstrap überspringt, startet seine eigene run.md. Aufnahmen, Manifests, Ergebnisprotokolle und Variantenblätter werden in dem von harness.md benannten, git-ignorierten Ordner abgelegt. Review-Pakete werden außerhalb des Repos, im Scratchpad oder Temp-Ordner der Sitzung abgelegt.

Die eigenen Regeln des Projekts haben Vorrang vor diesem Skill: seine AGENTS.md bezüglich Abhängigkeiten, Entwicklungsservern und was committet wird. Wenn der Run etwas benötigt, das diese Regeln verbieten oder für eine Diskussion reservieren, fragen Sie den Benutzer, bevor Sie es tun.

Ablauf

• Neue Benutzeroberfläche: Bootstrap → Erkunden → Der Benutzer wählt aus → Verfeinern → Review → Genehmigung einer Referenz → Holdout → Ausliefern über den Rollout-Pfad des Projekts.
• Bestehende Benutzeroberfläche: Bootstrap → Review → Genehmigen → Ausliefern. Wenn der Benutzer zuerst sichtbare Änderungen wünscht, verfeinern Sie vor dem Review.

Treten Sie in der Phase ein, die die Anfrage nennt; eine kleine Anpassung tritt in der Verfeinerungsphase ein.

Phase	Zuerst lesen
Bootstrap	references/bootstrap.md, dann references/harness-contract.md für jede Fähigkeit, die der Run benötigt
Erkunden	references/explore.md
Verfeinern	references/refine.md, und references/craft.md vor der ersten UI-Bearbeitung
Review	references/council.md
Verwendung einer anderen Design-Skill-Datei	references/integrations.md, vor dem Aufruf

Mitglieder des Reviews. Wenn der Run das Review erreicht, fragen Sie den Benutzer zu Beginn, wer daran teilnimmt (Modell und Reasoning-Aufwand jedes Mitglieds), es sei denn, er hat sie bereits benannt. Schlagen Sie Mitglieder von verschiedenen Anbietern vor. Protokollieren Sie die Mitglieder in run.md und verwenden Sie genau diese für den gesamten Run. Wenn ein Mitglied nicht verfügbar ist, sagen Sie das; ersetzen Sie es niemals.

Genehmigen einer Referenz. Nur die Worte des Benutzers genehmigen einen Bildschirm; Bewertungen zählen nie. Kopieren Sie seine Aufnahmen in docs/design/references/ und listen Sie sie in der DESIGN.md unter „Referenzbildschirme“ auf, wobei Sie angeben, wofür jeder die Referenz ist.

Holdout. Nach der ersten genehmigten Referenz entwirft ein neuer Agent eine Oberfläche, die noch nicht entworfen wurde, allein auf Basis dieses Skills, der Projektdateien und der Testumgebung, und listet jede Stelle auf, an der er raten musste. Zeigen Sie dem Benutzer das Ergebnis. Beheben Sie jede Annahme in der Datei, die sie hätte beantworten sollen, oder protokollieren Sie sie in run.md als offen. Abgeschlossen, wenn der Benutzer reagiert hat und jede Annahme behoben oder protokolliert ist.

Reaktionen protokollieren

Immer wenn der Benutzer auf ein Design reagiert, in jeder Phase:

1. Fügen Sie eine Zeile zum Reaktionsprotokoll der DESIGN.md pro Reaktion hinzu: Datum (UTC), Oberfläche und Viewport, welches Design und welcher Aufnahme-Run, die Worte des Benutzers wörtlich zitiert, Typ, Umfang, Status observed.
   • Typ: like (beibehalten), dislike (ändern) oder defect (eine Aufgabe fehlgeschlagen oder etwas kaputt; auch zum Ergebnisprotokoll hinzufügen). Eine Reaktion kann einen Teil mögen und einen anderen ablehnen; benennen Sie jeden Teil. Eine noch nicht gebaute Funktion ist keine Reaktion: Listen Sie sie unter den bekannten Einschränkungen in run.md auf.
   • Umfang ist das, was der Benutzer angegeben hat: dieses Element, dieser Oberflächentyp oder seitenweit. Wenn er nichts angegeben hat, ist es das Element. Weiten Sie ihn niemals selbst aus.
   • Was Sie als Antwort geändert haben, steht im Ergebnisprotokoll, nicht in der Zeile.
2. Stufen Sie eine Zeile zu einer Entscheidung hoch, wenn der Benutzer sie allgemein formuliert. Wenn dieselbe Reaktion auf einer zweiten Oberfläche auftritt, fragen Sie, ob sie allgemein gilt, und stufen Sie sie nur bei „Ja“ hoch. Markieren Sie die Zeile als promoted mit einem Link.
3. Wenn eine Reaktion einer Entscheidung widerspricht, fragen Sie, welche gewinnt, bearbeiten oder entfernen Sie dann die alte Entscheidung und markieren Sie die unterlegenen Zeilen als superseded.

Abgeschlossen, wenn jede Reaktion eine Zeile hat und jede Hochstufung die allgemeine Aussage des Benutzers oder sein „Ja“ zitiert.

Datenschutz

Aufnahmen verwenden Fixture-Daten, Seed-Daten oder ein Demokonto, niemals das eigene Konto des Benutzers oder echte Personenaufzeichnungen. Nichts, das personenbezogene Daten oder Erwachseneninhalte zeigt, darf in ein Review-Paket, eine Referenzaufnahme oder einen Commit gelangen.