Frontend-Projekt-Bootstrap
Den von UI/UX gelieferten Prototypen in ein „teameigenes Frontend-Projekt + ausgefüllte Dokumente + startbereite Aufgabenliste“ umwandeln, sodass später von verschiedenen Personen und Coding-Agenten geschriebener Code wie von einer Person aussieht.
Version: Siehe obersten Eintrag in CHANGELOG.md.
Kernprinzipien
- Der Prototyp ist Anforderungsmaterial, kein in das Projekt zu kopierender Code. Extrahiere Screenshots, Daten, Farbpaletten und Interaktionen daraus, kopiere aber nicht die Implementierung; lege die Originaldateien und Screenshots im Repo als Abnahmekriterien ab.
- Teamstandards werden unverändert kopiert, Projektinhalte werden gemäß Prototyp ausgefüllt. Die beiden Dateitypen werden unterschiedlich behandelt (siehe „Datei-Index“ unten).
- Bei Unsicherheit nachfragen, nicht raten. Stelle Fragen in Pausen schrittweise mit jeweils einem Lösungsvorschlag; ein „Ja“ bedeutet Annahme des Vorschlags.
- Keine Geschäftslogik implementieren. Dieses Skill erstellt nur das Skelett, leere Seiten und Dokumente; die Geschäftslogik wird später anhand der Aufgabenliste von
/implemententwickelt. - Erst nach Validierung ist es fertig. Lint, Typecheck, Test und Build müssen grün sein, es dürfen keine Platzhalter mehr vorhanden sein, und jeder Bildschirm muss einen Screenshot haben.
Erforderliche Eingaben
- Prototyp (einzelnes HTML, mehrseitiges HTML, Link zu einer Designdatei oder Screenshots) sowie seine Version / sein Lieferdatum
- Projektname und ein Satz Beschreibung
- Ordnerpfad für das neue Projekt (muss ein leerer Ordner oder ein neues Repo sein; bei vorhandenem Inhalt vorher anhalten und nachfragen)
Weitere Informationen (Bereitstellungsumgebung, Backend-Status, Sprachauswahl, Dark Mode) werden in Schritt 1 abgefragt; Details siehe references/workflow-detail.md.
Vorbereitung (einmal pro Maschine)
cd <skill> && npm ci && npx playwright install chromium # Playwright und Prettier für scripts/; nicht im Projektskelett
# Wenn Chromium bereits auf der Maschine vorhanden ist, kann der Download entfallen; beim Ausführen des Screenshot-Skripts dann CHROMIUM_EXECUTABLE=<Pfad> verwenden
Ablauf
Erstelle eine Aufgabenliste, um die folgenden fünf Schritte zu verfolgen; hake jeden Schritt nach Abschluss ab.
Schritt 1: Eingang
Prüfe zuerst, ob der Projektordner nicht existiert oder leer ist (bei vorhandenem Inhalt anhalten und nachfragen). Bestätige dann die Prototyp-Datei, die Version und den gemeinsamen Ablageort des Teams und frage die in der Tabelle von Schritt 1 in references/workflow-detail.md genannten Punkte ab, die noch nicht in der Nachricht enthalten sind.
Schritt 2: Prototyp analysieren und Screenshots erstellen
Lies references/prototype-analysis.md und analysiere gemäß der dortigen Methode. Erstelle docs/_bootstrap/prototype-analysis.md (Format: templates/prototype-analysis.md). Wenn der Prototyp HTML ist, lege die Originaldatei gleichzeitig in docs/prototype/ ab, fülle docs/prototype/screens.json (Format: templates/prototype-screens.json) aus und führe das Screenshot-Skript aus, um PNGs jedes Bildschirms zu erstellen.
⏸ Pause: Stelle gemäß den „Pausen“ in references/prototype-analysis.md schrittweise Fragen: Zu klärende Punkte, Standardvorgehen bei fehlenden Statusangaben, Routing-Modus (history / hash), Backend-Status. Trage die Antworten in den Abschnitten 11 und 12 der Analysedatei ein, bevor du fortfährst.
Schritt 3: Skelett erstellen
Kopiere assets/skeleton/ (exklusive node_modules), führe npm ci aus, und ändere dann gemäß Schritt 3 von references/workflow-detail.md die Namen, Farbpaletten, den Routing-Modus, Routen und Menüs, leere Seiten und Berechtigungscodes. Behalte die Item-Beispielfunktion, bis die erste echte Funktion fertig ist.
Schritt 4: Dokumente erstellen
Kopiere und fülle gemäß der Tabelle in Schritt 4 von references/workflow-detail.md aus. Fülle alle <!-- FILL: --> gemäß den Anweisungen aus und entferne die Kommentare. Ersetze alle {{PLACEHOLDER}}. Schreibe „noch zu klären“, wenn du es nicht weißt, erfinde nichts.
Schritt 5: Validieren, committen und berichten
npm run lint && npm run typecheck && npm test && npm run build
node <skill>/scripts/check-placeholders.mjs <project>
Erst wenn alle vier Prüfungen grün sind (Lint ohne Warning) und das Prüfskript 0 Fehler meldet, ist der Schritt abgeschlossen. Führe dann den ersten Commit durch.
Berichtsformat siehe Schritt 5 von references/workflow-detail.md.
Wenn der Benutzer nicht anwesend ist: Verwende bei Vorschlägen den Vorschlag und kennzeichne ihn mit „Vorschlag angenommen (vorläufig)“; schreibe bei fehlendem Vorschlag „noch zu klären“ und fahre normal fort; beides wird im Bericht aufgeführt. Der einzige Fall, in dem angehalten werden muss, ist, wenn der Projektordner bereits Inhalt hat.
Datei-Index
Unverändert kopieren (nur Namen ersetzen, Inhalt nicht umschreiben)
| Pfad | Kopieren nach | Inhalt |
|---|---|---|
assets/skeleton/ | Projektwurzel | Ausführbares Skelett: Konfigurationsdateien, API-Schicht, Daten-Hooks, DataBoundary, Berechtigungen, i18n, Theme, MSW, Tests, CI (Azure DevOps), PR-Vorlage, Item-Beispielfunktion |
references/standards/ | docs/conventions/ | 18 Team-Entwicklungsstandards + Index |
references/adr-baseline/ | docs/adr/ | ADR 0001–0016 + Index |
templates/agents/ | docs/agents/ | Mattpocock-Skills-Tracker und Domain-Docs-Konfiguration (lokales Markdown, Single-Context) |
Gemäß Prototyp ausfüllen
| Vorlage | Ausgabe |
|---|---|
templates/prototype-analysis.md | docs/_bootstrap/prototype-analysis.md |
templates/prototype-screens.json | docs/prototype/screens.json (Eingabe für Screenshot-Skript) |
templates/README.md、AGENTS.md、ARCHITECTURE.md、GLOSSARY.md | Projektwurzel |
templates/CLAUDE.md | Projektwurzel (Adapter für Claude Code: einzeiliger Erklärungskommentar plus @AGENTS.md, unverändert kopieren) |
templates/prototype-README.md | docs/prototype/README.md |
templates/adr-router-mode.md | docs/adr/0017-router-mode.md |
templates/api-interface-auth.md、api-interface.md、api-checklist.md | docs/api/ |
templates/feature-spec.md | docs/specs/<feature>.md |
templates/task.md、tasks-README.md、task-remove-example.md | docs/tasks/ |
templates/adr.md、bug-report.md etc. | Zusätzlich eine Kopie in docs/templates/ für die spätere Verwendung |
Anleitungen und Werkzeuge
| Pfad | Wann lesen? |
|---|---|
references/workflow-detail.md | Konkrete Vorgehensweise, Befehle und Dateizuordnung für jeden Schritt |
references/prototype-analysis.md | Schritt 2 |
scripts/screenshot-prototype.mjs | Schritt 2 (auch bei Prototyp-Änderungen erneut ausführen) |
scripts/check-placeholders.mjs | Schritt 5 |
Anbindung an mattpocock skills
Die Ausgabe dieses Skills ist die Eingabe für mattpocock/skills; das Projekt muss nicht erneut /setup-matt-pocock-skills ausführen (falls doch, wird nur der Abschnitt ## Agent skills in AGENTS.md und docs/agents/ aktualisiert; lass es nicht in CLAUDE.md schreiben).
| Sein Skill | Entsprechung hier |
|---|---|
/grill-with-docs、grilling | Die Pausen in Schritt 2 sind dieselbe Art von Interview; bei späteren Designänderungen direkt verwenden, Fachbegriffe in GLOSSARY.md, Entscheidungen in docs/adr/0018+ |
domain-modeling | Liest und schreibt GLOSSARY.md (gleiches Format) und docs/adr/ (Teamformat, siehe docs/agents/domain.md) |
/to-spec、/to-tickets | Nicht erforderlich. Spezifikationen sind bereits in docs/specs/ (Gherkin-nummeriert), Aufgaben bereits in docs/tasks/ (mit geschichteten Dateipfaden und wiederverwendbaren Komponenten) |
/implement | Implementierungsweise der ersten Version: ein Task pro docs/tasks/<ID>-*.md, Branch von main aus mit Aufgabenliste; es ruft tdd und code-review auf |
tdd | Seams sind bereits in AGENTS.md unter „Test-Seams“ definiert, keine weitere Diskussion nötig |
/implement-spec | Nutzbar, aber noch nicht getestet: Jeder Worktree benötigt npm ci (husky prepare), Azure DevOps hat keine Draft-PR-Integration |
Agent-Tool-Kompatibilität
AGENTS.md ist die einzige Regelquelle. opencode und Kimi Code CLI lesen direkt die AGENTS.md im Projektstammverzeichnis; Claude Code liest CLAUDE.md, daher enthält das Skelett eine Adapterdatei, die nur @AGENTS.md enthält. Schreibe keine zusätzlichen Regeln in die Adapterdatei.
Dieses Skill aktualisieren
Wenn sich Teamstandards ändern, ändere dieses Skill (Standards, ADR-Baseline, Skelett gemeinsam), dokumentiere die Änderung in CHANGELOG.md und erhöhe die Version. Ändere nicht nur in einzelnen Projekten. Abweichungen in einzelnen Projekten werden als deren ADR (ab 0017) dokumentiert.
Nach einer Änderung am Skelett muss in assets/skeleton/ mindestens ein Lint, Typecheck, Test und Build durchlaufen werden; nach einer Änderung an Markdown-Dateien führe npm run format aus.