Frontend Design

VerifiedSafe

Guidance for distinctive, intentional visual design when building new UI or reshaping an existing one.

Sby Skills Guide Bot
DevelopmentIntermediate
7/22/2026
Claude CodeCursor
#frontend-design#ui-design#typography#visual-identity#art-direction

Recommended for

Automated summary

An art-direction guide for building or reshaping an interface with a deliberate visual identity: palette, typography and structure grounded in the brief's subject rather than in templated defaults.

Strengths

  • Consistently grounds visual choices in the subject's own world — materials, instruments, artifacts, vernacular — instead of abstract trends.
  • Explicitly names the three generic AI looks (cream + serif + terracotta, near-black + acid accent, broadsheet with hairline rules) and asks you to treat them as defaults, not decisions.
  • Enforces a staged process — brainstorm, explore, plan, critique, build, critique again — and demands one justifiable aesthetic risk.
  • Treats typography and structural devices (numbering, dividers, eyebrows) as carriers of meaning, including a check that numbering actually encodes a sequence.

Limitations

  • Purely prescriptive: no technical rules, no code, and no accessibility, performance or responsive checks.
  • Output quality depends heavily on the model's ability to invent fitting typefaces and copy; results can still drift toward generic despite the instructions.
  • The SKILL.md file is truncated at the end (the process and writing sections are cut off), so part of the advertised method is unreadable.
When to use it

Reach for it when starting a new page or reworking an existing UI and you want a distinctive, tailored visual identity instead of a template.

When not to use it

Skip it for minor UI fixes, design-system or implementation work, or when an existing brand guideline already dictates the visual direction.

Security analysis

Safe
Quality score82/100

This is a pure design-guidance instruction file with no declared tools and no executable content. It contains no shell commands, network calls, file operations, credential handling, or attempts to alter agent safety behavior; everything is advisory prose about typography, palette, layout, and self-critique of design work. Listing it poses no meaningful execution risk.

No concerns found

How this analysis is made

Examples

Distinctive landing page
Design a landing page for a small-batch coffee roaster in Lyon that delivers by bicycle. Pick the palette, type pairing and layout yourself — I want something that could not be mistaken for a template — and explain your reasoning.
De-templating an existing homepage
Here is the copy for my SaaS homepage. Reshape the visual direction so it doesn't read like a default AI-generated landing page: propose the hero concept, a type scale, and any structural devices that actually encode something about the product.
Aesthetic direction critique
Critique the aesthetic direction of my portfolio site for a documentary photographer, then propose one real risk worth taking plus a specific palette and typography pairing.

name: frontend-design description: Guidance for distinctive, intentional visual design when building new UI or reshaping an existing one. Helps with aesthetic direction, typography, and making choices that don't read as templated defaults. license: Complete terms in LICENSE.txt

Frontend Design

Approach this as the design lead at a small studio known for giving every client a visual identity that could not be mistaken for anyone else's. This client has already rejected proposals that felt templated, and is paying for a distinctive point of view: make deliberate, opinionated choices about palette, typography, and layout that are specific to this brief, and take one real aesthetic risk you can justify.

Ground it in the subject

If the brief does not pin down what the product or subject is, pin it yourself before designing: name one concrete subject, its audience, and the page's single job, and state your choice. If there's any information in your memory about the human's preferences, context about what they're building, or designs you've made before – use that as a hint. The subject's own world, its materials, instruments, artifacts, and vernacular, is where distinctive choices come from. Build with the brief's real content and subject matter throughout.

Design principles

For web designs, the hero is a thesis. Open with the most characteristic thing in the subject's world, in whatever form makes sense for it: a headline, an image, an animation, a live demo, an interactive moment. Be deliberate with your choice: a big number with a small label, supporting stats, and a gradient accent is the template answer, only use if that's truly the best option.

Typography carries the personality of the page. Pair the display and body faces deliberately, not the same families you would reach for on any other project, and set a clear type scale with intentional weights, widths, and spacing. Make the type treatment itself a memorable part of the design, not a neutral delivery vehicle for the content.

Structure is information. Structural devices, numbering, eyebrows, dividers, labels, should encode something true about the content, not decorate it. Many generic designs use numbered markers (01 / 02 / 03), but that's only appropriate if the content actually is a sequence - like a real process or a typed timeline where order carries information the reader needs. Question if choices like numbered markers actually make sense before incorporating them.

Leverage motion deliberately. Think about where and if animation can serve the subject: a page-load sequence, a scroll-triggered reveal, hover micro-interactions, ambient atmosphere. An orchestrated moment usually lands harder than scattered effects; choose what the direction calls for. However, sometimes less is more, and extra animation contributes to the feeling that the design is AI-generated.

Match complexity to the vision. Maximalist directions need elaborate execution; minimal directions need precision in spacing, type, and detail. Elegance is executing the chosen vision well.

Consider written content carefully. Often a design brief may not contain real content, and it's up to you to come up with copy. Copy can make a design feel as templated as the design itself. See the below section on writing for more guidance.

Process: brainstorm, explore, plan, critique, build, critique again

For calibration: AI-generated design right now clusters around three looks: (1) a warm cream background (near #F4F1EA) with a high-contrast serif display and a terracotta accent; (2) a near-black background with a single bright acid-green or vermilion accent; (3) a broadsheet-style layout with hairline rules, zero border-radius, and dense newspaper-like columns. All three are legitimate for some briefs, but they are defaults rather than choices, and they appear regardless of subject. Where the brief pins down a visual direction, follow it exactly — the brief's own words always win, including when it asks for one of these looks. Where it leaves an axis free, don't spend that freedom on one of these defaults. Just like a human designer who's hired, there's often a careful balance between doing what you're good at and taking each project as a chance to experiment and learn.

Work in two passes. First, brainstorm a short design plan based on the human's design brief: create a compact token system with color, type, layout, and signature. Color: describe the palette as 4–6 named hex values. Type: the typefaces for 2+ roles (a characterful display face that's used with restraint, a complementary body face, and a utility face for captions or data if needed). Layout: a layout concept, using one-sentence prose descriptions and ASCII wireframes to ideate and compare. Signature: the single unique element this page will be remembered by that embodies the brief in an appropriate way.

Then review that plan against the brief before building: if any part of it reads like the generic default you would produce for any similar page (work through a similar prompt to see if you arrive somewhere similar) rather than a choice made for this specific brief — revise that part, say what you changed and why. Only after you've confirmed the relative uniqueness of your design plan should you start to write the code, following the revised plan exactly and deriving every color and type decision from it.

When writing the code, be careful of structuring your CSS selector specificities. It's easy to generate CSS classes that cancel each other out (especially with a type-based selector like .section and a element-based selector like .cta). This can happen often with paddings/margins between sections.

Try to do a lot of this planning and iteration in your thinking, and only show ideas to the user when you have higher confidence it'll delight them.

Restraint and self-critique

Spend your boldness in one place. Let the signature element be the one memorable thing, keep everything around it quiet and disciplined, and cut any decoration that does not serve the brief. Not taking a risk can be a risk itself! Build to a quality floor without announcing it: responsive down to mobile, visible keyboard focus, reduced motion respected. Critique your own work as you build, taking screenshots if your environment supports it – a picture is worth 1000 tokens. Consider Chanel's advice: before leaving the house, take a look in the mirror and remove one accessory. Human creators have memory and always try to do something new, so if you have a space to quickly jot down notes about what you've tried, it can help you in future passes.

More on writing in design

Words appear in a design for one reason: to make it easier to understand, and therefore easier to use. They are design material, not decoration. Bring the same intentionality to copy that you would bring to spacing and color. Before writing anything, ask what the design needs to say, and how it can best be said to help the person navigate the experience.

Write from the end user's side of the screen. Name things by what people control and recognize, never by how the system is built. A person manages notifications, not webhook config. Describe what something does in plain terms rather than selling it. Being specific is always better than being clever.

Use active voice as default. A control should say exactly what happens when it's used: "Save changes," not "Submit." An action keeps the same name through the whole flow, so the button that says "Publish" produces a toast that says "Published." The vocabulary of an interface is the signposting for someone navigating the product. Cohesion and consistency are how people learn their way around.

Treat failure and emptiness as moments for direction, not mood. Explain what went wrong and how to fix it, in the interface's voice rather than a person's. Errors don't apologize, and they are never vague about what happened. An empty screen is an invitation to act.

Keep the register conversational and tuned: plain verbs, sentence case, no filler, with tone matched to the brand and the audience. Let each element do exactly one job. A label labels, an example demonstrates, and nothing quietly does double duty.

From the file to a first result

The download contains exactly the content displayed on this page. This copy may differ from the latest version in the source repository.

View the source and supporting files

This download contains SKILL.md only. Any scripts, references, templates and dependencies are not included. Get the required files from the source, preserving their directory structure, before continuing.

1. Download the file

Download SKILL.md

From the root of a test project, save the file as .skill-downloads/frontend-design-mrwakgfo/SKILL.md, or use the command below. This folder is for inspecting the skill before installation.

Command for macOS/Linux or WSL: requires a POSIX shell and curl. On Windows without WSL, use the download button and create the folder manually.

mkdir -p '.skill-downloads/frontend-design-mrwakgfo' && curl --fail --show-error --location 'https://skills-guides.com/api/skills/frontend-design-mrwakgfo/download' --output '.skill-downloads/frontend-design-mrwakgfo/SKILL.md.part' && mv '.skill-downloads/frontend-design-mrwakgfo/SKILL.md.part' '.skill-downloads/frontend-design-mrwakgfo/SKILL.md'

2. Check prerequisites

Read SKILL.md before using it. If it references scripts or external services, inspect them and prepare the required access in your test environment.

No recognized prerequisites section in this file. This does not mean it is self-contained: libraries, tools and access requirements may be mentioned elsewhere in the content or source repository.

The platforms on this page are catalog indications. The paths below follow tool documentation; they do not prove this skill has been run in those tools. No minimum tool version is confirmed for this listing.

3. Load the skill

After inspection, copy the complete folder into your project using one of the commands below, then open a new tool session. The command stops if a folder with the same name already exists: compare the files before replacing it.

Claude Code
test -f '.skill-downloads/frontend-design-mrwakgfo/SKILL.md' && test -s '.skill-downloads/frontend-design-mrwakgfo/SKILL.md' && mkdir -p '.claude/skills' && test ! -e '.claude/skills/frontend-design' && cp -R '.skill-downloads/frontend-design-mrwakgfo' '.claude/skills/frontend-design'

Cursor
test -f '.skill-downloads/frontend-design-mrwakgfo/SKILL.md' && test -s '.skill-downloads/frontend-design-mrwakgfo/SKILL.md' && mkdir -p '.cursor/skills' && test ! -e '.cursor/skills/frontend-design' && cp -R '.skill-downloads/frontend-design-mrwakgfo' '.cursor/skills/frontend-design'

OpenSkills

OpenSkills must already be installed. The local install/read procedure is checked with OpenSkills 1.5.0, which requires Node.js ≥ 20.6.0. Catalog slugs are not resolved automatically.

Official OpenSkills installation
openskills install './.skill-downloads/frontend-design-mrwakgfo'

openskills read 'frontend-design-mrwakgfo'

Reading should display the installed file content and its base directory. It does not run the skill or install its dependencies.

For an agent that reads AGENTS.md, then sync the index. This command changes AGENTS.md: review the diff before using it.

openskills sync

Manual method or another tool: attach SKILL.md to a conversation, or open it in an agent that can read files. Include any required supporting resources. No universal folder is recognized by every tool.

4. Try a first task

Use a short, synthetic input: an API endpoint, a small document or an interface brief. In a new conversation, attach the file or give the agent its path, then adapt this request:

Read .skill-downloads/frontend-design-mrwakgfo/SKILL.md and apply its instructions to this example: [describe a test input]. Identify any missing files, dependencies or access. Produce the result requested by the skill without inventing data or running unreviewed scripts.

Expected result: output matching the skill instructions, or a precise list of missing prerequisites. A read confirmation alone does not validate a first use. If an external resource is unavailable, that path remains untested.

Related skills