본문으로 건너뛰기
cccskills
무료GitHub에 공개

nothing-design

This skill should be used when the user explicitly says "Nothing style", "Nothing design", "/nothing-design", or directly asks to use/apply the Nothing design system. NEVER trigger automatically for generic UI or design tasks.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

설치 방법 보기

포함된 파일(4)

  • SKILL.md9.0 KB
  • references/components.md6.1 KB
  • references/platform-mapping.md1.9 KB
  • references/tokens.md5.8 KB

SKILL.md(원문)

설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.

Nothing-Inspired UI/UX Design System

A senior product designer's toolkit trained in Swiss typography, industrial design (Braun, Teenage Engineering), and modern interface craft. Monochromatic, typographically driven, information-dense without clutter. Dark and light mode with equal rigor.

Before starting any design work, declare which Google Fonts are required and how to load them (see references/tokens.md Section 1). Never assume fonts are already available.


1. DESIGN PHILOSOPHY

  • Subtract, don't add. Every element must earn its pixel. Default to removal.
  • Structure is ornament. Expose the grid, the data, the hierarchy itself.
  • Monochrome is the canvas. Color is an event, not a default — except when encoding data status (see Section 3).
  • Type does the heavy lifting. Scale, weight, and spacing create hierarchy — not color, not icons, not borders.
  • Both modes are first-class. Dark mode: OLED black. Light mode: warm off-white. Neither is "derived" — both get full design attention. Ask the user which mode to start with.
  • Industrial warmth. Technical and precise, but never cold. A human hand should be felt.

2. CRAFT RULES — HOW TO COMPOSE

2.1 Visual Hierarchy: The Three-Layer Rule

Every screen has exactly three layers of importance. Not two, not five. Three.

LayerWhatHow
PrimaryThe ONE thing the user sees first. A number, a headline, a state.Doto or Space Grotesk at display size. --text-display. 48–96px breathing room.
SecondarySupporting context. Labels, descriptions, related data.Space Grotesk at body/subheading. --text-primary. Grouped tight (8–16px) to the primary.
TertiaryMetadata, navigation, system info. Visible but never competing.Space Mono at caption/label. --text-secondary or --text-disabled. ALL CAPS. Pushed to edges or bottom.

The test: Squint at the screen. Can you still tell what's most important? If two things compete, one needs to shrink, fade, or move.

Common mistake: Making everything "secondary." Evenly-sized elements with even spacing = visual flatness. Be brave — make the primary absurdly large and the tertiary absurdly small. The contrast IS the hierarchy.

2.2 Font Discipline

Per screen, use maximum:

  • 2 font families (Space Grotesk + Space Mono. Doto only for hero moments.)
  • 3 font sizes (one large, one medium, one small)
  • 2 font weights (Regular + one other — usually Light or Medium, rarely Bold)

Think of it as a budget. Every additional size/weight costs visual coherence. Before adding a new size, ask: can I create this distinction with spacing or color instead?

DecisionSizeWeightColor
Heading vs. bodyYesNoNo
Label vs. valueNoNoYes
Active vs. inactive navNoNoYes
Hero number vs. unitYesNoNo
Section title vs. contentYesOptionalNo

Rule of thumb: If reaching for a new font-size, it's probably a spacing problem. Add distance instead.

2.3 Spacing as Meaning

Spacing is the primary tool for communicating relationships.

Tight (4–8px)   = "These belong together" (icon + label, number + unit)
Medium (16px)    = "Same group, different items" (list items, form fields)
Wide (32–48px)   = "New group starts here" (section breaks)
Vast (64–96px)   = "This is a new context" (hero to content, major divisions)

If a divider line is needed, the spacing is probably wrong. Dividers are a symptom of insufficient spacing contrast. Use them only in data-dense lists where items are structurally identical.

2.4 Container Strategy (prefer top)

  1. Spacing alone (proximity groups items)
  2. A single divider line
  3. A subtle border outline
  4. A surface card with background change

Each step down adds visual weight. Use the lightest tool that works. Never box the most important element — let it float on the background.

2.5 Color as Hierarchy

In a monochrome system, the gray scale IS the hierarchy. Max 4 levels per screen:

--text-display (100%) → Hero numbers. One per screen.
--text-primary (90%)  → Body text, primary content.
--text-secondary (60%) → Labels, captions, metadata.
--text-disabled (40%) → Disabled, timestamps, hints.

Red (#D71921) is not part of the hierarchy. It's an interrupt — "look HERE, NOW." If nothing is urgent, no red on the screen.

Data status colors (success green, warning amber, accent red) are exempt from the "one accent" rule when encoding data values. Apply color to the value itself, not labels or row backgrounds. See references/tokens.md for the full color system.

2.6 Consistency vs. Variance

Be consistent in: Font families, label treatment (always Space Mono ALL CAPS), spacing rhythm, color roles, component shapes, alignment.

Break the pattern in exactly ONE place per screen: An oversized number, a circular widget among rectangles, a red accent among grays, a Doto headline, a vast gap where everything else is tight.

This single break IS the design. Without it: sterile grid. With more than one: visual chaos.

2.7 Compositional Balance

Asymmetry > symmetry. Centered layouts feel generic. Favor deliberately unbalanced composition:

  • Large left, small right: Hero metric + metadata stack.
  • Top-heavy: Big headline near top, sparse content below.
  • Edge-anchored: Important elements pinned to screen edges, negative space in center.

Balance heavy elements with more empty space, not with more heavy elements.

2.8 The Nothing Vibe

  1. Confidence through emptiness. Large uninterrupted background areas. Resist filling space.
  2. Precision in the small things. Letter-spacing, exact gray values, 4px gaps. Micro-decisions compound into craft.
  3. Data as beauty. 36GB/s in Space Mono at 48px IS the visual. No illustrations needed.
  4. Mechanical honesty. Controls look like controls. A toggle = physical switch. A gauge = instrument.
  5. One moment of surprise. A dot-matrix headline. A circular widget. A red dot. Restraint makes the one expressive moment powerful.
  6. Percussive, not fluid. Imagine UI sounds: click not swoosh, tick not chime. Design transitions that feel mechanical and precise.

2.9 Visual Variety in Data-Dense Screens

When 3+ data sections appear on one screen, vary the visual form:

FormBest forWeight
Hero number (large Doto/Space Mono)Single key metricHeavy — use once
Segmented progress barProgress toward goalMedium
Concentric rings / arcsMultiple related percentagesMedium
Inline compact barSecondary metrics in rowsLight
Number-only with status colorValues without proportionLightest
SparklineTrends over timeMedium
Stat row (label + value)Simple data pointsLight

Lead section → heaviest treatment. Secondary → different form. Tertiary → lightest. The FORM varies, the VOICE stays the same.


3. ANTI-PATTERNS — WHAT TO NEVER DO

  • No gradients in UI chrome
  • No shadows. No blur. Flat surfaces, border separation.
  • No skeleton loading screens. Use [LOADING...] text or segmented spinner.
  • No toast popups. Use inline status text: [SAVED], [ERROR: ...]
  • No sad-face illustrations, cute mascots, or multi-paragraph empty states
  • No zebra striping in tables
  • No filled icons, multi-color icons, or emoji as UI
  • No parallax, scroll-jacking, or gratuitous animation
  • No spring/bounce easing. Use subtle ease-out only.
  • No border-radius > 16px on cards. Buttons are pill (999px) or technical (4–8px).
  • Data visualization: differentiate with opacity (100%/60%/30%) or pattern (solid/striped/dotted) before introducing color.

4. WORKFLOW

  1. Declare fonts — tell the user which Google Fonts to load (see references/tokens.md)
  2. Ask mode — dark or light? Neither is default.
  3. Sketch hierarchy — identify the 3 layers before writing any code
  4. Compose — apply craft rules (Sections 2.1–2.9)
  5. Check tokens — consult references/tokens.md for exact values
  6. Build components — consult references/components.md for patterns
  7. Adapt to platform — consult references/platform-mapping.md for output conventions

5. REFERENCE FILES

For detailed token values, component specs, and platform-specific guidance:

  • references/tokens.md — Fonts, type scale, color system (dark + light), spacing scale, grid, motion, iconography, dot-matrix motif
  • references/components.md — Cards, buttons, inputs, lists, tables, nav, tags, segmented controls, progress bars, charts, widgets, overlays, state patterns
  • references/platform-mapping.md — HTML/CSS, SwiftUI, React/Tailwind, Paper output conventions

리뷰

아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.

댓글

로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.

아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.

보내면 바로 공개됩니다. 이메일 주소나 전화번호 같은 개인 정보는 쓰지 마세요. URL은 2개까지입니다.

0 / 1,000자

이 양식은 reCAPTCHA로 보호되며 Google 개인정보처리방침 및 서비스 약관이 적용됩니다.

같은 저장소의 스킬

Use when evaluating, designing, or pressure-testing the business model of an AI agent product. Triggers on "agent business model", "agent economics", "agent canvas", "evaluate agent product", "agent pricing", "agent unit economics", "agentic business", "AI agent company", "agent cost structure".

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

harperreed/dotfiles3352026년 10월 16일 업데이트

Create user-facing App Store release notes by collecting and summarizing all user-impacting changes since the last git tag (or a specified ref). Use when asked to generate a comprehensive release changelog, App Store "What's New" text, or release notes based on git history or tags.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

harperreed/dotfiles3352026년 10월 16일 업데이트

Use when someone wants to launch a content brand from scratch on any platform. Triggers on "launch a channel", "start a YouTube channel", "build a podcast", "start a newsletter", "content brand", "creator launchpad", "build my audience", "start creating content", "grow on TikTok", "start a blog".

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

harperreed/dotfiles3352026년 10월 16일 업데이트

Use when you have an existing pipeline DOT file that needs review, fixing, or validation. Use when validation produces warnings or errors, when a DOT file was hand-written or generated by another tool, or when you want to verify a pipeline covers 100% of a spec before running it.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

harperreed/dotfiles3352026년 10월 16일 업데이트

Use when you want to build a project but don't have a spec yet and need to brainstorm the idea into a design doc structured for pipeline DOT generation. Use when starting from a vague idea, project concept, or feature request that needs to become a headless autonomous build pipeline.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

harperreed/dotfiles3352026년 10월 16일 업데이트

Use when you have a spec, design doc, structured plan, or prompt_plan and need to generate a pipeline Graphviz DOT file for headless autonomous building. The agent reads the spec, extracts build pipeline phases, determines tech stack, asks about human gates and model preferences, generates a validated DOT digraph with rich self-contained prompts, and saves it to the project root. Handles any language or framework.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

harperreed/dotfiles3352026년 10월 16일 업데이트

harperreed의 스킬 모두 보기

이 스킬의 문제 신고