GitHub Copilot UI design that passes review

Copilot is good at doing what the issue says. The trouble with UI is that issues rarely say much: "add a projects page" gets you a table that works with ten projects and shows "No data" to every new team. The fix is to give Copilot the missing parts, once in the repository and once per task.

Example task used in this guide: the first-use state of a Projects page, the first screen every new team sees.

Write the issue like a brief

When you assign an issue to Copilot, the issue is the brief. Say who the screen is for, what they should be able to do when it's done, what must not change, and which states to cover. One specific design question ("how do good apps handle an empty list on first use?") is more useful than "make it modern".

The free UI design prompt builder turns those answers into a brief you can paste straight into an issue or Copilot Chat. Choose GitHub Copilot as the agent.

Put UI rules where Copilot reads them

Copilot reads .github/copilot-instructions.md for the whole repository. Keep it short, with the few rules that apply to every UI change:

## UI work

- Reuse the components in src/components/ui. Don't restyle them inside a page.
- Every list or page that loads data needs designed empty, loading and error states.
- Before calling UI work done, render it and check 390px and 1440px widths and keyboard use.

Put the detailed UI rules in a path-specific file, so they only apply when Copilot works on UI files. Files in .github/instructions/ ending in .instructions.md use applyTo to say which files they cover:

---
applyTo: "**/*.tsx,**/*.jsx,**/*.css"
---

# UI files

- Use our spacing and color tokens from src/styles/tokens.css. No one-off hex values.
- Write labels in the product's words ("Create project"), never "Submit" or "Get started".
- Empty states say what the thing is, give one main action, and offer a secondary way in if there is one.
- When a layout or wording decision isn't covered here and UXKIN is connected, look it up with find_ui_references and name the reference you used.

Adjust the paths and component names to your project. If your repository already has an AGENTS.md, Copilot reads that too; keep one source for each rule so they don't drift apart.

Add the no-ui-slop skill

Instructions say what the rules are. A skill gives Copilot a workflow to follow for a kind of task. UXKIN's free no-ui-slop skill walks through five steps for any UI work: understand the task, find references, gather materials, build, and review the rendered result.

Copilot looks for project skills in .github/skills. Adding it there and committing it means the cloud agent, code review, the Copilot CLI and VS Code agent mode all use it:

mkdir -p .github/skills/no-ui-slop
curl -fsSL https://uxkin.com/.well-known/agent-skills/no-ui-slop/SKILL.md \
  -o .github/skills/no-ui-slop/SKILL.md

The skill needs no token or account. It works on its own, and uses UXKIN's tools when they're connected.

Review the pull request

Copilot's work arrives as a pull request, which makes it a good moment to check the UI properly, not just the code:

• Open the preview (or run the branch) and see the empty state as a new team would: no projects, then one project.
• Make the request fail on purpose. There should be a clear error and a retry, not a blank page.
• Check a phone width (390px), a desktop width (1440px) and the keyboard.
• Read the pull request description: it should list what Copilot checked and what it couldn't. Ask for that list if it's missing.

The coding agent UI checklist has all 10 checks with a test for each, and a report you can paste back into the pull request as a review comment.

Connect UXKIN to Copilot

Connecting UXKIN lets Copilot look up real app screens and website design systems when a decision isn't covered by your rules. Get your token from your setup prompt (it's on the Agent SDK tab once you're logged in), then set up the Copilot you use.

VS Code

Add .vscode/mcp.json to your repository. It doesn't contain the token: VS Code asks for it the first time the server starts and stores it securely, so the file is safe to commit and each teammate uses their own token.

{
  "inputs": [
    {
      "type": "promptString",
      "id": "uxkin-token",
      "description": "UXKIN token",
      "password": true
    }
  ],
  "servers": {
    "uxkin": {
      "type": "http",
      "url": "https://uxkin.com/mcp",
      "headers": {
        "Authorization": "Bearer ${input:uxkin-token}"
      }
    }
  }
}

Open Copilot Chat in Agent mode. The UXKIN tools show in the tools list once the server is running.

Copilot CLI

Replace YOUR_UXKIN_TOKEN with your token:

copilot mcp add --transport http \
  --header "Authorization: Bearer YOUR_UXKIN_TOKEN" \
  uxkin https://uxkin.com/mcp

This saves the server to ~/.copilot/mcp-config.json on your computer, outside your repository. Don't copy that file into a project.

Copilot cloud agent

1. In your repository, go to Settings → Secrets and variables → Agents and add a secret named COPILOT_MCP_UXKIN_TOKEN with your token as the value.
2. Go to Settings → Copilot → MCP servers, paste this into MCP configuration and click Save MCP configuration:

{
  "mcpServers": {
    "uxkin": {
      "type": "http",
      "url": "https://uxkin.com/mcp",
      "headers": {
        "Authorization": "Bearer $COPILOT_MCP_UXKIN_TOKEN"
      },
      "tools": ["*"]
    }
  }
}

To check it, assign an issue to Copilot, open the pull request, click View session, then … → Copilot, and open the Start MCP Servers step: uxkin should be listed with find_ui_references and find_ui_materials. Copilot code review uses the same configuration.

An issue you can use

Adapt the file path and names, then assign the issue to Copilot. It gives the who, the outcome, the states and how the result will be checked:

Title: Design the first-use state of the Projects page

The Projects page (src/app/projects/page.tsx) shows an empty table with "No data" when a team has no projects yet. That's the first thing every new team sees.

Who it's for: a team admin who just signed up and wants to set up their first project.
Done means: they understand what a project is and can create one (or import a CSV) from this screen.

Before building:
- Read the existing Projects page, the table and button components, and our tokens.
- If UXKIN is connected, use find_ui_references to look at how two real apps handle a first-use empty state for a list, and say what you're taking from each.

Build:
- A first-use state: one sentence on what a project is, one primary "Create your first project" button, a secondary "Import from CSV" link.
- Keep the table for when projects exist. Also cover loading, and a failed request with a retry.
- Don't change the create or import flows themselves.

Check: render it at 390px and 1440px, use it by keyboard, and list in the pull request what you checked and anything you couldn't.

Questions