Frontend design
Design or implement frontend UI with restrained craft, clear hierarchy, and explicit UX/UI decision questions before building. Use when asked for a clean page, compact component, dashboard panel, form, settings screen, app UI, landing page, or when the user wants smaller scope, fewer decorative choices, or design review before implementation.From its SKILL.md
npx -y skills add bakerstreetco/skills --skill frontend-designAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 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.
SKILL.md
4.3 KB, 766 tokens by cl100k_base, as published. Nobody here has run it
Frontend Design
Use this skill to create focused frontend interfaces with deliberate visual design. Favor clarity, hierarchy, spacing, accessible controls, and implementation restraint over novelty or decoration.
Shared Baseline
Frontend design skills converge on the same useful habits: decide intent before coding, make one clear visual direction, constrain type/color/motion systems, avoid generic template defaults, keep copy purposeful, and verify the final UI in real viewports.
Workflow
- Inspect the product context, existing UI, design system, routes, components, and styles before proposing changes. This keeps new work aligned with the real app instead of inventing a parallel look.
- Identify the smallest useful surface: the specific component, page region, state, or workflow that needs design. Avoid expanding into landing pages, hero treatments, or broad redesigns unless the user explicitly asks.
- Ask only the key UX/UI questions before implementing when the answers are missing and materially affect the result. Prefer 2-5 concrete questions about audience, primary action, information priority, density, navigation, states, and visual restraint.
- Before coding, state or infer a compact design direction: purpose, tone, constraints, primary hierarchy, and one detail that makes the UI specific to this product.
- If the user has already supplied enough direction, state the assumptions briefly and proceed. Do not block on cosmetic preferences that can be inferred from the existing product.
- Choose a quiet design system: legible type, clear spacing rhythm, low-noise color, obvious affordances, predictable layout, purposeful copy, and restrained motion. Use brand or repo colors when present.
- Implement the smallest complete experience, including empty, loading, error, disabled, focused, and responsive states when relevant. Keep controls stable in size and avoid layout shifts.
- Validate the result in the app or with the closest available checks. Verify text fit, focus states, contrast, keyboard behavior, and mobile/desktop layout for user-facing surfaces.
Question Guide
Ask questions that change the implementation:
- Primary job: What should the user accomplish first?
- Priority: Which information or action must be most visible?
- Density: Should this be compact for repeated use or spacious for comprehension?
- Tone: Should it feel utilitarian, calm, editorial, premium, playful, or match an existing screen?
- Boundaries: Should this be a narrow component pass or a page-level layout pass?
Skip questions when the repository already answers them through nearby UI, design tokens, copy, or established workflow patterns.
Design Rules
- Prefer existing components, tokens, icons, forms, and spacing scales.
- Use cards only for repeated items, dialogs, or genuinely framed tools.
- Keep palettes restrained but not monochrome; use accent color for action or status, not decoration.
- Use motion sparingly for feedback and transitions; avoid ornamental animation.
- Make hierarchy visible through layout, weight, spacing, and alignment before adding borders or backgrounds.
- Keep copy short and task-oriented; do not add explanatory marketing text inside tools.
- Preserve accessibility: labels, focus indicators, keyboard paths, semantic controls, and readable contrast.
Avoid
- Generic SaaS card grids when plain layout, sections, lists, or tables would scan better.
- Decorative gradients, thick borders, dramatic shadows, or motion that does not clarify hierarchy.
- Marketing-style hero copy inside operational product UI.
- More than two typefaces, competing accent colors, or visual systems that ignore existing tokens.
- Building a broad visual redesign when the user asked for a narrow interface decision.
Output
Return the design questions first when needed. After implementation, summarize the decisions made, files changed, and verification performed. Note any unanswered decision handled as an assumption.
What ships with it: 2 files
797 B alongside SKILL.md
agents/
- openai.yaml242 B
- skill.json555 B