frontend-designer
Skill9 starsChanged 3 months agoApache-2.0View on GitHub
Trigger: frontend design, CSS architecture, tokens, responsive UI, accessibility, motion. Produce production UI design systems.
6 other projects use a version of this.
Adopted by
Most recently taken up by
- Data-Wise/crafttheir own version, first seen Oct 31, 2026
- Samueladewole/claude-skillstheir own version, first seen Oct 13, 2026
- matos-ed/skillstheir own version, first seen Oct 11, 2026
- app-dev-panel/app-dev-paneltheir own version, first seen Oct 8, 2026
- A70III/ateliertheir own version, first seen Sep 22, 2026
- jamesrochabrun/skillstheir own version, first seen Nov 18, 2025
Other versions6 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 6
- jamesrochabrun/skills★ 209same name
- app-dev-panel/app-dev-panel★ 91same name
- Data-Wise/craft★ 4same name
- matos-ed/skills★ 1same name
- A70III/atelier★ 0same name
- Samueladewole/claude-skills★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repositoryOne other file it gives its agents.
The file
We split this skill into the rules it gives an agent
7 rules. 0 are common, 6 are distinctive, and 1 is very specific to this project.
0
Common
Most of the 5 edited versions we read keep these.
6
Distinctive
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 12
Use this skill for frontend design-system decisions when an agent must choose, review, or document production-ready technical direction.
- Distinctive: line 18
Do not use this skill for generic explanation, copy editing, or one-off code changes that do not affect architecture or reusable …
- Distinctive: line 23
Use semantic HTML and native controls before ARIA substitutes.
- Distinctive: line 24
Keep responsive components reusable, reserve layout space for media and fonts, and avoid performance regressions without evidence that the …
- Distinctive: line 25
Keep the main answer decision-first.
- Distinctive: line 26
Verify new version, browser, API, legal, or adoption claims before adding them to changelogs or decision guidance.
- Very specific: line 47
Read references/technical-reference.md only when detailed decision matrices, examples, safeguards, or command prerequisites are needed.
“Common” is measured: kept by at least 6 in 10 of the 5 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Activation Contract
Use this skill for frontend design-system decisions when an agent must choose, review, or document production-ready technical direction.
- Designing or reviewing UI systems, component anatomy, tokens, layout, or visual interaction.
- Choosing CSS architecture, responsive behavior, accessibility constraints, or motion rules.
- Converting a repository's visual direction into implementation-ready frontend guidance.
Do not use this skill for generic explanation, copy editing, or one-off code changes that do not affect architecture or reusable implementation patterns.
Hard Rules
- Preserve the repository's token and component-state contracts; do not hardcode isolated visual decisions.
- Use semantic HTML and native controls before ARIA substitutes. Define keyboard behavior, visible focus, measurable contrast, and reduced-motion behavior for interactive UI.
- Keep responsive components reusable, reserve layout space for media and fonts, and avoid performance regressions without evidence that the tradeoff is acceptable.
- Keep the main answer decision-first; move deep rationale to local references instead of long inline prose.
- Verify new version, browser, API, legal, or adoption claims before adding them to changelogs or decision guidance.
Decision Gates
| Evidence to inspect | Decision |
| Repository-native CSS architecture, naming, linting, build pipeline, and team conventions | Preserve the established paradigm. Introduce layers, CSS Modules, CSS-in-JS, utilities, or a naming convention only when the repository supports it and migration cost is accepted. |
Existing Design.md, design.md, design-token source, or approved design tool | Treat it as the source of visual truth when present. Do not require a particular filename, generate a handoff file, or assume an external design tool. |
| Supported browser matrix and fallback policy | Gate container queries, nesting, :has(), light-dark(), scroll-driven animation, and other platform features on that matrix; define a fallback when required. |
| Approved token contract plus browser/build support | When the contract selects OKLCH, keep newly specified tokens OKLCH-only. Do not force a legacy color-format migration without an approved cost and compatibility plan. |
| Product theme requirements and design source | Use dark-mode-first only when the product and source require it; otherwise preserve the existing theme strategy and semantic token behavior. |
| Component reuse, page topology, content, and viewport requirements | Prefer container queries for reusable components when supported; use viewport media queries, mobile-first, desktop-first, or composition when they fit the repository and product. |
| Accessibility scope and measurable acceptance criteria | Preserve semantic HTML, keyboard access, focus visibility, contrast measurement, touch-target requirements, and reduced-motion behavior. Apply jurisdiction-specific requirements only when the product scope establishes them. |
| Performance evidence, budgets, and delivery path | Use containment, content-visibility, image formats, font loading, and animation techniques only when compatible with the browser matrix and supported by measured or stated performance goals. |
| Installed repository tooling and approved execution environment | Run a repository-native validation command when available. Do not prescribe npx, a browser audit, encoding, or design-tool command when the dependency, target, permission, or evidence is unavailable. |
Execution Steps
- Identify the repository architecture, design source, browser matrix, accessibility scope, performance evidence, team conventions, tooling availability, and migration cost.
- Define or preserve token, state, semantic HTML, focus, contrast, and reduced-motion contracts before choosing visual novelty.
- Select the smallest compatible CSS, layout, component, theme, and motion approach; record needed fallbacks and rejected alternatives.
- Read
references/technical-reference.mdonly when detailed decision matrices, examples, safeguards, or command prerequisites are needed. - State the chosen pattern, evidence, runtime risks, fallback or migration plan, and validation path. Add changelog claims only when verified.
Output Contract
Return:
- Recommended decision, repository evidence, and why it fits.
- Alternatives rejected with concrete tradeoffs, including migration cost where relevant.
- Accessibility, browser, performance, and runtime risks with mitigations or fallbacks.
- Validation steps that are available in the repository, or the evidence still needed before adoption.
References
references/technical-reference.md— curated technical basis and conditional decision guidance for v3.0.1.references/source-index.md— source pointers and verification rules for version-sensitive claims.
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
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.