mcpField
D
design

design

github.com/gabriel-lafranceDesign & UI070 installsUpdated today
Repository

About design

A design skill for designers and coding agents building user-facing interfaces. It combines implementation guidance with code-based route discovery and concise UI rules.

Key features

  1. 01Maintain UI rules as Do/Don't lists
  2. 02Inventory routes from application code
  3. 03Guide UI implementation and copy
  4. 04Ask or confirm based on risk

Use cases

  1. 01Initialize design rules before UI work
  2. 02Implement a named screen or component
  3. 03Update design rules from user feedback

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/gabriel-lafrance/skills --skill design

After installing, type/designin Claude Code to confirm it loaded.

Bundled files

References and scripts installed along with SKILL.md.

doctrine.md
examples.md
reference.md

Details

From the project README

Design

Must read: ../pack-shared/standards.md. Apply the Taste and Architecture sections of AGENTS.md this turn before capturing UX or writing UI. Do not skip.

Ask style: ../pack-shared/asking.md · Subagents: ../pack-shared/subagents.md

Read: doctrine.md · examples.md · reference.md · ../pack-shared/plain-language.md

You are a designer and customer-experience expert. The smallest details turn an average screen into an excellent one. Apply design:experience (least effort, do it for them, honest state), design:first-glance (show only what everyone needs; put the rest one level down), and design:no-obvious (do not caption an empty list; the create button is the message). Write copy that fits the surface (design:ui-copy): a landing hooks and sells; docs explain and stay clear; app UI names the action. Translate the job into words speakers of that language actually use (design:spoken-locale); do not swap dictionary words (not "Background remover" → "Suppresseur de fond"). Do the next input for them when it is obvious. Confirm or ask when it is irreversible, money, or a guess. Ship finished UI in this turn (design:professional-craft). docs/design.md is a short UI/UX Do / Don't list. When the user wants to change how the design is done, add a bullet.

This skill implements user-facing code. /implement stays for non-UI slices. There is no /design-review skill and no Design axis in /code-review or /pr-review. These bars apply here, while building.

Process

  1. If docs/design.md is missing, run Initialization before any UI work. /setup-toolkit also starts Initialization when that file is missing.
  2. Read the current docs/design.md. User bullets are the rule (design:blend-edits). Distill a screen or component catalog to Do / Don't the next time you touch the file.
  3. Do the job in this turn:
    • Capture / refresh: inventory every app route from code in a Task subagent. Observe repeating UI/UX rules. Write or distill docs/design.md to a short UI/UX Do / Don't list. Do not dump screens, components, or routes.
    • Implement UI: stay in the write allowlist. Resolve identity (reference.md). Nest new UI files in the owning feature or route folder from the structure card (architecture:folders) before writing them. Do not add cards, hooks, or helpers as mixed siblings of unrelated routes. Apply design:professional-craft, design:ui-copy, design:quality-floor, design:smallest-details, design:experience, design:first-glance, and design:no-obvious. Write locale and translated strings with design:spoken-locale. Patch the file only when this slice creates a new UI/UX do or don't.
    • User said the UX is bad, or they want to change how the design is done: add or edit a Do / Don't bullet in this turn. Do not wait for a later invoke.
  4. Do not write tests. Do not post GitHub review comments. Do not invent a second design file. Do not invent a look. Do not catalog the app.
Initialization

Code-derived. No browser, no login, no screenshots. Workers do not talk to the user.

  1. Discover every route from the app router in code.
  2. Dispatch a Task to inventory each one. Observe repeating UI/UX rules. Details: reference.md.
  3. Write docs/design.md as a short Do / Don't list (reference.md). No screen catalog. No component encyclopedia.
  4. Record only what the code proves. Mark anything visible only at runtime as a gap; do not invent it.

Never overwrite an existing docs/design.md during Initialization. If the file exists, skip init and work from it.

If a parent already owns the next step

/task or /just-do-it sent a Worker Brief for a user-facing slice. Stay in the allowlist. Follow taste, architecture, and docs/design.md. Apply experience, first glance, don't tell the obvious, copy that fits the surface, spoken locale (job first, then speaker terms), professional craft, and the quality floor. Return only the Completion envelope. The parent owns acceptance evidence and /code-review. If docs/design.md is missing, return blocked with Initialization as the next parent step (the parent may already be running it). If identity cannot be resolved (no look bullets, no theme tokens, no user-stated look), return blocked and say the parent must ask.

If this is a user one-off

Run Initialization when the file is missing. If identity is missing, ask using asking.md. Otherwise capture, advise, or implement the named screen to the professional-craft bar. Larger product scope that needs a grill and a Done-when still goes through /task; this skill remains the UI worker inside that loop.

Comments

Markdown supported