agentleFS
evgenii-studitskikhevgenii-studitskikh/Claude-Code-SaaS-Studio/.claude/skills/design-ui/SKILL.md

design-ui

Skill1 starsChanged 5 months agoMITView on GitHub

For each screen in flows.md, select shadcn/ui components and layout, note empty/loading/error states, and document basic accessibility. Drafts ui.md then awaits approval.

11 other projects use a version of this.

Adopted by

Most recently taken up by

The file

Files
SKILL.md

Define the component-level UI specification for every screen in the approved screen list, grounded in shadcn/ui and Tailwind conventions, so that frontend-engineer can build with minimal back-and-forth. Non-autonomous: component choices are proposed and confirmed before the spec is written.

Phases

  1. Load flows — read docs/specs/flows.md. If missing, stop and direct to /map-flows. If a specific screen name was passed as an argument, scope this run to that screen only; otherwise process all screens.
  2. Propose layout and components — for each screen, suggest: overall layout pattern (full-page, split-panel, modal, drawer), the primary shadcn/ui components (Card, DataTable, Form, Dialog, etc.), and any Tailwind utility patterns. Reference shadcn/ui component names exactly so the frontend-engineer can look them up directly.
  3. Specify interaction states — for every screen, explicitly call out: empty state (what the user sees before any data), loading state (skeleton or spinner approach), and error state (inline error, toast, or full-page). Missing these is a common source of rework — do not skip.
  4. Note accessibility — for each screen note the required ARIA landmarks, focus-trap requirements (for modals/drawers), and any keyboard navigation considerations. Flag any component where shadcn defaults need augmentation.
  5. Approval gate — under full review, walk through each screen's spec with the user; under lean or solo, present a summary table and ask for a single sign-off. Do not write until approved.
  6. Write the spec — write docs/specs/ui.md with the approved component decisions. Next step: point to /setup-stack (if scaffold not yet created) or /build-feature.

Output

docs/specs/ui.md — per-screen component spec. Writes nothing else without approval.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.