ibelick/ui-skills

# Baseline UI

Enforces an opinionated UI baseline to prevent AI-generated interface slop.

## How to use

- `/baseline-ui`
  Apply these constraints to any UI work in this conversation.

- `/baseline-ui <file>`
  Review the file against all constraints below and output:
  - violations (quote the exact line/snippet)
  - why it matters (1 short sentence)
  - a concrete fix (code-level suggestion)

# Component canvas

Build a canvas that shows the project's existing components as they really behave. The canvas wraps components. It never changes them.

## Ground rules

- Do not modify component source, exports, styles, hooks, or behavior to make the canvas work. Components must not import or depend on canvas code.
- Do not patch libraries, browser APIs, rendered component DOM, or portal roots.
- Show only the components the user asked for. Adding components, installing dependencies, changing a component's design, or making the canvas public requires permission first.
- Keep existing access controls.
- Leave unrelated work alone. If removing an earlier canvas integration, undo only its changes to components.
- Follow any restrictions on commands, browser access, dependencies, and edits.

## Before building

# Create canvas

Build a freeform workspace for exploration and iteration through conversation. The model changes content in source files. The canvas makes that content live, named, movable, and easy to reference.

## Start with the project

- Read repository rules, routes, component APIs, themes, design tokens, and tests.
- Look for an existing canvas before creating another.
- Use the project's framework, components, typography, design tokens, themes, and access controls.
- Respect restrictions on edits, commands, and browser access.
- Ask before changing scope, adding dependencies, changing shared code, or exposing the canvas publicly.
- If safe isolation is unclear, ask before proceeding. Never mount an unsafe preview.
- Choose sensible defaults for other decisions. Do not ask the user to repeat clear requests.
- Keep canvas code together. Separate camera and placement logic from previews, test data, and their registry. Do not build a framework.

# Create DESIGN.md

Create a `DESIGN.md` for one product or coherent website. Record the design language that governs it, not every value that happens to exist.

## Boundaries

- Modify only `DESIGN.md`. Do not change product source, dependencies, configuration, or generated files.
- Use the DESIGN.md format contract below. Do not invent a competing schema.
- Do not copy every discovered token or component into the document.
- Do not convert repetition, local styling, or visual preference into product intent.

## 1. Choose the mode

### Repository mode

# fixing-accessibility

Fix accessibility issues.

## how to use

- `/fixing-accessibility`
  Apply these constraints to any UI work in this conversation.

- `/fixing-accessibility <file>`
  Review the file against all rules below and report:
  - violations (quote the exact line or snippet)
  - why it matters (one short sentence)
  - a concrete fix (code-level suggestion)

## Workflow

1. Identify pages with missing or incorrect metadata (titles, descriptions, canonical, OG tags)
2. Audit against the priority rules below — fix critical issues (duplicates, indexing) first
3. Ensure title, description, canonical, and og:url all agree with each other
4. Verify social cards render correctly on a real URL, not localhost
5. Keep diffs minimal and scoped to metadata only — do not refactor unrelated code
## when to apply

Reference these guidelines when:
- adding or changing page titles, descriptions, canonical, robots
- implementing Open Graph or Twitter card metadata
- setting favicons, app icons, manifest, theme-color
- building shared SEO components or layout metadata defaults

# fixing-motion-performance

Fix animation performance issues.

## how to use

- `/fixing-motion-performance`
  Apply these constraints to any UI animation work in this conversation.

- `/fixing-motion-performance <file>`
  Review the file against all rules below and report:
  - violations (quote the exact line or snippet)
  - why it matters (one short sentence)
  - a concrete fix (code-level suggestion)

# Improve UI

Audit one coherent product surface against the system that actually governs it. Preserve the product's identity, reuse existing owners, and prefer no finding to an unsupported one. Write plans only for changes the user selects; another agent executes them.

## Boundaries

- Never modify product source. Create or edit files only under `design-plans/`.
- Do not install dependencies, run formatters, commit, push, or otherwise mutate the working tree.
- Do not update design documentation. Record accepted documentation changes in the plan for its executor.
- Use rendered evidence only when the user provides it or explicitly requests visual inspection.
- Make every plan self-contained; its executor has no context from the audit or conversation.

## 1. Select the surface

# UI Skills Root

You are the routing layer for UI Skills.

This skill is shown by `npx ui-skills start` and is also available in the registry.

Use it when an agent in Codex, Cursor, or Claude Code has a clear UI goal.

If the goal is unclear, ask one short question.

If the goal is clear, choose the right category, load the smallest useful skill context, then implement.

## Protocol