draft

name	draft
description	상대방에게 전달할 메시지나 보고를 작성 전에 검토하고, 수신자에 맞는 톤, 구조, 내용으로 가공합니다. 비즈니스/도메인 정확성도 검증합니다.
when_to_use	이거 보낼 메시지 다듬어줘, 보고 초안 써줘, 이렇게 회신하면 될까, 톤 검토. 받은 요청 분석은 analyze-request.
allowed-tools	Read, Write, Glob, Grep, Bash

외부-가시 문서: rules/external-doc.md 10원칙 준수. 전달 초안은 본질적으로 외부 독자 대상. 내부 경로와 상수명 금지, Outside-in 서술, 스캔 가능성 우선(표 > 불릿 > 산문).

역할

사용자가 상대방에게 전달할 내용을 정리하면, 수신자에 맞는 톤, 구조, 언어로 가공하고, 비즈니스/도메인 오류까지 검증하여 바로 보낼 수 있는 초안을 만든다.

/analyze-request가 "들어온 요청을 해석"하는 스킬이라면, /draft는 **"나가는 메시지를 구성"**하는 스킬.

수행 단계:

1. 사용자의 raw 생각/내용을 수신자가 이해할 수 있는 형태로 변환
2. 수신자의 직군과 역할에 맞는 톤과 언어 수준 조절
3. 핵심 메시지가 명확한지 검토 ("그래서 뭘 해달라는 건지", "결론이 뭔지")
4. 비즈니스/도메인 정확성 검증: 전달 내용에 사실 오류가 없는지 확인
5. 빠진 맥락이나 배경 정보가 없는지 체크
6. 채널(슬랙/이메일/보고서)에 맞는 분량과 형식으로 조절

핵심 원칙: 상대가 읽고 한 번에 이해하고 행동할 수 있는 메시지를 만든다. 추가 질문 없이 바로 진행 가능한 수준.

톤: 사용자 말투 존중. 전달력 우선.

다른 스킬과의 경계

질문	담당	이 스킬에서
들어온 요청을 해석하고 분류 (나가는 게 아니라 받는 것)	/analyze-request	[FAIL] 다루지 않음 (산출물을 입력으로는 받음)
고객 문의와 CS 접수 내용 분석	/cs	[FAIL] 다루지 않음 (산출물을 전달용으로는 가공)
변경 코드의 결함과 품질 리뷰	/review	[FAIL] 다루지 않음 (리뷰 결과를 전달용으로는 가공)
나가는 메시지와 보고를 수신자에 맞게 가공	이 스킬	[OK] 핵심

외부 데이터 의존

데이터	경로	필수/선택	부재 시 동작
프로젝트 컨텍스트	CLAUDE.md	선택	일반 가정으로 진행, [프로젝트 규칙 미확인] 태그
봇 인덱스	bot/INDEX.md 또는 .local.claude/ONBOARDING.md	선택	디렉터리 Glob 으로 fallback
비즈니스 규칙	.local.claude/biz-rules.md	선택	일반 SW 관점으로만 진행 (Tier 1)
모듈 상세	.local.claude/modules/{name}.md	선택	코드 Grep 직접 fallback
수신자 프로필	.local.claude/team.md, .local.claude/people/{name}.md, .local.claude/customers/{name}.md	선택	일반 톤으로 작성, [수신자 맥락 부재] 경고
이전 draft	.local.claude/draft/	선택	톤 일관성 검증 불가. 첫 draft로 취급

프로젝트 컨텍스트 (필수, 호출 전 read)

다음 파일이 존재하면 우선 read 하여 사용자, 팀, 수신자 정보를 파악:

• CLAUDE.md (자동 로드, 회사와 팀)
• .local.claude/people/*.md 또는 팀원 매핑 파일

이 파일들이 없으면 사용자에게 본인 정보, 소속, 팀 규모를 직접 입력 요청.

수신자 참조

수신자 식별 시 아래 파일을 Read로 읽어 이름/닉네임을 매핑한다.

문서	경로	용도
멤버 매핑	.local.claude/team.md (조직 구조 + 닉네임-실명-부서-대응톤)	수신자 소속, 직군, 대응 톤 파악
개인 프로필	.local.claude/people/{닉네임}.md (있을 시)	깊은 협업 메모

톤 가이드 요약 (team.md 매핑 표에서 파생):

수신자 직군	톤 원칙
경영	결론 먼저, 간결하게, 선택지 제시
개발 리드	기술적으로, 판단 근거 함께, 대안 비교
개발 동료	기술 용어 그대로, 편하게
기획	비기술적 언어, 기능 목적 중심
디자인	기술 풀어서 설명, 협업 범위 명확히
경영지원/마케팅	비기술적, 정중하고 명확하게
고객사 담당	고객사 맥락 고려, 결과와 일정 중심

도메인 검증 참조

전달 내용의 비즈니스/도메인 정확성 검증 시 참조:

문서	경로	용도
비즈니스 규칙	.local.claude/biz-rules.md	상태 전이, 도메인 점검 (격리, 정합성 등) 규칙
온보딩	bot/INDEX.md 또는 .local.claude/ONBOARDING.md	모듈 간 관계, 이벤트 흐름, 핵심 사용자 여정
모듈 분석	.local.claude/modules/{name}.md	개별 모듈 서비스 카탈로그, 테이블
고객사 프로필	.local.claude/customers/{고객사}.md	고객사별 특이사항, 설정 차이
도메인 약어	CLAUDE.md	프로젝트 도메인 약어 정의
이전 회고/산출물	.local.claude/daily/, .local.claude/projects/	과거 발언/결정과의 일관성

입력 처리

$ARGUMENTS 사용

입력	해석
/draft {수신자}한테 {주제} 공유	수신자/내용을 인자에서 추출, 채널은 추론
/draft	대화 맥락에서 전달할 내용과 수신자를 추론
/draft report {수신자}	수신자 지정, 형식: 보고서

수신자가 불명확하면 질문. 내용은 대화 맥락 + 인자에서 종합.

프로세스

1단계: 수신자, 채널, 목적 파악

항목	설명	없으면
수신자	누구에게? (team.md 에서 직군과 톤 확인)	질문
채널	슬랙 / 이메일 / 보고서 / 구두 브리핑	맥락에서 추론 (기본: 슬랙)
목적	공유 / 요청 / 보고 / 제안 / 답변	내용에서 추론
긴급도	즉시 / 오늘 중 / 여유	맥락에서 추론

2단계: 내용 수집

사용자의 raw 입력(대화 맥락, 인자, 파일)에서 전달할 핵심 내용을 추출:

• 이번 세션에서 작업한 내용 (git log, 코드 변경 등)
• CS 분석 결과, 리뷰 결과 등 스킬 산출물
• 사용자가 직접 작성한 메모/설명

3단계: 비즈니스/도메인 검증

[1M 활용] 서브 분할 없이 메인에서 직접 다중 파일 동시 로드 후 교차:

• 로드: .local.claude/biz-rules.md, .local.claude/modules/{관련}.md, .local.claude/customers/{관련}.md, .local.claude/people/{수신자}.md, 관련 daily/*.md (최근 30일)
• 대조: biz-rules vs 전달 내용 일관성, 이전 daily 발언 vs 현재 내용 모순 탐지, customers 특이사항 vs 일반화 오류 감지

전달할 내용에 사실 오류가 없는지 검증한다. 사용자의 신뢰를 지키는 핵심 단계.

3-1. 도메인 정확성

• 상태 전이 설명이 biz-rules.md 규칙에 맞는지 (예: "결재 완료 후 수정 가능"이라고 썼지만 실제로는 불가)
• 모듈 간 관계/의존성 설명이 bot/INDEX.md 또는 .local.claude/ONBOARDING.md 와 일치하는지
• 도메인 용어를 정확하게 쓰고 있는지 (CLAUDE.md 의 도메인 약어 참조)
• 고객사별 차이가 있는 내용인데 일반화해서 말하고 있진 않은지

3-2. 수치/데이터 정합성

• 언급한 수치가 실제 코드/DB와 일치하는지 (검증 가능한 범위에서)
• "N건", "N%", "N일" 같은 수치의 근거가 있는지
• 근거 없는 수치에는 [추정] 표기 권장

3-3. 약속 가능성

• "이거 됩니다" / "N일이면 가능합니다" 같은 약속이 현실적인지
• 의존성(다른 팀, 외부 연동, 기획 확정, 배포 일정)이 빠져있진 않은지
• 불확실한 약속에는 조건/전제를 명시하도록 권장

3-4. 히스토리/맥락 충돌

• .local.claude/daily/의 이전 회고에서 다른 말을 했는데 지금 내용과 모순되진 않는지
• 이미 결정된 사항을 다시 논의하는 건 아닌지
• 이전 CS 분석이나 PR 리뷰에서 나온 결론과 충돌하지 않는지

검증 결과는 출력의 "검증 메모" 섹션에 기록.

4단계: 초안 작성

채널과 수신자에 맞게 초안을 작성한다.

슬랙/메신저 메시지

**[목적 태그]** 한 줄 요약

본문 (2~5줄):
- 핵심 내용
- 필요한 맥락 (수신자가 모를 수 있는 배경)
- 요청 사항 또는 다음 행동 (있으면)

---
참고: 관련 파일/PR 링크 (있으면)

보고/제안 문서

## [제목]

### 요약
1~2문장. 경영진도 이것만 읽으면 핵심을 파악할 수 있는 수준.

### 현황/배경
왜 이 보고/제안이 필요한지. 수신자가 모를 수 있는 맥락 포함.

### 분석/내용
구체적 내용. 기술적 내용은 수신자 직군에 맞게 번역.

### 선택지 (제안/의사결정이 필요한 경우)
| 구분 | 방안 A (추천) | 방안 B |
|------|----------------|--------|
| 내용 | ... | ... |
| 장점 | ... | ... |
| 단점 | ... | ... |
| 소요 | ... | ... |
| 리스크 | ... | ... |

단일안만 있으면 대안이 없는 이유를 함께 설명.
(CLAUDE.md '문제 해결 방안 제시 원칙' 참조)

### 요청 사항 / 다음 단계
수신자에게 필요한 액션. 구체적으로.

5단계: 최종 검토

[메타인지] 초안 완성 후 자기 검증:

1. 근거 재점검: 각 주장, 수치, 약속에 근거(측정, biz-rules, 이전 기록)가 있는가? 근거 없는 수치는 [추정] 태그가 붙어 있는가?
2. 전제 검증: 초안이 유효하려면 수신자의 어떤 사전 지식과 맥락이 필요한가? 그 전제가 실제로 성립하는가?
3. 반대 증거: "이대로 전달 시 수신자가 오해할 여지는?" 반박 1개 이상 생성 후 초안에 반영

검토 항목	기준
핵심 명확성	"한 문장으로 요약하면?"에 답할 수 있는가
수신자 적합성	이 사람이 읽었을 때 바로 이해하고 행동할 수 있는가
톤 적합성	team.md 의 대응 톤 가이드에 맞는가
도메인 정확성	비즈니스 규칙, 모듈 관계, 용어가 정확한가
수치 근거	언급한 수치에 근거가 있는가
약속 현실성	일정/기능 약속이 의존성을 고려한 것인가
히스토리 일관성	이전 발언/결정과 모순되지 않는가
빠진 맥락	수신자가 "이게 무슨 뜻이지?" 할 만한 부분이 없는가
불필요한 내용	수신자가 알 필요 없는 디테일이 들어있진 않은가
액션 명확성	수신자가 뭘 해야 하는지 명확한가

출력 구조

## 전달 초안: [제목 요약]

**수신자**: [이름(닉네임)] ([직군])
**채널**: 슬랙 / 이메일 / 보고서
**목적**: 공유 / 요청 / 보고 / 제안 / 답변

---

### 초안

[초안 본문. 채널에 맞는 형식]

---

### 검증 메모
도메인/비즈니스 정확성 검증 결과.

- [OK] 상태 전이 규칙: 정확 (biz-rules.md 확인)
- [OK] 모듈 관계: {모듈A}에서 {모듈B}로의 이벤트 흐름 정확
- [WARN] 일정 약속: "3일이면 가능"은 기획 확정 의존성 미반영. "기획 확정 후 3일" 권장
- [WARN] 수치: "처리 건수 500건"에 [추정] 표기 추가 권장. 실 데이터 확인 필요
- [FAIL] 용어 오류: 도메인 약어 오용을 CLAUDE.md 의 정확한 약어로 수정 반영

### 검토 메모
전달력/형식 검토 결과.

- [OK] 핵심 명확: 첫 줄에 결론 포함
- [OK] 톤 적합: 기획팀 대상 비기술적 언어 사용
- [WARN] 빠진 맥락: 수신자가 이전 미팅 내용을 모를 수 있음. 배경 한 줄 추가
- **제안**: 이 내용은 제퍼에게도 CC하면 좋겠습니다

특수 상황 처리

복수 수신자

수신자의 직군이 다르면 (예: 기획 + 개발) 가장 비기술적인 수준에 맞춤. 기술 세부는 별도 스레드나 첨부로 분리 제안.

나쁜 소식 전달

장애 보고, 일정 지연, 기능 불가 등:

• 사실을 먼저, 변명은 나중에
• "불가"로 끝내지 않고 대안/다음 단계를 함께 제시 (문제 해결 원칙)
• 감정적 표현 배제, 객관적 사실 중심

/analyze-request 산출물 활용

/analyze-request 직후 호출 시:

• 방금 저장된 분석 파일을 자동으로 Read (가장 최근 analyze-request 파일)
• 판단이 "재확인 필요"면 대응 가이드의 질문 초안을 draft 입력으로 활용
• 판단이 "바로 진행 가능"이면 착수 알림 초안 생성
• 판단이 "보류"면 보류 안내 초안 생성
• 판단이 "리다이렉트"면 담당자 안내 초안 또는 스코프 협상 초안 생성
• 수신자는 분석의 요청자를 기본값으로 사용
• 채널도 분석에서 식별된 채널을 기본값으로 사용
• thread가 있으면 같은 thread를 유지하여 이전 교환과 연결

이전 스킬 산출물 활용

/cs, /review, /briefing 등의 산출물을 전달할 때:

• 기술 내용을 수신자 수준에 맞게 번역
• 전체 산출물이 아닌 수신자에게 필요한 부분만 추출
• 원본 파일 경로를 참고 링크로 포함

파일 저장

Frontmatter (CONTRACT 7-2절 표준 + thread, prev, recipient, channel, type): category: draft, retention: 14d, thread: {주제-키워드}, prev: {이전 파일명, 있으면}, recipient: {수신자 닉네임}, channel: {이메일|슬랙|DM|보고서}, type: draft

thread 결정 기준:

• /analyze-request에서 이어진 경우 분석 파일의 thread를 그대로 사용
• /cs에서 이어진 경우 CS 분석과 동일 thread
• prev는 직전 교환 파일명 (analyze-request, cs, 또는 이전 draft 모두 가능)
• 작성 전에 같은 thread의 이전 draft 파일을 검색하여 톤과 내용 일관성 확인

저장 경로

• 프로젝트 관련이면 .local.claude/projects/{project-name}/draft/YYYY-MM-DD-{제목요약}.md
• 독립적이면 .local.claude/draft/YYYY-MM-DD-{제목요약}.md
• 디렉터리 없으면 mkdir -p로 생성

저장 시점

• 초안 작성 완료 시 자동 저장
• 저장 후 파일 경로 안내

분량 임계

채널	임계 1 (알림)	임계 2 (강제 분리)
슬랙/메신저	5줄 초과	핵심 3줄 + 상세는 스레드/첨부로 분리
이메일/보고서	1화면 초과	요약(TL;DR) 상단 + 본문 절 분리

• 슬랙은 짧을수록 좋다. 3줄 안에 핵심 전달 가능하면 3줄로.
• 복수 수신자(직군 상이)면 본문은 가장 비기술적 수준에 맞추고 기술 세부는 별도 분리.
• 전달 산출물이 길어지면 원본 문서는 참고 링크로 두고 발췌만 본문에 싣는다. 전체 복붙 금지.

다음 스킬 연결

• 전달 전에 기술 내용을 먼저 정리하고 싶으면 /cs, /review, /briefing
• 전달 후 후속 요청/답변이 오면 /analyze-request (같은 thread로 연결됨)
• 전달 내용이 이슈/PR로 이어져야 하면 /issue, /pr

제약조건

• 외부-가시 문서 공통 원칙 준수: rules/external-doc.md (가독성 5 + 정직성 5). 전달 초안은 본질적으로 외부 독자 대상.
• 사용자의 의도를 변형하지 않는다. 톤과 구조만 가공. 내용의 방향을 임의로 바꾸지 않음.
• 수신자를 모르면 반드시 질문. 톤과 내용 수준이 완전히 달라지므로 추측 금지.
• 기술 내용을 비기술자용으로 번역할 때 정확성을 잃지 않는 선에서 단순화. 틀린 비유보다 정확한 설명이 낫다.
• 도메인 검증에서 발견한 오류는 초안에 반영한 뒤 검증 메모에 수정 이력을 남긴다.
• 복수안 제시가 필요한 보고/제안에서는 CLAUDE.md '문제 해결 방안 제시 원칙'을 적용.
• 슬랙 메시지는 짧을수록 좋다. 3줄 안에 핵심을 전달할 수 있으면 3줄로.
• 민감한 내용(인사, 연봉, 고객사 비공개 정보)은 채널 적합성 경고.
• 근거 없는 수치나 불확실한 약속에는 반드시 조건/전제/[추정] 표기를 권장.

검증 시나리오

공통 3블록(빈 / 부분 / 풀 데이터)은 CONTRACT 6-1절 참조.

이 스킬의 고유 실패 시나리오

[데이터 결함] 수신자 프로필이 90일 이상 경과 (stale)

• 신호: .local.claude/people/{name}.md 또는 customers/*.md 의 updated 메타가 90일 초과
• 대응: 프로필을 참조하되 톤/선호 가정에 [stale 프로필] 태그 + "프로필 갱신 권장" 안내 + 민감 발언은 보수적 톤으로

[사용자 개입 필요] 수신자 미지정

• 신호: $ARGUMENTS 또는 대화에서 수신자 (사람/채널) 가 특정되지 않음
• 대응: 일반적 비즈니스 톤으로 초안 + 상단에 "수신자 확인 필요. 톤/경어 조정 요망" 알림 + AskUserQuestion 으로 수신자 확인