domains / design / brutalist-ui-implementation / brutalism
The two copies describe the same aesthetic but serve different purposes and contain non-overlapping, sometimes conflicting, implementation guidance. The bergside copy is a design-system authoring workflow (tokens, accessibility, QA checklist, output structure) with a specific palette (Darker Grotesque, #DD614C, #DAA144) and spacing scale. The sickn33 copy is a direct implementation guide for Web, SwiftUI, Flutter, and React Native, prescribing system fonts (Courier New, Times New Roman, Comic Sans), raw browser defaults, and a clashing palette (#0000FF, #FF0000, #C0C0C0). Crowning one would hide the other's concrete code patterns or the other's governance workflow.
| Repository | Path |
|---|---|
| bergside/awesome-design-skills | skills/brutalism/SKILL.md |
| sickn33/agentic-awesome-skills | plugins/agentic-awesome-skills-claude/skills/design-it/brutalism/SKILL.md |
| Role | Repository | Path |
|---|---|---|
| peer | bergside/awesome-design-skills | skills/brutalism/SKILL.md |
| peer | sickn33/agentic-awesome-skills | plugins/agentic-awesome-skills-claude/skills/design-it/brutalism/SKILL.md |
| adapter | sickn33/agentic-awesome-skills | plugins/agentic-awesome-skills/skills/design-it/brutalism/SKILL.md |
| adapter | sickn33/agentic-awesome-skills | skills/design-it/brutalism/SKILL.md |
# Brutalism Design & Implementation
## 1. Design System Authoring (Guidelines)
When creating design-system documentation for Brutalism:
1. **Restate Intent**: Define the aesthetic as raw, anti-design, and inspired by 1950s concrete architecture.
2. **Define Tokens**: Establish a spacing scale (4/8/12/16/24/32) and color tokens. Note: For a 'raw' implementation, prefer system defaults; for a 'curated' system, use tokens like primary=#DD614C.
3. **Accessibility**: Enforce WCAG 2.2 AA. Ensure keyboard-first interactions and visible focus states.
4. **Component Rules**: Define states (default, hover, focus-visible, active, disabled, loading, error). Use 'must' for non-negotiables and 'should' for recommendations.
5. **QA Checklist**: Include a code-review checklist for contrast, spacing rhythm, and semantic token usage.
## 2. Direct Implementation (Code)
When building UI components:
1. **Web (HTML/CSS)**:
- Use standard HTML tags without overriding default appearance.
- Use `border: 1px solid #000` for structure.
- Use `#0000FF` for links and `#C0C0C0` for button backgrounds.
- Use `font-family: monospace` or system defaults.
2. **SwiftUI**:
- Avoid native `ButtonStyle`.
- Use `Text` with `.underline()` and `.foregroundColor(.blue)` for links.
- Use `.border(Color.black, width: 1)` instead of shadows.
3. **Flutter**:
- Avoid `ElevatedButton`, `Card`, or `AppBar`.
- Build UI from raw `Container`s with `Border.all(color: Colors.black)`.
- Use `TextDecoration.underline` for interactivity.
4. **React Native**:
- Use `View` with `borderWidth: 2` and `borderColor: '#000000'`.
- Use `TouchableOpacity` with `activeOpacity={1}`.
## 3. Conflicts & Trade-offs
- **Fonts**: The design-system copy suggests curated fonts (Darker Grotesque), while the implementation copy mandates system fonts (Courier New). **Resolution**: Use system fonts for maximum 'raw' authenticity in code; use curated fonts only if the design system explicitly overrides the 'raw' constraint for brand consistency.
- **Palette**: The design-system copy uses a muted, curated palette (#DD614C), while the implementation copy uses clashing, raw colors (#0000FF, #FF0000). **Resolution**: Use raw colors for 'Industrial Chic' or 'Anti-Aesthetic' goals; use curated tokens for 'Functional Minimalism' goals.