Pi pour le design.

Ce qu'est réellement Pi

Pi est un agent de codage IA open-source (MIT) pour le terminal, qui fait partie de la boîte à outils earendil-works pi. Il lit votre dépôt, modifie les fichiers et exécute des commandes shell — planifiant et vérifiant le travail à partir de tâches en langage naturel plutôt que de simplement compléter des lignes. Son cœur est délibérément petit : quatre outils par défaut — read, write, edit et bash — plus grep, find et ls intégrés.

Pour le travail de design, la propriété remarquable est que Pi est agnostique du fournisseur. Il normalise Anthropic, OpenAI, Google et de nombreux autres fournisseurs derrière une API unifiée, vous apportez donc vos propres clés et choisissez le modèle par tâche — par exemple un modèle multimodal puissant pour lire des captures d'écran de référence — et changez avec /model ou Ctrl+L en cours de session sans modifier votre workflow.

• N'importe quel modèle, vos clés: Pi se connecte à plus de 20 fournisseurs dont Anthropic et OpenAI. Vous vous authentifiez avec vos propres clés API (BYOK), ou vous connectez à un abonnement Claude Pro/Max, ChatGPT Plus/Pro ou GitHub Copilot avec /login.
• Skills + Extensions: Pi charge des Skills (packages de capacités Markdown suivant le standard Agent Skills) et des Extensions TypeScript — l'endroit naturel pour encoder vos conventions de design et ajouter des outils personnalisés.
• Sessions avec branches: Les sessions sont stockées sous forme d'arbres JSONL, vous pouvez donc créer des branches d'exploration et naviguer dans l'historique au sein d'un seul fichier sans perdre les itérations antérieures.

• Éditeur : earendil-works (projet communautaire open-source)
• Identifiant : votre propre clé API de fournisseur (BYOK — Anthropic, OpenAI, Google, etc.) ou une connexion par abonnement via /login ; stocké localement dans ~/.pi/agent/auth.json (0600)
• Licence : MIT, open source

Pourquoi un agent multi-fournisseurs BYOK convient au design

L'avantage design de Pi est la flexibilité, pas un seul modèle intégré — mais, comme pour tout agent, le goût doit toujours être fourni.

• Choisir le bon modèle par tâche: Parce que Pi route vers n'importe quel fournisseur, vous pouvez recourir à un modèle multimodal performant pour lire des captures d'écran de référence, puis basculer vers un autre pour le refactoring — sans quitter l'agent.
• Vos clés, aucun verrouillage: BYOK signifie que vous n'êtes pas lié à la tarification ou aux limites de contexte d'un seul fournisseur ; choisissez le modèle dont les forces correspondent au travail de design qui vous attend.
• Conventions dans Skills: Un Skill (plus une source MCP comme un serveur Figma) oriente l'agent vers vos tokens, composants et spécifications réelles, de sorte qu'il travaille sur une marque plutôt qu'un style par défaut.

La leçon est la même que celle enseignée par chaque agent : Pi n'a pas de goût par défaut, et aucun choix de modèle ne le fournit. Il produit un bon design lorsque vous lui donnez des contraintes — un design system, un skill esthétique et des références concrètes. Open Design regroupe exactement ces entrées, c'est pourquoi les deux s'assemblent si bien (plus de détails ci-dessous).

Configurer Pi pour le travail de design, à partir de zéro

Voici le chemin complet depuis une machine vierge jusqu'à un Pi capable de construire et vérifier une UI.

# 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

• Encodez vos règles de conception: Placez vos tokens, primitives et conventions dans un Skill et orientez Pi vers eux, pour que la sortie corresponde à une marque plutôt qu'un style générique par défaut.
• Ajoutez une vérification par navigateur: Connectez un MCP Playwright ou navigateur pour que Pi effectue le rendu dans un vrai navigateur et vérifie sa sortie sur tous les breakpoints au lieu de confirmer seulement que le build passe.

Le workflow capture d'écran-vers-UI

La boucle de design la plus efficace avec Pi consiste à transformer une image de référence en interface utilisateur fonctionnelle et responsive, puis à itérer jusqu'à ce qu'elle corresponde — en s'appuyant sur un modèle multimodal pour comparer le résultat à la référence. Comme Pi est agnostique au fournisseur, orientez-le vers le modèle qui lit le mieux les images pour cette passe.

1. Partez des références visuelles les plus claires que vous avez — et incluez plusieurs états (desktop et mobile, hover, vide, chargement), pas seulement un seul écran héroïque.
2. Choisissez un modèle multimodal puissant pour la passe avec /model, car la compréhension d'image est ce qui détermine la qualité de la conversion capture d'écran vers UI.
3. Soyez précis dans le prompt ; des prompts vagues produisent une interface générique même avec un modèle performant.
4. Conservez votre système de design et vos conventions dans un Skill, et indiquez à Pi où se trouvent les tokens et les primitives canoniques.
5. Lancer un serveur de développement et faire effectuer le rendu par Pi dans un vrai navigateur, en redimensionnant aux points de rupture, puis itérer en comparant son implémentation aux captures d'écran — pas simplement confirmer que ça compile.

Donnez à l'agent les références et les contraintes concrètes dès le départ :

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.

Gardez les prompts courts et concentrés, commitez les bonnes itérations et annulez les mauvaises (en indiquant à Pi quand vous annulez), pour que chaque passe parte d'une base propre. Les sessions JSONL branchées de Pi vous permettent aussi d'explorer une alternative sans perdre le fil d'origine.

Skills, Extensions et thèmes

Pi s'étend automatiquement au runtime à travers quelques couches, et elles correspondent clairement à un workflow de design ouvert.

• Skills: Packages de capacités Markdown suivant le standard Agent Skills — le foyer durable et portable pour vos conventions de design, tokens et listes de vérification. Le même Skill fonctionne avec tous les agents compatibles, pas seulement Pi.
• Extensions et modèles de prompts: Les extensions TypeScript ajoutent des outils personnalisés, des commandes et de l'UI ; les templates de prompts réutilisables s'exécutent via /name. Les deux permettent de scripter la boucle de vérification sans quitter le terminal.
• MCP et thèmes: Pi se connecte aux serveurs MCP pour intégrer du contexte de design externe (plus particulièrement un serveur MCP Figma), et les thèmes se rechargent à chaud pour que l'interface du terminal reste lisible pendant que vous travaillez.

Ce sont des capacités portables — Skills et MCP en particulier — exactement le genre de choses qu'Open Design est conçu pour orchestrer, plutôt que de recréer par projet.

Pi vs Codex vs Claude Code vs Cursor vs Gemini CLI pour le design

Il n'y a pas de gagnant unique pour le travail de design — chaque agent a une force différente, et les équipes expérimentées les superposent. Un résumé équitable :

L'approche de Pi est orthogonale aux autres : c'est l'agent qui vous permet d'utiliser n'importe lequel de ces modèles sous-jacents avec vos propres clés. Le verdict récurrent de la communauté tient toujours — le goût vient des humains : tous adoptent par défaut une esthétique générique sans skills, références et contraintes. C'est le vrai problème à résoudre, et il a la forme d'un outil de design, pas d'un modèle.

Pièges, et comment éviter l'aspect « contenu IA générique »

La plainte la plus courante concernant le design généré par IA est qu'il a l'air générique — des dégradés doux, des panneaux flottants, des coins arrondis surdimensionnés, des ombres dramatiques, une ambiance Inter-et-violet qui « crie qu'une IA l'a créé ». D'autres problèmes signalés incluent des mises en page mobiles cassées et des instructions qui se glissent dans le texte de l'interface. Aucun de ces éléments n'est propre à Pi ou à un modèle particulier ; c'est ce qui se produit lorsque n'importe quel agent s'exécute sans contexte de design organisé.

• Ajoutez un skill esthétique: Un skill design organisé force l'agent à s'engager vers une direction réelle plutôt que le style par défaut — et comme c'est un Skill portable, il vous suit d'un modèle à l'autre.
• Vérifier dans un véritable navigateur: Choisissez un modèle multimodal et faites en sorte que Pi rende et vérifie lui-même sur tous les breakpoints pour que les mises en page ne cassent pas silencieusement sur mobile.
• Fournir des tokens et des références: De véritables tokens de design et des captures d'écran de référence constituent le levier le plus important sur la qualité de sortie.
• Encoder les règles là où Pi les lit: Placez des règles de style comme « pas de hero cards, maximum deux polices, hiérarchie brand-first » dans un Skill que l'agent charge à chaque exécution.

Notez que chaque mesure d'atténuation consiste à fournir à l'agent un contexte de conception soigné — indépendamment du fournisseur vers lequel vous vous dirigez. Maintenir ce contexte manuellement, projet par projet, est la corvée qu'Open Design supprime.

Concevoir avec Pi au sein d'Open Design

Open Design est la couche de conception open-source que le workflow ci-dessus ne cesse de demander. Il traite Pi comme un adaptateur first-party et l'enveloppe dans une bibliothèque de skill et de système de conception soignée, un pipeline de rendu structuré et une interface de bureau locale — de sorte que le contexte de conception qui rend Pi performant est là dès la première exécution, sans être assemblé manuellement à chaque fois. Les deux sont open-source et local-first, ce qui fait de cette association un choix naturel.

1. Installez Open Design et sélectionnez Pi comme agent.
2. Authentifiez-vous avec votre propre clé API de fournisseur (BYOK) ou une connexion par abonnement — les identifiants restent sur votre machine dans ~/.pi/agent/auth.json et ne sont jamais relayés par nos serveurs.
3. Choisissez un design system et un skill, puis générez des decks, des prototypes et des landing pages avec un goût cohérent.
4. Chaque artifact et fichier DESIGN.md réside dans votre propre dépôt, pas dans un cloud hébergé.

Même agent Pi, mêmes clés, même liberté de changer de modèles — plus un véritable workflow de design open-source et portable autour de lui. Il est local-first et MIT, donc rien concernant votre travail ou vos identifiants ne quitte votre machine.

Questions fréquemment posées

1. 01 Pi peut-il vraiment faire du travail de design ? +

   Oui — avec un skill esthétique, un système de design et de vraies images de référence en contexte, Pi produit une interface utilisateur responsive de qualité production, et vous pouvez le router vers un modèle multimodal puissant pour vérifier la sortie par rapport aux références. Sans ce contexte, il a tendance à adopter un aspect générique, ce qui est le fossé que Open Design comble.

2. 02 Dois-je payer pour concevoir avec Pi ? +

   Pi lui-même est gratuit et open source (MIT). Vous ne payez que pour le modèle sous-jacent — apportez votre propre clé API de fournisseur (BYOK), ou utilisez un abonnement Claude Pro/Max, ChatGPT Plus/Pro ou GitHub Copilot via /login. Open Design ne proxie jamais vos identifiants non plus.

3. 03 Qu'est-ce qui rend Pi particulièrement adapté au design ? +

   Il est agnostique de fournisseur : vous apportez vos propres clés et routez vers l'un des 20+ fournisseurs, en choisissant le modèle dont les forces correspondent à la tâche et en changeant en cours de session. Mais le goût provient toujours du système de design, du skill et des références que vous fournissez, pas du modèle.

4. 04 Quel modèle dois-je utiliser avec Pi pour le design frontend ? +

   Pi se connecte à de nombreux fournisseurs, alors choisissez selon la tâche — un modèle multimodal puissant lit bien les captures d'écran de référence, tandis que d'autres peuvent convenir à la refactorisation. L'avantage de Pi est que vous pouvez changer sans modifier votre workflow. Open Design vous permet de conserver le même contexte de design quel que soit le modèle que vous choisissez.

5. 05 Comment connecter Pi à Figma ? +

   Pi prend en charge les serveurs MCP, vous pouvez donc ajouter un serveur MCP Figma et extraire le contexte de design réel — composants, variables, données de mise en page — pour que le code généré corresponde à la source au lieu de l'approximer.

6. 06 Open Design est-il affilié à Pi ? +

   Non. Pi est un projet open-source indépendant d'earendil-works ; Open Design est un projet open-source indépendant distinct qui prend en charge Pi en tant qu'adaptateur first-party.

7. 07 Mes fichiers et identifiants sont-ils en sécurité ? +

   Oui — Open Design est local-first et open source. Vos fichiers, artifacts et DESIGN.md restent dans votre propre dépôt, et vos clés de fournisseur sont utilisées directement par Pi (stockées localement dans ~/.pi/agent/auth.json), jamais routées via les serveurs Open Design.