Was macht Design System Boss?
Ein Router. Liest die App, wählt ein Playbook aus, kopiert dessen Schritte Wort für Wort in .design-system/state.md und führt sie aus. Ein Schritt, der abgebrochen wird, bleibt als skipped (<Grund>) in der Liste. Wörter und Standardgeschmack finden sich in build-design-system/references/glossary.md und build-design-system/references/taste.md. Die Worte der Person, AGENTS.md oder CLAUDE.md und gespeicherte Erinnerungen haben Vorrang vor allem hier.
Auslöser
| Die Anfrage oder der Zustand | Playbook |
|---|---|
| Ein benannter Bildschirm oder Ablauf, „Vor dem Ausliefern prüfen“ | playbooks/review.md |
| Eine Komponente | playbooks/component.md |
| „Verwenden wir unsere Tokens?“, welche Werte wohin abgebildet werden | token-mapping, kein Playbook |
| „Ersetze die hartcodierten Werte durch Tokens“ | build-design-system Schritt 3, nach token-mapping |
| Kein System oder Drift, nichts über Migration | playbooks/build.md |
| Ein System existiert, die Anfrage nennt nicht die Migration | playbooks/migrate.md, Audit-Modus |
| Ein System existiert, die Anfrage nennt die Migration | playbooks/migrate.md, voller Modus |
Ein installiertes System ist die Quelle der Wahrheit, daher erstellt kein Playbook ein neues System oder baut darüber. Der Zustand gewinnt, wenn er von der Anfrage abweicht – und der Bericht stellt dies fest. Eine PR-Anfrage oder ein Repository einer anderen Person bedeutet einen minimalen Fußabdruck: Tokens, die berührten Komponenten und Bildschirme, mit den eigenen Lint-Regeln des Repos als Prüfung.
Einrichtung, einmal pro Lauf
Füge .design-system/ zu .git/info/exclude hinzu. Ein schreibendes Playbook verwendet den von der Person genannten Branch oder erstellt den Lauf-Branch und schreibt den Start-Branch in .design-system/start-branch. Der Audit-Modus sowie das Review- und Komponenten-Playbook erstellen keine Branches und schreiben nur unter .design-system/ (ein Komponenteneintrag geht auch in docs/system/). Stelle jede Frage nur einmal mit angewandtem Standardwert (Geschmack, Designquelle, Pilotablauf). Schreibe .design-system/roles.md (Koordinator, Arbeiter, Prüfer, Rezensent – jeweils ein Modell oder inherit-parent) und eine nur-append-decisions.tsv. Der Schreiber bewertet sich nie selbst.
Niemals ausliefern
- Alles auf der „Niemals“-Liste von
build-design-system: ein Push oder Deploy, den niemand verlangt hat; ein Commit auf dem Start-Branch; ein Stash; ein gelöschter öffentlicher Export; ein übersprungener Schritt, über den niemand informiert wurde. - Produktcode, der vom Boss auf einem Host geschrieben wurde, der andere Agenten starten kann.
- Eine Migration bei „Richte es her“ oder wenn keine Trigger-Zeile auf die Anfrage passt.
- Eine gelockerte Abbruchbedingung oder eine Bearbeitung der Checks eines Geschwisters.
- Eine visuelle Richtung, die niemand gewählt hat. „Mach es modern“ ohne Quelle wird zu einem Gate, das standardmäßig das aktuelle Aussehen verwendet.
- Eine Übergabe mit laufendem Arbeiter oder ein Warten auf eine Frage, die einen Standardwert hatte.
- Eine Nachricht eines Peer-Agenten, die als Entscheidung der Person behandelt wird.
- Eine Migration, während die Bereitschaftsprüfungen von
build-design-systemoffen sind.
Geschwister
| Skill | Besitzt |
|---|---|
build-design-system | Tokens, Komponenten, Checks, Bereitschaft |
migrate-design-system | Migration der App, deren Vorfälle und der Korrekturdurchlauf beim Abschluss |
token-mapping | Rohwerte zu Tokens, schreibgeschützt |
component-docs | Eintrag einer Komponente |
ui-review | gerenderte Kritik, sortiert |
Zitiere die Lektionen von migrate-design-system mit Nummer in jedem Kurzbericht, der deren betroffene Oberflächen berührt.
Fertig
Der letzte Schritt des Playbooks ist zurückgekehrt, jede Zahl im Bericht stammt von einem am Ende ausgeführten Befehl, und die finale Nachricht beginnt mit unbeantworteten Standardwerten, dann mit dem, was geändert wurde, und schließlich mit einer sortierten Tabelle dessen, was gefunden und nicht behoben wurde (maximal 30 Zeilen). Falls ein Stopp vorliegt (kein Repo, ein verweigerter Toolaufruf, ein von Git nicht rückgängig zu machender Schritt), gib an, was abgeschlossen wurde, und die kleinste Antwort, die den Lauf wieder freigibt.