Designbrief
A library of UI design direction files that provide style guardrails for building tasteful, consistent interfaces. Use when building any UI — select a style or let the AI recommend one based on the project context.From its SKILL.md
npx -y skills add Heiberg-Industries/designbriefAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 10 stars10 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
6.5 KB, ~1.4k tokens by cl100k_base, as published. Nobody here has run it
designbrief
A library of rich design direction files — one per UI style — that provide guardrails for building tasteful, consistent interfaces without prescribing exact values.
How It Works
Each style is a standalone markdown file in styles/ that defines the design DNA of a visual direction: typography families, color theory, spacing philosophy, border/shadow characteristics, layout principles, component behavior, and implementation guidance.
These are guardrails, not templates. They define what kind of font, color, spacing — not the exact values. The developer (or AI) makes specific choices within the style's constraints.
When This Skill Activates
Use this skill when the user:
- Asks to build any UI, page, component, or app
- Mentions a specific design style by name
- Asks for style recommendations or comparisons
- Wants to change the visual direction of an existing project
Workflow
1. Determine the Style
If the user specifies a style (e.g., "use Bauhaus", "make it glassmorphic"):
- Read the corresponding file from
styles/{style-name}.md - Apply its guardrails to all UI decisions
If the user does NOT specify a style:
- Read
styles/_index.mdfor the full catalog with mood/industry tags - Ask the user what mood, audience, and industry they're targeting
- Recommend 2-3 styles with brief reasoning
- Let them choose, then load the full style file
2. Apply the Style
When generating UI code, use the style file as your design system:
- Typography: Choose specific fonts from within the style's recommended families/characteristics
- Colors: Build a palette that follows the style's color theory and contrast rules
- Spacing: Apply the style's spacing philosophy (generous vs. tight, rhythmic vs. uniform)
- Components: Shape buttons, cards, inputs, navbars according to the style's component guidance
- Layout: Follow the style's grid and composition principles
- Effects: Apply borders, shadows, blur, gradients per the style's visual depth rules
- Dark/Light Mode: Check the style's Dark Mode & Light Mode section. If the user hasn't specified, use the style's recommended primary mode. If they ask for both, implement the style's palette adaptation for each.
- Responsive: Apply the style's Responsive & Mobile guidance. Ensure touch targets (44px minimum), compress spacing and typography for mobile, and handle any performance concerns (e.g., heavy blur on mobile devices).
- Content & Voice: Match headline tone, body copy style, CTA language, and microcopy personality to the style's Content & Voice section.
- Icons & Illustrations: Choose icon sets and illustration approaches that match the style's guidance.
- Accessibility: Verify contrast ratios per the style's Accessibility section. Implement style-appropriate focus states. Add
prefers-reduced-motionfallbacks for animations.
3. Teach Along the Way
When making a design decision, briefly explain why (one sentence) to help the user build taste over time. For example: "Using a warm off-white (#FAF8F5) instead of pure white because Japandi draws from natural materials — pure white feels clinical, not crafted." This is optional but encouraged, especially when the user is learning.
4. Stay Consistent
Once a style is selected for a project:
- Reference the style file for every new component or page
- Do not mix styles unless explicitly asked to create a hybrid
- When in doubt about a design decision, re-read the relevant section of the style file
- The style's "Don'ts" section is as important as its "Do's"
- Ensure dark mode, responsive behavior, content tone, and accessibility remain consistent across all pages
File Structure
styles/
├── _index.md # Catalog of all styles with tags, mood, best-for
├── bauhaus.md # Each style is a rich guardrail document
├── glassmorphism.md
├── neubrutalism.md
├── flat-design.md
├── ... (21 styles total)
Style File Anatomy
Every style file follows this structure:
- Non-Negotiables — The 3 defining characteristics that MUST be present for the style to be recognizable
- Identity — Name, origin, mood keywords, best-for industries
- Typography — Font families/characteristics, scale philosophy, weight usage
- Color — Palette theory, contrast approach, accent strategy
- Spacing & Layout — Grid system, whitespace philosophy, rhythm, composition
- Borders & Shadows — Radius, depth, elevation, visual effects
- Components — How buttons, cards, inputs, navbars, modals should look and feel
- Motion — Animation philosophy, transition characteristics
- Dark Mode & Light Mode — Palette adaptation, mode preference, implementation
- Responsive & Mobile — Typography scaling, spacing compression, layout collapse, touch targets, performance
- Content & Voice — Headline tone, body copy style, CTA language, microcopy personality
- Icons & Illustrations — Icon style, illustration approach, photography direction
- Accessibility — Contrast verification, focus states, motion sensitivity, screen reader considerations
- Do's and Don'ts — Critical guardrails to maintain style integrity
- Implementation Hints — Tailwind classes, CSS custom properties, token ranges
Important Notes
- These files define direction, not specification. Two projects using the same style should look related but not identical.
- Always prioritize readability and accessibility over style purity. If a style's aesthetic conflicts with usability, usability wins. Check the style's Accessibility section for known risks and remediation.
- The user can override any guardrail — the style file is a starting point, not a cage.
- When building for mobile, follow the style's Responsive & Mobile section — adapt the principles to touch targets and smaller viewports rather than abandoning them.
- Match the content tone to the visual style. A Neubrutalism site with corporate copy feels wrong; a Corporate Modern site with slang feels unprofessional. The Content & Voice section guides this.
- When teaching: good design is not arbitrary. Every rule exists for a reason — the "why" matters more than the "what." Help users understand the reasoning behind choices so they build taste over time.
What ships with it: 43 files
536.3 KB alongside SKILL.md, 12 of them executable
.cursor/
- rules/designbrief.mdc2.6 KB
lib/
- contrast.mjsruns2.3 KB
- css.mjsruns3.1 KB
- dtcg.mjsruns5.5 KB
- generate.mjsruns1.8 KB
- palette.mjsruns1.5 KB
- parser.mjsruns7.4 KB
- styles.mjsruns749 B
- tailwind.mjsruns3.6 KB
- telemetry.mjsruns1.4 KB
- tokens.mjsruns2.9 KB
styles/
- anti-design.md23.0 KB
- art-deco.md20.7 KB
- aurora.md22.2 KB
- bauhaus.md22.4 KB
- bento-grid.md13.7 KB
- claymorphism.md29.8 KB
- corporate-modern.md18.6 KB
- dark-mode-premium.md28.6 KB
- flat-design.md20.3 KB
- freeform.md25.9 KB
- glassmorphism.md22.8 KB
- _index.md16.8 KB
- japandi.md17.2 KB
- material-design.md24.5 KB
- minimalism.md23.2 KB
- neubrutalism.md27.1 KB
- neumorphism.md14.7 KB
- organic.md15.8 KB
- retro-futurism.md20.3 KB
- skeuomorphism.md22.2 KB
- AGENTS.md915 B
- .gitignore143 B
- LICENSE1.1 KB
- .npmignore71 B
- package.json1.1 KB
- PASTE-INSTRUCTIONS.md5.4 KB
- README.md6.6 KB
3 more files not listed here. See all 43 in the repository.