Agent skill

Frontend Design

by spytensor in spytensor/openmozi

Guidance for distinctive, intentional visual design when building or reshaping UI, HTML/React artifacts, dashboards, charts, and visual reports.

Apache-2.0Auto-check passedFrontend & Design

Install Frontend Design

skills CLI
$ npx skills add spytensor/openmozi --skill frontend-design -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install spytensor/openmozi frontend-design --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/spytensor/openmozi.git skills-src && mkdir -p .claude/skills && cp -r skills-src/skills/frontend-design .claude/skills/frontend-design && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
frontend-design
GitHub stars
448
Token cost
~2.6k tokens
SKILL.md length
1,614 words
Files
2
Skills in repo
13
Repo updated
First seen
Licence
Apache-2.0

At a glance

Guidance for distinctive, intentional visual design when building or reshaping UI, HTML/React artifacts, dashboards, charts, and visual reports.

  • Tasks that involve Typography
  • SKILL.md covers Ground it in the subject, Design principles, Structure before styling and Data products, dashboards, and…, plus 3 more sections
  • Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md
  • Tasks that involve UI design

What it does

Frontend Design is an agent skill from spytensor/openmozi. Guidance for distinctive, intentional visual design when building or reshaping UI, HTML/React artifacts, dashboards, charts, and visual reports. Use before implementation to choose a content-specific structure, typography, and visual system that does not read as a templated default.

Its SKILL.md is about 2.6k tokens, which your agent loads only when the skill is triggered. The skill folder holds 1 other file.

It sits in Frontend & Design, covering Typography and UI design. It works with React. The repository describes itself as: A custom Agent OS built to be hackable, heavily inspired by OpenClaw. The licence is Apache-2.0.

When your agent uses it

  • Tasks that involve Typography
  • Tasks that involve UI design

Example prompts

  • “/frontend-design”

What it can do on your machine

Read from SKILL.md and the folder at commit ac46df0. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    No scripts in the folder and no shell commands in SKILL.md.

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Frontend Design loads about 2.6k tokens when it runs. Until then it costs about 75 tokens; SKILL.md has 1,614 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~75
When it runs · the whole SKILL.md, loaded when a task matches
~2.6k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from spytensor/openmozi at commit ac46df0, republished under its Apache-2.0 licence (© spytensor). 1,614 words, ~2,649 tokens.

Download SKILL.mdSave it as .claude/skills/frontend-design/SKILL.md (or your agent's skills folder). This skill also uses 1 other file; get the full folder from GitHub.
name
frontend-design
description
Guidance for distinctive, intentional visual design when building or reshaping UI, HTML/React artifacts, dashboards, charts, and visual reports. Use before implementation to choose a content-specific structure, typography, and visual system that does not read as a templated default.
license
Complete terms in LICENSE.txt
version
1.1.0
category
coding
user-invocable
true

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.

Structure before styling

Choose the composition before choosing colors or polishing components. Name the artifact's dominant reading pattern — comparison, sequence, investigation, monitoring, narrative, reference, or decision — and make that pattern visible in the layout. Do not reuse the same hero, equal-card grid, and footer rhythm for unrelated briefs.

Use containers only when they express a real boundary, interaction, or reusable unit. Prefer whitespace, alignment, rules, and typography for ordinary grouping. A page where every fact is boxed has no hierarchy; a grid of equal cards says every item matters equally even when the content does not.

Lock a small set of color, type, spacing, radius, and motion tokens before building. Every later value should come from those tokens. Use real content only: never invent metrics, testimonials, logos, or benchmark claims to make a layout feel complete.

Data products, dashboards, and reports

Start from the decision the reader needs to make, not from a checklist of available metrics. Give the primary finding or most useful chart the dominant visual position, then arrange supporting evidence by causal or analytical relationship.

  • Do not automatically turn summary metrics into four equal cards. Use one compact metric band, an annotated lead visualization, a comparison table, or inline figures when those better express the argument.
  • Do not turn observations into rounded pills. Chips are for compact state, filters, or removable values — not sentences or conclusions.
  • Avoid card-in-card layouts and repeated borders. One semantic surface may contain several aligned facts without wrapping each fact again.
  • Charts need honest scales, labels, units, and source context. Decorative empty chart frames are worse than a clear table or prose finding.
  • Use tabular numerals for dense figures and monospace only for code or genuinely machine-like data; it is not a shortcut to “technical.”
  • Put detail on demand. The first viewport should explain what changed and why it matters, not display every dimension at equal weight.
  • Check that headline totals and ratios recompute from the detailed data. If they conflict, remove the summary until the data is corrected.

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.

Show full SKILL.md (801 more words)Show less

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. 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.

© spytensor, Apache-2.0. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

SKILL.md and 1 other file in skills/frontend-design of spytensor/openmozi.

  • SKILL.md
  • LICENSE.txt

Open the folder on GitHubat commit ac46df0

Compare with similar skills

Frontend Design next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Frontend Design compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Frontend Design this skillspytensor/openmozi448—~2.6kAutomated safety check: PassApache-2.0
UI UX Pro Maxsaoudi-h/solar-icons18418 repos~11kAutomated safety check: NotesCustom licence
UI/UX Design System AdvisorGalaxy-Dawn/claude-scholar5.7k1 repos~1.1kAutomated safety check: PassMIT
Tidyfactor StylerTidyFactor/Styler118—~1.7kAutomated safety check: PassApache-2.0
UI UX Pro Maxfutureboard/futureboard-studio106—~5.6kAutomated safety check: PassMIT
UI UX Pro Maxshobcoder/shob577—~3.7kAutomated safety check: PassMIT

Similar skills

  • UI UX Pro Max

    saoudi-h/solar-icons

    UI/UX design intelligence for web and mobile. An agent skill from saoudi-h/solar-icons.

    184 GitHub starsUsed in 18 repos~11k tokens
    Frontend & DesignAuto-check: notes
  • UI/UX Design System Advisor

    Galaxy-Dawn/claude-scholar

    Turns a vague UI request into a concrete design system with style, palette, typography and layout guidance from a search script, plus stack-specific implementation advice.

    5.7k GitHub starsUsed in 1 repo~1.1k tokens
    Frontend & DesignAuto-check passed
  • Tidyfactor Styler

    TidyFactor/Styler

    Production framework styler and surgical RTL UI polish engine with Contextual Decision Layer (CDL).

    118 GitHub stars~1.7k tokensUpdated 1 mo ago
    Frontend & DesignAuto-check passed
  • UI UX Pro Max

    futureboard/futureboard-studio

    Comprehensive design guide for web, mobile, and desktop applications.

    106 GitHub stars~5.6k tokensUpdated today
    Frontend & DesignAuto-check passed
  • UI UX Pro Max

    shobcoder/shob

    UI/UX design intelligence expert for web and mobile applications.

    577 GitHub stars~3.7k tokensUpdated 19 days ago
    Frontend & DesignAuto-check passed
  • UI UX Pro Max Skill

    Jason904/ui-skill-lab

    A skill your agent uses for UI/UX design intelligence in Codex: planning, building, reviewing, improving, or implementing web/mobile interfaces, landing pages, dashboards, design systems…

    144 GitHub stars~865 tokensUpdated 3 mo ago
    Frontend & DesignAuto-check passed

More from spytensor/openmozi

All 13 skills in this repo
  • Commit

    spytensor/openmozi

    Smart commit: bump version, find related issues, commit with Co-authored-by, push.

    448 GitHub stars~480 tokensUpdated 2 mo ago
    Auto-check passed
  • Pipeline

    spytensor/openmozi

    Full development pipeline: create GitHub issue, plan, implement with agent team, verify (build+test), commit, push, close issue.

    448 GitHub stars~549 tokensUpdated 2 mo ago
    Auto-check passed
  • Skill Authoring

    spytensor/openmozi

    How to install a skill package a user hands over (.skill/.zip/.tar.gz), and how to write a new skill into this runtime so it is listed, enabled and usable.

    448 GitHub stars~1.3k tokensUpdated 2 mo ago
    Auto-check passed
  • Coding Agent

    spytensor/openmozi

    Structured coding workflow: read, plan, implement, test, verify

    448 GitHub stars~723 tokensUpdated 2 mo ago
    Auto-check passed
  • Research Workflow

    spytensor/openmozi

    Structured research workflow: decompose the question, search in parallel, cross-verify sources, synthesize with citations.

    448 GitHub stars~594 tokensUpdated 2 mo ago
    Auto-check passed
  • Self Ops

    spytensor/openmozi

    Runtime self-diagnosis knowledge: database layout, observability APIs, timeout hierarchy, restart procedure, failure replay.

    448 GitHub stars~767 tokensUpdated 2 mo ago
    Auto-check passed

Works with

Questions about Frontend Design

What does Frontend Design do?

Guidance for distinctive, intentional visual design when building or reshaping UI, HTML/React artifacts, dashboards, charts, and visual reports. Frontend Design is an agent skill from spytensor/openmozi. Guidance for distinctive, intentional visual design when building or reshaping UI, HTML/React artifacts, dashboards, charts, and visual reports.

When should I use Frontend Design?

Frontend Design fits situations like: tasks that involve Typography; tasks that involve UI design.

How do I install Frontend Design in Claude Code?

Run `npx skills add spytensor/openmozi --skill frontend-design -a claude-code`. Or copy the skill folder (skills/frontend-design in spytensor/openmozi) into .claude/skills/frontend-design in your project. Claude Code loads it when a task matches its description.

How do I install Frontend Design in Codex?

Run `npx skills add spytensor/openmozi --skill frontend-design -a codex`. Or copy the skill folder (skills/frontend-design in spytensor/openmozi) into .agents/skills/frontend-design in your project. Codex loads it when a task matches its description.

Can I use Frontend Design in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add spytensor/openmozi --skill frontend-design -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/frontend-design, .gemini/skills/frontend-design, .github/skills/frontend-design and .opencode/skills/frontend-design in your project.

What does Frontend Design need to run?

SKILL.md names no scripts, command-line tools or credentials: Frontend Design is instructions for the agent only.

Does Frontend Design access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Frontend Design safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Frontend Design use?

Frontend Design is published under the Apache-2.0 licence (from the LICENSE file in the skill folder). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Frontend Design use?

About 2.6k tokens (SKILL.md is roughly 11k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Frontend Design?

Skills that share tags, products or a category with Frontend Design: UI UX Pro Max (saoudi-h/solar-icons, 184 stars), UI/UX Design System Advisor (Galaxy-Dawn/claude-scholar, 5.7k stars), Tidyfactor Styler (TidyFactor/Styler, 118 stars) and UI UX Pro Max (futureboard/futureboard-studio, 106 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Frontend Design?

spytensor (a GitHub user) maintains it in spytensor/openmozi, which has 448 GitHub stars. The repository holds 13 skills in this directory. The repository was last updated on August 7, 2026.

Source: spytensor/openmozi on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.