Question 1

Can Pi Really Do Design Work?

Accepted Answer

Yes — with an aesthetic skill, a design system, and real reference images in context, Pi produces production-quality, responsive UI, and you can route it to a strong multimodal model to verify output against references. Without that context it tends to default to a generic look, which is the gap OpenDesign fills.

Question 2

Do I Need to Pay to Design With Pi?

Accepted Answer

Pi itself is free and open source (MIT). You pay only for the underlying model — bring your own provider API key (BYOK), or use a Claude Pro/Max, ChatGPT Plus/Pro, or GitHub Copilot subscription via /login. OpenDesign never proxies your credentials either way.

Question 3

What Makes Pi Suited for Design?

Accepted Answer

It is provider-agnostic: you bring your own keys and route to any of 20+ providers, picking the model whose strengths fit the task and switching mid-session. But taste still comes from the design system, skill, and references you supply, not from the model.

Question 4

Which Model Should I Use With Pi for Frontend Design?

Accepted Answer

Pi routes to many providers, so choose per task — a strong multimodal model reads reference screenshots well, while others may suit refactoring. The advantage of Pi is that you can switch without changing your workflow. OpenDesign lets you keep the same design context across whichever model you pick.

Question 5

How Do I Connect Pi to Figma?

Accepted Answer

Pi supports MCP servers, so you can add a Figma MCP server and pull real design context — components, variables, layout data — so the generated code matches the source instead of approximating it.

Question 6

What Pi actually is

Accepted Answer

Pi is an open-source (MIT) AI coding agent for the terminal, part of the earendil-works pi toolkit. It reads your repository, edits files, and runs shell commands — planning and verifying work from natural-language tasks rather than just completing lines. Its core is deliberately small: four default tools — read, write, edit, and bash — plus built-in grep, find, and ls.

For design work, the standout property is that Pi is provider-agnostic. It normalizes across Anthropic, OpenAI, Google and many other providers behind one unified API, so you bring your own keys and choose the model per task — for example a strong multimodal model to read reference screenshots — and switch with /model or Ctrl+L mid-session without changing your workflow.

Any model, your keys: Pi routes to 20+ providers including Anthropic and OpenAI. You authenticate with your own API keys (BYOK), or sign in to a Claude Pro/Max, ChatGPT Plus/Pro, or GitHub Copilot subscription with /login.

Skills + Extensions: Pi loads Skills (Markdown capability packages following the Agent Skills standard) and TypeScript Extensions — the natural place to encode your design conventions and add custom tools.

Branching sessions: Sessions are stored as JSONL trees, so you can branch an exploration and navigate history in a single file without losing earlier passes.

Credential: your own provider API key (BYOK — Anthropic, OpenAI, Google, etc.) or a subscription login via /login; stored locally in ~/.pi/agent/auth.json (0600)

Vendor: earendil-works (open-source community project)

License: MIT, open source

Question 7

Why a multi-provider, BYOK agent fits design

Accepted Answer

Pi’s design edge is flexibility, not a single built-in model — but, as with every agent, taste still has to be supplied.

Pick the right model per task: Because Pi routes to any provider, you can reach for a strong multimodal model to read reference screenshots, then switch to another for refactoring — without leaving the agent.

Your keys, no lock-in: BYOK means you are not tied to one vendor’s pricing or context limits; choose the model whose strengths fit the design job in front of you.

Conventions in Skills: A Skill (plus an MCP source like a Figma server) points the agent at your tokens, components, and real specs, so it works against a brand instead of a default look.

Taste comes from three inputs you provide: a design system, a skill, and real reference images.

The lesson is the same one every agent teaches: Pi does not have taste by default, and no model choice supplies it. It produces good design when you give it constraints — a design system, an aesthetic skill, and concrete references. OpenDesign packages exactly those inputs, which is why the two fit together (more below).

Question 8

Set Up Pi for Design Work from Scratch

Accepted Answer

The setup sequence: install → authenticate (BYOK) → encode design rules in a Skill → choose a model → enable browser verification.Encode your design rules: Put your tokens, primitives, and conventions in a Skill and point Pi at them, so output matches a brand instead of defaulting to a generic look.Add browser verification: Wire a Playwright or browser MCP so Pi renders in a real browser and checks its output across breakpoints instead of only confirming the build passes.Use the current setup section for commands and version-specific details, which may change.# 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+LHistorical command example from the previous guide; verify current syntax in the linked vendor documentation.

Question 9

The screenshot-to-UI workflow

Accepted Answer

The highest-leverage design loop with Pi is turning a reference image into working, responsive UI and iterating until it matches — leaning on a multimodal model to compare output back to the reference. Because Pi is provider-agnostic, point it at whichever model reads images best for this pass.Start from the clearest visual references you have — and include multiple states (desktop and mobile, hover, empty, loading), not just one hero shot.Pick a strong multimodal model for the pass with /model, since image understanding is what drives screenshot-to-UI quality.Be specific in the prompt; vague prompts produce generic UI even with a strong model.Keep your design system and conventions in a Skill, and tell Pi where the tokens and canonical primitives live.Run a dev server and have Pi render in a real browser, resizing to breakpoints, then iterate by comparing its implementation back to the screenshots — not merely confirm it builds.Give the agent the references and concrete constraints up front:Keep prompts small and focused, commit good iterations and revert bad ones (telling Pi when you revert), so each pass builds on a clean base. Pi’s branching JSONL sessions also let you explore an alternative without losing the original thread.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.Historical command example from the previous guide; verify current syntax in the linked vendor documentation.

Question 10

Skills, Extensions, and themes

Accepted Answer

Pi self-extends at runtime through a few layers, and they map cleanly onto an open design workflow.

Skills: Markdown capability packages following the Agent Skills standard — the durable, portable home for your design conventions, tokens, and review checklists. The same Skill works across compatible agents, not just Pi.

Extensions and prompt templates: TypeScript Extensions add custom tools, commands, and UI; reusable prompt templates run via /name. Both let you script the verification loop without leaving the terminal.

MCP and themes: Pi connects to MCP servers to bring in external design context (most relevantly a Figma MCP server), and themes hot-reload so the terminal UI stays readable while you work.

These are portable capabilities — Skills and MCP especially — exactly the kind of thing OpenDesign is built to orchestrate, rather than re-create per project.

Question 11

Pi vs Codex vs Claude Code vs Cursor vs Gemini CLI for design

Accepted Answer

There is no single winner for design work — each agent has a different strength, and experienced teams stack them. A fair summary:

Pi — Provider-agnostic and BYOK — route to any model (Anthropic, OpenAI, Google…) and switch mid-session; MIT, self-extensible — Choosing the best model per task without vendor lock-in

Codex — Strong visual polish with a frontend skill; sandboxed async builds — Delegated async builds and portable AGENTS.md rules

Claude Code — Specific design decisions (hex, spacing, type) and codebase-aware UX — Frontend reasoning and large-context refactors

Cursor — Visual build-and-see loop with live preview and inline edits — Tight iterate-and-watch UI work inside an IDE

Gemini CLI — Strong multimodal image understanding and a 1M-token context; free tier — Screenshot-heavy work and holding a whole design system in context

Pi’s angle is orthogonal to the others: it is the agent that lets you use any of those underlying models on your own keys. The recurring community verdict still holds — taste comes from humans: all of them default to a generic aesthetic without skills, references, and constraints. That is the real problem to solve, and it is design-tool-shaped, not model-shaped.

Agent — Design strength — Best for

Question 12

Pitfalls, and how to avoid the “AI slop” look

Accepted Answer

The most common complaint about AI-generated design is that it looks generic — soft gradients, floating panels, oversized rounded corners, dramatic shadows, an Inter-and-purple vibe that “screams an AI made this.” Other reported issues include broken mobile layouts and instructions leaking into UI copy. None of these are unique to Pi or to any one model; they are what happens when any agent runs without a curated design context.

Add an aesthetic skill: A curated design skill forces the agent to commit to a real direction instead of the default look — and since it is a portable Skill, it travels with you across models.

Verify in a real browser: Pick a multimodal model and have Pi render and self-check across breakpoints so layouts do not silently break on mobile.

Supply tokens and references: Real design tokens and reference screenshots are the single biggest lever on output quality.

Encode rules where Pi reads them: Put “no hero cards, max two typefaces, brand-first hierarchy” style rules in a Skill the agent loads every run.

Notice that every mitigation is about giving the agent a curated design context — independent of which provider you route to. Maintaining that context by hand, per project, is the toil OpenDesign removes.

Question 13

Designing with Pi inside OpenDesign

Accepted Answer

OpenDesign is the open-source design layer the workflow above keeps asking for. It treats Pi as a first-party adapter and wraps it in a curated skill and design-system library, a structured render pipeline, and a local desktop UI — so the design context that makes Pi good is there from the first run, not assembled by hand each time. Both are open-source and local-first, which makes the pairing a natural fit.

Authenticate with your own provider API key (BYOK) or a subscription login — credentials stay on your machine in ~/.pi/agent/auth.json and are never proxied through us.

Pick a design system and a skill, then generate decks, prototypes, and landing pages with consistent taste.

Every artifact and DESIGN.md file lives in your own repo, not a hosted cloud.

Same Pi agent, same keys, same freedom to switch models — plus a real, portable, open-source design workflow around it. It is local-first and MIT, so nothing about your work or your credentials leaves your machine.

Install OpenDesign and select Pi as your agent.

Question 14

Is OpenDesign affiliated with Pi?

Accepted Answer

No. OpenDesign is independent and integrates Pi as a community-supported adapter.

Design With
Pi in
OpenDesign.

Pick Your Starting Point for Pi

Create a Product Interface Using Pi

Set Up Pi From Zero

Compare Pi With Other Agents

A Pi Design Job: Brief Through to Interface

1Design Brief and Constraints

2Who Does What: You, Pi and OpenDesign

3Pi Artifact: Plan Comparison Page at 1440px and 390px

4Review Before Handoff

Grid and Spacing

Visual Hierarchy

Mobile Layout

Interaction Checks

When Pi Is the Right Fit—and When It Is Not

Pi Fits When

Choose Another Workflow When

Pi Requirements Before You Start

Tool ScopePi, by community

Accounts and AuthenticationYour own provider API key (BYOK) or

System and VersionsDesktop app or source

Connection CheckThe success signal

Pi Setup in Three Steps

Download the OpenDesign Desktop App

Prepare Your Pi Connection

Run One Small Pi Task

Pi's Five-Step Design Workflow

Design Brief

Design Constraints

Generate the Interface

Preview

Revise and Verify

Pi Design Resources

Further Reading for Pi

Design Skills

Design Systems

Templates

Pi Limitations, Manual Checks and Fallbacks

Common Questions About Pi and OpenDesign

Design With Pi in OpenDesign.