agentsclimarketplace

Designbrief

Skill Heiberg-Industries/designbrief

Design guardrails, not templates. A library of UI design direction files that give LLMs (and humans) the context to build tasteful, consistent interfaces in any style.

Install
npx -y skills add Heiberg-Industries/designbrief

Assembled 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.

What its author says it does

Copied from the file, not written here

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.

SKILL.md

6.5 KB, 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.md for 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-motion fallbacks 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:

  1. Non-Negotiables — The 3 defining characteristics that MUST be present for the style to be recognizable
  2. Identity — Name, origin, mood keywords, best-for industries
  3. Typography — Font families/characteristics, scale philosophy, weight usage
  4. Color — Palette theory, contrast approach, accent strategy
  5. Spacing & Layout — Grid system, whitespace philosophy, rhythm, composition
  6. Borders & Shadows — Radius, depth, elevation, visual effects
  7. Components — How buttons, cards, inputs, navbars, modals should look and feel
  8. Motion — Animation philosophy, transition characteristics
  9. Dark Mode & Light Mode — Palette adaptation, mode preference, implementation
  10. Responsive & Mobile — Typography scaling, spacing compression, layout collapse, touch targets, performance
  11. Content & Voice — Headline tone, body copy style, CTA language, microcopy personality
  12. Icons & Illustrations — Icon style, illustration approach, photography direction
  13. Accessibility — Contrast verification, focus states, motion sensitivity, screen reader considerations
  14. Do's and Don'ts — Critical guardrails to maintain style integrity
  15. 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.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.