GitHub Copilot CLI for design.

What GitHub Copilot CLI actually is

GitHub Copilot CLI is GitHub's terminal-native coding agent. It reads your repository, edits files, runs shell commands, and works directly with your GitHub context — issues, pull requests, and repositories — authenticated with your existing GitHub account. It is powered by the same agentic harness as GitHub's Copilot coding agent, so it plans complex tasks and iterates rather than just completing lines. It reached general availability in February 2026 after a public preview that opened in September 2025.

For design work, two properties stand out. It reads custom instruction files — repository-wide rules in .github/copilot-instructions.md plus AGENTS.md — so your design conventions are included automatically on every run. And it supports multiple foundation-model providers, so you can switch the model per task with the /model command to whichever reasons best about a given UI.

• Instruction files: Copilot CLI reads repository instructions in .github/copilot-instructions.md, path-specific files under .github/instructions, and AGENTS.md — the natural place to encode your design conventions, tokens, and review checklists.
• Built-in tools + MCP: It ships with GitHub's MCP server built in and runs file and shell tools, and you can add custom MCP servers with /mcp add (stored in mcp-config.json under ~/.copilot) for external context like a live Figma file.
• Model choice: Use the /model command to pick among frontier models from Anthropic, OpenAI, and Google — switching per task, all on your existing Copilot subscription.

• Vendor: GitHub
• Credential: an active GitHub Copilot subscription (Pro, Pro+, Business, or Enterprise)
• Install: npm install -g @github/copilot, then run copilot

Why repository instructions and model choice fit design

Copilot CLI's design edge comes from two properties — but, as with every agent, taste still has to be supplied.

• Conventions that travel with the repo: Because Copilot CLI reads .github/copilot-instructions.md and AGENTS.md automatically, your tokens, primitives, and review rules are in context on every run — the agent works against a brand instead of a default look.
• Pick the right model per task: Model choice across Anthropic, OpenAI, and Google means you can reach for the model that reasons best about a given layout, then switch for the next task — without changing your workflow.
• Real specs via MCP: The built-in GitHub MCP server plus a Figma MCP server point the agent at your tokens, components, and real specs, so it builds from source instead of approximating.

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

Set up Copilot CLI for design work, from zero

Here is the full path from a clean machine to a Copilot CLI that can build and verify UI.

# 1. Install Copilot CLI (Node.js required)
npm install -g @github/copilot

# 2. Start it in your project and authenticate on first run
cd your-project
copilot           # run /login and follow the prompts to sign in

# 3. Choose a model for the task
#    inside the session:
/model            # pick a frontier model from Anthropic, OpenAI, or Google

# 4. Add custom instructions and the Figma MCP server (optional)
#    write .github/copilot-instructions.md or AGENTS.md
/mcp add          # add the Figma MCP server for design handoff

• Encode your design rules: Put your tokens, primitives, and conventions in .github/copilot-instructions.md or AGENTS.md, so output matches a brand instead of defaulting to a generic look.
• Add browser verification: Wire a Playwright or browser MCP so Copilot renders in a real browser and checks its output across breakpoints instead of only confirming the build passes.

The screenshot-to-UI workflow

The highest-leverage design loop with Copilot CLI is turning a reference image into working, responsive UI and iterating until it matches — leaning on a strong multimodal model to compare output back to the reference.

1. Start from the clearest visual references you have — and include multiple states (desktop and mobile, hover, empty, loading), not just one hero shot.
2. Be specific in the prompt; vague prompts produce generic UI even with a strong model.
3. Keep your design system and conventions in .github/copilot-instructions.md or AGENTS.md, and tell Copilot where the tokens and canonical primitives live.
4. Run a dev server and have Copilot render in a real browser, resizing to breakpoints to check the result.
5. Iterate by having Copilot compare its implementation back to the screenshots — not merely confirm it builds.

Point Copilot at your reference images and give concrete constraints; it previews each file edit or command for your approval before it runs:

copilot
# in the prompt:
> Implement the design in reference-desktop.png and reference-mobile.png
  in React + Vite + Tailwind + TypeScript.
  Reuse my existing design-system components and tokens described in
  .github/copilot-instructions.md.
  Match spacing, layout, and hierarchy; make it responsive.
  Render it in the browser and iterate until it matches the references
  across breakpoints.

Keep prompts small and focused, commit good iterations and revert bad ones (telling Copilot when you revert), so each pass builds on a clean base.

Custom instructions, MCP, and extensions

Three extension points make Copilot CLI practical for sustained design work, and all three map cleanly onto an open design workflow.

• Custom instructions: Repository rules live in .github/copilot-instructions.md (with path-specific files under .github/instructions and AGENTS.md). They are the durable home for your design conventions, included automatically on every run.
• MCP servers: Copilot CLI ships with GitHub's MCP server built in and lets you add custom servers via /mcp add (stored in mcp-config.json under ~/.copilot) — the portable way to bring in design context, most relevantly the Figma MCP server, that works across agents, not just Copilot.
• Specialized agents and built-in tools: Copilot CLI's specialized modes — for codebase exploration, running builds and tests, change review, and planning — plus its file and shell tools let it gather references and run the verification loop without leaving the terminal.

These are portable, multi-agent capabilities — exactly the kind of thing Open Design is built to orchestrate, rather than re-create per project.

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

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

The recurring community verdict is that 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.

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

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 Copilot CLI; 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.
• Verify in a real browser: Render and self-check across breakpoints with a browser MCP 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 in custom instructions: Put “no hero cards, max two typefaces, brand-first hierarchy” style rules in .github/copilot-instructions.md or AGENTS.md, where the agent reads them every run.

Notice that every mitigation is about giving the agent a curated design context. Maintaining that context by hand, per project, is the toil Open Design removes.

Designing with Copilot CLI inside Open Design

Open Design is the open-source design layer the workflow above keeps asking for. It treats GitHub Copilot CLI 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 Copilot good is there from the first run, not assembled by hand each time. Open Design is independent, open-source (Apache-2.0), and local-first, which is why the pairing fits: the agent does the work, your files and credentials stay yours.

1. Install Open Design and select GitHub Copilot CLI as your agent.
2. Authenticate with your GitHub Copilot subscription — credentials stay on your machine and are never proxied through us.
3. Pick a design system and a skill, then generate decks, prototypes, and landing pages with consistent taste.
4. Every artifact and DESIGN.md file lives in your own repo, not a hosted cloud.

Same Copilot CLI agent, same subscription — plus a real, portable, open-source design workflow around it. Open Design is local-first and Apache-2.0, so nothing about your work or your credentials leaves your machine.

Frequently asked questions

1. 01 Can GitHub Copilot CLI really do design work? +

   Yes — with an aesthetic skill, a design system, and real reference images in context, Copilot CLI produces production-quality, responsive UI, and you can pick the model that verifies output best against references. Without that context it tends to default to a generic look, which is the gap Open Design fills.

2. 02 Do I need a subscription to design with Copilot CLI? +

   Yes — Copilot CLI runs on an active GitHub Copilot subscription (Pro, Pro+, Business, or Enterprise); it is not bring-your-own-key. You authenticate with your GitHub account. Open Design never proxies your credentials — your subscription is used directly by your agent.

3. 03 What makes Copilot CLI good for design specifically? +

   Two things: it reads repository instructions and AGENTS.md automatically, so your design conventions travel with the repo; and it lets you switch among frontier models from Anthropic, OpenAI, and Google per task. Both help — but taste still comes from the design system, skill, and references you supply.

4. 04 Copilot CLI or Claude Code for frontend design? +

   Both are strong. Claude Code is known for specific, codebase-aware design decisions; Copilot CLI's edge is model choice across providers and deep GitHub integration on a subscription you may already have. Many teams use both — Open Design lets you switch agents without changing your design workflow.

5. 05 How do I connect Copilot CLI to Figma? +

   Add the Figma MCP server with the /mcp add command; settings are stored in mcp-config.json under ~/.copilot. Copilot can then pull real design context — components, variables, layout data — so the generated code matches the source instead of approximating it.

6. 06 Is Open Design affiliated with GitHub or Microsoft? +

   No. GitHub Copilot CLI is a product of GitHub; Open Design is an independent open-source project that supports it as a first-party adapter. GitHub Copilot is a trademark of GitHub, Inc. and Microsoft.

7. 07 Are my files and credentials safe? +

   Yes — Open Design is local-first and Apache-2.0. Your files, artifacts, and DESIGN.md stay in your own repo, and your GitHub Copilot credentials are used directly by your agent, never routed through Open Design servers.