Zur Nutzungsanleitung springen
Design Flowvon julianoczkowski

Design Flow Skill.

Führe ein Designprojekt durch klar definierte Phasen mit gespeicherten Ergebnissen.

  • Designworkflow
  • Review
Quellprüfung · design-flowSKILL.md
Aufgabe Führe ein Designprojekt durch klar definierte Phasen mit gespeicherten Ergebnissen. Ergebnisse Funktionsspezifisches Briefing, Informationsarchitektur und Token-Artefakte nach Bedarf. Vor dem Start Der Orchestrator ist auf die benannten Skills und deren vollständige Anweisungen angewiesen.
Redaktionelle Zusammenfassung · Quelle geprüft am 2026-11-02 · kein generiertes Beispiel

01 Funktionen

Führe ein Designprojekt durch klar definierte Phasen mit gespeicherten Ergebnissen

Führe Designfragen und Informationsarchitektur über Tokens und Implementierungsaufgaben bis zur Implementierung. Eine Prüfung wird gesondert angefordert.

Quellenbasierter WorkflowKein Ausführungs-Benchmark

Die Arbeitsweise

Design Flow orchestriert die ergänzenden Designer-Skills in einer festgelegten Reihenfolge. Der Ablauf beginnt mit Klärungsfragen, hält ein Briefing fest, entwickelt die Informationsarchitektur, legt Tokens an und übersetzt das Briefing in umsetzbare Aufgaben. Anschließend folgt die Frontend-Implementierung dieser Aufgabenliste. Jede Phase hat ein explizites Ergebnis und einen Übergang, den die gestaltende Person bestätigt.

Die Quelle behandelt den Workflow als wiederaufnehmbar. Funktionsspezifische Ergebnisse liegen zusammen in einem .design-Ordner, sodass die Arbeit bei der nächsten unvollständigen Phase fortgesetzt werden kann. Design-Review ist ein separat angeforderter Schritt, nachdem etwas gebaut wurde. Der Abschluss der Phasenfolge allein belegt nicht, dass eine visuelle Prüfung bestanden wurde.

Erwartete Ergebnisse

  • Funktionsspezifisches Briefing, Informationsarchitektur und Token-Artefakte nach Bedarf.
  • Eine geordnete TASKS.md-Checkliste für die Frontend-Implementierung.
  • In der Implementierungsphase erstellte Komponenten und Seiten sowie gespeicherte Planungsartefakte für die Wiederaufnahme.
Beispiel-Briefing ansehen

Vom Briefing zur Prüfung

  1. 01
    Notwendige Phasen auswählen

    Erkläre die vollständige Abfolge und identifiziere überspringbare Phasen. Vorhandene Tokens oder der Umfang einer einzelnen Komponente können unnötige Arbeit entfallen lassen.

  2. 02
    Designabsicht klären und speichern

    Führe die relevanten ergänzenden Skills vollständig aus und bewahre Briefing und Informationsarchitektur im selben Funktionsordner auf. Bestätige jede Phase vor dem Fortfahren.

  3. 03
    Absicht in eine Umsetzung überführen

    Erzeuge oder erweitere Tokens, erstelle die Aufgabenliste und arbeite ihre Implementierungsschritte ab. Hake erledigte Aufgaben ab und hole zwischen ihnen Bestätigung ein.

  4. 04
    Auf Anfrage prüfen

    Führe den separaten Skill design-review erst aus, wenn eine gebaute Oberfläche vorliegt und eine Prüfung angefordert wurde. Screenshots und Befunde gehören zu den übrigen Artefakten der Funktion.

02 Einsatzbereiche

Wann einsetzen?

Der Orchestrator ist auf die benannten Skills und deren vollständige Anweisungen angewiesen.

Gut geeignet

  • Neue Funktionen planenEine gestaltende Person möchte einen geführten Weg von der ersten Idee zur Implementierung.
  • Unterbrochene ProjekteGespeicherte Funktionsartefakte ermöglichen die Wiederaufnahme unter Erhalt früherer Entscheidungen.

Zu prüfende Grenzen

  • Ergänzende Skills erforderlichDer Orchestrator ist auf die benannten Skills und deren vollständige Anweisungen angewiesen.
  • Explizite ÜbergängeDie Quelle erwartet Bestätigungen zwischen den Phasen, statt die gesamte Abfolge stillschweigend auszuführen.
  • Separate PrüfungReview erfolgt nicht automatisch und benötigt gebauten Code als Prüfgegenstand.

Diese Eingaben mitbringen

  • ProjektabsichtBeschreibe Funktion, Nutzerziel und bestehende Entscheidungen.
  • Aktuelles RepositoryStelle vorhandene Komponenten, Tokens und Funktionsartefakte bereit.
  • Workflow-PräferenzBenenne bereits abgeschlossene oder bewusst übersprungene Phasen.

03 Wichtige Entscheidungen

Wichtige Entscheidungen

  1. Verknüpfte Entscheidungen

    Das Briefing bildet die Grundlage für Architektur, Tokens und Implementierungsaufgaben.

  2. Abgegrenzte Artefakte

    Separate Funktionsordner verhindern, dass unzusammenhängende Projekte einander überschreiben.

  3. Klare Wiederaufnahme

    Vorhandene Artefakte zeigen, wo nach einer Pause weiterzuarbeiten ist.

04 Beispielbriefing

Ein konkretes Briefing ausprobieren

Das folgende Beispiel-Briefing wurde nicht getestet. Prüfen Sie die Einrichtung des Skills, bevor Sie es verwenden.

Quelle und Einrichtung prüfen

Beschreibe Funktion, Nutzerziel und bestehende Entscheidungen.

Upstream-Quelldatei
https://github.com/julianoczkowski/designer-skills/blob/c259656c76d9758d7ead46b0d2f125cbe84f8665/design-flow/SKILL.md

Der folgende Verweis öffnet die Originalanleitung. Prüfe vor der Nutzung die Einrichtung des Repositorys; dies ist kein Installationsbefehl.

Mit einem Ergebnis beginnen

Passen Sie Umfang, Quellmaterial und Rahmenbedingungen in diesem Briefing an, bevor Sie den Skill ausführen.

Beispiel-Briefing
Nutze design-flow für eine neue Teamaktivitätsseite in diesem Repository. Prüfe zuerst vorhandene .design-Funktionsordner und unsere aktuellen Tokens. Erkläre die Phasenfolge und empfehle anhand des vorhandenen Stands, welche Phasen wir überspringen können. Halte Briefing, Architektur und Aufgaben in einem Funktionsordner zusammen. Bestätige jeden Übergang vor dem Fortfahren und übernimm akzeptierte Entscheidungen in die nächsten Schritte. Folge während der Implementierung der Aufgabencheckliste. Lasse das Design-Review als klar benannten separaten Schritt offen, sofern ich es nicht ausdrücklich während des Ablaufs anfordere.

Ergebnis prüfen

Prüfen Sie die tatsächliche Ausgabe anhand dieser beobachtbaren Kriterien.

  • Jedes Phasenartefakt spiegelt Entscheidungen der vorangehenden Phase wider.
  • Abgeschlossene und übersprungene Phasen sind in der Übergabe unterscheidbar.
  • Die Prüfung wird nicht allein deshalb als bestanden bezeichnet, weil die Implementierung fertig ist.

OpenDesign bietet einen lokalen Design-Arbeitsbereich für Coding-Agenten. Dieser Eintrag bedeutet nicht, dass der Skill mitgeliefert wird oder dass seine externen Tools, Zugangsdaten und Software-Abhängigkeiten enthalten sind.

05 Quelle und Lizenz

Quelle und Lizenz

Diese Seite beschreibt die unten verlinkte, festgelegte Quellrevision. Verhalten und Anforderungen im Upstream können sich ändern.

Quellinhaber
julianoczkowski
Skill-Datei
SKILL.md
Geprüfter Stand
2026-11-02 · c259656c76d9
Redaktionelle Quellenzusammenfassung
Führe ein Designprojekt durch klar definierte Phasen mit gespeicherten Ergebnissen.

Originalzusammenfassung von OpenDesign auf Grundlage der verlinkten Quelle. Repository-Sterne sind ein datiertes Popularitätssignal, keine Skill-Nutzung und keine Qualitätsbewertung.

06 Fragen vor dem Start

Fragen vor dem Start

Muss jedes Projekt jede Phase durchlaufen?

Nein. Die Quelle unterstützt ausdrücklich das Überspringen unnötiger Phasen, etwa der Informationsarchitektur für eine einzelne Komponente.

Wo werden die Artefakte gespeichert?

Sie werden unter .design/<feature-slug>/ gruppiert, sodass jede Funktion eine eigene Dokumentation besitzt.

Führt der Ablauf automatisch ein Design-Review aus?

Nein. Review wird gesondert angefordert, nachdem Komponenten oder Seiten gebaut wurden.

OpenDesign

Briefing und Designarbeit an einem Ort.

Halten Sie Briefing, Quellmaterial und Designarbeit in einem lokalen Arbeitsbereich zusammen. Prüfen Sie die Einrichtung des Skills, bevor Sie ihn in Ihren Workflow aufnehmen.

Upstream-Quelldatei
https://github.com/julianoczkowski/designer-skills/blob/c259656c76d9758d7ead46b0d2f125cbe84f8665/design-flow/SKILL.md