디자인 시스템 빌더 스킬 (eond-design-system-builder) — 디자인 규칙 정리

eond-design-system-builder는 반복 업무를 더 안정적으로 처리하기 위한 AI 에이전트 스킬입니다.

Build, audit, and maintain Eond's design system across large multi-service websites. Use when the user asks to make Eond pages feel coherent as one brand, define design tokens, component rules, layout patterns, hero systems, card/button/navigation standards, reusable CSS structure, or when repeated pages look inconsistent across el_unified, market, portfolio, hosting, AXAI, guide, support, and product pages.

사용 방법

Codex나 호환되는 AI 에이전트의 스킬 폴더에 아래 SKILL.md 내용을 저장한 뒤, 설명에 포함된 트리거 문장으로 호출하세요.

사용 예:
eond-design-system-builder 스킬 사용해줘.
이 작업은 eond-design-system-builder 기준으로 진행해줘.

연관스킬

이 스킬과 함께 쓰면 좋은 관련 스킬입니다.

• eond-premium-design-director
• improve-eond-uxui
• web-motion-director

원본 위치

.codex/skills/eond-design-system-builder/SKILL.md

SKILL.md

---
name: eond-design-system-builder
description: Build, audit, and maintain Eond's design system across large multi-service websites. Use when the user asks to make Eond pages feel coherent as one brand, define design tokens, component rules, layout patterns, hero systems, card/button/navigation standards, reusable CSS structure, or when repeated pages look inconsistent across el_unified, market, portfolio, hosting, AXAI, guide, support, and product pages.
---

# Eond Design System Builder

## Role

Create and maintain a coherent design system for Eond's multi-service site. This skill is for system-level consistency, not one-off page decoration.

Use it to define tokens, page types, components, visual asset rules, responsive behavior, and implementation standards that make many Eond pages feel like one product ecosystem.

## Relationship To Page Design

- Use `eond-premium-design-director` for one page or one menu's high-quality creative direction.
- Use this skill when the same inconsistency repeats across pages or when a reusable system should be created before more pages are designed.

## Core System Goals

- Keep Eond recognizable across 제작 의뢰, 마켓, 호스팅, 주요제품, AXAI, 포트폴리오, 가이드, 고객지원.
- Let each page type have its own structure without inventing a new visual language every time.
- Make revenue pages clear, product pages visual, portfolio pages credible, resource pages easy to scan, and support pages direct.
- Provide implementation rules that map to templates, CSS tokens, components, and browser QA.

## Reference Selection

Load only the reference needed:

- Before defining or auditing the Eond-wide system, read `docs/eond-brand-guide.md`; preserve its approved brand decisions and use this skill to translate them into reusable tokens, components, and page patterns.
- Read `references/eond-design-tokens.md` when defining or auditing color, type, spacing, radius, shadow, or motion.
- Read `references/component-standards.md` when designing buttons, cards, heroes, tabs, filters, nav, forms, search, or CTAs.
- Read `references/korean-product-design-system.md` when translating Toss, KakaoTalk, Imweb, Cafe24, OpenAI, or “한국형 UX/UI” references into concrete Eond product design rules.
- Read `references/page-patterns.md` when deciding reusable page structures by page mode.
- Read `references/system-audit-checklist.md` when reviewing many pages or preparing implementation tasks.

## Workflow

1. Identify the scope: one layout, one page family, or the whole Eond site.
2. Inventory current patterns from source and screenshots before inventing new ones.
3. Classify pages into modes:
   - sales
   - catalog
   - proof
   - resource
   - support
   - utility/tool
4. Define system decisions:
   - visual principles
   - tokens
   - component standards
   - page pattern templates
   - image and asset rules
   - responsive rules
   - QA gates
5. Convert the system into implementation tasks:
   - CSS variables or token file
   - shared component classes
   - page template updates
   - migration order
   - regression checks
6. Do not change code until the user approves implementation.

## Output Shape

```text
시스템 목표
- 범위:
- 해결할 문제:
- 유지할 기존 패턴:
- 바꿀 패턴:

디자인 원칙
1. ...
2. ...
3. ...

토큰 결정
- 색:
- 타이포그래피:
- 간격:
- 반경:
- 그림자:
- 모션:

컴포넌트 기준
- 히어로:
- 카드:
- 버튼:
- 필터/탭:
- 폼:
- 검색:
- 내비게이션:

페이지 패턴
- sales:
- catalog:
- proof:
- resource:
- support:

개발 작업 분해
- 공통 CSS:
- 템플릿:
- 페이지별 적용:
- 검수:

완료 기준
- 1440/768/390 확인
- 가로 스크롤 0
- 한 페이지 한 H1
- CTA 위계 명확
- 게시판형 회귀 없음
```

## System Decision Rules

- If two pages serve different jobs, allow different layouts but keep shared tokens and component behavior.
- If many pages look inconsistent, fix shared primitives before rewriting every page.
- If a component is used across revenue pages, design its empty, hover, focus, disabled, and mobile states.
- If a visual asset is page-specific, define its art direction in the page skill, not in global tokens.
- If a page needs a one-off exception, document why it should not become a system pattern.

## Anti-Patterns

- Do not make all Eond pages a single repeated card grid.
- Do not use a one-note palette dominated by one hue family.
- Do not solve brand coherence by making every page visually identical.
- Do not introduce global CSS that breaks existing page templates.
- Do not define tokens that cannot be found or used by the current codebase.

## Validation

After system changes, verify:

- Representative sales, catalog, proof, resource, and support pages.
- 1440px, 768px, and 390px screenshots.
- Header, submenu, search, footer, and CTA consistency.
- Text overflow and mobile wrapping.
- Component states where visible.
- `git diff --check` and relevant template/CSS syntax checks.

참고 리소스

이 스킬이 직접 참조하는 Markdown 참고 파일입니다. 재사용할 때 같은 상대 경로로 저장하면 동작이 안정적입니다.

.codex/skills/eond-design-system-builder/references/eond-design-tokens.md

# Eond Design Tokens

Use this as the baseline when defining or auditing Eond-wide visual tokens.

## Principles

- Neutral first, accent second.
- Use color to guide action and status, not to decorate every surface.
- Keep radius restrained: 8px for cards/panels by default.
- Use shadows sparingly for interactive elevation and overlays.
- Keep typography stable and avoid viewport-width font scaling.

## Color Roles

| Role | Purpose | Guidance |
|---|---|---|
| ink | primary text, dark surfaces | near black / graphite |
| muted | secondary text | readable gray, not too light |
| canvas | page background | white or very light neutral |
| paper | section background | subtle contrast from canvas |
| border | dividers and card outlines | low contrast but visible |
| accent | primary Eond action | warm orange is preferred |
| success | completion/available | green, use sparingly |
| warning | caution/pending | amber, use with text |
| danger | destructive/error | red, never only color |

Avoid dominant purple-blue gradients, beige-heavy palettes, dark blue-only sites, and brown/orange one-note palettes.

## Typography

- Use one primary sans-serif family.
- H1 should be reserved for true page hero or page identity.
- Compact panels, cards, sidebars, filters, and dashboards need smaller headings.
- Letter spacing should be 0 except small uppercase labels where local style already uses it.
- Body copy should prioritize Korean readability and line length.

Recommended hierarchy:

| Token | Use |
|---|---|
| display | homepage or flagship hero only |
| h1 | page hero title |
| h2 | section title |
| h3 | card or group title |
| body | paragraphs and descriptions |
| meta | badges, dates, secondary labels |

## Spacing

Use consistent scale:

- 4, 8, 12, 16, 20, 24, 32, 40, 56, 72, 96

Rules:

- First viewport should show a hint of the next section when possible.
- Avoid oversized empty hero spaces unless a strong visual fills them.
- Mobile should reduce vertical padding before reducing content clarity.

## Radius

- 6-8px: cards, panels, repeated content items.
- 999px: chips, pills, compact filters only.
- 0-4px: dense tables, screenshots, framed UI.

Do not make every button and card a pill.

## Shadow

- Use border-first cards.
- Use shadow on hover, overlays, dropdowns, and modals.
- Avoid heavy floating-card pages.

## Motion

- Motion should clarify state or focus.
- Use subtle reveal and hover movement only.
- Respect reduced motion if global scripts support it.

## Asset Style

- Product screenshots and realistic UI mockups are preferred.
- Illustrations can be used only when they explain the service.
- Avoid decorative orbs, bokeh blobs, and purely atmospheric images.

.codex/skills/eond-design-system-builder/references/component-standards.md

# Component Standards

Use this when defining or auditing reusable Eond components.

## Hero

Each hero must include:

- eyebrow or category label
- one H1
- lead copy
- primary CTA when conversion is expected
- optional secondary CTA
- meaningful visual for commercial pages

Hero variants:

| Variant | Use |
|---|---|
| compact subhero | support, FAQ, guide pages |
| sales hero | 제작 의뢰, AXAI, hosting |
| product showcase hero | 주요제품, eondcms, wpstore |
| proof hero | portfolio and cases |
| utility hero | search, tools |

Failure: hero only says a title and then drops into a list.

## Cards

Card types:

- service card: user problem, service promise, action.
- product card: platform, preview, title, price/status, action.
- proof card: screenshot, project type, capability proven.
- resource card: topic, summary, reading path.
- support card: issue type, next step, support route.

Rules:

- Cards should not contain nested cards.
- Use stable min-height only where it prevents layout jump.
- Long Korean titles must wrap without overlapping.
- Hover can lift card slightly but should not move surrounding layout.

## Buttons

Hierarchy:

- primary: one dominant action per section.
- secondary: alternate path.
- ghost/text: low-priority navigation.
- icon: search, close, menu, external, back.

Rules:

- Button labels should state the result: `제작 문의하기`, `마켓 보기`, `호스팅 신청`.
- Mobile buttons should be at least 44px tall.
- Use focus-visible state.
- Do not use many equal-weight primary buttons.

## Tabs And Filters

Use for:

- portfolio categories
- product platform filters
- market type filters
- guide topics

Rules:

- Current selection must be visible.
- Horizontal scroll is acceptable on mobile if masked or clear.
- Category count can be shown only if it is accurate.

## Forms

Use for:

- request
- hosting apply
- login/signup
- contact

Rules:

- Labels must be visible.
- Required fields must be clear.
- Errors must tell the next action.
- Keep form lower than decision content unless the page is a pure application form.

## Search

Search should work as a sitewide escape hatch for a large Eond ecosystem.

Rules:

- Search input should be visually prominent.
- Results should show type/category and destination.
- Empty state should suggest service inquiry or alternate keywords.

## Navigation

Top navigation:

- Keep first depth short.
- Full-width submenu should group by category, not raw depth.
- Left edge should align with logo/content grid.

Sub navigation:

- Show current context.
- Avoid too many equal-weight items.
- On mobile, allow horizontal scroll without page overflow.

## Footer

Footer should support:

- revenue paths: request, market, hosting
- proof paths: portfolio, works
- help paths: support, FAQ, terms/privacy
- ecosystem paths: subdomains/tools where relevant

.codex/skills/eond-design-system-builder/references/korean-product-design-system.md

# Korean Product Design System Lens

Use this reference when a design skill says “Toss-like”, “KakaoTalk-like”, “한국형 소비자 서비스”, “10년차 UX/UI”, or when the output feels visually weak because the reference was too abstract.

This is not a copy guide for Toss, KakaoTalk, Imweb, Cafe24, OpenAI, or any other brand. It converts observable product quality into reusable Eond rules.

## 1. Product Clarity Layer

### First viewport

- One promise, one primary action, one proof cluster.
- The H1 must name the user benefit, not the internal service category.
- The lead copy should answer `누가 / 어떤 문제를 / 어떻게 쉽게 해결하는가`.
- Avoid two primary CTAs in the same visual weight. Use primary + secondary + text link.
- Put the next section hint in the first viewport unless a strong product visual fills the space.

### Copy density

- H1: 1–2 lines on desktop, 2–3 lines on mobile.
- Lead: 1–2 short Korean sentences. Avoid abstract nouns stacked together.
- Button labels state the result: `제작 문의하기`, `마켓 상품 보기`, `호스팅 신청하기`, `사례 확인하기`.
- Replace developer-first words with customer outcomes unless the target page is explicitly for developers.

### Trust before commitment

Before forms, payment, consultation, or installation, show:

- who provides it
- what happens after clicking
- whether there is cost, login, or waiting
- proof: real site, product, screenshot, market item, operation history, or support route

## 2. Familiar Interaction Layer

### Navigation

- Use stable top-level names; do not rename the same concept across pages.
- Show the current section and where the user can go next.
- Use familiar patterns first: list, detail, write, search, filter, more, back.
- On mobile, horizontal category scroll is acceptable only when page overflow is prevented and the active item is visible.

### Feedback states

Every important action must have at least the states that matter:

- default
- hover or pressed
- focus-visible
- loading or submitting
- success
- error with next action
- disabled with reason when relevant

Do not leave async actions silent. If a result takes time, show progress or an expectation.

### Recovery

- Destructive actions must be visually separated from primary actions.
- Forms should preserve user input after validation errors.
- Empty states should suggest next action or alternate route.
- Error messages should start with what the user can do next, then explain the cause if useful.

## 3. Visual System Layer

### Color

Use a restrained role system:

| Role | Use |
| --- | --- |
| canvas | page background |
| paper | section/card surface |
| ink | primary text |
| muted | secondary text |
| line | borders/dividers |
| accent | one main action or brand highlight |
| success/warning/danger | state only |

Rules:

- One dominant accent per page.
- Avoid “AI 느낌” default purple/blue gradient unless the page’s product actually needs it.
- Do not use color as the only status cue.
- On dark pages, preserve clear contrast and avoid gray-on-black fatigue.

### Typography

Use hierarchy, not random size jumps:

| Role | Typical use |
| --- | --- |
| display | flagship main or campaign hero only |
| h1 | page promise |
| h2 | section decision point |
| h3 | card or group title |
| body | explanation |
| meta | status, date, category, price note |

Rules:

- Korean body text needs generous line-height and moderate line length.
- Use display type sparingly; too many bold oversized headings reduce trust.
- Use labels to support scanning, but do not decorate with meaningless `01/02/03` unless order matters.

### Spacing and layout

- Use one spacing scale: 4, 8, 12, 16, 20, 24, 32, 40, 56, 72, 96.
- Desktop pages should align hero, sections, cards, and footer to a consistent content grid.
- Avoid floating many disconnected cards. Group by user decision.
- Mobile is not a squeezed desktop: reorder by user priority.

### Radius and shadow

- Cards/panels: 6–10px by default.
- Chips/pills: 999px only for compact filters, badges, or small selections.
- Use border-first surfaces; shadows are for overlays, hover elevation, or focused cards.
- Do not make every surface rounded and floating.

## 4. Component Rules

### Hero

Required:

- category/eyebrow
- H1 promise
- lead
- primary CTA
- optional secondary path
- proof or product visual

Failure signs:

- “서비스를 소개합니다” style generic H1
- decorative background without product meaning
- CTA below the fold on mobile
- hero followed immediately by raw board/list

### Cards

Choose card type by page job:

- service card: problem → promise → action
- product card: platform → preview → title → price/status → action
- proof card: screenshot → project type → solved problem → related CTA
- resource card: topic → summary → next read
- support card: issue → required info → contact route

Every card should answer why it exists. Remove cards that only fill a grid.

### Forms

- Visible label, helper text where needed, clear required state.
- Place decision content before form unless the page is only an application form.
- Submit button says outcome, not generic `확인`.
- Show what happens after submission.

### Lists and catalogs

- Filters must match user intent, not internal taxonomy only.
- Product/service lists need status, platform, preview, and action.
- Long lists need search or category shortcuts.

## 5. Motion Rules

Use motion to explain state, sequence, or identity.

Good uses:

- hero product scene assembles once
- selected category transitions
- card hover reveals action
- form submission shows progress
- logo motion explains brand meaning

Bad uses:

- every section fade-up
- random parallax that hides content
- looping background that competes with CTA
- motion without reduced-motion fallback

## 6. Scoring Add-On

When scoring UX/UI or design directions, include these checks explicitly:

| Check | Question |
| --- | --- |
| 5-second comprehension | Can a new visitor explain the page and next action? |
| CTA hierarchy | Is there exactly one dominant next action per decision area? |
| Evidence quality | Is the proof real, specific, and visible enough? |
| Korean readability | Are sentences short, natural, and customer-facing? |
| Familiar operation | Does interaction match common Korean web/mobile patterns? |
| State completeness | Are loading, empty, error, success, disabled considered? |
| Mobile decision flow | Does 390px preserve the decision order? |
| System coherence | Does it reuse Eond tokens/components without becoming generic? |

## 7. Eond Translation Rules

- “토스식” means: reduce decision noise, make the next action safe, make copy easy.
- “카카오톡식” means: familiar repeated-use patterns, stable navigation, generous recovery.
- “아임웹식” means: polished landing rhythm, curated sections, good commercial readability.
- “카페24식” means: catalog scalability, product status, support and purchase clarity.
- “OpenAI식” means: confident editorial minimalism, strong visual thesis, restrained technical atmosphere.

Never translate these references into cloned colors, rounded cards, fake dashboards, or generic gradients.

.codex/skills/eond-design-system-builder/references/page-patterns.md

# Page Patterns

Use these patterns when aligning many Eond pages under one system.

## Sales Pattern

Use for: 제작 의뢰, AXAI, hosting, service detail pages.

Section order:

1. Hero: problem, promise, CTA, trust.
2. Service choices or use cases.
3. Proof or examples.
4. Process and scope.
5. FAQ or reassurance.
6. Final CTA.

Mobile priority:

- H1
- lead
- primary CTA
- top 2-3 choices
- proof

## Catalog Pattern

Use for: market, wpstore, works, product families.

Section order:

1. Hero: catalog promise and platform split.
2. Category cards.
3. Featured products or product families.
4. Filters/search.
5. Product grid/list.
6. Support or custom request CTA.

Mobile priority:

- catalog category first
- product preview second
- long list after filters

## Proof Pattern

Use for: portfolio, case studies, client examples.

Section order:

1. Hero: proof promise and filters.
2. Featured case or proof summary.
3. Category filters.
4. Case grid.
5. Case detail CTA.
6. Similar project request.

Mobile priority:

- proof statement
- case filters
- card grid

## Resource Pattern

Use for: guide, dev, wordpress, prompt, threads.

Section order:

1. Hero: what users can learn/do.
2. Topic paths.
3. Recommended reads or representative content.
4. Recent posts.
5. Related service or support CTA.

Mobile priority:

- topic path
- recommended content
- recent list

## Support Pattern

Use for: support, FAQ, help topics.

Section order:

1. Hero: find help quickly.
2. Issue type cards.
3. Search or FAQ.
4. Process/expected response.
5. Contact CTA.

Mobile priority:

- issue type cards
- direct contact
- FAQ

## Utility Pattern

Use for: search, IP, sitespeed, small tools.

Section order:

1. Tool input/action.
2. Result state.
3. Explanation.
4. Related services.

Mobile priority:

- input and result above all else.

## Choosing A Pattern

If a page has mixed purpose:

- Choose the pattern that matches the primary business goal.
- Add a secondary section for the other purpose.
- Do not mix two full patterns on one page.

Example:

- `portfolio`: proof pattern with a sales CTA, not sales pattern with proof cards.
- `works`: catalog pattern with proof links, not proof pattern.
- `guide`: resource pattern with service CTA, not sales pattern.

.codex/skills/eond-design-system-builder/references/system-audit-checklist.md

# System Audit Checklist

Use this when auditing many Eond pages or preparing a design-system implementation plan.

## Inventory

For each page, collect:

- URL
- actual template file
- page mode
- H1
- primary CTA
- first visual asset
- section count
- card/list type
- mobile overflow
- broken image count
- board/list-first risk

## Page Mode Coverage

At minimum, audit:

- sales: `/request`, `/axai`, `/hosting`
- catalog: `/market`, `/works`, `/wpstore`
- proof: `/portfolio`
- resource: `/blog`, `/dev`, `/wordpress`, `/prompt`, `/threads`
- support: `/support`, `/faq`
- utility: `/search`, tool pages when present

## Coherence Checks

- Header and submenu align with content grid.
- Similar page modes use similar section rhythm.
- CTAs use consistent labels and hierarchy.
- Cards use consistent radius, border, spacing, and hover.
- Badges and category chips use consistent visual language.
- Forms use consistent input size, label placement, and error style.
- Search feels like part of the same site.

## Differentiation Checks

- Sales pages do not look like catalog pages.
- Catalog pages do not look like boards.
- Portfolio does not look like recent posts.
- Guides do not look like empty category pages.
- Support pages do not bury contact routes.

## Responsive Checks

Test 1440px, 768px, 390px:

- horizontal overflow is 0
- H1 wraps intentionally
- CTA is visible without awkward clipping
- cards do not become too narrow
- sticky/subnav does not cover content
- image crops preserve meaning

## Content Trust Checks

- No fake client logos, fake testimonials, fake metrics, or unverifiable claims.
- "500+" can refer to product/material/build experience only when context is clear.
- Prices and support scope include caveats when needed.
- External subdomain links explain what the user will find there.

## Implementation Checks

- Existing CSS tokens are reused before new global rules are added.
- Page-specific CSS is scoped.
- New shared classes are documented by pattern.
- No global rule breaks board/editor/admin screens.
- `git diff --check` passes.
- Browser screenshots are saved for representative pages.

## Final Score

Score the system out of 100:

- brand coherence: 20
- page-mode fit: 20
- component consistency: 15
- visual proof and assets: 15
- conversion clarity: 15
- responsive stability: 10
- implementation safety: 5

Below 80 means the system is still too fragmented for production polish.