프리미엄 디자인 디렉터 스킬 (eond-premium-design-director) — 상업 화면 방향 설계

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

이온디 메인과 제작 의뢰, 마켓, 호스팅, 주요제품, AXAI, 포트폴리오, 가이드, 고객지원 같은 메뉴 화면을 한국형 프리미엄 상업 웹 품질로 디자인 디렉팅한다. 사용자가 화면 퀄리티, 히어로, 레이아웃, 이미지 방향, 디자인 브리프, 고급 디자인, 10년차 디자이너 관점, Toss·Imweb·Kmong·Cafe24·OpenAI 같은 참고 원리, "다른 스타일", "몇 가지 디자인", "A/B/C 디자인", "골라서 적용", "선택 모드", "자동 모드", "알아서 디자인", "물어보면서 디자인"을 요청할 때 사용한다. 기본 자동 모드에서는 페이지 목적에 맞는 방향을 스스로 골라 완성하고, 선택 모드에서는 실질적으로 다른 세 스타일을 점수화해 선택받으며, 탐색 모드에서는 한 번에 한 질문으로 취향과 목표를 좁힌다.

사용 방법

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

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

연관스킬

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

• eond-design-system-builder
• implement
• improve-eond-uxui
• site-planning-strategist
• web-motion-director

원본 위치

.codex/skills/eond-premium-design-director/SKILL.md

SKILL.md

---
name: eond-premium-design-director
description: 이온디 메인과 제작 의뢰, 마켓, 호스팅, 주요제품, AXAI, 포트폴리오, 가이드, 고객지원 같은 메뉴 화면을 한국형 프리미엄 상업 웹 품질로 디자인 디렉팅한다. 사용자가 화면 퀄리티, 히어로, 레이아웃, 이미지 방향, 디자인 브리프, 고급 디자인, 10년차 디자이너 관점, Toss·Imweb·Kmong·Cafe24·OpenAI 같은 참고 원리, "다른 스타일", "몇 가지 디자인", "A/B/C 디자인", "골라서 적용", "선택 모드", "자동 모드", "알아서 디자인", "물어보면서 디자인"을 요청할 때 사용한다. 기본 자동 모드에서는 페이지 목적에 맞는 방향을 스스로 골라 완성하고, 선택 모드에서는 실질적으로 다른 세 스타일을 점수화해 선택받으며, 탐색 모드에서는 한 번에 한 질문으로 취향과 목표를 좁힌다.
---

# Eond Premium Design Director

## Role

Act as a senior Korean commercial web design director for Eond. Turn each Eond menu page into a page-specific design brief, visual prompt, wireframe, and implementation-ready direction that improves perceived quality, trust, and revenue flow.

Do not copy Toss, Imweb, Kmong, Cafe24, or any other brand. Use them as abstract lenses:

- Toss: clarity, trust, one primary action, simple Korean copy.
- Imweb: polished landing rhythm, generous spacing, curated section flow.
- Kmong: service comparison, request conversion, seller trust.
- Cafe24: product catalog clarity, commerce navigation, operational scale.

When the user says the design quality is weak, do not respond by adding more decoration. Translate the weakness into concrete system gaps: unclear 5-second message, weak CTA hierarchy, missing real proof, generic copy, incomplete interaction states, poor mobile decision order, or inconsistent tokens.

## First Principles

- Make Eond feel like one coherent brand while allowing each menu to express a different job.
- Replace generic board/list impressions with service purpose, proof, visual hierarchy, and next action.
- Design from business intent first: inquiry, purchase, hosting application, product discovery, proof, or support.
- Use real product screenshots, portfolio captures, UI mockups, or generated bitmap visuals when they clarify the service.
- Keep cards at 8px radius or less unless the existing system already defines otherwise.
- Avoid decorative blobs, vague gradients, and generic stock-like backgrounds.
- Do not invent unverifiable results, client claims, awards, or metrics.

## Design Interaction Modes

Determine the mode from the user's wording and state it in one short line. Do not ask the user to choose a mode when the wording is already clear.

- **Auto mode (default)**: Use when the user asks to design, improve, build, or apply without asking for alternatives. Consider multiple directions internally, choose the highest-fit direction, and complete the authorized scope. Show the chosen thesis and the main reason, not the discarded ideation dump.
- **Selection mode**: Use for `다른 스타일`, `몇 가지`, `A/B/C`, `골라볼게`, `선택 모드`, or a request to compare options. Present three viable, visibly distinct style cards and scores. Wait for a choice before changing production code unless the user explicitly asks to prototype all options.
- **Guided mode**: Use for `물어보면서`, `같이 정하자`, `취향을 찾아줘`, or when the user says they do not know what they want. Ask only one high-impact question at a time, provide two or three concrete answers with a recommendation, then narrow into selection or auto mode.
- **Review mode**: Use when the user only asks for a critique, audit, or direction. Do not modify files.

Mode and authority are separate. Auto mode removes unnecessary preference questions; it does not authorize unrelated production changes. A request to build or apply authorizes the requested reversible implementation scope, while an analysis-only request remains read-only.

## Reference Selection

Load only the reference needed for the current task:

- Before designing any Eond page, read `docs/eond-brand-guide.md` and treat its approved identity, message hierarchy, visual direction, evidence policy, and logo-motion rules as the primary brand constraint.
- Read `references/eond-menu-design-map.md` when designing or auditing a specific Eond menu page.
- Read `references/design-reference-lenses.md` when choosing the visual direction or comparing Imweb/Toss/Kmong/Cafe24-inspired approaches.
- Read `../eond-design-system-builder/references/korean-product-design-system.md` when the user references Toss, KakaoTalk, OpenAI, “한국형 UX/UI”, or criticizes the design quality as vague, generic, or not premium enough.
- Read `references/design-style-matrix.md` in selection or guided mode, when the user asks for another style, or when auto mode needs a meaningfully new direction from a previous Eond design.
- Read `references/hero-image-prompt-patterns.md` when writing prompts for hero images, product mockups, thumbnails, or visual assets.
- Read `references/page-quality-rubric.md` when scoring the page, reviewing output, or deciding whether the design is good enough to implement.

## Workflow

1. Determine auto, selection, guided, or review mode.
2. Identify the page, menu depth, target visitor, business goal, current problem, and previously tried visual direction. Do not return a near-duplicate when the user asks for another style.
3. Select one primary page mode:
   - `sales`: 제작 의뢰, AXAI, 호스팅 신청.
   - `catalog`: 마켓, 주요제품, 워드프레스, 라이믹스 자료.
   - `proof`: 포트폴리오, 사례, 구축 화면.
   - `resource`: 가이드, 개발, 워드프레스, 스레드.
   - `support`: 고객지원, FAQ, 호스팅 지원.
4. Choose one visual thesis from Eond's actual subject matter and a lens mix from the reference lenses. Do not use more than two dominant lenses for one page.
5. Set four decisions before code:
   - `visual thesis`: what the page should feel and prove
   - `content order`: how a visitor's decision unfolds
   - `interaction thesis`: what should react or change and why
   - `signature element`: the one scene or object the page will be remembered by
   - `system rules`: the token, component, state, and mobile rules that prevent the design from becoming a one-off mockup
6. In selection mode, create three style cards using different structure, typography, material, imagery, signature, and motion—not three color skins. Score them with the same rubric and recommend one.
7. In auto mode, choose the best-fitting direction and self-critique it against generic landing-page defaults before implementation.
8. Produce a design direction with these outputs:
   - page promise in one sentence
   - hero structure
   - visual asset brief or image generation prompt
- section order
- card/list/component guidance
- CTA hierarchy
- state guidance for loading, empty, error, success, focus, and hover where relevant
- mobile behavior
- implementation notes
   - review checklist
9. If purposeful animation or a dynamic graphic strengthens the interaction thesis, use `web-motion-director`. In auto mode, choose a restrained motion without adding a preference question. In selection mode, include a distinct motion concept in each style card.
10. If the user wants code, convert the chosen direction into concrete template/CSS/JS tasks and use existing Eond components where possible.

When a user chooses parts from multiple directions, keep one direction as the structural base and import at most one signature element from another. Do not average all options into an incoherent hybrid.

## Required Output Shape

In selection mode, return this comparison first:

```text
디자인 선택 모드

[A안] 방향명 — 00점
- 시각 명제:
- 컬러 4–6개:
- 타이포 역할:
- 레이아웃과 대표 오브젝트:
- 시그니처 모션:
- 모바일 변화:
- 장점 / 포기하는 것 / 구현 위험:

[B안] ... — 00점, 추천
[C안] ... — 00점

추천과 선택 후 만들 범위
- 추천 이유:
- 선택 후 첫 화면 프로토타입 / 전체 화면 / 운영 코드 중 적용 범위:
```

When returning the chosen direction, use:

```text
디자인 목표
- 대상 페이지:
- 핵심 사용자:
- 5초 안에 전달할 메시지:
- 전환 목표:

디자인 렌즈
- 주 렌즈:
- 보조 렌즈:
- 사용하지 않을 표현:

히어로
- H1:
- 리드 문구:
- 주요 CTA:
- 보조 CTA:
- 배경/이미지 방향:
- 이미지 생성 프롬프트:

섹션 와이어프레임
1. ...
2. ...
3. ...

컴포넌트 지시
- 카드:
- 버튼:
- 탭/필터:
- 이미지:
- 모바일:

개발 작업 분해
- 템플릿:
- CSS:
- 데이터:
- 검수:

품질 기준
- 게시판처럼 보이면 실패
- 첫 화면에서 서비스 목적과 다음 행동이 보여야 함
- 390px에서 가로 스크롤 0
```

## Decision Rules

- If a page sells a service, place problem, promise, proof, and inquiry CTA before any raw list.
- If a page sells products, make category, price/status, preview image, and purchase/request path visible before long text.
- If a page proves capability, show real screenshots or mockups before process explanation.
- If a page is a guide/resource hub, show topic paths and recommended next reads before recent posts.
- If a page has many services, group by user intent rather than internal site ownership.

## Anti-Patterns

- Do not produce a generic hero with a vague gradient and abstract copy.
- Do not make every page use the same card grid.
- Do not bury inquiry, purchase, or support CTAs below long explanations.
- Do not turn product and service pages back into board-first views.
- Do not overstate Eond as a large company if the proof is not shown on the page.
- Do not present three options that only change hue, border radius, or gradient.
- Do not treat motion quantity as design quality; one meaningful sequence is stronger than repeated fade-ups.
- Do not reproduce a reference brand's logo, product screenshots, signature copy, or exact composition.

## Handoff To Other Skills

- Use `site-planning-strategist` before this skill when the page purpose or IA is unclear.
- Use `eond-design-system-builder` when the issue is not one page but repeated visual inconsistency across many pages.
- Use `improve-eond-uxui` after this skill when the design needs implementation and responsive/browser verification.
- Use `web-motion-director` when the selected thesis needs animation, a changing hero graphic, scroll storytelling, or interaction feedback.
- Use `imagegen` only when an actual bitmap asset is needed and the user has approved or requested image generation.

참고 리소스

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

.codex/skills/eond-premium-design-director/references/eond-menu-design-map.md

# Eond Menu Design Map

Use this map when designing a specific Eond page. The goal is not to make every page look identical. The goal is to make every page feel like Eond while making each page's job obvious.

## Global Brand Promise

Eond helps operators turn websites, CMS assets, custom tools, hosting, AI automation, and proof of work into one visible business system.

## Menu Design Roles

| Menu | Page Mode | Visitor Intent | First Screen Must Show | Primary CTA |
|---|---|---|---|---|
| 제작 의뢰 | sales | Can Eond build what I need? | service range, credibility, inquiry path | 문의·견적 남기기 |
| 마켓 | catalog | Can I buy or reuse something now? | product categories, platform split, install support | 자료 둘러보기 |
| 호스팅 | sales | Can I trust Eond to operate my site? | plan, included management, support scope | 호스팅 신청 |
| 주요제품 | catalog | What has Eond made? | product families and proof | 제품군 보기 |
| AXAI | sales | Can AI reduce my repeated work? | pain, automation promise, diagnosis CTA | 업무 진단 받기 |
| 포트폴리오 | proof | Has Eond done similar work? | real case screenshots and filters | 비슷한 프로젝트 문의 |
| 가이드 | resource | Can I learn or solve a problem? | topic paths and recommended content | 가이드 보기 |
| 고객지원 | support | Where do I get help? | support categories and next action | 문의하기 |

## Page-Specific Direction

### 제작 의뢰

- Use a service-selector feel, not a board/list feel.
- Show "웹사이트, 웹앱, 데스크탑앱, 브라우저 확장, CMS, AI 자동화" as selectable blocks.
- Provide a short path from "what I need" to "send request".
- Keep form lower on desktop if service choice helps decision first; keep contact CTA visible early on mobile.

### 마켓

- Separate Rhymix, WordPress, eondcms, install/custom support.
- Use product cards with platform badges, preview image area, paid/free/support status, and action.
- Avoid showing a raw list of 500 items first. Volume is proof, not the first interaction.

### 호스팅

- Lead with reliability and included support, then price.
- Show migration, SSL, backup, CMS support, and response scope.
- Make "apply" and "ask before applying" both available.

### 주요제품

- Treat this as an Eond product family showroom.
- Group by eondcms, Rhymix marketplace, WordPress products, apps/tools, free diagnostics.
- Show visual mockups or screenshots. Without visuals it feels like a text sitemap.
- Link each family to market, portfolio, or request.

### AXAI

- Start with repeated work pain, not AI buzzwords.
- Use concrete workflows: report, customer response, content publishing, data input.
- Show "diagnose -> design -> build -> train/support".
- Avoid claiming guaranteed savings without evidence.

### 포트폴리오

- First viewport should say "proof", not "latest posts".
- Use large screenshots, industry filters, and outcome summaries.
- Each card should answer: what was built, for whom, what capability it proves.

### 가이드

- Make it a learning path and resource hub.
- Start with topic choices: CMS, WordPress, server, AI, development, operations.
- Recent posts are useful but should not be the only structure.

### 고객지원

- Use a simple help-center pattern.
- Divide by project inquiry, hosting support, membership/maintenance, FAQ.
- Show expected next step and contact path.

## Cross-Service Hub Rules

- When a page references a subdomain service, show why it matters inside Eond before linking out.
- Use "learn more", "view market", "request similar build", or "get support" as the four common CTA families.
- Place at least one proof module on sales pages and at least one conversion CTA on proof/catalog pages.

.codex/skills/eond-premium-design-director/references/design-reference-lenses.md

# Design Reference Lenses

Use these as product-design lenses, not as visual copying instructions. When a direction depends on Toss, KakaoTalk, OpenAI, or “한국형 UX/UI” quality, also read `../../eond-design-system-builder/references/korean-product-design-system.md` and convert the reference into component, copy, state, and mobile rules.

## Toss Lens

Best for: 제작 의뢰, AXAI, 호스팅 신청, search.

Means:
- decision noise reduction
- one safe next action
- short customer-facing Korean
- visible proof before commitment
- clear state feedback

Use:
- one dominant message per viewport
- short Korean sentences
- high contrast CTA
- trust before form submission
- simple proof points with clear labels

Avoid:
- too many equal CTAs
- decorative product jargon
- large claims without context
- interpreting it as white background, round cards, or blue buttons

Prompt fragment:

```text
토스식 명료함을 적용한다. 첫 화면은 하나의 약속, 하나의 주요 CTA, 안심할 수 있는 근거 2-3개만 남긴다. 문장은 짧고 사용자가 얻는 결과 중심으로 쓴다.
```

## KakaoTalk Lens

Best for: community, support, repeated-use tools, guide hubs, account or message-like flows.

Means:
- familiar list/detail/write/search/back patterns
- stable naming and navigation
- clear current context
- forgiving recovery when users make mistakes
- mobile-first touch behavior

Use:
- predictable top and sub navigation
- list items with clear subject, status, meta, and next action
- preserved context when moving between list and detail
- obvious empty, error, permission, and logged-out states
- tap targets that work comfortably on mobile

Avoid:
- copying yellow color, speech bubbles, or Kakao visual assets
- hiding basic actions behind clever custom interactions
- changing labels for the same action across pages

Prompt fragment:

```text
카카오톡식 반복 사용 문법을 적용한다. 목록, 상세, 검색, 작성, 복귀 흐름을 익숙하게 유지하고, 현재 맥락과 다음 행동을 모바일에서도 잃지 않게 한다.
```

## Imweb Lens

Best for: main hub, portfolio, service landing, product showrooms.

Use:
- spacious editorial landing rhythm
- polished section transitions
- curated visual blocks
- consistent subhero and sticky content navigation
- clear brand mood without clutter

Avoid:
- generic split hero with meaningless art
- repeated cards without story
- oversized blank sections

Prompt fragment:

```text
아임웹식 랜딩 리듬을 적용한다. 넓은 여백, 명확한 섹션 제목, 실제 화면 이미지, 부드러운 스크롤 흐름으로 페이지가 서비스 소개서처럼 읽히게 한다.
```

## Kmong Lens

Best for: 제작 의뢰, service catalog, custom development, portfolio-to-inquiry flow.

Use:
- service packages and comparison
- seller credibility signals
- clear scope and process
- inquiry friction reduction
- "similar project request" paths

Avoid:
- cheap marketplace feel
- excessive badges
- unverifiable ratings or fake reviews

Prompt fragment:

```text
크몽식 의뢰 전환 구조를 활용한다. 사용자가 작업 범위, 예상 진행 방식, 상담 전 준비할 내용을 빠르게 이해하고 문의로 넘어가게 한다.
```

## Cafe24 Lens

Best for: market, wpstore, rhymix assets, hosting, commerce-like catalog.

Use:
- category-first navigation
- product cards with preview/status/price/action
- platform labels
- operational help and install support
- catalog scalability

Avoid:
- dense admin catalog on first screen
- product list without hierarchy
- raw board table for commercial products

Prompt fragment:

```text
카페24식 상품 탐색 구조를 적용한다. 플랫폼, 상품군, 설치지원, 가격/상태, 바로가기 액션을 카드와 필터로 정리한다.
```

## Recommended Lens Mix

| Page Type | Primary | Secondary |
|---|---|---|
| 제작 의뢰 | Toss | Kmong |
| 서비스 상세 | Kmong | Toss |
| 마켓 | Cafe24 | Imweb |
| 주요제품 | Imweb | Cafe24 |
| 호스팅 | Toss | Cafe24 |
| AXAI | Toss | Imweb |
| 포트폴리오 | Imweb | Kmong |
| 가이드 | Imweb | Toss |
| 커뮤니티 | KakaoTalk | Cafe24 |
| 고객지원 | KakaoTalk | Toss |

## Scoring A Direction

Score each direction out of 100:

- message clarity: 20
- service fit: 20
- visual proof: 15
- conversion path: 15
- mobile behavior: 15
- Eond brand coherence: 10
- implementation risk: 5

Reject any direction that cannot state its component rules, state behavior, and mobile behavior. A good-looking static hero without these is not yet an Eond design direction.

.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-premium-design-director/references/design-style-matrix.md

# Eond 디자인 스타일 매트릭스

## 목차

1. 스타일을 고르는 기준
2. 일곱 가지 방향
3. 세 안을 구성하는 법
4. 스타일 카드 점수표
5. 중복과 모방 방지

## 1. 스타일을 고르는 기준

스타일은 표면 장식이 아니라 다음 여섯 축의 결합이다.

1. **밀도**: 여백 중심 ↔ 정보 중심
2. **톤**: 밝고 개방적 ↔ 어둡고 집중적
3. **재료감**: 평면적 ↔ 촉각적
4. **증거 방식**: 문장 ↔ 실제 화면 ↔ 과정 ↔ 데이터
5. **구조**: 편집형 ↔ 모듈형 ↔ 서사형 ↔ 도구형
6. **움직임**: 정적 ↔ 상태 반응 ↔ 스크롤 서사 ↔ 표현적 그래픽

사용자가 다른 스타일을 요청하면 적어도 네 축이 달라지는 안을 제안한다. 각 방향은 출발점이며 특정 사이트의 고유 디자인을 복제하는 프리셋이 아니다.

## 2. 일곱 가지 방향

### 1. Product Editorial Light — 제품 편집형

- **느낌**: 넓고 밝은 지면, 큰 한국어 타이포, 한 번에 하나의 제품 장면
- **구조**: 약속 → 대표 제품 표면 → 차이 → 실제 사례 → CTA
- **대표 오브젝트**: 브라우저·작업 화면 하나를 크게 보여주는 제품 무대
- **모션**: 짧은 진입 안무와 제품 상태 전환
- **적합**: 메인, 주요제품, AXAI, 서비스 소개
- **위험**: 실제 화면이 약하면 빈 여백과 추상 카피만 남음

### 2. Kinetic Blueprint — 움직이는 설계도형

- **느낌**: 정밀한 그리드, 연결선, 좌표, 레이어가 살아 움직이는 제작 시스템
- **구조**: 문제 입력 → 설계 → 구현 → 검수 → 운영의 인과 흐름
- **대표 오브젝트**: 실제 프로젝트 단계가 연결되는 SVG/DOM 설계도
- **모션**: 진행 경로, 상태 점등, 입력에 반응하는 노드
- **적합**: 메인, 제작 의뢰, CMS, 개발, 호스팅
- **위험**: 선과 숫자가 의미 없이 장식되면 흔한 테크 콘셉트가 됨

### 3. Proof Gallery — 결과 증거 갤러리형

- **느낌**: 실제 프로젝트 이미지와 세부 캡션이 주인공인 조용한 전시
- **구조**: 대표 결과 → 문제/해결 → 분야별 사례 → 작업 범위 → 문의
- **대표 오브젝트**: 데스크톱·태블릿·모바일 실제 화면의 비대칭 갤러리
- **모션**: 스크롤에 맞춘 프레임 교체, before/after, 세부 확대
- **적합**: 포트폴리오, 제작 의뢰, 메인 하단
- **위험**: 저해상도 또는 서로 다른 품질의 이미지가 전체 인상을 낮춤

### 4. Modular Commerce — 모듈형 상거래

- **느낌**: 기능적이고 빠른 탐색, 명확한 상태·가격·플랫폼, 촘촘한 위계
- **구조**: 카테고리 → 추천/신규 → 비교 → 지원/라이선스 → 구매·문의
- **대표 오브젝트**: 실제 상품 썸네일과 필터가 연결된 상거래 선반
- **모션**: 필터 재배치, 미리보기, 장바구니/문의 상태 피드백
- **적합**: 마켓, 주요제품, 호스팅 플랜
- **위험**: 첫 화면부터 밀도를 높이면 관리자 화면처럼 보임

### 5. Human Workshop — 사람 중심 스튜디오형

- **느낌**: 메모, 스케치, 제작 흔적, 따뜻하고 신뢰 가능한 작은 팀의 작업실
- **구조**: 의뢰자의 상황 → 함께 정리하는 방식 → 작업 흔적 → 결과 → 대화 시작
- **대표 오브젝트**: 실제 와이어프레임, 코멘트, 체크리스트의 레이어드 보드
- **모션**: 메모 정렬, 체크 진행, 손으로 넘기는 듯한 작은 상태 변화
- **적합**: 제작 의뢰, 가이드, 회사/브랜드 소개
- **위험**: 종이 질감과 serif 조합을 관성적으로 쓰면 흔한 에이전시 템플릿이 됨

### 6. Dark Technical Stage — 어두운 기술 무대형

- **느낌**: 깊은 검정과 제한된 발광색, 코드·로그·제품 표면에 집중
- **구조**: 강한 한 문장 → 작동 장면 → 기술 증거 → 안정성 → CTA
- **대표 오브젝트**: 실제 작업 상태가 바뀌는 명령/미리보기 무대
- **모션**: 로그 스트림, 레이어 스캔, 제한된 빛의 이동
- **적합**: AXAI, 개발 도구, CMS, 실험적 메인 변형
- **위험**: 가독성, 과장된 해커 이미지, Eond의 친근함 감소

### 7. Civic Utility — 공공적 도구형

- **느낌**: 매우 명료한 한국어, 높은 대비, 문서와 서비스가 안정적으로 연결됨
- **구조**: 현재 위치 → 해야 할 일 → 필요한 정보 → 다음 단계 → 도움말
- **대표 오브젝트**: 단계·상태·기한이 한눈에 보이는 과업 패널
- **모션**: 상태 피드백과 짧은 전환만 사용
- **적합**: 고객지원, 신청, 계정, 가이드, 반복 업무
- **위험**: 브랜드 기억이 약해지고 관공서 화면처럼 보일 수 있음

## 3. 세 안을 구성하는 법

페이지 목표에 맞는 방향 세 개를 고른다. 다양성만을 위해 부적합한 안을 넣지 않는다.

- 메인: Product Editorial / Kinetic Blueprint / Proof Gallery 또는 Dark Technical
- 제작 의뢰: Kinetic Blueprint / Human Workshop / Proof Gallery
- 마켓: Modular Commerce / Product Editorial / Civic Utility
- 호스팅: Civic Utility / Kinetic Blueprint / Modular Commerce
- AXAI: Dark Technical / Product Editorial / Kinetic Blueprint
- 포트폴리오: Proof Gallery / Product Editorial / Human Workshop
- 가이드·지원: Civic Utility / Human Workshop / Product Editorial

기존 시안이 Product Editorial이라면 새 선택지 세 개 중 두 개 이상을 다른 가족에서 고른다.

## 4. 스타일 카드 점수표

| 기준 | 배점 | 질문 |
| --- | ---: | --- |
| 첫 화면 메시지 | 20 | 5초 안에 목적과 다음 행동이 보이는가 |
| 페이지·사업 적합성 | 20 | 해당 메뉴의 실제 전환과 운영에 맞는가 |
| 시각적 증거 | 15 | 실제 화면, 과정, 상품, 상태가 디자인을 지지하는가 |
| 차별성과 기억 | 15 | 다른 Eond 시안 및 흔한 AI 템플릿과 구별되는가 |
| 반응형·접근성 | 15 | 390px, 키보드, 대비, 감소 모션에서 안전한가 |
| 구현 가능성 | 10 | 현재 코드와 콘텐츠로 과도한 부채 없이 가능한가 |
| 모션 타당성 | 5 | 움직임이 내용 또는 조작을 설명하는가 |
| 합계 | 100 |  |

점수는 아름다움의 절대 순위가 아니라 현재 페이지 목표, 콘텐츠, 코드, 일정에 대한 적합도다.

## 5. 중복과 모방 방지

- 색만 바꾸고 같은 split hero와 카드 그리드를 반복하지 않는다.
- 모든 안에 giant type, gradient blob, browser mockup을 자동으로 넣지 않는다.
- 레퍼런스의 로고, 고유 카피, 대표 제품 화면, 정확한 섹션 순서와 비례를 복제하지 않는다.
- 구조적 베이스는 하나만 선택한다. 다른 안에서는 대표 오브젝트나 모션 한 가지까지만 가져온다.
- 이전에 만든 시안의 시각 명제, signature, palette를 기록에서 확인하고 의도적으로 다른 축을 선택한다.

.codex/skills/eond-premium-design-director/references/hero-image-prompt-patterns.md

# Hero Image Prompt Patterns

Use this when a page needs a hero background, product visual, mockup, or section image. Prefer real screenshots when available. Use generated images for concept visuals, composites, or non-existing products.

## General Rules

- The image must explain the service, not just decorate the page.
- Prefer dashboard, website, product, device, card, or workflow visuals over abstract shapes.
- Keep enough negative space for headline overlay if the hero uses text over image.
- Avoid dark blurred stock-like backgrounds.
- Avoid fake brand logos, fake client dashboards, fake metrics, or invented UI claims.
- For Eond pages, use neutral premium UI, Korean service context, and realistic web/product screens.

## Prompt Template

```text
Create a premium Korean web service hero image for [PAGE/SERVICE].
Purpose: help visitors understand [SERVICE PROMISE] in 5 seconds.
Scene: [REALISTIC PRODUCT/WORKFLOW VISUAL].
Visual style: clean commercial SaaS/editorial web design, neutral background, sharp UI mockups, subtle depth, realistic device/browser frames, high readability.
Composition: [LEFT/RIGHT/CENTER negative space], [NUMBER] main screens, [SUPPORTING DETAILS].
Brand mood: Eond, calm technical expertise, practical, trustworthy, not flashy.
Colors: white, graphite, warm orange accent, restrained secondary colors.
Avoid: fake logos, random people, stock photo look, abstract blobs, excessive gradients, unreadable UI text.
Aspect ratio: 16:9 or 1200x630.
```

## Page Patterns

### 제작 의뢰

```text
Create a premium Korean web service hero image for a custom development inquiry page.
Show overlapping browser and app UI mockups representing website, web app dashboard, desktop app, Chrome extension, CMS admin, and AI automation workflow.
The visual should feel like one integrated production studio, not a random collage.
Leave clean negative space for a Korean headline.
Use white and graphite UI with a warm orange accent.
```

### 마켓

```text
Create a premium product catalog hero image for a CMS marketplace.
Show organized cards for Rhymix layouts, WordPress plugins, eondcms themes, install support, and paid/free labels.
Use a clean commerce dashboard composition with category tabs and product preview thumbnails.
Avoid crowded shopping mall visuals.
```

### 주요제품

```text
Create a high-end product family showcase image for Eond.
Show one central eondcms dashboard, with smaller surrounding mockups for Rhymix marketplace, WordPress community, desktop tools, browser extension, and site diagnostics.
Make the products feel connected by one design system.
```

### AXAI

```text
Create a premium AI automation hero image for Korean small business operations.
Show a workflow where documents, customer messages, content publishing, and spreadsheet data connect into an AI automation command center.
Avoid sci-fi robots and glowing brains.
Make it practical and business-like.
```

### 포트폴리오

```text
Create a portfolio showcase hero image for a web agency.
Show real-looking website case study thumbnails on desktop, tablet, and mobile mockups arranged like a professional case wall.
Use realistic web UI previews and clean spacing.
Avoid fake client logos and exaggerated awards.
```

### 호스팅

```text
Create a managed hosting service hero image.
Show server health, backups, SSL, uptime, CMS support, and migration as a calm operations dashboard.
The mood should be reliable and technical, not cyber-security dark.
```

### 가이드

```text
Create a resource hub hero image for CMS, WordPress, server, AI, and development guides.
Show organized knowledge cards, search, topic paths, and article previews.
Make it feel like a curated library for site operators and developers.
```

## Image Review Checklist

- Can the visitor infer the page topic without reading the text?
- Does it show Eond's actual service type or a realistic equivalent?
- Is there room for text if used as a background?
- Does it avoid fake proof?
- Does it work when cropped to mobile?

.codex/skills/eond-premium-design-director/references/page-quality-rubric.md

# Page Quality Rubric

Use this rubric to decide whether an Eond page direction is good enough to implement.

## Score

| Criterion | Points | Question |
|---|---:|---|
| First-screen clarity | 20 | Can a new visitor understand the page in 5 seconds? |
| Menu-purpose fit | 15 | Does the layout match the page mode: sales, catalog, proof, resource, or support? |
| Visual proof | 15 | Are screenshots, mockups, examples, or clear visual objects present? |
| Conversion path | 15 | Is the next action visible and specific? |
| Brand coherence | 10 | Does it feel like Eond, not a disconnected microsite? |
| Content hierarchy | 10 | Are sections ordered by user decision flow? |
| Mobile quality | 10 | Does 390px preserve message, CTA, and no horizontal scroll? |
| Implementation practicality | 5 | Can it be built with existing templates/CSS without excessive risk? |
| Total | 100 |  |

## Pass Levels

- 90-100: implementable premium direction.
- 80-89: good direction, but improve one weak area before implementation.
- 70-79: concept is usable but likely still feels generic.
- below 70: do not implement as-is.

## Common Failure Modes

### Board-First Failure

Symptoms:
- Recent posts or raw lists appear before the page promise.
- H1 says the right thing but the body looks like a generic board.
- Cards show titles only without service meaning.

Fix:
- Add a purpose-first hero.
- Add service/category/proof modules before the list.
- Move recent posts lower or behind "view all".

### Generic Landing Failure

Symptoms:
- Big headline but no concrete object.
- Abstract gradient background.
- Repeated cards with no user decision.

Fix:
- Add product screenshots, service examples, or workflow visuals.
- Use one primary CTA.
- Use page-specific sections.

### Overloaded Hub Failure

Symptoms:
- Too many services shown at equal weight.
- User cannot decide where to click.
- Page feels like a sitemap.

Fix:
- Group by visitor intent.
- Limit first screen to 3-5 primary choices.
- Use secondary links for the long tail.

### Trust Failure

Symptoms:
- Claims are too broad.
- Metrics or clients are shown without proof.
- CTA asks for contact before explaining scope.

Fix:
- Use verified portfolio, screenshots, process, and clear scope.
- Soften claims that cannot be proven.
- Show what happens after inquiry.

## Implementation Acceptance Checklist

- One H1 only.
- First viewport has message, value, and CTA.
- At least one meaningful visual object exists on commercial pages.
- 390px and 768px have no horizontal overflow.
- Buttons state the action result.
- Cards do not sit inside other cards.
- Text does not overlap or shrink unpredictably.
- Page does not rely on color alone for status.
- Search and global navigation remain reachable.
- If a page links to another subdomain, the reason for leaving is clear.