Dissecting a skill

---
aliases: ["Dissecting a Skill"]
---
# Dissecting a skill

A line-by-line breakdown of a real skill from the official Claude Code
plugin ecosystem. This one is different from the agent and command
dissections: it has no steps, no checklist, no pipeline. It is a
personality injection that changes how the model thinks about an entire
category of output.

## The specimen

- Skill: `frontend-design/SKILL.md`
- Plugin: `frontend-design` (Frontend Design Plugin)
- Author: Anthropic (no individual author listed)
- Source: `claude-plugins-official/plugins/frontend-design/skills/frontend-design/SKILL.md`
- License: Apache 2.0
- Role within the plugin: changes how the model approaches any frontend
  code generation task; shifts output away from generic AI aesthetics
  toward distinctive, opinionated design

## The full file

Here is the skill exactly as shipped. Nothing removed, nothing added.

```markdown
---
name: frontend-design
description: Create distinctive, production-grade frontend interfaces with high design quality. Use this skill when the user asks to build web components, pages, or applications. Generates creative, polished code that avoids generic AI aesthetics.
license: Complete terms in LICENSE.txt
---

This skill guides creation of distinctive, production-grade frontend interfaces that avoid generic "AI slop" aesthetics. Implement real working code with exceptional attention to aesthetic details and creative choices.

The user provides frontend requirements: a component, page, application, or interface to build. They may include context about the purpose, audience, or technical constraints.

## Design Thinking

Before coding, understand the context and commit to a BOLD aesthetic direction:
- **Purpose**: What problem does this interface solve? Who uses it?
- **Tone**: Pick an extreme: brutally minimal, maximalist chaos, retro-futuristic, organic/natural, luxury/refined, playful/toy-like, editorial/magazine, brutalist/raw, art deco/geometric, soft/pastel, industrial/utilitarian, etc. There are so many flavors to choose from. Use these for inspiration but design one that is true to the aesthetic direction.
- **Constraints**: Technical requirements (framework, performance, accessibility).
- **Differentiation**: What makes this UNFORGETTABLE? What's the one thing someone will remember?

**CRITICAL**: Choose a clear conceptual direction and execute it with precision. Bold maximalism and refined minimalism both work - the key is intentionality, not intensity.

Then implement working code (HTML/CSS/JS, React, Vue, etc.) that is:
- Production-grade and functional
- Visually striking and memorable
- Cohesive with a clear aesthetic point-of-view
- Meticulously refined in every detail

## Frontend Aesthetics Guidelines

Focus on:
- **Typography**: Choose fonts that are beautiful, unique, and interesting. Avoid generic fonts like Arial and Inter; opt instead for distinctive choices that elevate the frontend's aesthetics; unexpected, characterful font choices. Pair a distinctive display font with a refined body font.
- **Color & Theme**: Commit to a cohesive aesthetic. Use CSS variables for consistency. Dominant colors with sharp accents outperform timid, evenly-distributed palettes.
- **Motion**: Use animations for effects and micro-interactions. Prioritize CSS-only solutions for HTML. Use Motion library for React when available. Focus on high-impact moments: one well-orchestrated page load with staggered reveals (animation-delay) creates more delight than scattered micro-interactions. Use scroll-triggering and hover states that surprise.
- **Spatial Composition**: Unexpected layouts. Asymmetry. Overlap. Diagonal flow. Grid-breaking elements. Generous negative space OR controlled density.
- **Backgrounds & Visual Details**: Create atmosphere and depth rather than defaulting to solid colors. Add contextual effects and textures that match the overall aesthetic. Apply creative forms like gradient meshes, noise textures, geometric patterns, layered transparencies, dramatic shadows, decorative borders, custom cursors, and grain overlays.

NEVER use generic AI-generated aesthetics like overused font families (Inter, Roboto, Arial, system fonts), cliched color schemes (particularly purple gradients on white backgrounds), predictable layouts and component patterns, and cookie-cutter design that lacks context-specific character.

Interpret creatively and make unexpected choices that feel genuinely designed for the context. No design should be the same. Vary between light and dark themes, different fonts, different aesthetics. NEVER converge on common choices (Space Grotesk, for example) across generations.

**IMPORTANT**: Match implementation complexity to the aesthetic vision. Maximalist designs need elaborate code with extensive animations and effects. Minimalist or refined designs need restraint, precision, and careful attention to spacing, typography, and subtle details. Elegance comes from executing the vision well.

Remember: Claude is capable of extraordinary creative work. Don't hold back, show what can truly be created when thinking outside the box and committing fully to a distinctive vision.
```

## The frontmatter: three fields and a surprise

### name and description

```yaml
name: frontend-design
description: Create distinctive, production-grade frontend interfaces with high
  design quality. Use this skill when the user asks to build web components,
  pages, or applications. Generates creative, polished code that avoids generic
  AI aesthetics.
```

Only three frontmatter fields: `name`, `description`, `license`. No `version`.
This is the simplest possible frontmatter for a skill.

The description is the trigger mechanism. [[04.2 Skill Anatomy|Skill Anatomy]]
explains that the model only sees name and description when deciding whether
to load a skill. This description contains the phrases "build web components",
"pages", "applications." These are what the model pattern-matches against
user requests.

Compare with agents, which can use `<example>` blocks for reliable triggering.
Skills rely on the description alone. The author packed three concrete trigger
phrases into two sentences. Enough for the model to activate on most frontend
requests without being so broad that it fires on backend work.

### license: the odd field out

```yaml
license: Complete terms in LICENSE.txt
```

Most skills do not have this field. It exists because this plugin is
distributed as part of a public repository and the author wants explicit
terms. The field has no effect on skill behavior; the CLI ignores it. It is
metadata for humans, not for the model.

### What is absent

No `version` field. The command dissection in
[[04.5 Dissecting a Command|Dissecting a Command]] showed a similar pattern:
include only what matters, skip the rest. A version number would be useful
for tracking changes across releases, but for a single-file skill in a
plugin, the git history serves that purpose.

## The body: not a workflow

Every other artifact we have dissected (the agent in
[[03.4 Dissecting an Agent|Dissecting an Agent]], the commit command in
[[04.5 Dissecting a Command|Dissecting a Command]], the complex command in
[[04.6 Dissecting a Complex Command|Dissecting a Complex Command]]) is
procedural. Do step 1, then step 2, then step 3. This skill has zero
numbered steps. No checklist. No pipeline.

It is a personality injection. The skill changes HOW the model thinks about
frontend code, not WHAT steps to follow. Guidance and constraints, not process.

This is a fundamentally different use of the skill mechanism.
[[04.2 Skill Anatomy|Skill Anatomy]] lists body patterns: checklist, decision
tree, constraint, template, process. This skill is almost pure constraint.
It works because frontend design is not a sequential task; it is a creative
task with quality standards. Telling the model "follow these 8 steps" would
produce formulaic output. Telling it "here is what good looks like and what
bad looks like" lets it adapt to each request.

### The opening line

```
This skill guides creation of distinctive, production-grade frontend
interfaces that avoid generic "AI slop" aesthetics.
```

"AI slop" is the most opinionated phrase in any official plugin we have seen.
The author names the problem directly. This is the skill's entire reason for
existing: the model's default frontend output looks generically AI-generated,
and this skill exists to counteract that tendency.

The phrase also serves as an anchor. The model reads this first, before any
of the detailed guidelines. It sets the frame: everything that follows is in
service of avoiding generic output. Without this line, the aesthetics
guidelines could be read as suggestions. With it, they are corrections to a
known problem.

### Design thinking: questions, not steps

```
Before coding, understand the context and commit to a BOLD aesthetic direction:
- Purpose: What problem does this interface solve? Who uses it?
- Tone: Pick an extreme: brutally minimal, maximalist chaos, retro-futuristic...
- Constraints: Technical requirements (framework, performance, accessibility).
- Differentiation: What makes this UNFORGETTABLE?
```

Four questions. The model is asked to think about purpose, tone, constraints,
and differentiation before writing any code. This is a thinking framework,
not an execution framework.

The tone list is deliberately long: "brutally minimal, maximalist chaos,
retro-futuristic, organic/natural, luxury/refined, playful/toy-like,
editorial/magazine, brutalist/raw, art deco/geometric, soft/pastel,
industrial/utilitarian." Eleven options plus "etc." This is few-shot
prompting applied to creative direction. The model reads these and
understands the range of acceptable aesthetic choices. Without this list,
it would default to its statistical center: clean, minimal, system fonts,
safe color palette.

"What makes this UNFORGETTABLE?" is a prompt engineering technique. It forces
the model to generate a distinctive feature rather than settling for the
first acceptable solution. The question demands a specific answer, which
means the model has to commit to something before it starts writing code.

## Hard gates: CRITICAL and NEVER

Two escalation markers in the entire skill. Compare with the system prompt,
which uses CRITICAL/IMPORTANT roughly 5-6 times in 2,000 words. This skill
uses them twice in about 700 words. The ratio is similar. The author is
disciplined about when to escalate.

### The CRITICAL gate

```
CRITICAL: Choose a clear conceptual direction and execute it with precision.
```

This prevents the model from hedging. Without it, the model might produce
something that is "a little brutalist and a little minimalist and a little
retro." The CRITICAL marker tells it to pick one direction and commit. Mixed
aesthetics read as indecision, not sophistication.

### The NEVER gate

```
NEVER use generic AI-generated aesthetics like overused font families
(Inter, Roboto, Arial, system fonts), cliched color schemes (particularly
purple gradients on white backgrounds), predictable layouts and component
patterns, and cookie-cutter design that lacks context-specific character.
```

This is the most aggressive use of negative examples in anything we have
dissected. The code-reviewer agent had a confidence threshold to filter
false positives. This skill has an aesthetic blacklist: specific fonts,
specific color schemes, specific layout patterns.

The principle is the same: telling the model what NOT to do is as important
as telling it what TO do. But abstract "don't be generic" is less effective
than naming the specific things to avoid. "Inter, Roboto, Arial" is a
checklist the model can verify its output against. "Generic fonts" is not.

## The cross-generation instruction

```
NEVER converge on common choices (Space Grotesk, for example) across
generations.
```

This is a fascinating line. It tells the model to vary its choices across
different invocations, not just within one. The model has a tendency to find
a "good enough" solution and reuse it. Space Grotesk is apparently one it
kept choosing. The parenthetical "(Space Grotesk, for example)" is the
author saying: I caught you doing this specific thing, stop it.

Whether this actually works across separate conversations is debatable; the
model has no memory between sessions. But within a session with multiple
frontend requests, the instruction has teeth. And even across sessions, it
biases the model away from the named font, which partially solves the
convergence problem.

## No tool restrictions

The skill has no `allowed-tools` field. It does not restrict what the model
can use.

This is correct. A frontend design skill needs Write (to create files),
Bash (to run dev servers, install packages, open browsers), Read (to check
existing code), and potentially anything else. Restricting tools would limit
the model's ability to actually build the interface. Compare with the commit
command from [[04.5 Dissecting a Command|Dissecting a Command]], which locks
tools down to three Bash patterns. That command has a narrow, mechanical
task. This skill has an open-ended creative task. Different tasks, different
constraints.

Skills also cannot restrict tools through frontmatter the way commands can.
The `allowed-tools` field belongs to [[04.3 Command Anatomy|Command Anatomy]],
not [[04.2 Skill Anatomy|Skill Anatomy]]. A skill operates within whatever
tool context already exists.

## What this skill teaches

### A skill does not have to be a workflow

It can be a personality injection that changes how the model approaches an
entire category of tasks. Checklists work for sequential processes.
Constraint-based skills work for creative and qualitative tasks where the
goal is "do it well" rather than "do these steps."

### Negative examples beat abstract instructions

"Be creative" is vague. "Do not use Inter, Roboto, Arial, or purple
gradients on white backgrounds" is concrete. The model can check its own
output against a blacklist. It cannot check its output against "be creative."
Name the specific things you want to avoid.

### The description is the only trigger

No `<example>` blocks, no shell expansion, no parent command deciding when
to invoke it. The description must contain the phrases users actually say.
"Build web components", "pages", "applications" cover the common requests.

### Hard gates should be rare and specific

Two in 700 words. Each one targets a specific failure mode: CRITICAL prevents
aesthetic hedging, NEVER prevents font and color convergence. If every
paragraph is CRITICAL, nothing is.

### Long option lists are few-shot prompting for creative direction

The eleven tone options expand the model's sense of what is possible. Without
them, it defaults to its training distribution center. With them, it has
explicit permission to go in unexpected directions. The list is not
exhaustive; "etc." signals that. But it provides enough variety to break the
model out of its default patterns.

### You can fight cross-invocation convergence

Naming specific outputs the model tends to repeat (Space Grotesk) and
telling it to avoid them is a practical, if imperfect, solution to the
problem of models settling on favorite answers. It works best within a
session and as a bias shift across sessions.

---

Previous: [[04.6 Dissecting a Complex Command|Dissecting a Complex Command]] | Next: [[04.8 Dissecting a Technical Skill|Dissecting a Technical Skill]]
Tags: #skills #practical #reference
Related: [[04.2 Skill Anatomy|Skill Anatomy]] | [[04.4 Writing for the Model|Writing for the Model]] | [[03.4 Dissecting an Agent|Dissecting an Agent]]