design-system-ui
Design System UI
Create production-grade frontend UI that feels native to the product and sharper than a default implementation.
For multi-step work, start with a short user-visible update that names the product context you are inspecting first.
Goal
Use the existing product as the creative material. The result should feel native to the app, visually intentional, consistent with usable components and tokens, and improved through hierarchy, composition, interaction quality, and polish.
Success Criteria
- The UI works as real code in the requested or existing stack.
- Existing components, tokens, typography, layout conventions, icon sets, and accessibility patterns are reused when they fit.
- The design has a clear product-aware direction instead of generic SaaS defaults.
- Relevant states are handled: loading, empty, error, disabled, selected, focused, hovered, active, success, destructive, long content, and small screens.
- Responsive behavior is checked for common viewport sizes.
- Validation is run when available; if visual quality matters, render or screenshot before finalizing.
More from marcellocurto/skills
github-issue-create
Draft and create GitHub issues with `gh`. Use for bugs, tasks, features, PRDs, specs, epics, sub-issues, blockers, and tracer-bullet vertical issue breakdowns. Draft first. After approval, create issues and approved native GitHub relationships in the same turn.
11wild-frontend
Explicit-only skill for unconstrained, highly creative frontend design. Use only when the user explicitly says to use wild-frontend or asks to invoke this exact skill. Do not trigger automatically for normal frontend, styling, beautification, product UI, design-system, or production polish requests.
8bug-fix-planner
Plan a concrete fix for a specific bug, regression, crash, failing test, error, or broken behavior without changing code. Use when the user wants a path forward from a bug report, GitHub issue, stack trace, logs, screenshots, repro steps, or failing test. Do not use for new features, broad refactors, general debugging advice, or requests to directly implement the fix.
7relentless-review
Relentlessly stress-test proposals, plans, implementations, designs, strategies, or answers. Use when the user asks "is this actually the best we can do?", wants assumptions challenged, edge cases explored, failure modes examined, or asks to push harder, red-team, find holes, or be relentless. The answer may be that the current work is already the best path and should not change. Do not use for proofreading, encouragement-only feedback, minor style review, or requests where the user only wants implementation.
7test-quality-audit
Audit tests for real bug-finding value. Use when the user asks whether tests are useful, trivial, redundant, over-mocked, implementation-coupled, snapshot-heavy, coverage-padding, only passing because the test controls both sides, or whether tests should be kept, fixed, cut, or added. Also use when reviewing test changes in a PR and the user wants honest judgment about whether the tests earn their place.
7simplify-code-solution
Simplify code fixes and feature proposals by grounding them in real requirements and existing code. Use when a coding plan feels overbuilt, speculative, too abstract, or needs assumptions challenged before implementation.
6