📐 Global design skill

New here? One skill (already introduced in Track 3) is a set of instructions saved in a file that the agent consults automatically before doing a particular type of work — like a procedure sheet an employee pulls from a drawer before starting a task that has an established "right way to do it" at the company. A design skill it’s that same mechanism, specialized in front end: it stores your color palette, typography, spacing, visual tone, and the principles that define what “beautiful” means to you—not to the entire internet.

Think of a real architecture studio: there’s a physical folder (or a PDF) called “visual identity guidelines”—exact colors in hexadecimal code, approved fonts, minimum margins, examples of what is and isn’t allowed. Every new intern reads it before their first project. Nobody re-explains every color in a meeting each time. The design skill is exactly that guide, except the “intern” is the agent, and it reads the guide on its own at the start of every front-end task— without you needing to type anything again.

"Build a beautiful website" is a vague request because "beautiful" has no fixed definition — everyone on the planet whose work was used to train that model has a different idea of "beautiful," and the model averages all of them, which is exactly the "AI feel" from the previous module. But a request backed by a design skill doesn’t need to say "beautiful" even once: the skill already defines in advance what "beautiful" means to you — what palette, typography, spacing, and tone to use (serious? fun? luxurious? handmade?). The agent doesn’t invent anything visual anymore: it applies the rules that are already there.

Caption: above, without any guide, the vague request falls straight to the statistical average. Below, the agent has a habit of opening the design skill BEFORE writing any front end — even a short request comes out with the right palette, typography, and tone because the decision was already made in the guide.

Every skill (recalling Learning Path 3) has a description/trigger — the short sentence that tells the agent WHEN to consult that file, without needing to read the entire file to decide. In a design skill, the trigger might be something like “use before creating, redesigning, or reviewing any page, component, or interface.” That’s what makes the agent open the manual automatically, even when you only asked “create a contact form” without mentioning “design” or “skill” at all.

After the trigger come the style rules themselves: color palette (with exact hexadecimal codes, not vague "blue" or "green"), the typography (which fonts to use, at what size, for headings and body text—typography is just the technical term for “the choice and style of letters”), spacing (how much breathing room between elements, square or rounded corners), and the overall visual tone (serious and corporate? fun and colorful? minimalist and sophisticated?). Finally, a good skill includes examples — code snippets or concrete descriptions of "this is right" and "this is wrong" — because concrete examples are a better guide than abstract rules.

New here? "Global vs. project" It’s about WHERE the skill is stored and WHICH projects can see it (covered in depth in module 3.5, but central here again). A skill of the project lives inside that specific project's folder and only applies there. A skill global gets installed once, in a place on your computer that every Claude Code project can see automatically — it works for any folder you open, without needing to copy the file again for each new project.

The practical difference is huge. Without a global skill, every time you open a new project—the bakery’s website, the consulting dashboard, the course landing page—you explain everything from scratch: “use this color, this font, this spacing.” It’s tiring, it’s easy to forget a detail, and the result varies from project to project even when you wanted the SAME style across all of them. With the skill installed globally, you save the guide just once, and every new project—even six months from now, even one you can’t imagine today—starts with that same reference.

The discipline that separates a useful skill from a forgotten one comes down to a single sentence: always invoke the design skill BEFORE writing any front end, never afterward. If you let the agent write the component first and “review it with the skill” afterward, it has already spent effort building on a generic guess—that means rework. The right habit is: a front-end request comes in → open the skill first → only then write the code using the right reference from the start.

Objective: test in your own environment whether a globally installed design skill changes the result of a simple component request — without you needing to mention color, font, or style even once in the request, because that should already come from the skill.

Before writing any HTML or CSS, check whether a design skill is installed
and use it as a style reference. Now create a product card for 
with a title, price, and a buy button. Don't ask me about colors or fonts — decide based on the skill.

If you already have a design skill installed globally, the result should use its palette and typography, without a generic blue “Get Started.” If you don't have any skills installed yet, the agent will probably tell you it couldn't find any—which confirms the lesson: without a manual to consult, it falls back on guesswork. (Installing your own design skill is covered step by step in modules 5.6 and 5.7, along with the complete brand folder.)

The design skill addresses cause 1 from module 5.1 — lack of reference — but it doesn’t address cause 2: no one makes the agent actually LOOK at the result before handing it to you. A well-written skill greatly reduces the “AI smell” because the agent starts with good choices, but it doesn’t replace a critical eye on the final result — the CSS can be technically correct and still look misaligned, cramped, or low-contrast on a real screen. The next module addresses exactly this second half.