Communitygithub.com

Design & Engineering Standards Lead

Nutze diese Fähigkeit nach dem System-Architekten, um aus specs/PRD.md, specs/ARCHITECTURE.md, specs/DATABASE.md und specs/SECURITY.md die Spezifikationen specs/DESIGN_SYSTEM.md, specs/CODE_STYLE.md und specs/TESTING.md zu generieren. Unterstützt sowohl TypeScript- als auch Python-Stacks, Headless/CLI-Produkte und LLM-Evaluierungs-Harnesses.

Was ist Design & Engineering Standards Lead?

Diese Fähigkeit fungiert als leitender Frontend-Architekt und Principal Quality Engineer, der operative Spezifikationen aus bestehenden Anforderungsdokumenten erstellt. Sie ist ideal für Entwickler, die ein klares, standardisiertes Regelwerk für Design, Codestil und Tests benötigen, um Konsistenz und Qualität in agilen oder KI-gestützten Entwicklungsworkflows sicherzustellen. Die Fähigkeit unterstützt sowohl TypeScript- als auch Python-Stacks sowie headless/CLI-Produkte und LLM-Evaluierungs-Harnesses. Sie generiert drei Dateien: `specs/DESIGN_SYSTEM.md` (UI-Tokens, Typografie, Komponentenzustände, Barrierefreiheit oder CLI-Ergonomie), `specs/CODE_STYLE.md` (Verzeichnisstruktur, Namenskonventionen, Linting/Formatierung, Fehlerbehandlung) und `specs/TESTING.md` (Test-Runner-Befehle, Datenbank-Isolation, Mocking-Richtlinien, Abnahmetest-Matrix). Die Fähigkeit interagiert mit dem Benutzer durch gezielte Fragen zu UI-Primitiven, Linting-Stacks und Test-Harnesses, bevor sie die endgültigen Dateien mit granularen Sub-IDs erstellt, die eine präzise Nachverfolgung von Aufgaben ermöglichen. Ein Qualitäts-Gate stellt sicher, dass alle CLI-Befehle korrekt sind und jede Akzeptanzbedingung abgedeckt ist.

Funktioniert mit~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/nizaalkhot/skills/tree/HEAD/skills/design-and-standards-lead
Original anzeigen→Alle Skills durchsuchen

In Ihrer bevorzugten KI fragen

Öffnet einen neuen Chat, in dem dieser Agent-Skill bereits geladen ist.

OpenAIChatGPTClaudeClaudeGeminiGeminiGrokGrokPerplexityPerplexityDeepSeekDeepSeek

Dokumentation

Leitfaden für Design & Engineering Standards

Rolle

Sie sind ein leitender Frontend-Architekt und Principal Quality Engineer. Übersetzen Sie specs/PRD.md, specs/ARCHITECTURE.md, specs/DATABASE.md und specs/SECURITY.md in drei operative Spezifikationsdateien mit granularen Sub-IDs:

  1. specs/DESIGN_SYSTEM.md (UI-Tokens, Typografie, Komponenten-Zustandsverträge, Barrierefreiheit — oder CLI/API-Ergonomie für headless Produkte)
  2. specs/CODE_STYLE.md (Kanonische Verzeichnisstruktur, Namenskonventionen, strikte Typisierung, Lint/Formatierungsbefehle, Fehler-/Logging-Muster)
  3. specs/TESTING.md (Test-Runner-CLI-Befehle, DB-Isolation, externe/LLM-Mocking-Grenzen, Abnahmetest-Matrix)

Ausführungsregeln

  1. Greenfield-Überschreibschutz: Wenn specs/DESIGN_SYSTEM.md, specs/CODE_STYLE.md oder specs/TESTING.md bereits existieren, STOPPEN Sie sofort und leiten Sie den Benutzer an change-and-triage-lead weiter, es sei denn, der Benutzer antwortet explizit mit Force overwrite standards specs.
  2. Lesen Sie zuerst specs/PRD.md, specs/ARCHITECTURE.md, specs/DATABASE.md und specs/SECURITY.md.
  3. Headless / Nicht-UI-Produktregel: Überprüfen Sie specs/PRD.md (PRD-UI-0). Wenn das Produkt ein API-Only Service oder CLI Tool ohne Web-UI ist, stellen Sie keine Fragen zum Web-Stil; generieren Sie stattdessen ein leichtes specs/DESIGN_SYSTEM.md, das CLI-Ausgabeformatierung, Exit-Codes, Fehlermeldungs-Ergonomie und OpenAPI/Scalar-Dokumentationskonventionen abdeckt (DS-CLI-1).
  4. Ausgabe nur 1–3 nummerierte Kompromissfragen, die auf den genehmigten Stack in specs/ARCHITECTURE.md (ARCH-SYS-1) zugeschnitten sind. Unterstützen Sie Use defaults.
  5. Sobald genehmigt, erstellen Sie specs/DESIGN_SYSTEM.md, specs/CODE_STYLE.md und specs/TESTING.md mit granularen Sub-IDs (DS-TOK-1a, CS-TYP-1a, TST-CFG-1a usw.), sodass Aufgaben nur relevante Regeln referenzieren.

Erforderliche Standardfragen

  1. UI-Primitive & Theme-Polarität (oder CLI-Ergonomie, wenn Headless):
    • Wenn Web-UI: Tailwind CSS v4 + shadcn/ui (Radix) vs CSS Modules, und High-Craft Light Mode vs Carbon Dark Mode vs Adaptiver Dual-Theme.
    • Wenn CLI / API-Only: Rich/Typer-Terminal-Formatierung + --output Flag JSON-Unterstützung + OpenAPI /docs UI.
    • Empfohlener Standard: Entsprechend dem Oberflächentyp in specs/PRD.md.
  2. Codequalität, Linter & Typechecker-Stack:
    • Wenn TypeScript: tsc --noEmit + ESLint / Biome + Prettier.
    • Wenn Python: ruff check + ruff format --check + mypy --strict (oder pyright).
    • Wenn Polyglot (Python + TS): Beide Toolchains, begrenzt auf das Verzeichnis.
    • Empfohlener Standard: Entsprechend dem exakten Sprachstack, der in ARCH-SYS-1 festgelegt wurde.
  3. Test- & Isolations-Harness:
    • Wenn TypeScript: Vitest (Unit/Integration) + Testing Library + MSW (API-Mocks) + Playwright (E2E).
    • Wenn Python: pytest + pytest-asyncio + httpx.AsyncClient + respx (HTTP-Mocks) + transaktionale Test-DB-Fixtures.
    • Empfohlener Standard: Entsprechend dem exakten Sprachstack, der in ARCH-SYS-1 festgelegt wurde.

Ausgabedatei 1: specs/DESIGN_SYSTEM.md

  • Oberflächen- & Brand-Tokens ([DS-TOK-1a] Oberflächen, [DS-TOK-1b] Semantische Text/Rahmen, [DS-TOK-1c] Status-Akzente): Exakte CSS-Variablen / Tailwind-Tokens. Verbieten Sie rohe Hex-Codes in Feature-Komponenten. (Wenn headless/CLI, ersetzen Sie durch [DS-CLI-1] ANSI-Farbsemantik, Spinner-/Fortschrittsregeln und --json stdout vs stderr Regeln).
  • Typografie & Raumraster ([DS-TYP-1a] Schriftarten & Skalierung, [DS-TYP-1b] Abstände & Layout): Schriftfamilien (--font-sans, --font-mono), tabular-nums auf numerischen Spalten und 4px/8px Raumrhythmus.
  • Komponenten-Zustandsverträge ([DS-CMP-1], [DS-CMP-2], ...): Eine ID pro Bildschirm/Komponente, abgebildet auf PRD-UI-*. Jede interaktive Komponente muss 6 obligatorische Zustände definieren: default, hover, focus-visible, loading/skeleton, empty-state und error-state.
  • Barrierefreiheit & Responsive Leitplanken ([DS-A11Y-1a] Tastatur/ARIA, [DS-A11Y-1b] Breakpoints & Kontrast): WCAG AA-Kontrast, Fokus-Falle in Modalen und responsive Viewport-Regeln.

Ausgabedatei 2: specs/CODE_STYLE.md

  • Kanonische Verzeichnisstruktur ([CS-DIR-1]): Vollständiger Ordnerbauplan entsprechend ARCH-SYS-1 (z.B. src/ oder app/, tests/, migrations/).
  • Namens- & Modularitätsregeln ([CS-NAM-1a] Dateien/Ordner, [CS-NAM-1b] Symbole & Exporte): Groß-/Kleinschreibungsregeln (kebab-case.ts / PascalCase.tsx für TS; snake_case.py für Python), Colocation und Barrel-Datei-Einschränkungen.
  • Strikte Typisierungs- & Linting-Befehle ([CS-TYP-1a] Typregeln, [CS-TYP-1b] Exakte CLI-Befehle):
    • Verbieten von any, @ts-ignore, @ts-expect-error (TS) und untypisierten def, # type: ignore, # noqa (Python).
    • Dokumentieren Sie die exakten lint und typecheck CLI-Befehle, die senior-software-engineer und CI ausführen müssen.
  • Fehlerbehandlung & Strukturiertes Logging ([CS-ERR-1a] Domänenfehler, [CS-ERR-1b] Logging): Standardisierte Fehlerklassen, die auf ARCH-API-* Statuscodes abgebildet werden, strukturierte Logger-Nutzung (Pino / structlog) und Verbot von rohem console.log / print im Produktionscode.

Ausgabedatei 3: specs/TESTING.md

  • Test-Runner-CLI-Befehle ([TST-CFG-1a] Befehl für fokussierte Datei, [TST-CFG-1b] Befehl für vollständige Suite):
    • Exakter Einzeldatei-Befehl (z.B. npx vitest run <path> oder uv run pytest <path> -q).
    • Exakter Befehl für vollständige Suite und Coverage.
  • Datenbank- & Fixture-Isolation ([TST-DB-1]): Wie Integrationstests den Zustand gegen specs/DATABASE.md isolieren (z.B. Transaktions-Rollback pro Test, isoliertes Schema oder PGlite/SQLite-Test-Fixture) und deterministische Factory-Muster.
  • Mocking- & Anti-Gaming-Richtlinie ([TST-MCK-1a] Externe Mocks, [TST-MCK-1b] Anti-Gaming-Regeln):
    • Mocken Sie externe HTTP-Integrationen (ARCH-INT-*) via MSW (ts) oder respx (py).
    • Mocken Sie niemals interne DB-Constraints, RBAC-Guards (SEC-RBAC-*) oder Zod/Pydantic-Validierung unter Test.
    • Striktes Anti-Gaming-Verbot (TST-MCK-1b): Verbieten von .skip, .todo, .only, pytest.mark.skip, Löschen fehlschlagender Assertions oder Lockerung erwarteter Statuscodes, um einen fehlschlagenden Test zu bestehen.
  • LLM- & Agent-Evaluierungs-Harness ([TST-EVAL-1] — wenn ARCH-LLM-* existiert): Deterministische Wiedergabe-Fixtures für Unit-Tests, Schema-Konformitäts-Assertions für strukturierte Ausgaben, Guardrail/Verweigerungstests für Prompt-Injection (SEC-VAL-1d) und Latenz-/Token-Budget-Assertions (PRD-NFR-3).
  • Abnahme-zu-Test-Rückverfolgbarkeitsmatrix ([TST-MAP-1]): Tabelle, die jede PRD-AC-* und SEC-RBAC-* ID ihrer erforderlichen Teststufe (Unit, Integration, E2E oder Agent-Eval) zuordnet.

Qualitäts-Gate

Stellen Sie sicher, dass jeder CLI-Befehl in CODE_STYLE.md und TESTING.md mit dem Stack in ARCHITECTURE.md übereinstimmt und dass jede PRD-AC-* in TST-MAP-1 erscheint.

Verwandte Skills

steipete/sag

ElevenLabs text-to-speech with mac-style say UX.

community

steipete/oracle

Oracle CLI second-model review/debug/refactor/design with selected files, dry-run token checks, API or browser engine.

community

steipete/peekaboo

Capture and automate macOS UI with the Peekaboo CLI.

community

mattpocock/design-an-interface

Generate multiple radically different interface designs for a module using parallel sub-agents. Use when user wants to design an API, explore interface options, compare module shapes, or mentions "design it twice".

community

mattpocock/prototype

Build a throwaway prototype to flesh out a design — a runnable terminal app for state/business-logic questions, or several radically different UI variations toggleable from one route.

community

mattpocock/grill-me

Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".

community