Vibe design
Frontend design workflow that produces non-generic, editorial-quality UI. Immediately invokes the frontend-design skill for aesthetic direction before any code is written. Enforces a written design contract that is re-read before every single component — not once and forgotten. Creates separate files per page and component, never monolithic output. Reads DESIGN.md if present for exact brand tokens. Reads ANTI_GENERIC.md to kill SaaS dashboard defaults. Reads SITE_TYPE_PLAYBOOK.md for site-type-specific vocabulary. Triggers on "design:" prefix, "style this", "make this look better", "redesign this page", "the UI needs work", "can you polish", "do a design pass", "it looks too plain", "it looks generic", "it looks like a saas dashboard", "make separate pages". Always use when the goal is visual — aesthetics, layout, feel, interactions. Never use for logic, data, tests, or spec changes.From its SKILL.md
npx -y skills add aakashdhar/vibe-skill --skill vibe-designAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 7 stars7 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
11.3 KB, ~2.5k tokens by cl100k_base, as published. Nobody here has run it
Vibe Design Skill
Handles all visual styling for a vibe project. Invokes frontend-design first. Commits to a design contract. Re-reads that contract before every component. Creates separate files.
The separation of concerns:
- vibe agent — spec compliance, data flow, logic, tests, docs
- vibe-design — aesthetics, layout, feel, interactions, visual polish
CRITICAL: How this skill works
The reason AI design tools produce generic output is that they commit to a direction once and then forget it during implementation.
This skill works differently:
- frontend-design is invoked first — before reading any project files
- A design contract is written — specific, named, irreversible choices
- The contract is re-read before every single component — not once, every time
- Each page gets its own file — never one monolithic output
If you find yourself about to write a white card with shadow-md — stop. Re-read the design contract. If the contract says "no cards" — no cards.
Step 1 — Invoke frontend-design IMMEDIATELY
Before reading project files. Before understanding the request. Before doing anything else.
Read ~/.claude/skills/frontend-design/SKILL.md in full right now.
This is not optional. This is not "if installed." This is the first action.
The frontend-design skill gives you:
- The instruction to commit to an EXTREME aesthetic direction
- The anti-generic typography, colour, and motion principles
- The mindset: make it UNFORGETTABLE, not safe
If the file is not found at ~/.claude/skills/frontend-design/SKILL.md:
Check ~/.claude/skills/public/frontend-design/SKILL.md.
If neither exists — proceed, but the output quality will be lower.
After reading frontend-design — internalise this:
"I will commit to a bold, specific aesthetic direction. I will not produce a SaaS dashboard. I will not use Inter, blue-500, shadow-md, or centered columns. Every component will reflect the committed direction."
Step 2 — Read project context and DESIGN.md
Read in this order:
First — check for DESIGN.md (highest priority):
ls DESIGN.md 2>/dev/null && echo "DESIGN.MD EXISTS" || echo "NO DESIGN.MD"
cat DESIGN.md 2>/dev/null
If DESIGN.md exists — its tokens are the law. Exact hex values. Exact font names. Exact shadow formulas. Do not approximate. Do not substitute. DESIGN.md overrides DESIGN_SYSTEM.md where they conflict.
Then read project files:
vibe/CODEBASE.md— stack, component library, file pathsvibe/SPEC.md— UI specification, screens, componentsvibe/DESIGN_SYSTEM.md— existing tokensCLAUDE.md— code style, naming conventions
Extract:
- Styling approach: Tailwind / CSS Modules / styled-components / vanilla CSS
- Framework: React / Vue / Next.js / vanilla — determines animation library
- Platform: mobile-first or desktop
- Pages and screens that need design work
Step 3 — Write the design contract
This is the most important step. Do not rush it.
Read references/ANTI_GENERIC.md in full.
Read references/SITE_TYPE_PLAYBOOK.md — find the matching site type.
Then write the design contract. This is a concrete, named document.
═══════════════════════════════════════════════════════════
DESIGN CONTRACT — [Project name] — [date]
═══════════════════════════════════════════════════════════
SITE TYPE: [AI/SaaS / Agency / Marketing / Developer tool / Dashboard]
ONE BOLD CHOICE: [Name it explicitly — this is non-negotiable]
Examples:
"Headlines are Fraunces 120px+ left-anchored — never centered"
"No cards anywhere — all content is in full-width rows"
"Brand colour appears in exactly 3 places — nowhere else"
"Navigation is 32px tall, text only, no icons"
TYPOGRAPHY CONTRACT:
Display font: [exact name — NOT Inter, NOT system-ui]
Body font: [exact name]
Mono font: [exact name — for labels, data, metadata]
Display size: [clamp(72px, 9vw, 140px) or specific px]
Display weight: [800 or 700 — not 400, not 500]
Display tracking: [-0.04em or tighter]
Body size: [17px or 18px]
Body line-height: [1.7]
COLOUR CONTRACT:
Surface: [warm off-white hex — NOT #ffffff]
Text: [warm near-black hex — NOT #000 or gray-900]
Brand accent: [one colour only — NOT blue-500 or indigo-600]
Brand appears on: [list exactly where]
Brand does NOT appear on: [everything else]
MOTION CONTRACT:
Library: [Framer Motion | CSS + IntersectionObserver | Vue Transition]
Hero: [specific animation]
Sections: [scroll-triggered reveal approach]
Interactions: [hover/tap approach]
FILE STRUCTURE:
[Every file to be created — one page per file, one component family per file]
BANNED FOR THIS PROJECT:
❌ Inter as display font
❌ blue-500 / indigo-600 / violet-500 as primary colour
❌ white card with shadow-md
❌ Centered hero headline
❌ 3-column icon feature grid
❌ Gray-100 section backgrounds
[add project-specific bans here]
═══════════════════════════════════════════════════════════
Save the contract:
mkdir -p vibe/design
# Write contract to file — this gets re-read before every component
Save as vibe/design/CONTRACT.md.
Present to user:
"Design contract written. Bold choice: [state it clearly] This will look like: [one sentence description] Files to create: [N files — list them] Proceeding."
Wait for approval only if 3+ components. Otherwise proceed immediately.
Step 4 — Establish file structure BEFORE writing any code
Rule: one file per page, one file per component family. Always.
Never put multiple pages in one file. Never create a single wireframe.html or index.html with everything.
If the user asks for a wireframe.html — respond:
"I create separate files per page for maintainability and because vibe-design produces production files, not wireframes. File structure: [list from contract]. Starting with [first page]."
Create the structure:
mkdir -p src/pages src/components src/lib src/styles
# Create animation tokens file FIRST — everything imports from here
# Write src/lib/animations.ts with tokens from ANTI_GENERIC.md
# Create CSS tokens file with values from the contract
# Write src/styles/tokens.css with all CSS custom properties
# Announce
echo "Structure created. Building [N] files:"
echo "[list all files from contract]"
echo "Starting with [first file]."
Step 5 — Implement — one file at a time
MANDATORY before each file: Re-read the design contract
cat vibe/design/CONTRACT.md
Then ask: does my plan for this component implement the bold choice? State out loud:
"Building [filename]. Bold choice implementation: [how this component shows it]. Using [display font] at [size]. Brand colour on [what, if anything]."
If you cannot answer how this component implements the bold choice — redesign the approach until you can.
Write the implementation
For each component:
- Implement the design
- Cover all states: default, hover, active, focus, disabled, loading, empty
- Mobile-first if project is mobile-first
Per-component self-check (mandatory before moving to next file):
- Bold choice is visible and intentional in this component
- Display font used for headlines — NOT Inter, NOT system fonts
- Brand colour appears only where the contract specifies
- Animation imported from
src/lib/animations.ts— not inline - No pattern from the BANNED LIST is present
- This component could not be mistaken for a generic SaaS dashboard
If any check fails — fix before moving to the next file.
Stack-specific guidance
React + Tailwind + Framer Motion:
// Tokens in tailwind.config.js, not hardcoded
// All animations from src/lib/animations.ts
// next/font for font loading
// motion.div with variants from animations.ts
React + CSS Modules + Framer Motion:
// CSS custom properties in tokens.css
// BEM class names in .module.css
// Framer Motion for all transitions
Vue 3:
// CSS custom properties globally
// Vue Transition + CSS @keyframes
// IntersectionObserver for scroll reveals
// No Framer Motion (React only)
Vanilla HTML + CSS + JS:
// CSS custom properties at :root
// IntersectionObserver for scroll triggers
// CSS @keyframes with animation-delay for stagger
// No dependencies required
Step 6 — Full consistency check after all files
After all files written:
Typography:
- Display font is the font from the contract — everywhere
- No Inter as display font unless it IS in the contract
- Mono font used for labels, metadata, numbers
Colour:
- Brand colour in ONLY the places the contract specifies
- Surface is warm off-white, NOT #ffffff
- Text is warm near-black, NOT gray-900 or #000000
- No blue-500, indigo-600 anywhere
Motion:
- All animations from animations.ts
-
prefers-reduced-motionhandled
Layout:
- The bold choice is visible on the page
- No centered hero headline (unless contract says so)
- No 3-column icon grid
- No white cards with shadow-md (unless in contract)
Files:
- Every page is a separate file
- No monolithic output
Step 7 — Update docs and commit
Update vibe/DESIGN_SYSTEM.md with the design contract as the direction section.
Update vibe/TASKS.md with what was built.
git add src/ vibe/
git commit -m "design([scope]): [bold choice] — [files created]"
Signal done:
✅ Design complete — [scope]
[One sentence: what it looks like]
Bold choice: [restate]
Files: [N files created — list them]
Contract: vibe/design/CONTRACT.md
Non-negotiable rules
frontend-design is read in Step 1. No exceptions.
The design contract is written before any code. No exceptions.
The contract is re-read before each file. No exceptions.
One file per page. One file per component family. No exceptions.
Generic is failure. A SaaS dashboard means the skill failed. Not played it safe — failed. Retry from Step 3.
What ships with it: 2 files
23.4 KB alongside SKILL.md
references/
- ANTI_GENERIC.md14.2 KB
- SITE_TYPE_PLAYBOOK.md9.2 KB