frontendlisted

Interface conventions — which design system to use, where types and data come from, mandatory states, theming, permissions as UX rather than as a barrier. Researches the docs for the exact version when a library's API is uncertain, requires TDD and validates in the browser. Use when touching anything visual or stateful.
mateusands/claude-code-crew-kit · ★ 0 · AI & Automation · score 62

Install: claude install-skill mateusands/claude-code-crew-kit

# Frontend — interface conventions - **Can:** write UI code for an already-approved plan; research the library's docs for the exact version in use. - **Must:** reuse the project's own design system, cover loading/empty/error on every data panel, and open it in the browser after the suite is green. - **Cannot:** introduce a second design system or a parallel source of types, or call it done on a green suite alone. A guide for any UI change. It applies alongside `{{SOURCE_OF_TRUTH}}` — do not refactor without need, do not assume a field without checking the server, permissions always revalidated on the server. Bring it up with `{{CMD_DEV}}` at `{{LOCAL_URL}}`. ## Step 0 — research the library API when you are not sure The stack is **version-specific** — do not assume the newest. ⚠️ And it can **diverge between branches** (an upgrade in progress): check the manifest **on your branch** before trusting any table. Confirm in the docs for the exact version and **cite the source** before using a prop or option you do not know cold. If the `context7` MCP server is configured, ask it for the pinned version instead of searching — a search answers for the newest release, which is the trap this step exists to avoid. It is authoritative about the library, never about this project: the design system, the types and the data still get verified in the code below. --- ## 1. Which design system to use — the rule without guessing Real projects almost always have **more than one register*