Pi für Design.

Was Pi tatsächlich ist

Pi ist ein quelloffener (MIT) KI-Coding-Agent für das Terminal, Teil des earendil-works-pi-Toolkits. Er liest dein Repository, bearbeitet Dateien und führt Shell-Befehle aus — er plant und verifiziert Arbeit aus natürlichsprachlichen Aufgaben, statt nur Zeilen zu vervollständigen. Sein Kern ist bewusst klein gehalten: vier Standard-Werkzeuge — read, write, edit und bash — plus integrierte grep, find und ls.

Für Design-Arbeit ist die herausragende Eigenschaft, dass Pi anbieterunabhängig ist. Er normalisiert über Anthropic, OpenAI, Google und viele andere Anbieter hinter einer einheitlichen API, sodass du deine eigenen Schlüssel mitbringst und das Modell pro Aufgabe wählst — zum Beispiel ein starkes multimodales Modell, um Referenz-Screenshots zu lesen — und mit /model oder Strg+L mitten in der Sitzung wechselst, ohne deinen Workflow zu ändern.

• Jedes Modell, deine Schlüssel: Pi routet zu über 20 Anbietern, darunter Anthropic und OpenAI. Du authentifizierst dich mit deinen eigenen API-Schlüsseln (BYOK) oder meldest dich mit /login bei einem Claude-Pro/Max-, ChatGPT-Plus/Pro- oder GitHub-Copilot-Abonnement an.
• Skills + Extensions: Pi lädt Skills (Markdown-Capability-Pakete nach dem Agent-Skills-Standard) und TypeScript-Extensions — der natürliche Ort, um deine Designkonventionen zu kodieren und benutzerdefinierte Werkzeuge hinzuzufügen.
• Verzweigende Sitzungen: Sitzungen werden als JSONL-Bäume gespeichert, sodass du eine Exploration verzweigen und die Historie in einer einzigen Datei durchnavigieren kannst, ohne frühere Durchgänge zu verlieren.

• Anbieter: earendil-works (quelloffenes Community-Projekt)
• Zugangsdaten: dein eigener Anbieter-API-Schlüssel (BYOK — Anthropic, OpenAI, Google usw.) oder eine Abonnement-Anmeldung über /login; lokal gespeichert in ~/.pi/agent/auth.json (0600)
• Lizenz: MIT, quelloffen

Warum ein mehranbieterfähiger BYOK-Agent zu Design passt

Pis Design-Vorteil ist Flexibilität, kein einzelnes integriertes Modell — aber wie bei jedem Agenten muss der Geschmack weiterhin beigesteuert werden.

• Wähle das richtige Modell pro Aufgabe: Weil Pi zu jedem Anbieter routet, kannst du zu einem starken multimodalen Modell greifen, um Referenz-Screenshots zu lesen, und dann zu einem anderen für Refactoring wechseln — ohne den Agenten zu verlassen.
• Deine Schlüssel, keine Bindung: BYOK bedeutet, dass du nicht an die Preise oder Kontextgrenzen eines einzelnen Anbieters gebunden bist; wähle das Modell, dessen Stärken zur Design-Aufgabe vor dir passen.
• Konventionen in Skills: Ein Skill (plus eine MCP-Quelle wie ein Figma-Server) richtet den Agenten auf deine Tokens, Komponenten und echten Spezifikationen aus, sodass er gegen eine Marke arbeitet statt gegen einen Standard-Look.

Die Lektion ist dieselbe, die jeder Agent lehrt: Pi hat von Haus aus keinen Geschmack, und keine Modellwahl liefert ihn. Es liefert gutes Design, wenn du ihm Beschränkungen gibst — ein Designsystem, einen ästhetischen Skill und konkrete Referenzen. Open Design bündelt genau diese Eingaben, weshalb die beiden zusammenpassen (mehr dazu weiter unten).

Pi von Grund auf für Design-Arbeit einrichten

Hier ist der vollständige Weg von einer sauberen Maschine zu einem Pi, das UI bauen und verifizieren kann.

# 1. Install the Pi coding agent CLI (Node)
npm install -g --ignore-scripts @earendil-works/pi-coding-agent

# 2. Authenticate with your own provider key (BYOK)
export ANTHROPIC_API_KEY=sk-ant-...   # or OPENAI_API_KEY=sk-...
#    (or run /login inside Pi for a Claude / ChatGPT / Copilot subscription)

# 3. Start it in your project
cd your-project
pi

# 4. Switch models any time with /model or Ctrl+L

• Kodiere deine Design-Regeln: Hinterlege deine Tokens, Primitive und Konventionen in einem Skill und richte Pi darauf aus, sodass der Output zu einer Marke passt, statt auf einen generischen Look zurückzufallen.
• Füge Browser-Verifizierung hinzu: Verdrahte einen Playwright- oder Browser-MCP, sodass Pi in einem echten Browser rendert und seinen Output über Breakpoints hinweg prüft, statt nur zu bestätigen, dass der Build durchläuft.

Der Workflow vom Screenshot zur UI

Die Design-Schleife mit der größten Hebelwirkung bei Pi besteht darin, ein Referenzbild in funktionierende, responsive UI zu verwandeln und so lange zu iterieren, bis es passt — wobei man sich auf ein multimodales Modell stützt, um den Output mit der Referenz zu vergleichen. Da Pi anbieterunabhängig ist, richte es auf das Modell aus, das für diesen Durchgang Bilder am besten liest.

1. Beginne mit den klarsten visuellen Referenzen, die du hast — und schließe mehrere Zustände ein (Desktop und Mobil, Hover, leer, Laden), nicht nur einen Hero-Shot.
2. Wähle mit /model ein starkes multimodales Modell für den Durchgang, da Bildverständnis die Qualität von Screenshot-zu-UI bestimmt.
3. Sei in der Eingabeaufforderung präzise; vage Prompts erzeugen generische UI selbst mit einem starken Modell.
4. Halte dein Designsystem und deine Konventionen in einem Skill und sage Pi, wo die Tokens und kanonischen Primitive liegen.
5. Starte einen Dev-Server und lass Pi in einem echten Browser rendern, mit Größenänderung auf Breakpoints, dann iteriere, indem du seine Implementierung mit den Screenshots vergleichst — nicht nur bestätigst, dass es baut.

Gib dem Agenten die Referenzen und konkrete Beschränkungen von Anfang an:

pi
# in the prompt:
> Implement reference-desktop.png and reference-mobile.png in
  React + Vite + Tailwind + TypeScript.
  Reuse my existing design-system components and tokens (see the Skill).
  Match spacing, layout, and hierarchy; make it responsive.
  Render it in the browser and iterate until it matches the references
  across breakpoints.

Halte Prompts klein und fokussiert, committe gute Iterationen und mache schlechte rückgängig (und sage Pi, wenn du zurücksetzt), sodass jeder Durchgang auf einer sauberen Basis aufbaut. Pis verzweigende JSONL-Sitzungen lassen dich zudem eine Alternative erkunden, ohne den ursprünglichen Strang zu verlieren.

Skills, Extensions und Themes

Pi erweitert sich zur Laufzeit über einige Schichten selbst, und sie lassen sich sauber auf einen offenen Design-Workflow abbilden.

• Skills: Markdown-Capability-Pakete nach dem Agent-Skills-Standard — das dauerhafte, portable Zuhause für deine Designkonventionen, Tokens und Review-Checklisten. Derselbe Skill funktioniert über kompatible Agenten hinweg, nicht nur bei Pi.
• Extensions und Prompt-Vorlagen: TypeScript-Extensions fügen benutzerdefinierte Werkzeuge, Befehle und UI hinzu; wiederverwendbare Prompt-Vorlagen werden über /name ausgeführt. Beide lassen dich die Verifikationsschleife skripten, ohne das Terminal zu verlassen.
• MCP und Themes: Pi verbindet sich mit MCP-Servern, um externen Design-Kontext einzubringen (am relevantesten ein Figma-MCP-Server), und Themes laden per Hot-Reload, sodass die Terminal-UI lesbar bleibt, während du arbeitest.

Das sind portable Fähigkeiten — Skills und MCP besonders — genau die Art von Dingen, die Open Design orchestrieren soll, statt sie pro Projekt neu zu erschaffen.

Pi vs. Codex vs. Claude Code vs. Cursor vs. Gemini CLI für Design

Es gibt keinen einzelnen Gewinner für Design-Arbeit — jeder Agent hat eine andere Stärke, und erfahrene Teams kombinieren sie. Eine faire Zusammenfassung:

Pis Blickwinkel ist orthogonal zu den anderen: Es ist der Agent, der dich jedes dieser zugrunde liegenden Modelle mit deinen eigenen Schlüsseln nutzen lässt. Das wiederkehrende Urteil der Community gilt weiterhin — Geschmack kommt von Menschen: Alle fallen ohne Skills, Referenzen und Beschränkungen auf eine generische Ästhetik zurück. Das ist das eigentlich zu lösende Problem, und es hat die Gestalt eines Design-Werkzeugs, nicht eines Modells.

Fallstricke und wie man den „AI-Slop“-Look vermeidet

Die häufigste Beschwerde über KI-generiertes Design ist, dass es generisch aussieht — weiche Verläufe, schwebende Panels, übergroße abgerundete Ecken, dramatische Schatten, eine Inter-und-Lila-Stimmung, die „schreit, dass eine KI das gemacht hat“. Weitere gemeldete Probleme sind kaputte mobile Layouts und Anweisungen, die in die UI-Texte durchsickern. Nichts davon ist Pi oder einem einzelnen Modell eigen; es passiert, wenn irgendein Agent ohne kuratierten Design-Kontext läuft.

• Füge einen ästhetischen Skill hinzu: Ein kuratierter Design-Skill zwingt den Agenten, sich auf eine echte Richtung festzulegen, statt auf den Standard-Look — und da es ein portabler Skill ist, reist er mit dir über Modelle hinweg.
• Verifiziere in einem echten Browser: Wähle ein multimodales Modell und lass Pi über Breakpoints hinweg rendern und selbst prüfen, sodass Layouts nicht stillschweigend auf Mobilgeräten brechen.
• Liefere Tokens und Referenzen: Echte Design-Tokens und Referenz-Screenshots sind der mit Abstand größte Hebel auf die Output-Qualität.
• Kodiere Regeln dort, wo Pi sie liest: Hinterlege Stilregeln wie „keine Hero-Cards, maximal zwei Schriftarten, markenorientierte Hierarchie“ in einem Skill, den der Agent bei jedem Durchgang lädt.

Beachte, dass es bei jeder Abhilfemaßnahme darum geht, dem Agenten einen kuratierten Design-Kontext zu geben — unabhängig davon, zu welchem Anbieter du routest. Diesen Kontext von Hand und pro Projekt zu pflegen, ist die Mühsal, die Open Design beseitigt.

Designen mit Pi in Open Design

Open Design ist die quelloffene Design-Ebene, nach der der obige Workflow immer wieder verlangt. Es behandelt Pi als First-Party-Adapter und umgibt es mit einer kuratierten Skill- und Designsystem-Bibliothek, einer strukturierten Render-Pipeline und einer lokalen Desktop-Oberfläche — sodass der Design-Kontext, der Pi gut macht, vom ersten Durchgang an da ist, statt jedes Mal von Hand zusammengestellt zu werden. Beide sind quelloffen und lokal-first, was die Kombination zu einer natürlichen Passung macht.

1. Installiere Open Design und wähle Pi als deinen Agenten.
2. Authentifiziere dich mit deinem eigenen Anbieter-API-Schlüssel (BYOK) oder einer Abonnement-Anmeldung — die Zugangsdaten bleiben auf deiner Maschine in ~/.pi/agent/auth.json und werden niemals über uns weitergeleitet.
3. Wähle ein Designsystem und einen Skill, dann erzeuge Decks, Prototypen und Landingpages mit konsistentem Geschmack.
4. Jedes Artefakt und jede DESIGN.md-Datei lebt in deinem eigenen Repo, nicht in einer gehosteten Cloud.

Derselbe Pi-Agent, dieselben Schlüssel, dieselbe Freiheit, Modelle zu wechseln — plus ein echter, portabler, quelloffener Design-Workflow darum herum. Es ist lokal-first und MIT, sodass nichts von deiner Arbeit oder deinen Zugangsdaten deine Maschine verlässt.

Häufig gestellte Fragen

1. 01 Kann Pi wirklich Design-Arbeit leisten? +

   Ja — mit einem ästhetischen Skill, einem Designsystem und echten Referenzbildern im Kontext liefert Pi produktionsreife, responsive UI, und du kannst es zu einem starken multimodalen Modell routen, um den Output gegen Referenzen zu verifizieren. Ohne diesen Kontext neigt es dazu, auf einen generischen Look zurückzufallen — das ist die Lücke, die Open Design füllt.

2. 02 Muss ich zahlen, um mit Pi zu designen? +

   Pi selbst ist kostenlos und quelloffen (MIT). Du zahlst nur für das zugrunde liegende Modell — bring deinen eigenen Anbieter-API-Schlüssel mit (BYOK), oder nutze ein Claude-Pro/Max-, ChatGPT-Plus/Pro- oder GitHub-Copilot-Abonnement über /login. Open Design leitet deine Zugangsdaten in keinem Fall weiter.

3. 03 Was macht Pi speziell gut für Design? +

   Es ist anbieterunabhängig: Du bringst deine eigenen Schlüssel mit und routest zu jedem von über 20 Anbietern, wählst das Modell, dessen Stärken zur Aufgabe passen, und wechselst mitten in der Sitzung. Doch der Geschmack kommt weiterhin aus dem Designsystem, dem Skill und den Referenzen, die du lieferst, nicht aus dem Modell.

4. 04 Welches Modell sollte ich mit Pi für Frontend-Design nutzen? +

   Pi routet zu vielen Anbietern, also wähle pro Aufgabe — ein starkes multimodales Modell liest Referenz-Screenshots gut, während andere zum Refactoring passen können. Der Vorteil von Pi ist, dass du wechseln kannst, ohne deinen Workflow zu ändern. Open Design lässt dich denselben Design-Kontext über welches Modell auch immer du wählst beibehalten.

5. 05 Wie verbinde ich Pi mit Figma? +

   Pi unterstützt MCP-Server, sodass du einen Figma-MCP-Server hinzufügen und echten Design-Kontext abrufen kannst — Komponenten, Variablen, Layout-Daten — sodass der generierte Code der Quelle entspricht, statt sie nur anzunähern.

6. 06 Ist Open Design mit Pi verbunden? +

   Nein. Pi ist ein unabhängiges quelloffenes Projekt von earendil-works; Open Design ist ein separates unabhängiges quelloffenes Projekt, das Pi als First-Party-Adapter unterstützt.

7. 07 Sind meine Dateien und Zugangsdaten sicher? +

   Ja — Open Design ist lokal-first und quelloffen. Deine Dateien, Artefakte und DESIGN.md bleiben in deinem eigenen Repo, und deine Anbieterschlüssel werden direkt von Pi verwendet (lokal gespeichert in ~/.pi/agent/auth.json), niemals über Open-Design-Server geleitet.