domains / design / claymorphism-style-guide / claymorphism

claymorphism

Skill card

combined

The two copies serve different purposes and contain non-overlapping material. The bergside copy is a design-system authoring workflow: it defines tokens (Montserrat/Poppins, specific hex palette, 4/8/12/16/24/32 spacing), accessibility gates (WCAG 2.2 AA), a required output structure, and a QA checklist. The sickn33 copy is an implementation guide: it defines the visual DNA (double inner shadows, squircles, pastel palettes, rounded fonts like Sniglet/Fredoka One), and provides concrete CSS, SwiftUI, and Flutter code with bouncy spring/elastic animations. Neither copy contains the other's core steps, so crowning one would hide a real alternative.

Repositories

Other copies

Combined skill

# Claymorphism Skill

## Mission
Create implementation-ready claymorphism guidance that covers both design-system authoring and platform-specific code.

## When to Use
Trigger when the user wants soft 3D elements, rounded shapes, and a playful, tactile appearance.

## Visual DNA
- Fluffy 3D volume: elements look like inflated balloons or soft clay blocks.
- Double inner shadows: inset light shadow on top-left, inset dark shadow on bottom-right.
- Continuous curves: maximum border-radius; no sharp edges.
- Shapes: squircles and perfect circles.
- Colors: pastels and bright, friendly hues; elements detach from the background with drop shadows.
- Typography: playful, thick, rounded fonts (e.g., Sniglet, Fredoka One, Nunito).

## Design Tokens and Foundations
- Spacing scale: 4/8/12/16/24/32.
- Color tokens: define primary, neutral, success, warning, danger, surface, and text tokens. Use pastel/bright hues for surfaces; ensure text contrast meets WCAG 2.2 AA.
- Typography: choose a rounded, playful font family for display and body; define weights 100–900 as needed.

## Component Rule Expectations
- Define required states: default, hover, focus-visible, active, disabled, loading, error.
- 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).

## Web Implementation (CSS)
```css
.clay-card {
  background-color: #F8B4A6;
  border-radius: 32px;
  padding: 40px;
  box-shadow:
    8px 8px 24px rgba(0, 0, 0, 0.15),
    inset -8px -8px 16px rgba(0, 0, 0, 0.1),
    inset 8px 8px 16px rgba(255, 255, 255, 0.4);
  transition: transform 0.2s cubic-bezier(0.34, 1.56, 0.64, 1);
}
.clay-card:hover {
  transform: translateY(-5px) scale(1.02);
}
```

## App Implementation
### SwiftUI
- Use a gradient stroke overlay (white top-left, dark bottom-right) to fake inner volume.
- Use `.interpolatingSpring(stiffness: 300, damping: 10)` for bouncy feel.
- Background color should be pastel/bright but NOT the same as the parent.

### Flutter
- Use `GradientBorder` with a linear gradient (white top-left, transparent middle, dark bottom-right) for clay volume.
- Use `Curves.elasticOut` for bouncy clay feel.

## Accessibility
- WCAG 2.2 AA compliance.
- Keyboard-first interactions with visible focus states.
- Every accessibility statement must be testable in implementation.

## 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
- 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

## Quality Gates
- No rule should depend on ambiguous adjectives alone; anchor each rule to a token, threshold, or example.
- Prefer system consistency over one-off local optimizations.
- Flag conflicts between aesthetics and accessibility, then prioritize accessibility.
- Use "must" for non-negotiable rules and "should" for recommendations.
- Pair every do-rule with at least one concrete don't-example.

## Conflicts
- Typography: bergside specifies Montserrat/Poppins/JetBrains Mono; sickn33 specifies Sniglet/Fredoka One/Nunito. Choose based on project context; both are valid for claymorphism.
- Color palette: bergside provides a fixed hex palette; sickn33 recommends pastel/bright hues. Use the fixed palette as a starting point, then adjust to pastel/bright hues as needed.
- Scope: bergside focuses on design-system authoring; sickn33 focuses on implementation. This combined skill covers both.