Vibe design
vibe-* is a collection of Claude Code CLI skills. Each skill is a structured instruction set that tells Claude Code exactly what to do at a specific moment in a project — how to plan it, build it, review it, test it, deploy it, and hand it off.
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.
- 6 stars6 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.
What its author says it does
Copied from the file, not written here
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.
SKILL.md
11.3 KB, 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.