Install
plan, review against the brief, build, critiqueWho it is for
Use frontend-design when you are making a new interface, or revising an existing one, and you need a deliberate, recognizable visual direction. It helps you set an aesthetic direction, type choices, and decisions that do not look like template defaults.
A better fit is treating this assignment as the design lead of a design studio: the client has already rejected generic or template-feeling proposals and is willing to pay for a clear point of view. You must make opinionated choices about color, type, and layout in this brief, and you may take aesthetic risks when the reasons are solid. The source material does not list agent products or an installer, so do not treat this as an exclusive feature of any one piece of software. The official description page is
https://raw.githubusercontent.com/anthropics/skills/main/skills/frontend-design/SKILL.md
First attempt in 3 minutes
This guide does not give an install command. Do not invent a repository path or a package-manager instruction for the first attempt. The recommended path is the process in the source material: plan first, then check against the brief, then build, then critique.
Prerequisite: you already have an interface task, even if the brief is short. The low-risk first move is positioning only — do not change code and do not write files. If the brief does not name a product or theme, first decide a concrete theme, audience, and main task for this design, write it as a proposal, and confirm it with the person who requested the work. Do not move into color or writing the interface before that confirmation.
Success signal: you can say in three sentences who this is for, what it solves, and what the theme is, and you only change after the other person nods or clearly objects. Do not start by laying down a warm cream ground close to #F4F1EA, then pairing it with high-contrast serif headlines and terracotta accents — the source material lists that as a trait of current generated work piling up.
Usage cases
Case 1: When the brief lacks product information, align first, then design. Per the source material, first propose a concrete theme, audience, and main task, treat it as a proposal, and confirm it. The done criterion is that those three items are confirmed, not that a full UI already exists. The source material does not say which tool to use for confirmation; spoken or written is fine. Drawing the interface before confirmation is outside this path.
Case 2: Make type decisions for an already aligned brief. The source material states: headlines and body do not each need a completely different typeface; use one family, or two families that are clearly distinct. Choose on purpose. Do not grab “the default font every project uses.” The summary also mentions keeping line length within 80 characters, but the excerpt does not describe a line-length checking procedure, so the done criterion for this case is that the number of type families and their contrast are decided, not that a typesetting check has already been run. Color and layout still have to be specific to this brief; do not reuse the common cream-ground-plus-terracotta-accent pairing.
Boundaries
The process is plan, check against the brief, build, then critique. Theme, audience, and main task come before visuals. Use one type family or two; refuse universal default fonts. Avoid the generated-look pile-up the source material names: a warm cream background (close to #F4F1EA), high-contrast serif headlines, and terracotta or warm-clay accents.
Do not invent an installer or an in-repo path. The source material does not give a component-library list, a default swatch file, or a client list. Confirm the proposal has been accepted before writing code or overriding existing styles. Anything beyond these stated positioning, type, and pitfall notes is outside this guide. If you are only applying a ready-made template without choosing for this brief, you should not follow this path. Align the brief first, then take justified aesthetic risk.