design

name	design
description	Build and fix mini-app screens. Run it for "화면 만들어줘", "출석 체크 화면 그려줘", "화면이 구린데 예쁘게 해줘", "디자인 좀 봐줘" — it writes and edits the project's actual screen files, it is not a review-only pass and not a chat answer about design. Works from nothing: with no screen, no CSS file and no design assets in the project, it still produces the screens. Carries a written render standard — default text/background colors, a type scale, and hard rules the skill fixes itself when a screen breaks them (text under 11px, touch targets, bottom safe area, chevrons drawn as text glyphs, ads that cover content, dark patterns). Then grades what it produced against the quality bar, with the Apps in Toss container constraints (safe-area, swipe-back, PageHeader) checked against official docs looked up through the docs MCP. Also produces registration image assets at the console MCP `miniapp_create` tool's exact specs (logo, thumbnail, screenshots). Reads a Figma file as well if a Figma MCP is configured — optional input, never required. Not a code refactor pass: it changes how screens look and behave, not component APIs, props shape, or state management. Never registers or uploads. Triggered by `/ait:design [screen or request]`.
argument-hint	[screen or request]

design skill

목적

/ait:design 한 번으로 미니앱 화면을 만들고 고친다. 화면이 하나도 없는 프로젝트에서 처음부터 그려 내고, 이미 있는 화면은 진단에서 멈추지 않고 하드 규칙 위반을 직접 해소한다. 등록용 이미지 자산 산출도 같은 명령이 맡는다.

이 skill이 하는 일은 넷이다:

1. 화면을 그린다 — 요청을 화면 명세로 옮기고, 문서로 고정된 렌더 규칙 (references/render-rules.md)에 따라 프로젝트의 실제 화면 파일에 반영한다. 규칙은 3층이다: 1층 하드(차단 — 어기면 완료가 아니고 design이 직접 해소), 2층 권장(목록으로만), 3층 자유(제작자의 몫 — 판정하지 않는다).
2. 화면을 판정한다 — 브랜드 안전·컨테이너 적합성·토큰 일관성·화면 구조· 상태 완전성·카피·렌더 무결성·다크패턴을 화면별로 채점한다. 기준은 references/quality-bar.md에 항목별 등급(차단·권장)과 함께 고정돼 있고, 근거가 공식 문서에 있어야 하는 항목은 docs MCP로 조회해 확인한다.
3. 차단 항목을 해소한다 — 판정에 차단 등급이 남으면 진단 목록으로 넘기지 않고 렌더 단계로 돌아가 고친 뒤 같은 항목을 재판정한다.
4. 등록 이미지 자산을 정확한 규격으로 산출한다 — 콘솔 등록(console MCP miniapp_create)이 소비하는 ./assets/의 PNG들(logo·thumbnail·세로 스크린샷 등)을 등록이 검증하는 것과 동일한 규격에 맞춘다.

기본 토큰·타입 스케일은 중립 기본값이다. 토스 디자인 시스템(TDS) 호환이나 디자인 인증을 뜻하지 않으며, 프로젝트가 자체 값을 정했으면(Figma에서 읽어 온 토큰 포함) 그쪽이 우선한다. TDS를 모사·의존하도록 권하지도 않는다 — 디자인 자유도를 묶고, 실제 값을 모른 채 "TDS 호환"을 추측하게 만들기 때문이다.

이 skill은 harness의 디자인 station(station 8)이다. 완료되면 요청한 화면이 실제 파일로 있고, 1층 하드 규칙 위반이 0이며, 화면별 판정(G0~G8)이 등급과 함께 고정 형식으로 남는다. 자산을 요청했으면 ./assets/의 PNG도 등록 규격에 맞아 곧바로 실기기 확인(/ait:test-on-device)이나 콘솔 등록으로 넘어갈 수 있다. 산출물과 안내에 과장·홍보성 문구를 넣지 않는다.

토스 브랜드·UI 모방 금지

미니앱은 토스 앱 WebView 안에서 실행되지만 토스가 아니다 — design이 산출하는 화면·자산이 토스 브랜드나 토스 앱 자체의 UI를 모방하면 품질 문제가 아니라 브랜드·IP 리스크다(2026-08-07 도그푸딩에서 "시키다 보니 토스 로그인 화면처럼 되어버림" 사례가 관측됐다).

금지 목록 (design이 산출하는 화면·자산 어디에도 적용):

• ❌ 토스 로고·워드마크(어떤 형태의 변형·재구성도 포함)를 미니앱 아이콘· 화면·등록 자산에 사용.
• ❌ 토스 브랜드 컬러(토스 블루 계열, 예: #0064FF)를 미니앱의 primary 색상으로 채택. 위 TDS 절처럼 사실 참조로 언급하는 것과, 실제 화면 색상값으로 그대로 채택하는 것은 다르다 — 후자를 금지한다.
• ❌ 토스 앱 자체의 화면 레이아웃·UI 패턴을 복제 — 특히 토스 로그인/인증 화면의 구성(문구·배치·인터랙션)을 그대로 흉내 내는 것. 미니앱에 로그인/인증 화면이 있어도(plan skill의 auth 도메인 참조) 토스 로그인 화면과 시각적으로 구별돼야 한다.
• ❌ "토스" 상호를 미니앱 이름·화면 타이틀·브랜딩 문구에 사용해 미니앱 자체를 토스의 공식 제품처럼 표방하는 것. (SDK가 실제로 제공하는 기능을 사실 그대로 안내하는 문구 — 예: "토스 로그인으로 시작하기" 버튼 라벨 — 는 이 금지에 해당하지 않는다.)
• ❌ 토스 전용 본문 서체(Toss Product Sans 계열)를 미니앱에 쓰는 것. font-family에 이름으로 지정하거나, 웹폰트로 불러오거나, 폰트 파일을 번들·자산에 넣지 않는다. 어딘가에서 파일을 구할 수 있더라도 쓰지 않는다 — 공개 배포되는 서체가 아니라는 것이 곧 사용 권한이 없다는 뜻이다. (이모지 서체 Tossface는 이 금지에 해당하지 않는다 — 아래 대안 참조. 본문 서체와 이모지 서체는 공개 여부가 다르다.)

대안: 미니앱은 자체 design token(색·타이포·spacing)으로 일관되게 디자인하면 충분하다 — 위 "토큰 일관성" 점검이 이미 요구하는 방향과 같다. 플레이스홀더 색상이 필요하면 토스 블루가 아닌 임의의 색을 쓰고(아래 3단계 예시 참조), 사용자가 실제 브랜드 색을 알려주면 그 값을 쓴다.

본문 서체는 시스템 폰트 스택을 기본으로 한다(-apple-system, system-ui, sans-serif 등) — 어느 기기에서나 렌더되고, 라이선스 판단이 필요 없고, 웹폰트 로딩 지연도 없다. 브랜드 서체가 필요하면 라이선스가 명확한 공개 웹폰트를 쓰고 그 출처를 산출물에 함께 남긴다.

이모지 서체(Tossface)는 금지 대상이 아니라 권장 대상이다. 토스의 이모지 서체는 toss/tossface로 공개 배포돼 있고 자체 라이선스가 붙어 있다 — 판매·부정 이용·무단 수정본이 아닌 한 자유롭게 쓸 수 있다. 자체 아이콘 세트가 아직 없는 초기 미니앱에서 이모지는 정당한 경량 아이콘 수단이고, Tossface를 적용하면 기기·OS마다 모양이 달라지는 시스템 이모지 대신 어디서나 같은 글리프로 렌더된다(웹폰트를 실어서 얻는 효과다).

• 적용 대상은 아이콘 자리뿐 아니라 본문·데이터 문자열에 섞인 이모지 전부다 (예: ✅ 완료, ⚠️ 주의). 한 화면 안에서 어떤 이모지는 Tossface로, 어떤 이모지는 시스템 폰트로 렌더되면 그 자체가 품질 결함으로 보인다.
• font-family는 Tossface이고, 공식 README가 안내하는 CDN 경로는 https://cdn.jsdelivr.net/gh/toss/tossface/dist/tossface.css다. 폰트 파일을 직접 번들·재배포하는 경로를 고르면 라이선스가 저작권 안내 + 라이선스 전문 동봉을 요구하므로, 링크로 쓰는 것과 조건이 다르다는 점을 사용자에게 알린다.
• 배포되는 dist/tossface.css는 단일 폰트 파일이 아니라 unicode-range로 나뉜 12개 subset(TossFaceFontMac-00-11)의 모음이다 — 이 사실이 CDN 링크와 번들 포함 사이의 대가를 가른다. CDN 링크는 런타임에 브라우저가 실제로 쓰는 subset만 내려받아 번들 용량을 늘리지 않지만, 토스 앱 webview 안에서의 CDN 도달성은 harness가 실측하지 않았다(확인 필요). 번들 포함은 네트워크 없이 결정적으로 동작하지만, 앱이 실제로 쓰는 이모지가 속한 subset만 골라 담아도 subset당 약 520KB1.9MB가 늘어난다(12개 전량은 약 13.2MB). 어느 쪽이든 원본 파일을 다시 subsetting하거나 포맷 변환하지 않는다 — 그건 라이선스의 '수정본' 정의(포맷 변경을 명시적으로 포함)와 허가 조건(허용되지 않은 수정본 금지·저작권자·저자 이름 사용 제한)에 걸린다. (공식 dist/tossface.css의 저작권 주석은 "Reserved Font Name Tossface"라고 표기하지만, 이는 CSS 파일의 저작권 고지 문구이지 라이선스 전문의 별도 조항이 아니다 — 라이선스 전문 자체에는 이 표현이 없다.)
• 이모지 모양을 이미지 자산으로 다시 그리지 않는다 — 텍스트로 쓴다 (등록 자산 규격에도 맞지 않고, 위 라이선스 조건과도 어긋날 수 있다).
• 실제 배선(CDN 링크 추가 또는 subset 번들 배치 + 라이선스 동봉)은 이 skill의 책임이 아니다 — design은 서체 정책을 판정할 뿐이고, 실제 배선은 /ait:inject-tossface(inject skill의 tossface facet)가 두 모드의 대가를 계산해 보여준 뒤 진행한다.

위반 의심 시 절차: 위 금지 목록에 해당할 만한 정황이 보이면(사용자 요청 문구, 업로드된 참고 디자인, 기존 화면 등) design은 계속 진행하지 않고 멈춘다 — 임의로 "괜찮은 선에서" 변형해 조용히 진행하지 않는다. 사용자에게 구체적으로 어느 항목에 해당하는지 알리고, 확인이나 대안 방향을 물은 뒤에만 다시 진행한다.

멈추는 시점은 산출 전이다. 이 절은 문구만이 아니라 절차 순서를 규정한다 — 판정과 고지는 자산·코드를 만드는 첫 도구 호출보다 앞에 와야 한다. 만들어 놓고 나중에 알리는 것은 이 절차를 지킨 것이 아니다. 집행 지점은 아래 실행 순서 0단계(브랜드 체크포인트)이고, 2-C의 G0은 이미 산출된 것을 다시 채점하는 두 번째 관문이지 첫 번째가 아니다.

사용자의 명시 요청은 예외가 아니다. 사용자가 직접 토스 블루를 primary로 지정하거나 "토스 앱 화면처럼"을 요청해도 그대로 채택하지 않는다 — 요청은 멈추고 확인해야 할 신호이지 승인이 아니다.

모드

요청을 보고 네 모드 중 하나로 들어간다. 묻지 않고 판정하고, 애매하면 A로 간다. 모드는 배타적이지 않다 — A로 시작했다가 기존 파일을 손대게 되면 그 파일에는 B의 승인 규칙을 적용한다. C·D가 1-B(가이드 주입)를 건너뛰는 이유는 화면 코드를 손대지 않기 때문이다 — 손대지 않을 프로젝트에 파일을 심지 않는다.

모드	언제	도는 단계	화면 코드
A. 새로 만든다	화면이 없거나 새 화면을 더한다	0→1→1-B→2→2-B→3→4→7	새 파일 — 승인 불요
B. 고친다	기존 화면을 개선한다("화면이 구려")	0→1→1-B→2(축약)→2-B→3→4→7	기존 파일 편집 — 승인 후
C. 본다	판정만 원한다("디자인 좀 봐줘")	0→1→2-B→4→7 (1-B skip)	손대지 않는다
D. 등록 자산	콘솔 등록용 PNG가 필요하다	0→1→5→6→7 (1-B skip)	무관

의존

• Figma MCP server (선택): 사용자가 Figma MCP(예: Figma Dev Mode MCP, framelink 계열)를 자신의 에이전트에 설정해 두었으면 design이 그것을 소비해서 프레임·레이어·토큰을 읽는다. 이 플러그인은 MCP server를 제공하지 않는다 — Figma MCP는 "있으면 쓰고, 없으면 우아하게 대체"하는 선택적 입력일 뿐이다 (아래 "실행 순서" 1단계의 detect-and-degrade 참조).
• 이미지 도구 (선택, 자산 리사이즈용): 정확한 규격으로 PNG를 만들려면 ImageMagick(magick/convert)이나 sips(macOS), 또는 다른 로컬 이미지 도구가 있으면 활용한다. 없으면 사용자에게 디자인 export 규격을 안내해 직접 채우게 한다(절벽이 아니라 seam — 콘솔 등록과 동일한 규격을 그대로 전달).
• 진입점을 탐지할 수 있는 프로젝트 형상 (선택): src/main.tsx 같은 JS 진입점이 있으면 스타일 배선이 그 파일 한 줄로 끝난다. 후보가 전부 없으면 index.html의 <link> 폴백으로 내려간다 — 어느 쪽이든 동작하므로 전제가 아니라 분기다.

이 skill은 콘솔 인증을 요구하지 않는다. 화면 산출·판정·자산 생성은 로컬 작업이고, 등록(console MCP miniapp_create)이 콘솔 세션을 쓴다(1회 인가는 /mcp에서 apps-in-toss-console 브라우저 OAuth).

입력

• 요청 문구: /ait:design [화면 또는 요청]. "출석 체크 화면 그려줘", "화면이 좀 구려 보여", "디자인 좀 봐줘", "등록용 로고랑 스크린샷 만들어줘"가 전부 정상 입력이다. 인자 없이 불러도 된다 — 1단계에서 프로젝트 형상을 읽어 모드를 정한다.
• Figma 입력 (선택): 파일·프레임 URL을 함께 줄 수 있다. 없어도 진행한다.
• 자산 의도 (모드 D): 어떤 화면이 앱 아이콘·대표 썸네일·스크린샷이 될지. Figma 프레임이 있으면 그 프레임을 후보로 제시한다. 규격표는 아래 5단계에 있고, 콘솔 등록(console MCP miniapp_create)이 요구하는 입력 규격과 정확히 일치한다.

실행 순서

0. 브랜드 체크포인트 (산출 도구 호출 전 관문)

이 관문을 통과하기 전에는 자산·코드를 만드는 도구를 호출하지 않는다. Write·Edit은 물론 Bash로 파일을 만드는 것(mkdir -p assets, cat > src/... <<'EOF', magick/sips/Pillow 호출)도 전부 해당한다. 읽기·탐지·docs MCP 조회는 이 관문 전에 해도 된다.

요청 문구·참고 디자인·기존 화면을 위 "토스 브랜드·UI 모방 금지" 금지 목록에 하나씩 대조해서, 다음을 먼저 판정한다:

1. 요청받은 색·로고·서체·문구·화면 구성 중 금지 목록에 걸리는 항목이 있는가? (예: primary로 지정된 토스 블루 계열 hex, 토스 로고 사용, 토스 전용 서체 지정, 토스 로그인 화면과 구별되지 않는 구성)
2. 걸리면 사용자가 명시적으로 요청했더라도 채택하지 않는다 — 위 "사용자의 명시 요청은 예외가 아니다".
3. 걸리는지 애매하면 통과시키지 말고 생성 전에 멈추고 확인받는다. 만들어 두고 사후에 고지하는 것은 확인이 아니다.

걸리는 항목이 하나라도 있으면 그 자리에서 아래 형태로 알리고 답을 기다린다. "괜찮은 선에서" 변형해 조용히 진행하지 않는다:

요청하신 내용 중 아래가 브랜드 가드에 걸립니다:
  - <금지 목록 항목> ← <요청의 어느 부분인지>

미니앱은 토스와 명확히 구분되는 브랜드 경험이어야 해서, 이 부분은 그대로
만들지 않고 먼저 여쭙습니다. 대안: <중립 색 / 자체 로고 자리 / 구별되는 구성>.
이 방향으로 진행할까요, 아니면 다른 브랜드 색·구성이 있을까요?

전부 통과하면 그 사실을 한 줄로 남기고(예: 브랜드 체크포인트: 통과) 1단계로 넘어간다. 이 판정은 2-C의 G0과 같은 목록을 쓰지만 역할이 다르다 — 0단계는 산출 전 차단, 2-C는 산출물 채점이다. 0단계를 건너뛰고 2-C에서 처음 걸러내면 이미 늦다.

1. 모드·요청 무게 판정 + 입력 수집

먼저 위 "모드" 표에서 하나를 고른다. 이어서 요청의 무게(국소 수정 / 명세 완료형 / 방향 탐색 / 신규 설계)를 판별한다 — 분류 기준과 판별 팁은 Read <이 skill의 base directory>/references/build-mode.md. 프로젝트 형상도 함께 읽는다: 화면 파일이 있는지, 스타일 진입점이 무엇인지, package.json에 react가 있는지(아이콘 계열 분기), 이미 쓰는 토큰·아이콘 세트가 있는지. 프로젝트가 이미 정한 값이 있으면 언제나 그쪽이 우선한다.

Figma는 선택 입력이다 (detect-and-degrade). tool 이름에 figma가 들어가는 MCP tool(get_code·get_image·get_variable_defs·get_metadata 류)이 노출돼 있으면 Figma MCP가 설정된 것이다. MCP 설치를 강요하지 않는다 — 부재를 이유로 되묻고 멈추지 않는다. 화면은 Figma 없이도 끝까지 나온다.

상황	거동
MCP 있음	URL(또는 선택 프레임)을 읽어 프레임·레이어·토큰·export 후보를 가져온다. 읽어 온 토큰이 기본 토큰보다 우선한다
MCP 없음 + URL 없음	묻지 않고 그대로 진행한다. Figma는 편의 입력이지 전제가 아니다
MCP 없음 + URL 있음	"Figma MCP가 없어 이 URL은 직접 읽지 못합니다 — 화면을 설명해 주시면 그대로 반영하고, 아니면 기본 토큰으로 진행합니다"를 한 번만 안내하고 계속 진행한다

1-B. 프로젝트 디자인 가이드 확인·주입 (모드 A·B)

프로젝트에 디자인 가이드(토큰·하드 규칙 요약·아이콘)를 심어, 이후 어떤 세션에서 화면을 손대도 같은 기준이 적용되게 한다. 절차의 정본은 Read <이 skill의 base directory>/references/project-guide.md 하나이고 (new-miniapp의 스캐폴드 후처리도 같은 문서를 쓴다), 이 단계는 그것을 그대로 돌린다:

1. 캐리어(CLAUDE.md·AGENTS.md)에서 ait:design-guide 마커를 grep한다.
2. 마커가 없으면 다이제스트를 넣는다 — 파일이 있으면 끝에 append하고 기존 내용은 손대지 않는다. 없으면 다이제스트만 담아 새로 만든다.
3. 마커가 있고 버전이 같으면 skip하고 보고만 한다.
4. 마커가 있고 버전이 다르면 조용히 덮어쓰지 않는다. 마커 안쪽만 잘라 diff를 표로 보이고 전체 적용 / 골라서 / 취소 3택으로 승인받는다. 승인이 나면 마커 구간만 교체하고 바깥은 무수정으로 둔다. 거절하면 그대로 두고 다음 항목으로 넘어간다.
5. 정적 자산(src/styles/tokens.css·base.css, 아이콘)은 각각 존재를 먼저 확인해 있으면 skip, 없을 때만 복사한다. 아이콘은 계열 분기다 — React 프로젝트면 icons.tsx만, vanilla면 .svg 6종만(둘 다 넣지 않는다).

이 단계의 실패는 흐름을 멈추지 않는다. 실패한 항목만 한 줄로 보고하고 다음 단계로 간다 — 다시 부르면 멱등 가드 덕분에 남은 항목만 채워진다.

2. 리스크 점검 + 화면 명세

무엇을 그릴지 확정한다. 상세 기준은 1단계에서 읽은 build-mode.md에 있다.

• 리스크 점검 — 검수 반려 소지·핵심 가치 매몰·다크패턴·광고 정직성 4축을 가볍게 훑는다. 걸리는 게 없으면 조용히 통과한다. 없는 문제를 지어내지 않고, 짚을 때도 "이대로면 검수에서 걸릴 수 있어요" 톤으로 제작자가 판단할 여지를 남긴다.
• 화면 명세 — 화면별로 컴포넌트 타입 + 담기는 콘텐츠를 위에서 아래 순서(그리는 순서 = 읽는 순서)로 적는다. 치수(px)·색값·CSS·아이콘 파일명은 3단계의 몫이라 여기서 정하지 않는다. 예시 데이터("오늘 방문 3명")는 오히려 구체적으로 적는다.
• 플로우는 메인 한 컷에서 멈추지 않는다 — 완료성 액션이 끝에 있으면 완료 화면을, 공유·초대가 있으면 공유받은 사람이 들어오는 화면을 포함한다. 빈 상태·에러·재방문 변형은 별도 화면으로 뺀다.

모드 B와 국소 수정은 이 단계를 축약한다 — 무엇을 왜 바꾸는지 한 줄로 확인하고 바로 2-B로 간다. 물음보다 초안이 먼저다 — 정보가 부족해도 상식으로 추론해 일단 명세를 세우고, 진짜 못 정하는 것만 최대 2개까지 묻는다.

2-B. 공식 문서로 근거 확인 (docs MCP)

컨테이너 제약(safe-area·swipe-back·헤더)과 품질 기준 중 근거가 공식 문서에 있어야 하는 항목(quality bar의 D 근거)은 추측하지 말고 docs MCP(apps-in-toss-docs)로 조회한다 — searchDocumentation으로 찾고, 근거로 삼을 페이지는 getPage로 열어 확인한다.

조회 경로·tool 4종 구분·단계별 질의어는 Read <이 skill의 base directory>/references/docs-lookup.md. 문서에서 확인한 항목만 "공식 규격"으로 말한다. 검색 결과가 비는 것은 정상이므로 질의어를 한 번 바꿔 재시도하고, 그래도 없으면 (문서 확인 필요)로 남긴다 — 없는 가이드를 지어내지 않는다. 문서의 규격과 아래 5단계 규격표가 어긋나면 문서 쪽을 정본으로 보고 그 사실을 사용자에게 알린다(임의로 규격표 값을 바꾸지 않는다).

3. 렌더 — 화면 코드 작성·수정

Read <이 skill의 base directory>/references/render-rules.md를 먼저 읽는다. 색·크기·간격 값의 정본은 그 파일이 가리키는 assets/project/tokens.css다 — 기억에서 꺼내 쓰지 말고 읽어서 쓴다. 가이드는 1-B에서 확정됐다 — 프로젝트에 있으면 그것이 정본이고 기본 토큰은 그 아래다.

CSS 배선: src/styles/base.css가 진입점에 이미 걸려 있는지 grep으로 먼저 확인한다. 걸려 있으면 다시 넣지 않는다(중복 @import는 낭비다). 탐지 순서· vite/client 가드·index.html 폴백까지 포함한 절차는 render-rules.md 부록 "CSS entry 배선 절차"가 정본이다. base.css는 진입점에서 한 번만 로드되고 토큰은 그 안에서 @import './tokens.css'; 한 줄로 딸려 온다.

1층 위반은 자동으로 해소한다. 렌더가 끝나면 1층 10항목(글자 크기·이모지 Tossface·한글 줄바꿈·대비와 어포던스·터치와 safe area·광고 배치·레이아웃 무결성·다크패턴·꺾쇠와 화살표·상단 네비 미포함)을 전수로 훑고, 걸리는 항목은 지적으로 끝내지 않고 코드를 고친다. 2층 권장은 목록으로만 남기고 3층은 판정하지 않는다 — 브랜드색·폰트·톤·레이아웃은 제작자의 것이다.

승인 규칙

상황	승인
새 파일 생성 (모드 A)	불요. 만든 뒤 파일 목록으로 알린다
기존 파일 편집 (모드 B)	필요. 적용 전에 파일 / 무엇을 / 왜(항목 ID) 표를 보인다
승인 단위	전체 적용 / 골라서 / 취소 3택. 항목 하나하나 되묻지 않는다
차단 등급 항목	표에 차단으로 표시하고, 미적용이면 완료가 아니라는 사실을 함께 알린다
G0(브랜드) 위반	승인 대상이 아니다 — 0단계 절차대로 중단하고 확인받는다

승인 없이 기존 파일을 대량으로 고치지 않는다. 요청이 한 화면이면 그 화면만 손대고, 옆 화면까지 "김에 정리"하지 않는다.

문구는 design이 다시 쓰지 않는다. 화면 카피의 재작성은 /ait:ux-writing이 맡는다 — design은 4단계에서 G6로 판정만 하고 넘긴다. 카피 외의 화면 코드(레이아웃·토큰·상태·아이콘)는 design의 몫이다.

4. 품질 판정 + 차단 항목 수정 루프

산출한 화면·자산을 명시된 품질 기준으로 채점한다. 기준 전문(G0~G8 항목표· 등급·완료 판정 규칙·출력 형식)은 Read <이 skill의 base directory>/references/quality-bar.md. 축만 요약하면:

그룹	무엇을 보나	등급
G0 브랜드·IP 안전	위 "토스 브랜드·UI 모방 금지" 금지 목록 위반 여부	차단 — 중단하고 확인
G1 컨테이너 적합성	safe-area / swipe-back / 헤더 / 하단 CTA 여백 / 웹 레이아웃 전제	차단
G2 등록 자산 규격	6단계 실측 치수 검증 결과를 그대로 인용	차단 (5단계로 복귀)
G3 토큰 일관성	이름 있는 토큰·역할별 일관성·타입 스케일·weight·이모지 서체	차단 + 권장 혼재
G4 화면 구조·조작성	주요 액션 위계·도달성·터치 타깃·명도 대비·버튼 어포던스	차단 + 권장 혼재
G5 상태 완전성	로딩·빈 상태·실패·권한 거부 화면이 설계에 있는가	권장
G6 카피	어투 일관·에러 문구·과장 금지·손실 프레이밍·감정 단정·반복	권장 — 재작성은 /ait:ux-writing
G7 렌더 무결성·시각 안티패턴	겹침·잘림·종횡비·글리프 아이콘·줄바꿈·배경·정렬	차단 + 권장 혼재
G8 다크패턴·광고	전면 광고·닫기 함정·가짜 버튼·배너 배치·CTA 중복	차단

판정 단위는 화면이다. 각 항목은 통과 / 조정 필요(사유 1줄) / 해당 없음 중 하나로 적고, 판정할 수단이 없으면 통과시키지 말고 (확인 필요)로 남긴다.

차단 등급 항목에 조정 필요가 남으면 여기서 끝내지 않는다. 3단계로 돌아가 고친 뒤 같은 항목을 재판정한다. 기존 파일을 고칠 때는 3단계의 승인 규칙을 그대로 적용한다. 권장 등급은 목록으로 남기고 진행할 수 있다 — 다만 화면당 3건 이상이면 완료로 선언하지 않고 우선순위를 사용자에게 묻는다.

루프는 같은 항목에 대해 최대 2회까지 돈다. 2회로 안 풀리면 계속 고치지 말고 무엇이 걸렸는지 적어 넘기고, 그 항목은 (확인 필요)로 남겨 7단계 완료 안내에 그대로 인쇄한다.

G0은 이 단계에서 다시 채점하지만 자동 수정 대상이 아니다 — 브랜드·IP는 대안 선택이 사용자의 것이라 0단계와 같은 절차로 중단하고 확인받는다. 0단계 절과 브랜드 절이 "2-C"라고 부르는 두 번째 관문이 이 4단계 재채점이다.

5. 등록 이미지 자산 생성 (정확한 규격)

모드 D이거나 사용자가 등록 자산을 요청했을 때 돈다. 0단계 브랜드 체크포인트를 통과했는지 먼저 확인한다. 미통과·미확인 상태면 아래 명령을 하나도 실행하지 않고 0단계로 돌아간다. ./assets/는 없을 때만 만든다 (mkdir -p assets).

아래 규격으로 PNG를 산출한다. 이 표는 console MCP miniapp_create의 입력 규격과 정확히 일치해야 한다 — 등록이 로컬 + 서버 양쪽에서 같은 규격을 강제하므로, 여기서 어긋나면 등록이 거부된다.

파일	규격	개수
assets/logo.png	600×600	1 (필수)
assets/thumbnail.png	1932×828	1 (필수)
assets/screenshot-*.png	636×1048	≥ 3 (필수, 세로)
assets/logo-dark.png	600×600	선택
assets/screenshot-h-*.png	1504×741	선택 (가로)

산출 방법은 가용 도구에 따라 분기한다 — 이 skill은 이미지 렌더링 백엔드가 아니라, 에이전트가 가용 도구로 정확한 규격을 맞추도록 지시한다:

• 이미지 도구가 있고 소스가 준비된 경우(Figma export 또는 사용자가 둔 원본): 로컬 도구로 정확한 규격에 맞춰 리사이즈·크롭한다. 종횡비가 다르면 임의로 늘리지 말고(왜곡 금지) 크롭/패딩 의도를 사용자에게 확인한다. 예시:

  # ImageMagick (정확히 600×600으로, 종횡비 깨지면 사용자 확인 후)
  magick source-logo.png -resize 600x600^ -gravity center -extent 600x600 assets/logo.png
  # macOS sips (정확한 픽셀로)
  sips -z 600 600 source-logo.png --out assets/logo.png
  

• 이미지 도구가 없고 소스도 없는 경우 (디자인 자산 전무): 에이전트가 직접 단색 플레이스홀더 PNG를 생성해 ./assets/에 배치한다. 생성 전에 앱 이름· 주 색상(hex, 예: #6B7280)·카테고리를 묻는다. 색을 지정받지 못했다고 토스 브랜드 컬러(#0064FF 등)를 기본값으로 쓰지 않는다 — 중립 색을 임시로 쓰고 사용자 응답을 기다린다. 사용자가 지정한 색이라도 금지 목록(토스 블루 계열)에 해당하면 그 색으로 자산을 만들지 않는다 — 아래 명령을 실행하지 말고 0단계로 돌아가 대안 색을 확인받는다. design은 이제 토큰 파일을 직접 쓰므로 이 규칙은 자산뿐 아니라 자기가 쓰는 토큰 값에도 그대로 적용된다 — --brand-primary에 금지 색을 넣고 "나중에 바꾸세요" 주석을 다는 것은 통과가 아니다. 생성 우선순위:

  1. ImageMagick (magick 명령이 있으면):

     mkdir -p assets
     magick -size 600x600 xc:#6B7280 assets/logo.png
     magick -size 1932x828 xc:#6B7280 assets/thumbnail.png
     magick -size 636x1048 xc:#6B7280 assets/screenshot-1.png
     magick -size 636x1048 xc:#6B7280 assets/screenshot-2.png
     magick -size 636x1048 xc:#6B7280 assets/screenshot-3.png
     

  2. Python Pillow (python3 -c "from PIL import Image" 성공하면):

     from PIL import Image
     import os
     os.makedirs("assets", exist_ok=True)
     color = (107, 114, 128)  # 사용자가 입력한 hex → RGB (토스 블루를 기본값으로 쓰지 않는다)
     for name, w, h in [("logo", 600, 600), ("thumbnail", 1932, 828),
                        ("screenshot-1", 636, ), (, , ),
                        (, , )]:
         Image.new(, (w, h), color).save()
     

세로 스크린샷은 최소 3장이 필수다. 2단계 명세에서 "스크린샷으로 쓸 화면"으로 고른 화면을 우선 후보로 삼는다.

6. 규격 검증

생성된 파일의 실제 픽셀 치수를 확인해서 규격과 맞는지 검증한다(서버 왕복 전에 잡는다):

# ImageMagick
magick identify -format "%f %wx%h\n" assets/*.png
# macOS (도구 없을 때)
sips -g pixelWidth -g pixelHeight assets/logo.png

각 파일을 규격표와 대조해서, 어긋나면 어느 파일이 어떤 치수로 틀렸는지 짚고 5단계로 돌아가 다시 만든다. 필수 자산(logo·thumbnail·세로 스크린샷 ≥3)이 모두 규격을 통과해야 완료로 본다. 이 검증 결과가 곧 quality bar의 G2 판정이다 — 눈으로 보고 통과시키지 않는다.

7. 완료 안내

한 블록으로 마무리한다. 해당 없는 절(자산을 만들지 않았으면 자산 절)은 빼고 인쇄한다.

design 완료

화면:
  - src/pages/Home.tsx        새로 만듦
  - src/pages/Detail.tsx      고침 — 본문 13px → 15px, 하단 CTA safe-area 여백

1층 하드 규칙: 위반 0
  - 자동 수정 3건 (11px 이하 텍스트 / 터치 타깃 44px / 텍스트 꺾쇠 → SVG 아이콘)
  - 못 고친 항목이 있으면 무엇이 왜 남았는지 여기에 함께 적습니다

품질 점검 (quality bar G0~G8):
  - 화면별 항목 판정 (references/quality-bar.md "자기 점검 출력 형식" 그대로)
  - 요약: 차단 N건 / 권장 M건 / 확인 필요 K건 / 문서 확인 필요 J건
  - 차단 등급 미해소가 있으면 "완료 보류"로 표기

생성된 자산 (./assets/):
  - logo.png             600×600        (필수)
  - thumbnail.png        1932×828       (필수)
  - screenshot-1.png …   636×1048       (필수, 세로 ≥ 3장)
  - logo-dark.png        600×600        (선택, 생성했으면)
  - screenshot-h-1.png   1504×741       (선택, 가로, 생성했으면)
  규격은 생성 직후 검증했고, 등록 시(console MCP miniapp_create) 서버에서 다시 강제됩니다.

다음 단계 (명령을 몰라도 됩니다 — 따옴표 안 문장을 그대로 말해도 같은 단계로 갑니다):
  /ait:test-on-device    # 번들을 올려 실제 토스 앱에서 화면 확인
                         # 말로: "만든 미니앱을 실제 토스 앱에서 돌려보고 싶어"
  /ait:ux-writing        # G6(카피)에 조정 필요가 있으면 문구 재작성
                         # 말로: "이 화면 문구를 UX 라이팅 기준으로 다듬어줘"
  /ait:debug             # 폰에서만 화면이 다르게 보이면 라이브 진단
                         # 말로: "미니앱이 폰에서 이상하게 동작하는데 라이브 상태를 디버깅하고 싶어"

  console MCP            # 이 자산으로 miniapp_create → bundle_upload →
                         # bundle_upload_complete 로 등록·업로드
                         # (최초 1회 /mcp 에서 apps-in-toss-console 인가 필요)
                         # 말로: "이 자산으로 콘솔에 등록하고 번들 올려줘"

Out of scope (이 skill이 하지 않는 것)

• ❌ MCP server 추가·제공 — 이 플러그인은 순수 skills 패키지(idle context 비용 0). Figma MCP는 소비만 한다(있으면 쓰고 없으면 수동 경로). 설치를 강요하지 않는다.
• ❌ 등록·업로드 — design은 그 앞 단계(화면·자산 생산자). 등록·업로드는 console MCP 도구(miniapp_create/bundle_upload/bundle_upload_complete)의 역할.
• ❌ 이미지 렌더링 백엔드 노릇 — 임의 디자인을 픽셀부터 창작하지 않는다. 가용 로컬 도구로 규격에 맞춰 리사이즈/검증하거나, 소스가 없으면 단색 플레이스홀더를 자동 생성한다. Figma export를 직접 실행하지 않는다.
• ❌ 승인 없는 기존 파일 대량 편집 — 새 파일은 만든 뒤 알리면 되지만, 이미 있는 파일은 적용 전에 승인을 받는다. 요청받지 않은 화면까지 "김에" 손대지 않는다.
• ❌ 컴포넌트 API·상태관리 리팩터 — design이 바꾸는 것은 화면이 보이고 동작하는 방식이지 코드 구조가 아니다. props 형태·상태 라이브러리·폴더 구조 재설계는 이 skill의 일이 아니다.
• ❌ 카피 재작성 — G6로 판정만 하고 재작성은 /ait:ux-writing에 넘긴다.
• ❌ 종횡비 왜곡 — 규격에 안 맞는 소스를 임의로 늘려 채우지 않는다. 크롭/패딩 의도를 사용자에게 확인한다.
• ❌ 심미성 점수화 — quality bar는 재현 가능한 항목만 판정한다. "예쁨"에 점수를 매기지 않고, 3층(브랜드색·폰트·톤·레이아웃)은 판정 대상이 아니다.
• ❌ 공식 디자인 가이드 저술 — 공식 가이드의 정본은 공식 문서다. design은 docs MCP로 조회해 인용할 뿐이고, quality-bar.md·render-rules.md는 harness 기준임을 명시한다.

하지 말아야 할 것

• ❌ 0단계 브랜드 체크포인트를 통과하지 않은 채 자산·코드 생성 도구를 호출 (Write/Edit/Bash의 파일 생성·magick). 만들고 나서 경고하는 순서는 가드를 지킨 것이 아니다.
• ❌ 금지 목록에 걸리는 색·로고·구성을 "사용자가 그렇게 요청했으니" 채택 — 요청은 승인이 아니라 멈춤 신호다.
• ❌ 1층 하드 규칙 위반을 목록으로만 남기고 완료 선언 — 차단 등급은 고쳐야 끝난다. 2회 시도로 안 되면 무엇이 걸렸는지 적어 넘긴다.
• ❌ 승인 없이 기존 화면 파일을 고치기 — 표로 보이고 3택으로 승인받는다.
• ❌ 2층 권장·3층 자유를 차단처럼 다루기 — 과잉 지적은 그 자체로 결함이다 (render-rules.md의 "과잉 지적 금지" 절).
• ❌ Figma MCP가 없다고 되묻거나 중단 — 정상 상태로 보고 그대로 진행한다.
• ❌ 콘솔 등록(console MCP miniapp_create)과 다른 자산 규격을 산출 — 어긋나면 등록 시점에 거부된다. 규격 검증 없이 "자산 생성 완료"만 전달하지도 않는다.
• ❌ 품질 판정을 눈대중으로 통과 처리 — 판정 수단이 없으면 (확인 필요)로 남긴다.
• ❌ 문서에 없는 "앱인토스 공식 가이드"를 지어내기 — docs MCP 조회 결과가 없으면 (문서 확인 필요)로 남긴다.
• ❌ TDS를 토스의 디자인 인증·제휴로 함의하기. 산출하는 안내에 과장·홍보성 문구 삽입 금지.

참고

• 짝 skill: new-miniapp (greenfield 프로젝트 생성 — 화면을 올릴 프로젝트가 아직 없을 때 먼저. 스캐폴드 후처리가 1-B와 같은 가이드 주입 절차를 쓴다).
• 짝 skill: ux-writing (G6 카피 "조정 필요" 판정을 재작성으로 이어받는 조력 skill — 재작성이 끝나면 G6 재판정으로 다시 넘어온다).
• 짝 skill: debug (폰에서만 다르게 보이는 화면의 라이브 진단).
• 생성한 자산은 콘솔 등록(console MCP miniapp_create)이 바로 소비한다.
• 진입·종료·화면 컨텍스트(swipe-back/PageHeader), 상단 네비게이션 바 악세서리 버튼(partner.addAccessoryButton) 등 주제별 가이드는 docs MCP (searchDocumentation/getPage)로 조회한다.
• 상세가 필요하면 이 skill의 base directory 아래 references 5종을 Read한다: render-rules.md(3층 렌더 규칙 정본 — 1층 하드 10항목·기본 토큰의 역할과 위계·CSS entry 배선 절차·아이콘 6종), build-mode.md(요청 무게 4분류·리스크 점검 4축·화면 명세 형식), project-guide.md(가이드 주입 절차 — 마커 형식· 멱등 가드·버전 불일치 갱신·자산 복사 폴백), quality-bar.md(판정 기준 G0~G8·항목별 등급·완료 판정 규칙·출력 형식), docs-lookup.md(docs MCP 4-tool 구분·단계별 질의어·근거 반영 규칙).