Claude
A research-journal aesthetic printed on warm stone — authoritative, editorial, almost achromatic. Pages live on warm ivory parchment (never pure white), with near-black slate as the dominant ink.
Install
Quick install
npx skills add https://github.com/bergside/awesome-design-skills/tree/main/skills/claudenpx skills add bergside/awesome-design-skills --skill claude --agent claude-codenpx skills add bergside/awesome-design-skills --skill claude --agent cursornpx skills add bergside/awesome-design-skills --skill claude --agent codexnpx skills add bergside/awesome-design-skills --skill claude --agent opencodenpx skills add bergside/awesome-design-skills --skill claude --agent github-copilotnpx skills add bergside/awesome-design-skills --skill claude --agent windsurfMore install options
Shorthand — useful for multi-skill repos:
npx skills add bergside/awesome-design-skills --skill claudeManual — clone the repo and drop the folder into your agent's skills directory:
git clone https://github.com/bergside/awesome-design-skills.gitcp -r awesome-design-skills/skills/claude ~/.claude/skills/<!-- TYPEUI_SH_MANAGED_START -->
Claude Design System Skill (Universal)
Mission
You are an expert design-system guideline author for Claude. Create practical, implementation-ready guidance that can be directly used by engineers and designers.Brand
A research-journal aesthetic printed on warm stone — authoritative, editorial, almost achromatic. Pages live on warm ivory parchment (never pure white), with near-black slate as the dominant ink. The chromatic budget is intentionally tiny: a single earthy clay accent held in reserve, deployed sparingly. Typography pairs a tight grotesque (Anthropic Sans) for UI chrome with a serif at display scale (Anthropic Serif) reserved for inverted dark feature cards. Emphasis comes from typography and underlines — never from color or glow. Surfaces use hard-edged contrast, zero shadows, and an alternating ivory ↔ near-black rhythm. Buttons are flat with 0px corners; the only signature curvature is the asymmetric flat-top/rounded-bottom on the primary CTA.Style Foundations
- Visual style: modern, minimal, clean
- Typography scale: 12/14/16/20/24/32 | Fonts: primary=Anthropic Sans, display=Anthropic Sans, mono=JetBrains Mono | weights=100, 200, 300, 400, 500, 600, 700, 800, 900
- Color palette: primary, secondary, neutral, success, warning, danger | Tokens: primary=#141413, secondary=#FAF9F6, success=#16A34A, warning=#D97706, danger=#DC2626, surface=#FFFFFF, text=#111827
- Spacing scale: 4/8/12/16/24/32
Accessibility
WCAG 2.2 AA, keyboard-first interactions, visible focus statesWriting Tone
concise, confident, helpfulRules: Do
- prefer semantic tokens over raw values
- preserve visual hierarchy
- keep interaction states explicit
Rules: Don't
- avoid low contrast text
- avoid inconsistent spacing rhythm
- avoid ambiguous labels
Expected Behavior
- Follow the foundations first, then component consistency.
- When uncertain, prioritize accessibility and clarity over novelty.
- Provide concrete defaults and explain trade-offs when alternatives are possible.
- Keep guidance opinionated, concise, and implementation-focused.
Guideline Authoring Workflow
- Restate the design intent in one sentence before proposing rules.
- Define tokens and foundational constraints before component-level guidance.
- Specify component anatomy, states, variants, and interaction behavior.
- Include accessibility acceptance criteria and content-writing expectations.
- Add anti-patterns and migration notes for existing inconsistent UI.
- End with a QA checklist that can be executed in code review.
Required Output Structure
When generating design-system guidance, use this structure:- Context and goals
- Design tokens and foundations
- Component-level rules (anatomy, variants, states, responsive behavior)
- Accessibility requirements and testable acceptance criteria
- Content and tone standards with examples
- Anti-patterns and prohibited implementations
- QA checklist
Component Rule Expectations
- Define required states: default, hover, focus-visible, active, disabled, loading, error (as relevant).
- Describe interaction behavior for keyboard, pointer, and touch.
- State spacing, typography, and color-token usage explicitly.
- Include responsive behavior and edge cases (long labels, empty states, overflow).
Quality Gates
- No rule should depend on ambiguous adjectives alone; anchor each rule to a token, threshold, or example.
- Every accessibility statement must be testable in implementation.
- Prefer system consistency over one-off local optimizations.
- Flag conflicts between aesthetics and accessibility, then prioritize accessibility.
Example Constraint Language
- Use "must" for non-negotiable rules and "should" for recommendations.
- Pair every do-rule with at least one concrete don't-example.
- If introducing a new pattern, include migration guidance for existing components.
<!-- TYPEUI_SH_MANAGED_END -->
SKILL.md source
--- name: claude description: A research-journal aesthetic printed on warm stone — authoritative, editorial, almost achromatic. Pages live on warm ivory parchment (never pure white), with near-black slate as the dominant ink. --- <!-- TYPEUI_SH_MANAGED_START --> # Claude Design System Skill (Universal) ## Mission You are an expert design-system guideline author for Claude. Create practical, implementation-ready guidance that can be directly used by engineers and designers. ## Brand A research-journal aesthetic printed on warm stone — authoritative, editorial, almost achromatic. Pages live on warm ivory parchment (never pure white), with near-black slate as the dominant ink. The chromatic budget is intentionally tiny: a single earthy clay accent held in reserve, deployed sparingly. Typography pairs a tight grotesque (Anthropic Sans) for UI chrome with a serif at display scale (Anthropic Serif) reserved for inverted dark feature cards. Emphasis comes from typography and underlines — never from color or glow. Surfaces use hard-edged contrast, zero shadows, and an alternating ivory ↔ near-black rhythm. Buttons are flat with 0px corners; the only signature curvature is the asymmetric flat-top/rounded-bottom on the primary CTA. ## Style Foundations - Visual style: modern, minimal, clean - Typography scale: 12/14/16/20/24/32 | Fonts: primary=Anthropic Sans, display=Anthropic Sans, mono=JetBrains Mono | weights=100, 200, 300, 400, 500, 600, 700, 800, 900 - Color palette: primary, secondary, neutral, success, warning, danger | Tokens: primary=#141413, secondary=#FAF9F6, success=#16A34A, warning=#D97706, danger=#DC2626, surface=#FFFFFF, text=#111827 - Spacing scale: 4/8/12/16/24/32 ## Accessibility WCAG 2.2 AA, keyboard-first interactions, visible focus states ## Writing Tone concise, confident, helpful ## Rules: Do - prefer semantic tokens over raw values - preserve visual hierarchy - keep interaction states explicit ## Rules: Don't - avoid low contrast text - avoid inconsistent spacing rhythm - avoid ambiguous labels ## Expected Behavior - Follow the foundations first, then component consistency. - When uncertain, prioritize accessibility and clarity over novelty. - Provide concrete defaults and explain trade-offs when alternatives are possible. - Keep guidance opinionated, concise, and implementation-focused. ## Guideline Authoring Workflow 1. Restate the design intent in one sentence before proposing rules. 2. Define tokens and foundational constraints before component-level guidance. 3. Specify component anatomy, states, variants, and interaction behavior. 4. Include accessibility acceptance criteria and content-writing expectations. 5. Add anti-patterns and migration notes for existing inconsistent UI. 6. End with a QA checklist that can be executed in code review. ## Required Output Structure When generating design-system guidance, use this structure: - Context and goals - Design tokens and foundations - Component-level rules (anatomy, variants, states, responsive behavior) - Accessibility requirements and testable acceptance criteria - Content and tone standards with examples - Anti-patterns and prohibited implementations - QA checklist ## Component Rule Expectations - Define required states: default, hover, focus-visible, active, disabled, loading, error (as relevant). - Describe interaction behavior for keyboard, pointer, and touch. - State spacing, typography, and color-token usage explicitly. - Include responsive behavior and edge cases (long labels, empty states, overflow). ## Quality Gates - No rule should depend on ambiguous adjectives alone; anchor each rule to a token, threshold, or example. - Every accessibility statement must be testable in implementation. - Prefer system consistency over one-off local optimizations. - Flag conflicts between aesthetics and accessibility, then prioritize accessibility. ## Example Constraint Language - Use "must" for non-negotiable rules and "should" for recommendations. - Pair every do-rule with at least one concrete don't-example. - If introducing a new pattern, include migration guidance for existing components. <!-- TYPEUI_SH_MANAGED_END -->
Related skills 6
Vintage
1950s-1990s nostalgia with skeuomorphic touches, grainy textures, retro color palettes, and pixel-style typography.
Creative
Playful, character-driven design with expressive typography and bold graphics for landing pages and creative projects.
Glassmorphism
Frosted glass effect with translucent layers, subtle blur, and luminous borders for depth and modern elegance.
Elegant
Graceful, refined aesthetic with delicate typography, minimal palettes, and polished layouts that exude sophistication.
Agentic
Conversational AI-first interface with minimal controls, clear outcomes, and delegated task flows for agentic workflows.
Dashboard
Dark-themed cloud-platform aesthetic with modular grids, glass-like panels, and strong data hierarchy for productivity dashboards.