Google stitch frontend taste design
Skill host452b/polish/skills/google-stitch-frontend-taste-design
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-frontend-taste-designAssembled 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 creating or reviewing frontend visual direction and the interface risks generic AI styling, weak hierarchy, incoherent color, repetitive layouts, poor typography, or decorative motion without purpose.
SKILL.md
2.9 KB, as published. Nobody here has run it
Frontend Taste Design
Overview
Create a coherent visual point of view before polishing components. Be opinionated about hierarchy and composition, but label assumptions and let product context override stylistic defaults.
Workflow
- Establish evidence. Identify the product goal, audience, real content, existing brand assets, platform, and technical constraints. Separate confirmed facts, reversible assumptions, and missing decisions. Never invent metrics, customers, testimonials, capabilities, or compliance claims.
- Choose a direction. Define atmosphere, density, compositional variance, and motion intensity. Then specify palette roles, type hierarchy, layout rhythm, imagery, elevation, and interaction character. Read taste-rules.md for detailed heuristics.
- Make it implementable. Cover desktop and mobile composition plus default, hover, focus, active, disabled, loading, empty, error, and success states where relevant. Give concrete tokens or bounded ranges, not adjectives alone.
- Record durable decisions. When the direction will guide multiple screens or agents, create or update
DESIGN.mdusing the template. Preserve compatible existing tokens unless the user approved a redesign. - Run the review gate. Check hierarchy at a glance, content truthfulness, contrast, keyboard focus, touch targets, responsive collapse, reduced motion, and consistency across repeated elements.
Decision Rules
| Situation | Response |
|---|---|
| Brand context is missing | Offer one recommended direction and label it provisional |
| Existing design language is coherent | Extend it instead of imposing a fashionable replacement |
| Interface feels generic | Change composition and hierarchy before adding decoration |
| Dense operational UI | Prioritize scanability, alignment, and restrained motion |
| Marketing or editorial UI | Allow more expressive type, imagery, and asymmetry |
Example
Weak: “Use a modern dark gradient, three feature cards, and smooth animations.”
Strong: “Use a calm, high-contrast operational canvas; organize capabilities as an alternating narrative rather than equal cards; reserve one accent for actions and focus; label the palette and type choices as provisional until brand assets are available.”
Common Mistakes
- Treating personal taste as a universal ban.
- Choosing fonts or colors without stating whether they are existing tokens or proposals.
- Polishing surfaces before fixing content hierarchy.
- Specifying only the ideal state and ignoring failures, empty data, focus, or mobile.
- Adding motion without explaining what change or relationship it communicates.