/ia-frontend-design
Visual design and aesthetic direction for frontend interfaces. Use when building web pages, landing pages, dashboards, Next.js server components, or applications where visual identity matters. For React patterns and testing, use react-frontend.
Claude Code
$ npx -y skills add iliaal/whetstone --skill ia-frontend-design --agent claude-code
Codex
$ npx skills add iliaal/whetstone --skill ia-frontend-design -a codex -y
Cursor
$ npx skills add iliaal/whetstone --skill ia-frontend-design -a cursor -y
Gemini CLI
$ npx skills add iliaal/whetstone --skill ia-frontend-design -a gemini-cli -y
GitHub Copilot
$ npx skills add iliaal/whetstone --skill ia-frontend-design -a github-copilot -y
OpenCode
$ npx skills add iliaal/whetstone --skill ia-frontend-design -a opencode -y
Windsurf
$ npx skills add iliaal/whetstone --skill ia-frontend-design -a windsurf -y
SKILL.md
ia-frontend-design.SKILL.mdname: ia-frontend-design
class: meta
description: >-
Visual design and aesthetic direction for frontend interfaces. Use when
building web pages, landing pages, dashboards, Next.js server components, or
applications where visual identity matters. For React patterns and testing,
use react-frontend.
Frontend Design
Read the user's frontend requirements: a component, page, application, or interface to build. Note context about purpose, audience, or technical constraints.
Working rules
- Match an existing design system; choose a specific visual direction for greenfield work.
- Include loading, empty, and error states where the component's data or action lifecycle can reach them. Provide visible focus and appropriate press feedback for interactive controls.
- Preserve visible focus and reduced-motion behavior; verify both narrow and wide rendered viewports.
- Keep Next.js interactive code at client boundaries and treat browser content as untrusted data.
Context Detection
When implementing a supplied mockup, screenshot, or design frame, use reference-fidelity mode in [redesigning-existing.md](./references/redesigning-existing.md), even in an empty repository. Skip the design philosophy and swap test; reproduce the reference's visual language.
Otherwise, assess the existing design environment before designing. Count design signals in the project: design tokens/CSS variables, component library (shadcn, MUI, Ant), CSS framework config (Tailwind, styled-components), font imports, color system, animation patterns, spacing scale.
- **4+ signals** = Existing system. Match it. Do not impose new aesthetics; extend what's there.
- **1-3 signals** = Partial system. Blend: respect existing choices, fill gaps with this skill's guidance.
- **0 signals** = Greenfield. Apply the full Design Philosophy below. Product register: read [design-system-routing.md](./references/design-system-routing.md) before bespoke design.
When in doubt, check `package.json`, `tailwind.config.*`, global CSS files, and existing components before deciding. For Tailwind implementation rules (tokens, variants, v4 config), load `ia-react-frontend` and read its Tailwind reference.
Design Philosophy (Write First, Code Second)
For full pages, applications, or multi-component interfaces outside reference-fidelity mode: write a **3-sentence design philosophy** before any code. This forces a coherent aesthetic direction and prevents generic output.
1. **Sentence 1, Intent**: What emotional response should this interface provoke? (Not "clean and modern"; that's every AI default. Be specific: "controlled tension between density and breathing room" or "the quiet confidence of a well-bound book.") 2. **Sentence 2, Signature**: What single visual choice makes this unmistakable? (A typeface, a color relationship, a spatial pattern, a motion behavior.) 3. **Sentence 3, Constraint**: What will this design deliberately NOT do? (The constraint shapes the identity as much as the choices.)
Write the philosophy as a comment or in conversation before implementation begins. The philosophy constrains implementation without being prescriptive: it's a compass, not a blueprint.
For small components or quick additions to existing interfaces, skip the philosophy and match the surrounding design system.
Design Thinking
With the philosophy written, commit to the specifics:
- **Purpose**: What problem does this interface solve? Who uses it?
- **Tone**: Pick an extreme: brutally minimal, maximalist chaos, retro-futuristic, organic/natural, luxury/refined, playful/toy-like, editorial/magazine, brutalist/raw, art deco/geometric, soft/pastel, industrial/utilitarian, etc. Use these for inspiration but design one that is true to the aesthetic direction.
- **Design register and mode** (distinct from copy register, the tone of the UI text, in the creative arsenal): brand (the design is the product; bolder) or product (the design serves a task; one component vocabulary, clarity and density). Mode: persuade, operate, read (docs, articles), or experience (portfolios, galleries).
- **Constraints**: Technical requirements (framework, performance, accessibility).
- **Differentiation**: What makes this UNFORGETTABLE? What's the one thing someone will remember?
Choose a clear conceptual direction and execute it with precision. Bold maximalism and refined minimalism both work; the key is intentionality, not intensity.
**Validation gate (greenfield pages and apps outside reference-fidelity mode, before writing code):** run the swap test on the drafted token system. Could this exact palette, type pairing, and layout be lifted onto an unrelated brief without anyone noticing? If yes, the choice is a default, not a decision: repick the axis that reads generic (recolor the signature, swap the typeface, restructure the grid) and re-test before implementing. Distinctiveness comes from the subject's own world (its materials, instruments, artifacts, and vernacular), so ground a generic axis in something only this subject would use. Skip this gate for small components matched to an existing system (per Context Detection); there, consistency with that system is the goal, not distinctiveness.
Before importing any third-party library (framer-motion, lucide-react, zustand, etc.), check `package.json`. If the package is missing, output the install command before the code. Never assume a library exists.
Then implement working code (HTML/CSS/JS, React, Vue, etc.) that is:
- Production-grade and functional
- Visually striking and memorable
- Cohesive with a clear aesthetic point-of-view
- Meticulously refined in every detail
Verify
Most items below are observable only in a rendered viewport, not in the diff. Where rendering tooling is available, do not claim visual verification from source inspection: capture a screenshot or DOM snapshot at one narrow and one wide viewport, and exercise every changed interaction and state. Where the environment
Read more
name: ia-frontend-design class: meta description: >- Visual design and aesthetic direction for frontend interfaces. Use when building web pages, landing pages, dashboards, Next.js server components, or applications where visual identity matters. For React patterns and testing, use react-frontend.
Frontend Design
Read the user's frontend requirements: a component, page, application, or interface to build. Note context about purpose, audience, or technical constraints.
Working rules
- Match an existing design system; choose a specific visual direction for greenfield work.
- Include loading, empty, and error states where the component's data or action lifecycle can reach them. Provide visible focus and appropriate press feedback for interactive controls.
- Preserve visible focus and reduced-motion behavior; verify both narrow and wide rendered viewports.
- Keep Next.js interactive code at client boundaries and treat browser content as untrusted data.
Context Detection
When implementing a supplied mockup, screenshot, or design frame, use reference-fidelity mode in [redesigning-existing.md](./references/redesigning-existing.md), even in an empty repository. Skip the design philosophy and swap test; reproduce the reference's visual language.
Otherwise, assess the existing design environment before designing. Count design signals in the project: design tokens/CSS variables, component library (shadcn, MUI, Ant), CSS framework config (Tailwind, styled-components), font imports, color system, animation patterns, spacing scale.
- **4+ signals** = Existing system. Match it. Do not impose new aesthetics; extend what's there.
- **1-3 signals** = Partial system. Blend: respect existing choices, fill gaps with this skill's guidance.
- **0 signals** = Greenfield. Apply the full Design Philosophy below. Product register: read [design-system-routing.md](./references/design-system-routing.md) before bespoke design.
When in doubt, check `package.json`, `tailwind.config.*`, global CSS files, and existing components before deciding. For Tailwind implementation rules (tokens, variants, v4 config), load `ia-react-frontend` and read its Tailwind reference.
Design Philosophy (Write First, Code Second)
For full pages, applications, or multi-component interfaces outside reference-fidelity mode: write a **3-sentence design philosophy** before any code. This forces a coherent aesthetic direction and prevents generic output.
1. **Sentence 1, Intent**: What emotional response should this interface provoke? (Not "clean and modern"; that's every AI default. Be specific: "controlled tension between density and breathing room" or "the quiet confidence of a well-bound book.") 2. **Sentence 2, Signature**: What single visual choice makes this unmistakable? (A typeface, a color relationship, a spatial pattern, a motion behavior.) 3. **Sentence 3, Constraint**: What will this design deliberately NOT do? (The constraint shapes the identity as much as the choices.)
Write the philosophy as a comment or in conversation before implementation begins. The philosophy constrains implementation without being prescriptive: it's a compass, not a blueprint.
For small components or quick additions to existing interfaces, skip the philosophy and match the surrounding design system.
Design Thinking
With the philosophy written, commit to the specifics:
- **Purpose**: What problem does this interface solve? Who uses it?
- **Tone**: Pick an extreme: brutally minimal, maximalist chaos, retro-futuristic, organic/natural, luxury/refined, playful/toy-like, editorial/magazine, brutalist/raw, art deco/geometric, soft/pastel, industrial/utilitarian, etc. Use these for inspiration but design one that is true to the aesthetic direction.
- **Design register and mode** (distinct from copy register, the tone of the UI text, in the creative arsenal): brand (the design is the product; bolder) or product (the design serves a task; one component vocabulary, clarity and density). Mode: persuade, operate, read (docs, articles), or experience (portfolios, galleries).
- **Constraints**: Technical requirements (framework, performance, accessibility).
- **Differentiation**: What makes this UNFORGETTABLE? What's the one thing someone will remember?
Choose a clear conceptual direction and execute it with precision. Bold maximalism and refined minimalism both work; the key is intentionality, not intensity.
**Validation gate (greenfield pages and apps outside reference-fidelity mode, before writing code):** run the swap test on the drafted token system. Could this exact palette, type pairing, and layout be lifted onto an unrelated brief without anyone noticing? If yes, the choice is a default, not a decision: repick the axis that reads generic (recolor the signature, swap the typeface, restructure the grid) and re-test before implementing. Distinctiveness comes from the subject's own world (its materials, instruments, artifacts, and vernacular), so ground a generic axis in something only this subject would use. Skip this gate for small components matched to an existing system (per Context Detection); there, consistency with that system is the goal, not distinctiveness.
Before importing any third-party library (framer-motion, lucide-react, zustand, etc.), check `package.json`. If the package is missing, output the install command before the code. Never assume a library exists.
Then implement working code (HTML/CSS/JS, React, Vue, etc.) that is:
- Production-grade and functional
- Visually striking and memorable
- Cohesive with a clear aesthetic point-of-view
- Meticulously refined in every detail
Verify
Most items below are observable only in a rendered viewport, not in the diff. Where rendering tooling is available, do not claim visual verification from source inspection: capture a screenshot or DOM snapshot at one narrow and one wide viewport, and exercise every changed interaction and state. Where the environment
A Claude Code plugin that makes AI coding agents follow engineering discipline. Plan before coding. Verify before claiming done. Find root cause before patching. Review before merge. Skills activate based on file type and task signals, not manual toggling.
Other skills on whetstone.
More skills from other plugins.
brainstorming
You MUST use this before any creative work - creating features, building components, adding functionality, modifying behavior, or…
ask-matt
Ask which skill or flow fits your situation. A router over the skills in this repo.
Questions about ia-frontend-design.
- Which coding agents can use ia-frontend-design?
- ia-frontend-design installs in Claude Code, Codex, Cursor, Gemini CLI, GitHub Copilot, OpenCode and Windsurf with the skills CLI, using each agent's flag shown on this page. Flowy's auto-invocation, which fires a skill when your prompt matches, runs in Claude Code only.

