design-system-tokens 가이드

한 줄 결과물: 토큰 3층 점검, 하드코딩 인벤토리(개수와 대표 위치), 테마 교체 준비도, 변칙 컴포넌트 후보. 코드는 고치지 않고 제안만 낸다.

스킬 본문: ../../design-system-tokens/SKILL.md

언제 쓰나

• 토큰이 정의, 사용, 컴포넌트 세 층으로 나뉘는지, 하드코딩이 얼마나 퍼졌는지 알고 싶을 때
• 새 테마나 새 제품을 붙이기 전에 "값만 바꿔 되는 구조"인지 확인할 때
• 반복되는 예외(변칙 컴포넌트)를 시스템에 넣을지 정리할 때
• 쓰지 않을 때: 색 램프 설계(color-system), 한 화면 검수(ui-review)

샘플

그림의 개수와 파일 이름은 모양을 보여 주는 예시다. 실제로는 search_files로 찾은 값을 쓴다.

따라하기

1. 입력 세 가지를 정한다. 토큰 정의 위치, 소비하는 코드 위치, 비교할 테마나 제품.

   design-system-tokens 스킬로 점검해 줘.
   토큰: <tokens.json 경로>, 소비 코드: <src/components>, 비교 테마: 다크.
   코드와 토큰 파일은 고치지 말고 제안만 내줘.

2. 층을 확인한다. 정의 층(날것의 값), 사용 층(의미 이름이 정의를 가리킴), 컴포넌트 층. 층마다 개수와 예시 셋을 적는다. 의미 층에 날것의 값이 직접 들어 있으면 이름만 바꾼 정의 층이다.
3. 하드코딩을 센다. 색 리터럴, px 값, 글자 크기 숫자, 폐기된 값을 종류별로 찾아 개수와 대표 위치를 적는다.
4. 이름 짝을 본다. 설계와 코드 한쪽에만 있는 토큰을 목록으로 만든다. 이름이 비슷해도 값은 직접 대조한다.
5. 테마 교체 준비도를 본다. 정답은 점수 하나가 아니라 "다시 짜야 하는 곳" 목록이다.
6. 변칙을 모은다. 같은 변칙이 세 번 이상 나오면 시스템에 넣을 후보다. 분류: 결함, 시각 불일치, 기능 요청, 제품이 소유하는 조합.

흔한 실패

• 존재를 확인하지 못한 토큰이나 컴포넌트를 지어낸다. 없으면 "없음, 제안"으로 쓴다.
• 점검 결과를 판결처럼 쓴다. 근거와 한계를 함께 적는 지도다.
• 모든 곳을 한 번에 맞추려 한다. 실제 제품에서 반복되는 필요에서 출발한다.
• 디자인 파일 정리 비용을 빼고 일정을 잡는다. 코드보다 먼저 일정에 넣는다.

다음 스킬

• 점검 결과를 개발에 넘길 때는 handoff-to-dev
• 색 구조는 color-system, 회사 값은 infograb-design-contract