프론트엔드 코드에서 디자인 시스템 추출은(는) 무엇을 하나요?
프론트엔드 소스 코드를 분석하여 애플리케이션을 빌드하거나 렌더링할 필요 없이 소스 파일에서 직접 프로젝트의 시각적 언어(색상, 타이포그래피, 간격, 컴포넌트 패턴, 레이아웃 원칙)를 포착한 종합적인 디자인 시스템 문서(DESIGN.md)를 추출합니다.
존재 이유
design-md 스킬은 렌더링된 HTML을 기반으로 동작합니다. 하지만 종종 코드베이스는 있지만 의존성이 누적되거나, 빌드가 깨졌거나, 빠른 감사만 필요한 상황에서 앱을 실행하기 전에 디자인 시스템을 이해하고 싶을 때가 있습니다. 이 스킬은 소스 파일 자체(스타일시트, 컴포넌트 파일, 테마 설정, Tailwind 구성)를 읽어들입니다. 더 빠르고 어디서나 작동합니다.
사용 시기
- 사용자가 프론트엔드 코드베이스를 가지고 있으며 디자인 시스템을 추출하거나 문서화하려는 경우
- 사용자가 프로젝트의 시각적 아이덴티티를 Stitch로 마이그레이션하려는 경우
- 사용자가 "스타일링 감사" 또는 "레포지토리의 디자인 언어 이해"를 요청한 경우
- 사용자가 기존 소스 코드에서 DESIGN.md를 생성하려는 경우
- 앱을 빌드/렌더링할 수 없지만 소스는 사용 가능한 경우
- 사용자가 코드베이스 전체의 일관성 없는 스타일을 통합하거나 조정하려는 경우
사전 요구 사항
- 프론트엔드 프로젝트 소스 디렉토리에 대한 접근 권한
- 빌드 또는 런타임 의존성 불필요 — 이 스킬은 소스 파일만 읽습니다
워크플로우
1단계: 프로젝트 탐색
무엇을 다루고 있는지 이해하는 것부터 시작합니다. 이에 따라 사용할 추출 패턴이 결정됩니다.
1. 프레임워크 및 스택 감지
프로젝트 루트에서 특징적인 파일을 스캔합니다:
| 시그널 파일 | 프레임워크/도구 |
|---|---|
react가 포함된 package.json | React / Next.js |
vue가 포함된 package.json | Vue / Nuxt |
svelte가 포함된 package.json | Svelte / SvelteKit |
@angular/core가 포함된 package.json | Angular |
tailwind.config.js/ts | Tailwind CSS |
postcss.config.js | PostCSS 파이프라인 |
styled-components 또는 @emotion (의존성) | CSS-in-JS |
.css / .scss / .less 파일만 있는 경우 | 일반 CSS / SASS |
theme.js / theme.ts / tokens.js | 디자인 토큰 파일 |
먼저 package.json을 읽으십시오 — 프레임워크, CSS 도구 및 디자인 토큰 라이브러리(예: style-dictionary, @chakra-ui/react, @mui/material, ant-design)를 알려줍니다. 이 컨텍스트는 스타일링 정보를 어디에서 찾아야 하는지 알려줍니다.
2. 소스 트리 매핑
분석할 주요 디렉토리와 파일을 식별합니다:
src/
├── components/ ← 컴포넌트 수준 스타일
├── styles/ ← 전역 스타일시트
├── theme/ ← 테마 정의, 토큰
├── assets/ ← 폰트, 이미지
├── app.css ← 루트 스타일
└── index.css ← 진입점 CSS
다음도 확인하십시오:
tailwind.config.js/tailwind.config.ts— 사용자 정의 색상, 폰트, 간격globals.css/global.css— CSS 사용자 정의 속성(변수)- 모든
theme.*또는tokens.*파일 - 컴포넌트 라이브러리 설정(예:
chakra-theme.ts,vuetify.config.ts)
3. 프레임워크별 가이드 참조
추출 패턴에 대한 적절한 참조 문서를 확인하십시오:
- React / Next.js / Tailwind → 참조/react-tailwind.md
- Vue / Nuxt → 참조/vue.md
- Svelte / SvelteKit → 참조/svelte.md
- Angular → 참조/angular.md
- 일반 CSS / SASS / Less → 참조/plain-css.md
이 참조 문서는 색상, 타이포그래피, 간격 및 컴포넌트 스타일을 찾기 위한 프레임워크별 패턴을 포함합니다. 진행하기 전에 일치하는 항목을 읽으십시오.
2단계: 심층 추출
각 디자인 요소를 체계적으로 처리하십시오. 각 요소에 대해 소스 파일에서 원시 데이터를 수집한 다음 설명적인 언어로 종합하십시오.
목표는 모든 CSS 속성을 덤프하는 것이 아니라 스타일링 선택 뒤에 숨은 의도를 이해하고 다른 디자이너(또는 Stitch)가 동일한 시각적 느낌을 재현하는 데 사용할 수 있는 인간적이고 편집적인 언어로 설명하는 것입니다.
1. 시각적 테마 및 분위기
전반적인 분위기를 이해하기 위해 가장 광범위한 스타일링을 먼저 읽으십시오:
- 루트 배경:
body또는 루트 요소의 배경은 무엇입니까? 밝은 크림(#f 범위)은 경쾌하고 깔끔함을 나타냅니다. 어두움(#0-#2 범위)은 무드 있고 드라마틱함을 나타냅니다. - 여백 철학: 간격 값이 넉넉합니까(32px+)? 아니면 빽빽합니까? 루트 컨테이너, 섹션 래퍼 및 카드 컴포넌트의 padding/margin 값을 확인하십시오.
- 밀도: 페이지/섹션당 컴포넌트 수를 세십시오. 공간이 있는 적은 수 = 미니멀; 빽빽하게 많이 = 정보 밀도.
- 색상 온도: 중성색이 따뜻합니까(크림, 황갈색)? 아니면 차갑습니까(청회색, 슬레이트)?
- 전반적인 느낌: 분위기를 포착하는 1-2개의 풍부한 문장으로 종합하십시오.
소스에서 이러한 신호를 찾으십시오:
| 소스 위치 | 알려주는 정보 |
|---|---|
루트 background-color 또는 레이아웃의 Tailwind bg-* | 전반적인 밝기/어두움 |
| Tailwind 설정 또는 CSS 변수의 간격 척도 | 여백 철학 |
| 컴포넌트 수 대 래퍼 패딩 | 밀도 |
사용자 정의 속성 이름(--warm-* vs --cool-*) | 색상 온도 의도 |
| 테마 파일의 주석 | 개발자 자신의 말로 표현된 디자인 의도 |
2. 색상 팔레트 및 역할
코드베이스에서 모든 고유 색상을 추출하고 기능적 역할을 할당하십시오. 모든 레이어를 검색하십시오:
색상을 찾을 수 있는 위치:
| 레이어 | 검색 대상 |
|---|---|
| CSS 사용자 정의 속성 | --color-*, --primary, --bg-* |
| Tailwind 설정 | theme.extend.colors |
| 테마/토큰 파일 | 색상 객체, 팔레트 |
| 컴포넌트 스타일 | background-color, color, border-color |
| 인라인/범위 스타일 | 템플릿의 bg-*, text-* 클래스 |
| CSS-in-JS 테마 객체 | colors, palette 키 |
구성 방법: 색조가 아닌 기능별로 색상을 그룹화하십시오:
- 기본 기반 — 배경 및 표면 색상
- 강조 및 상호작용 — CTA 버튼, 활성 상태, 링크
- 타이포그래피 및 텍스트 계층 — 기본, 보조, 3차 텍스트
- 기능적 상태 — 성공, 오류, 경고, 정보
각 색상에 대해 원시 16진수 값 대신 색상의 특성을 연상시키는 설명적인 이름을 만드십시오:
- ❌
#294056→ "파란색" - ✅
#294056→ "진한 뮤트 틸-네이비" — 기본 CTA, 활성 탐색
중복 제거가 중요합니다. 코드베이스에는 종종 거의 중복되는 색상(예: #333 및 #2C2C2C)이 있습니다. 의도된 색상을 가장 잘 나타내는 하나의 이름 아래에 통합하십시오.
3. 타이포그래피 규칙
완전한 타이포그래피 시스템을 추출하십시오:
글꼴 패밀리:
- CSS
font-family, TailwindfontFamily, Google Fonts 링크 또는 로컬@font-face선언을 확인하십시오. - 각 글꼴의 특성에 주목하십시오: 기하학적 vs 휴머니스트, 세리프 vs 산세리프, 연상시키는 느낌.
타입 스케일(계층):
- 모든 제목 수준(H1-H6)과 본문 텍스트를 찾아 다음을 기록하십시오:
font-size(rem 또는 px 단위)font-weight(숫자 값 + 설명적인 이름)letter-spacing(그리고 그 이유 — 우아함? 간결함?)line-height(가독성을 위해 넉넉함? 디스플레이용으로 빡빡함?)
- 컴포넌트 사용법을 매핑하십시오: 제품 카드는 어떤 제목 수준을 사용합니까? 히어로 섹션은 어떻습니까?
간격 원칙:
- 텍스트 간격은 전체 간격 척도와 어떻게 관련됩니까?
- 제목 대 본문의 자간 패턴
- 행간 철학(본문은 넉넉함/편안함, 디스플레이는 더 빡빡함)
4. 컴포넌트 스타일링
가장 중요한 4-5개의 UI 기본 요소를 분석하십시오:
버튼:
- 모서리 반경(그리고 그것이 전달하는 것 — 장난기? 전문성? 미니멀?)
- 기본, 보조 및 고스트 변형의 색 구성표
- 호버/포커스/활성 상태 및 전환 타이밍
- 패딩 비율(가로 대 세로)
카드/컨테이너:
- 모서리 반경(종종 버튼과 다름 — 약간 더 둥글)
- 그림자 전략: 평면, 미묘한 호버 그림자 또는 항상 입체?
- 테두리 처리: 가는 테두리, 색상 악센트 또는 없음?
- 내부 패딩(넉넉함 또는 콤팩트?)
- 카드 내 이미지 처리(전면, 패딩, 둥글게?)
내비게이션:
- 레이아웃 패턴(가로 막대, 세로 사이드바, 드로어)
- 타이포그래피 처리(대문자, 자간, 굵기)
- 활성/호버 상태 표시기(밑줄, 색상, 배경)
- 모바일 동작(햄버거, 하단 내비게이션, 드로어)
입력 및 양식:
- 테두리 스타일 및 포커스 상태 동작
- 버튼과의 모서리 스타일 일관성
- 패딩 및 터치 대상 크기 조정
도메인별 컴포넌트:
- 이 프로젝트에 고유한 1-2개의 컴포넌트(예: 제품 카드, 대시보드 위젯, 채팅 버블)를 식별하고 스타일링 패턴을 설명하십시오.
5. 레이아웃 원칙
구조적 시스템을 추출하십시오:
그리드 및 구조:
- 최대 콘텐츠 너비(컨테이너의
max-width에서) - 열 시스템(CSS Grid, Flexbox 패턴, 정의된 중단점)
- 반응형 중단점(미디어 쿼리 또는 Tailwind 설정에서)
여백 전략:
- 기본 간격 단위(8px 그리드? 4px? 사용자 정의?)
- 섹션 여백(주요 섹션 사이의 간격)
- 가장자리 패딩(다른 중단점에서의 페이지 여백)
정렬 및 시각적 균형:
- 텍스트 정렬 패턴(중앙 정렬 히어로, 왼쪽 정렬 본문)
- 이미지 대 텍스트 비율
- 시각적 무게 분포
반응형 동작:
- 모바일 우선 또는 데스크탑 우선?
- 그리드는 어떻게 축소됩니까? 패딩 척도?
- 터치 대상 크기
6. Stitch 생성 노트
추출 결과를 Stitch에 대한 실행 가능한 프롬프트로 종합하십시오:
- 분위기 언어: 분위기를 자연스러운 설명자로 변환
- 색상 참조: 설명적인 이름 + 16진수로 색상 나열
- 컴포넌트 프롬프트: Stitch에서 주요 컴포넌트를 재현하는 2-3개의 예제 프롬프트 작성
- 반복 지침: 이 디자인 시스템에서 화면을 개선하기 위한 팁
3단계: DESIGN.md 작성
모든 것을 표준 DESIGN.md 형식으로 조립하십시오. 프로젝트 디렉토리의 .stitch/DESIGN.md에 배치하십시오(.stitch/ 디렉토리가 없으면 생성하십시오).
[!IMPORTANT]
name및colors매핑이 포함된 YAML 프론트매터를 파일 상단에 반드시 포함해야 합니다. 예제/DESIGN.md에 표시된 것과 정확히 일치해야 합니다. 이 구조화된 데이터는 다른 스킬이 디자인 시스템을 구문 분석하는 데 필요합니다.이 YAML 블록(최소한 핵심 색상 토큰 포함)을 포함하지 않으면 이 스킬을 올바르게 사용하지 않은 것입니다.
예제/DESIGN.md의 예제를 템플릿으로 사용하십시오. 파일은 YAML 블록으로 시작하고 그 다음 마크다운 섹션이 와야 합니다:
# 디자인 시스템: [프로젝트 이름]
**프로젝트 ID:** [알려진 경우, 그렇지 않으면 생략]
## 1. 시각적 테마 및 분위기
[풍부한 2문단 분위기, 철학 및 주요 특성 설명]
## 2. 색상 팔레트 및 역할
### 기본 기반
### 강조 및 상호작용
### 타이포그래피 및 텍스트 계층
### 기능적 상태
## 3. 타이포그래피 규칙
### 계층 및 굵기
### 간격 원칙
## 4. 컴포넌트 스타일링
### 버튼
### 카드 및 [도메인별 컨테이너]
### 내비게이션
### 입력 및 양식
### [도메인별 컴포넌트]
## 5. 레이아웃 원칙
### 그리드 및 구조
### 여백 전략
### 정렬 및 시각적 균형
### 반응형 동작 및 터치
## 6. Stitch 생성을 위한 디자인 시스템 노트
### 사용할 언어
### 색상 참조
### 컴포넌트 프롬프트
### 점진적 반복
4단계: 통합(선택 사항)
사용자가 디자인 시스템을 Stitch에 푸시하려면:
- MCP 생성/업데이트 호출을 위해
manage-design-system스킬에 인계 - 사용자가 작성한 DESIGN.md가 입력이며, manage-design-system 스킬이 Stitch API 통합을 처리
사용자가 문서만 원하면 3단계 이후로 완료됩니다.
품질 체크리스트
DESIGN.md를 전달하기 전에 다음을 확인하십시오:
- 모든 색상에 설명적인 이름, 16진수 코드 및 기능적 역할이 있음
- 타이포그래피에 글꼴 패밀리, 문자 설명 및 전체 계층이 포함됨
- 컴포넌트 스타일이 모양, 색상, 상태 및 전환을 설명함
- 레이아웃에 최대 너비, 그리드, 중단점 및 간격 전략이 포함됨
- Stitch 생성 노트가 CSS 구문이 아닌 자연어를 사용함
- 분위기 섹션이 기술 문서가 아닌 편집 카피처럼 읽힘
- 거의 중복되는 색상이 통합됨
- 문서가 원시 값뿐만 아니라 스타일링 뒤에 숨은 의도를 포착함
더 나은 추출을 위한 팁
- 주석 및 커밋 메시지를 읽으십시오. 개발자는 종종 코드 주석(
/* 히어로 섹션 — 여유로운 */) 및 커밋 메시지에 디자인 의도를 문서화합니다. 이것들은 이유를 이해하는 데 금광입니다. - 디자인 토큰 라이브러리를 확인하십시오. 프로젝트가
style-dictionary,@tokens-studio또는 이와 유사한 것을 사용하는 경우 이러한 파일이 디자인 값의 가장 권위 있는 소스입니다. - 테마 파일은 컴포넌트 스타일보다 신호가 더 강합니다. 팔레트를 정의하는
theme.ts는 의도된 디자인 시스템을 말해줍니다. 컴포넌트에 흩어져 있는 인라인 스타일은 실제로 출시된 것을 말해줍니다. 둘 다 중요하지만 테마에서 시작하십시오. - Tailwind 설정은 디자인 시스템입니다. 프로젝트에 사용자 정의된
tailwind.config.js가 있다면 그것이 바로 디자인 시스템입니다. 먼저 그것에서 추출한 다음 재정의가 있는지 컴포넌트를 표본 검사하십시오. - CSS 사용자 정의 속성은 의도적입니다. 개발자가
--brand-primary를 정의했다면 이것이 디자인 토큰임을 알려주는 것입니다. 이를 존중하십시오.