Google stitch shadcn ui
Claude Code skill/plugin that rewrites a raw question into a high-performing LLM prompt by auto-selecting research-backed prompt-engineering strategies.
npx -y skills add host452b/polish --skill google-stitch-shadcn-uiAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Use when implementing or reviewing a React interface with shadcn/ui and it needs coherent theming, component composition, variants, accessibility, interaction states, responsive behavior, or visual consistency.
SKILL.md
3.3 KB, as published. Nobody here has run it
shadcn/ui Interface Integration
Overview
Build product interfaces from owned shadcn/ui source without turning registry primitives into domain components. Start from the project’s real configuration and design contract, then compose accessible states and verify them in context.
Workflow
- Inspect before installing. Read
components.json,package.json, global CSS, Tailwind configuration, import aliases, installedcomponents/ui, existing composed components, project scripts, andDESIGN.mdwhen present. Runscripts/verify-setup.shwhen setup is uncertain. - Reuse the project vocabulary. Match its registry style, primitive library, icon set, CSS-variable convention, radii, spacing, and dark-mode strategy. Do not introduce a second token system or arbitrary colors.
- Choose the boundary. Keep reusable primitives in
components/ui. Put product data, copy, routing, permissions, async behavior, and domain-specific composition outside that directory. Wrap or compose primitives rather than embedding business logic into them. - Model states explicitly. Cover applicable default, hover, focus-visible, active, selected, disabled, loading, empty, validation, error, success, and partial-data states. Preserve accessible names, descriptions, keyboard behavior, focus management, and non-color cues.
- Design responsive behavior. Specify ordering, stacking, overflow, action placement, target size, and information priority at the project’s existing breakpoints. Do not shrink dense desktop UI until it becomes unreadable.
- Verify with project commands. Run the available typecheck, lint, and tests; inspect light/dark themes and narrow/wide viewports; complete keyboard and accessibility checks. Report commands and observed results.
Reference Routing
- New or uncertain setup: setup-guide.md
- Component selection: component-catalog.md
- Tokens, variants, and composition: customization-guide.md
- Existing-library migration: migration-guide.md
- Complete form composition: form-pattern.tsx
Decision Rules
| Need | Preferred response |
|---|---|
| Primitive already exists | Reuse it; do not reinstall |
| Product-specific variant | Compose or wrap outside components/ui |
| Reusable visual variant | Add a typed variant while preserving primitive semantics |
| Registry source needs updating | Review the diff; preserve intentional local changes |
| No design contract exists | Infer from repeated project tokens and label assumptions |
Common Mistakes
- Installing components before checking the project registry and aliases.
- Editing copied primitives for one screen’s business logic.
- Using one-off class strings instead of tokens and variants.
- Treating a dialog, toast, or card as the default answer to every hierarchy problem.
- Testing only the ideal desktop state.
- Claiming accessibility from the primitive alone after custom composition.