s-skill-ui-writing

name	s-skill-ui-writing
version	1.0.0
description	UI 문구 작성 및 검토. 컴포넌트 유형과 상황을 전달하면 SMWS 기준으로 문구를 작성하거나 기존 문구를 검토한다. Use when asked to "UI 문구", "문구 작성", "문구 검토", "라이팅", "writing", "토스트 문구", "다이얼로그 문구", "에러 메시지", "버튼 텍스트", or anything involving UI copy writing/review.
allowed-tools	["Bash","Read","AskUserQuestion","ToolSearch","mcp__claude_ai_Notion__notion-fetch"]

UI Writing

세일즈맵 라이팅 시스템(SMWS) 기준으로 UI 문구를 작성하거나 검토한다.

입력

• $ARGUMENTS로 요청을 받는다.
• 요청이 불명확하면 아래를 반드시 확인한다:
  1. 모드: 작성(새 문구) / 검토(기존 문구 리뷰)
  2. 컴포넌트 유형: Dialog, Toast, Tooltip, Field, Empty State, Button, Error 등
  3. 행동 상황: 생성, 수정, 삭제, 안내, 경고, 확인 등

사전 준비

1. Notion에서 SMWS 문서를 읽는다: https://www.notion.so/1e3c6d2ec8a78083b398ed62e3d138c4
2. Notion에서 용어 사전 WIKI를 읽는다: https://www.notion.so/1acc6d2ec8a780ee9ceffa8a9ea5676b
3. SMWS에 해당 컴포넌트의 Writing Template이 있으면 참고한다. 단, 템플릿이 상황에 안 맞으면 무시하고 명확성 기준으로 작성한다.

Writing 규칙

1. 명확하고 쉬운 문구 우선

• **최우선 기준은 "명확하고 쉬운가"**이다. 템플릿보다 기준이 우선.
• SMWS 내 컴포넌트별 Writing Template은 참고하되, 템플릿이 상황에 맞지 않으면 기준(명확성, 간결성)에 따라 자유롭게 작성한다.
• 금지 표현 목록에 해당하는 문구는 사용하지 않는다.

2. 맥락 이해

• Writing이 쓰이는 UI 컴포넌트 유형과 행동 상황을 먼저 파악한다.
• 맥락이 불명확하면 반드시 사용자에게 재질문한다. 추측으로 문구를 작성하지 않는다.
• 오브젝트명은 변수로 템플릿화한다. ({오브젝트}, {필드명}, {N} 등)

3. 용어 일관성

• 세일즈맵 용어 사전 WIKI에 정의된 공식 용어를 기본으로 사용한다.
• 용어 사전에 "기존 -> 개선" 매핑이 있으면 개선된 용어를 사용한다.
• 단, UI 맥락에서 더 쉽고 직관적인 표현이 있으면 그것을 우선한다. 사용자가 바로 이해하는 문구가 최우선.
• 용어 사전에 없는 새로운 용어는 임의로 만들지 않고 사용자에게 확인한다.

4. Tone & Manner

• 신뢰감을 주며 명확하고 친절하게 행동을 안내한다.
• 명령조가 아닌 부드러운 요청형 사용 (예: "입력해 주세요")
• 오류 책임을 사용자에게 전가하지 않는다.
• 전문 용어, 사내 용어 배제 -> 사용자 입장에서 직관적인 용어 사용
• 과도한 감탄, 과잉 사과, 공포 조장 표현 금지

5. 문장 규칙

• 짧고 쉽게 이해되는 문장 구조 우선
• 1문장 권장, 최대 3문장 이내
• 연속된 문장 외에는 온점(.) 사용하지 않음. , ! ? 등은 상황에 따라 사용

6. 조사 및 어미

• 조사 선택은 맥락에 맞게: 목적지(에) vs 변환/수단(로), 대상(을/를) vs 방향(으로) 등 뉘앙스 차이를 구분한다.
  • 예: "노트에 저장" (목적지) vs "노트로 저장" (변환) -> 요약을 노트 형태로 만드는 맥락이면 "로"가 자연스러움
• 동일 화면 내 어미 패턴 일관성: "~하기" / 명사형 등 버튼 간 어미가 혼재되지 않도록 통일한다.
• 원어민 관점에서 자연스러운 표현인지 점검한다.

---

모드 A: 문구 작성

절차

1. 컴포넌트 유형과 행동 상황을 파악한다.
2. SMWS Writing Template이 있으면 참고하되, 맞지 않으면 명확성 기준으로 자유롭게 작성한다.
3. 용어 사전에서 관련 용어를 확인하고, "기존 -> 개선" 매핑이 있으면 개선된 용어를 사용한다.
4. 문구 초안을 작성한다.
5. 검토 체크리스트로 자체 검증 후 최종안을 제시한다.

출력 양식

## UI Writing -- 작성

| 항목 | 내용 |
|------|------|
| 컴포넌트 | {유형} |
| 상황 | {행동 상황} |
| SMWS 템플릿 | {있음/없음 -- 있으면 템플릿명} |

### 문구안

| 위치 | 문구 |
|------|------|
| {Title / Body / CTA / Placeholder 등} | {문구} |

### 근거
- {SMWS 규칙 또는 용어 사전 기반 판단 이유}

모드 B: 문구 검토

절차

1. 기존 문구와 사용 맥락(컴포넌트 유형, 상황)을 파악한다.
2. 아래 체크리스트 항목별로 검토한다.
3. 문제가 있으면 수정안을 제시한다.

검토 체크리스트

#	항목	기준
1	명확성 + SMWS 참고	명확하고 쉬운가, SMWS 템플릿이 있으면 참고했는가
2	용어 일관성	용어 사전 WIKI의 공식 용어를 사용하는가
3	Tone & Manner	부드러운 요청형인가, 사용자에게 책임을 전가하지 않는가
4	문장 길이	1문장 권장, 최대 3문장 이내인가
5	온점 사용	연속된 문장 외에 불필요한 온점이 없는가
6	조사/어미	조사 선택이 맥락에 맞는가, 동일 화면 내 어미 패턴이 일관되는가
7	금지 표현	SMWS 금지 표현 목록에 해당하는 문구가 없는가
8	변수 템플릿화	오브젝트명이 {변수}로 템플릿화 가능한가

출력 양식

## UI Writing -- 검토

| 항목 | 내용 |
|------|------|
| 컴포넌트 | {유형} |
| 상황 | {행동 상황} |
| 원본 문구 | {검토 대상 문구} |

### 검토 결과

| # | 항목 | 결과 | 비고 |
|---|------|------|------|
| 1 | 명확성 + SMWS 참고 | {통과/미달} | {상세} |
| 2 | 용어 일관성 | {통과/미달} | {상세} |
| 3 | Tone & Manner | {통과/미달} | {상세} |
| 4 | 문장 길이 | {통과/미달} | {상세} |
| 5 | 온점 사용 | {통과/미달} | {상세} |
| 6 | 조사/어미 | {통과/미달} | {상세} |
| 7 | 금지 표현 | {통과/미달} | {상세} |
| 8 | 변수 템플릿화 | {통과/미달} | {상세} |

### 수정안 (문제가 있는 경우)

| 위치 | 원본 | 수정안 | 사유 |
|------|------|--------|------|
| {위치} | {원본} | {수정} | {근거} |

$ARGUMENTS