mcpField
I
interface-craft

interface-craft

github.com/sylphxaiDesign & UI168 installsUpdated 1d ago
Repository

About interface-craft

Interface Craft is a skill for building, polishing, or reviewing user interfaces. It guides focused improvements using relevant rules while preserving usability and accessibility safeguards.

Key features

  1. 01Build, polish, and review modes
  2. 02Surface-specific interface workflow
  3. 03Restraint checks for proposed details
  4. 04Accessibility and interaction guardrails
  5. 05Prioritized findings with implementation plans

Use cases

  1. 01Adding considered details while building a UI
  2. 02Polishing an existing interface consistently
  3. 03Reviewing interface states and prioritizing fixes

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/sylphxai/skills --skill interface-craft

After installing, type/interface-craftin Claude Code to confirm it loaded.

Bundled filesagents/openai.yamlreferences/interface-craft-rules.md

Details

From the project README

Interface Craft

Use this skill to make UI feel intentional without turning polish into decoration.

Resolve the mode

  • Build: add relevant craft details while implementing UI.
  • Polish: improve existing UI directly and explain high-impact changes.
  • Review: do not edit unless asked; produce concise findings with file/line evidence.

If the user's intent is ambiguous, assume Review for existing code and Build for new UI.

Workflow

  1. Identify the surface: form, button, navigation, loading state, empty state, content display, motion, or platform shell.
  2. Read references/interface-craft-rules.md and load only the relevant section(s).
  3. Apply the restraint gate before proposing any detail.
  4. In Build/Polish mode, implement the smallest consistent improvement across sibling surfaces.
  5. In Review mode, rank the few highest-impact findings, cover every requested state, then give the smallest implementation plan.

Guardrails

Skip a detail if any answer is no:

  • Does it help the user complete or understand the task?
  • Does it preserve keyboard, screen reader, touch, and reduced-motion behavior?
  • Is it consistent with the product's existing system?
  • Is the effect quieter when the interaction is frequent?
  • Can the improvement be described in observable terms?

Output format

P0 — path/to/File.tsx:42 — ic-form-1
Issue: Label is visually present but not programmatically associated with the input.
Fix: connect label and input with htmlFor/id or wrap the input in the label.

Implementation plan:
1. Fix P0 accessibility and state blockers first.
2. Add loading/error/success/focus/reduced-motion tests or stories.
3. Apply the same pattern to sibling controls only after the first surface is verified.

Keep review findings high-signal. Prefer 3 to 6 material fixes over 20 cosmetic notes. For checkout/payment surfaces, explicitly cover disabled, loading, duplicate-submit, error, success, focus, mobile touch target, and reduced-motion states when present in the prompt.

When not to use

  • Do not use to invent a brand identity, extract a whole design system, or certify formal accessibility conformance when the requested artifact is not an interface build/polish/review.
  • Do not issue file-level findings without seeing the relevant code, screenshots, or interaction states; state the evidence gap and give an inspection plan instead.

Comments

Markdown supported