Communitygithub.com

pretty-ui

AI가 만든 UI를 디자인된 것처럼 보이게 만듭니다. 세 가지 실제 디자인 방향을 나란히 보여주고, 사용자가 하나를 선택하면 DESIGN.md로 저장하여 에이전트가 모든 화면에서 따르도록 한 후, 패스별로 UI를 재구축 또는 다듬고 AI 흔적을 검사합니다.

pretty-ui란 무엇인가요?

pretty-ui는 AI가 생성한 UI에서 흔히 나타나는 '템플릿 같은' 외형을 해결하는 스킬입니다. 이 스킬은 실제 디자이너의 워크플로우를 모방하여, 사용자가 시각적으로 비교하고 선택할 수 있도록 세 가지 명확히 다른 디자인 방향을 제시합니다. 선택된 방향은 DESIGN.md 파일에 체계적으로 기록되어 이후 모든 화면에서 일관되게 적용됩니다. pretty-ui는 Tailwind, shadcn/ui, React, Vue, Svelte, React Native, SwiftUI, Compose, Flutter 등 다양한 기술 스택을 지원하며, `scripts/check.mjs`를 통해 HTML, CSS, JSX, TSX, Vue, Svelte 파일에서 AI 특유의 흔적(예: 모든 요소가 중앙 정렬됨, 동일한 카드 반복, 필러 카피)을 탐지합니다. 또한, 사용자의 기존 브랜드(색상, 폰트)를 존중하며, Codex Design 캔버스나 `compare.mjs` 스크립트를 통해 세 가지 디자인 방향을 나란히 비교할 수 있는 기능을 제공합니다. 최종적으로 변경 전후를 비교하는 페이지를 생성하여 결과를 공유할 수 있습니다.

지원 대상✓Claude Code✓Codex CLI~Cursor
npx skills add https://github.com/ummydev/pretty-ui/tree/HEAD/skills/pretty-ui

즐겨 사용하는 AI에게 물어보기

이 에이전트 스킬이 미리 로드된 새 채팅을 엽니다.

문서

pretty-ui은(는) 무엇을 하나요?

AI가 만든 화면은 아무것도 선택되지 않았기 때문에 모두 비슷해 보입니다. 모델은 모든 빈틈을 가장 흔하게 본 정답으로 채우고, 그 결과는 어떤 제품에도 속할 수 있는 페이지가 됩니다.

pretty-ui는 디자이너가 하는 순서대로 이 문제를 해결합니다: 방향을 선택하고, 기록하고, 모든 곳에 적용한 다음 결과를 확인합니다. 선택은 에이전트가 아닌, 실제 옵션을 볼 수 있는 사람이 합니다.

실행 과정

다음 단계를 순서대로 따르세요. 각 단계를 사용자에게 알리세요.

1. 프로젝트 읽기

  • 빌드 중인 것이 무엇인지 파악하세요: 읽고 스크롤하는 페이지(랜딩 페이지, 마케팅 사이트, 포트폴리오), 사람들이 작업하는 웹 앱 화면(대시보드, 설정, 받은 편지함), 또는 모바일 앱.
  • 스택을 파악하세요: 일반 HTML, Tailwind, shadcn/ui, React, Vue, Svelte, React Native, SwiftUI, Compose 또는 Flutter. 해당 스택에서 작업하세요. 절대 마이그레이션하지 마세요.
  • 기존 시각 시스템을 찾으세요: DESIGN.md, AGENTS.md 또는 CLAUDE.md 디자인 노트, Tailwind 또는 shadcn 테마 변수, 브랜드 가이드, 로고. 브랜드에 이미 색상과 글꼴이 있으면 유지하세요. 그러면 3단계의 방향은 브랜드 자체가 아닌 브랜드 내에서 레이아웃, 서체 크기, 밀도 및 강조를 변경합니다.
  • 실제 콘텐츠를 수집하세요: 제품 이름, 기능, 대상, 실제 숫자, 실제 스크린샷. 플레이스홀더 콘텐츠는 모든 디자인을 평범하게 만듭니다.

2. 감사(UI가 이미 존재하는 경우에만)

references/tells.md를 읽으세요. UI를 렌더링하는 파일에서 검사기를 실행하세요:

node <skill>/scripts/check.mjs <files or folders>

심각도별로 그룹화된 결과를 파일과 줄 번호와 함께 사용자에게 나열하세요. 검사기가 코드를 읽어서 볼 수 없는 항목(세 개의 동일한 카드, 모든 것이 중앙 정렬됨, 명확한 초점 부족, 필러 카피)을 추가하세요. 화면이 이미 잘 디자인되었다면 그렇게 말하고 재설계 대신 두세 가지 작은 개선 사항을 제안하세요.

3. 세 가지 방향 제시

references/systems.md를 읽으세요. 24개의 완전한 디자인 시스템이 나열되어 있으며, 웹용 12개와 모바일 앱용 12개가 각각 공개 DESIGN.md와 함께 있습니다.

  1. 의도적으로 다른 세 가지 시스템을 선택하세요: 예를 들어 하나는 밝고 에디토리얼, 하나는 어둡고 조밀함, 하나는 부드럽고 친근함. 플랫폼(웹 또는 앱)과 제품의 세계에 맞추세요. 절대 같은 디자인의 세 가지 변형을 제공하지 마세요.
  2. 각 시스템의 DESIGN.md를 해당 URL에서 가져오세요.
  3. 동일한 주요 화면을 각 방향으로, 동일한 실제 콘텐츠로, 독립형 HTML 파일로 빌드하세요:
    • pretty-ui/directions/a-<slug>.html, b-<slug>.html, c-<slug>.html
    • 웹 페이지는 1440×900, 모바일 화면은 390×844. 인라인 CSS, Google Fonts 링크, 외부 이미지 없음.
  4. 쉽게 비교할 수 있도록 만드세요:
    • Codex Design 캔버스 도구를 사용할 수 있는 경우(예: create_canvas와 add_node), 세 파일을 하나의 캔버스에 나란히 놓고 여세요.
    • 그렇지 않으면 node <skill>/scripts/compare.mjs pretty-ui/directions/*.html --out pretty-ui/directions/index.html을 실행하고 사용자에게 해당 파일을 열도록 알리세요.
  5. 사용자에게 하나를 선택하거나 부분을 결합하도록 요청하세요("A의 서체와 C의 색상"). 사용자가 결정을 요청했다면 제품에 가장 잘 맞는 것을 선택하고 한 문장으로 이유를 말하세요.

브랜드가 고정된 경우, 세 가지 방향은 브랜드의 색상과 글꼴을 사용하고 대신 레이아웃, 크기 및 밀도에서 차별화됩니다.

4. 시스템 기록

  • 선택한 시스템을 프로젝트 루트에 DESIGN.md로 저장하세요. 형식을 유지하세요: 토큰이 있는 YAML 머리말, 개요, 색상, 타이포그래피, 레이아웃, 형태, 구성 요소 및 해야 할 일과 하지 말아야 할 일.
  • 사용자가 요청한 변경 사항(브랜드 색상, 다른 제목 글꼴)을 코드뿐만 아니라 파일에도 적용하세요.
  • AGENTS.md(그리고 프로젝트에 CLAUDE.md가 있으면 거기에도)에 한 줄을 추가하세요: 모든 화면에서 DESIGN.md를 따르세요: 색상, 서체, 간격, 반경 및 구성 요소. Codex는 AGENTS.md는 자동으로 읽지만 DESIGN.md는 읽지 않습니다.
  • shadcn 또는 Tailwind 프로젝트의 경우 토큰을 테마 변수(--background, --primary, --radius 등)에 매핑하세요. 모든 시스템 페이지는 준비된 shadcn 테마를 연결합니다: npx shadcn@latest add https://codexdesign.io/r/<slug>.json.

5. 패스별로 적용

디자이너의 레드라인 리뷰처럼 한 번에 한 레이어씩 전체 화면에 작업하세요. 사용자가 달리 요청하지 않는 한 기능, 콘텐츠 및 섹션 순서를 유지하세요.

  1. 토큰. 하드코딩된 색상, 크기 및 반경을 시스템의 토큰으로 바꾸세요.
  2. 서체. 최대 두 개의 패밀리. 시스템의 척도를 사용하세요. 화면에서 가장 중요한 한 줄이 명확히 가장 크게 보이도록 만드세요. 정렬되는 숫자에는 표 형식 숫자를 사용하세요.
  3. 간격 및 레이아웃. 시스템의 간격 단위 하나와 그 배수. 모든 것을 그리드 또는 화면 패딩에 맞추세요. 관련된 것은 밀접하게 그룹화하고 그룹 간에는 넉넉히 분리하세요.
  4. 색상. 중립색이 화면을 이끕니다. 기본 색상은 사용자가 행동하는 곳에, 뷰당 약 한 번 나타납니다. 차트는 시스템의 차트 색상을 순서대로 사용합니다.
  5. 구성 요소. 버튼, 입력, 카드, 목록 및 내비게이션은 시스템의 구성 요소 섹션을 따릅니다. 실제 아이콘(Lucide, Phosphor, SF Symbols, Material Symbols)을 사용하고, 아이콘으로 이모지를 절대 사용하지 마세요.
  6. 카피. 제품의 평범하고 구체적인 단어. 필러("완벽한", "잠금 해제", "가속화")를 없애세요. 헤드라인은 그것이 무엇인지 또는 무엇을 하는지 말합니다.
  7. 세부 사항. 호버, 포커스 및 누름 상태; 빈 상태, 로딩 상태 및 오류 상태; 텍스트의 명암비는 최소 4.5:1.
  8. 모션. 무언가를 설명할 때만: 상태 변경, 화면 간 전환. 모든 섹션에 페이드인 또는 펄스 장식 없음.

모바일 앱의 경우 references/app.md도 읽으세요.

6. 확인

  • 변경된 파일에서 검사기를 다시 실행하고 모든 오류와 합당한 수의 경고를 수정하세요.
  • 결과를 확인하세요. Playwright 또는 브라우저 도구를 사용할 수 있으면 1440 및 390 너비(또는 앱의 경우 장치 크기)로 스크린샷을 찍고 잘못된 부분(초점 부족, 비좁은 그룹, 잘못 줄바꿈되는 텍스트, 낮은 명암비)을 수정하세요.
  • 재설계의 경우 사용자가 공유할 수 있는 전후 페이지를 작성하세요:
node <skill>/scripts/compare.mjs before.html after.html --labels "Before,After" --out pretty-ui/before-after.html

7. 보고

사용자에게 간단히 알리세요: 선택한 방향과 이유, 변경된 파일, 검사기가 전후에 발견한 사항, 그리고 사용자의 결정이 필요한 사항(실제 사진, 로고, 사용자만이 작성할 수 있는 카피).

항상 적용되는 규칙

  • 하나에 확정하기 전에 옵션을 보여주세요. 절대 조용히 스타일을 선택하지 마세요.
  • 사용자의 브랜드, 콘텐츠 및 스택을 유지하세요.
  • 제품당 하나의 디자인 시스템, DESIGN.md에 작성되고 모든 곳에서 따라야 합니다.
  • 사용자가 명시적으로 원하지 않는 한 보라색 또는 바이올렛 그라데이션, 그라데이션 텍스트, 유리 패널, 빛나는 그림자, 이모지 아이콘, 모든 헤드라인 위의 알약 배지 또는 동일한 아이콘 카드 행을 사용하지 마세요.
  • 한 클리셰를 다른 클리셰로 바꾸지 마세요. 세리프와 테라코타 악센트가 있는 크림색, 또는 거의 검은색에 산성 녹색 악센트 하나는 새로운 기본값입니다. 제품의 세계가 요구할 때만 사용하세요.
  • 장식 제거가 작업의 절반입니다. 공간을 실제 콘텐츠, 중요한 것에 대한 더 큰 서체, 그리고 제품 자체에서 가져온 하나의 기억에 남는 요소로 채우세요.

파일

  • references/systems.md: 24개의 디자인 시스템, 플랫폼, 스타일 및 DESIGN.md URL 포함.
  • references/tells.md: UI를 AI가 만든 것처럼 보이게 하는 요소와 대신 해야 할 일.
  • references/app.md: iOS, Android 및 크로스 플랫폼 앱 화면에 대한 규칙.
  • scripts/check.mjs: HTML, CSS, JSX, TSX, Vue 및 Svelte 파일에서 AI 흔적을 검사하는 정적 검사기. Node 18+, 종속성 없음.
  • scripts/compare.mjs: 방향 선택 또는 전후 비교를 위해 여러 화면을 나란히 보여주는 HTML 페이지를 작성합니다.

관련 스킬