Menu
상대방에게 전달할 메시지나 보고를 작성 전에 검토하고, 수신자에 맞는 톤, 구조, 내용으로 가공합니다. 비즈니스/도메인 정확성도 검증합니다.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
지정 디렉터리의 문서를 심층 분석하여 지식을 추출하고, 기존 문서 갱신 + 신규 문서 생성으로 프로젝트 지식 베이스에 반영합니다.
기술 의사결정 기록 (Architecture Decision Record). 중요한 기술적 결정의 맥락, 대안, 근거를 구조화하여 기록합니다.
현재 디렉터리의 내용을 분석하여 어떤 목적의 폴더인지 파악
슬랙/메일/메신저로 받은 업무 요청 메시지를 분석하여 의도, 핵심 내용, 판단, 액션 플랜, 대응 가이드를 정리합니다.
비즈니스 규칙, 도메인 규칙, 상태 전이 규칙을 하나의 문서로 관리합니다. 변경 이력이 누적됩니다.
열린 질문, 문제 해결, 기술 의사결정, 아이디어 발산을 구조화합니다. 회의록이나 메모 파일 경로를 인자로 전달하거나 직접 질문하세요.
| name | draft |
| description | 상대방에게 전달할 메시지나 보고를 작성 전에 검토하고, 수신자에 맞는 톤, 구조, 내용으로 가공합니다. 비즈니스/도메인 정확성도 검증합니다. |
| when_to_use | 이거 보낼 메시지 다듬어줘, 보고 초안 써줘, 이렇게 회신하면 될까, 톤 검토. 받은 요청 분석은 analyze-request. |
| allowed-tools | Read, Write, Glob, Grep, Bash |
외부-가시 문서:
rules/external-doc.md10원칙 준수. 전달 초안은 본질적으로 외부 독자 대상. 내부 경로와 상수명 금지, Outside-in 서술, 스캔 가능성 우선(표 > 불릿 > 산문).
사용자가 상대방에게 전달할 내용을 정리하면, 수신자에 맞는 톤, 구조, 언어로 가공하고, 비즈니스/도메인 오류까지 검증하여 바로 보낼 수 있는 초안을 만든다.
/analyze-request가 "들어온 요청을 해석"하는 스킬이라면,
/draft는 **"나가는 메시지를 구성"**하는 스킬.
수행 단계:
핵심 원칙: 상대가 읽고 한 번에 이해하고 행동할 수 있는 메시지를 만든다. 추가 질문 없이 바로 진행 가능한 수준.
톤: 사용자 말투 존중. 전달력 우선.
| 질문 | 담당 | 이 스킬에서 |
|---|---|---|
| 들어온 요청을 해석하고 분류 (나가는 게 아니라 받는 것) | /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 하여 사용자, 팀, 수신자 정보를 파악:
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 {수신자} | 수신자 지정, 형식: 보고서 |
수신자가 불명확하면 질문. 내용은 대화 맥락 + 인자에서 종합.
| 항목 | 설명 | 없으면 |
|---|---|---|
| 수신자 | 누구에게? (team.md 에서 직군과 톤 확인) | 질문 |
| 채널 | 슬랙 / 이메일 / 보고서 / 구두 브리핑 | 맥락에서 추론 (기본: 슬랙) |
| 목적 | 공유 / 요청 / 보고 / 제안 / 답변 | 내용에서 추론 |
| 긴급도 | 즉시 / 오늘 중 / 여유 | 맥락에서 추론 |
사용자의 raw 입력(대화 맥락, 인자, 파일)에서 전달할 핵심 내용을 추출:
[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 일반화 오류 감지
전달할 내용에 사실 오류가 없는지 검증한다. 사용자의 신뢰를 지키는 핵심 단계.
biz-rules.md 규칙에 맞는지 (예: "결재 완료 후 수정 가능"이라고 썼지만 실제로는 불가)bot/INDEX.md 또는 .local.claude/ONBOARDING.md 와 일치하는지.local.claude/daily/의 이전 회고에서 다른 말을 했는데 지금 내용과 모순되진 않는지검증 결과는 출력의 "검증 메모" 섹션에 기록.
채널과 수신자에 맞게 초안을 작성한다.
**[목적 태그]** 한 줄 요약
본문 (2~5줄):
- 핵심 내용
- 필요한 맥락 (수신자가 모를 수 있는 배경)
- 요청 사항 또는 다음 행동 (있으면)
---
참고: 관련 파일/PR 링크 (있으면)
## [제목]
### 요약
1~2문장. 경영진도 이것만 읽으면 핵심을 파악할 수 있는 수준.
### 현황/배경
왜 이 보고/제안이 필요한지. 수신자가 모를 수 있는 맥락 포함.
### 분석/내용
구체적 내용. 기술적 내용은 수신자 직군에 맞게 번역.
### 선택지 (제안/의사결정이 필요한 경우)
| 구분 | 방안 A (추천) | 방안 B |
|------|----------------|--------|
| 내용 | ... | ... |
| 장점 | ... | ... |
| 단점 | ... | ... |
| 소요 | ... | ... |
| 리스크 | ... | ... |
단일안만 있으면 대안이 없는 이유를 함께 설명.
(CLAUDE.md '문제 해결 방안 제시 원칙' 참조)
### 요청 사항 / 다음 단계
수신자에게 필요한 액션. 구체적으로.
[메타인지] 초안 완성 후 자기 검증:
- 근거 재점검: 각 주장, 수치, 약속에 근거(측정, biz-rules, 이전 기록)가 있는가? 근거 없는 수치는 [추정] 태그가 붙어 있는가?
- 전제 검증: 초안이 유효하려면 수신자의 어떤 사전 지식과 맥락이 필요한가? 그 전제가 실제로 성립하는가?
- 반대 증거: "이대로 전달 시 수신자가 오해할 여지는?" 반박 1개 이상 생성 후 초안에 반영
| 검토 항목 | 기준 |
|---|---|
| 핵심 명확성 | "한 문장으로 요약하면?"에 답할 수 있는가 |
| 수신자 적합성 | 이 사람이 읽었을 때 바로 이해하고 행동할 수 있는가 |
| 톤 적합성 | team.md 의 대응 톤 가이드에 맞는가 |
| 도메인 정확성 | 비즈니스 규칙, 모듈 관계, 용어가 정확한가 |
| 수치 근거 | 언급한 수치에 근거가 있는가 |
| 약속 현실성 | 일정/기능 약속이 의존성을 고려한 것인가 |
| 히스토리 일관성 | 이전 발언/결정과 모순되지 않는가 |
| 빠진 맥락 | 수신자가 "이게 무슨 뜻이지?" 할 만한 부분이 없는가 |
| 불필요한 내용 | 수신자가 알 필요 없는 디테일이 들어있진 않은가 |
| 액션 명확성 | 수신자가 뭘 해야 하는지 명확한가 |
## 전달 초안: [제목 요약]
**수신자**: [이름(닉네임)] ([직군])
**채널**: 슬랙 / 이메일 / 보고서
**목적**: 공유 / 요청 / 보고 / 제안 / 답변
---
### 초안
[초안 본문. 채널에 맞는 형식]
---
### 검증 메모
도메인/비즈니스 정확성 검증 결과.
- [OK] 상태 전이 규칙: 정확 (biz-rules.md 확인)
- [OK] 모듈 관계: {모듈A}에서 {모듈B}로의 이벤트 흐름 정확
- [WARN] 일정 약속: "3일이면 가능"은 기획 확정 의존성 미반영. "기획 확정 후 3일" 권장
- [WARN] 수치: "처리 건수 500건"에 [추정] 표기 추가 권장. 실 데이터 확인 필요
- [FAIL] 용어 오류: 도메인 약어 오용을 CLAUDE.md 의 정확한 약어로 수정 반영
### 검토 메모
전달력/형식 검토 결과.
- [OK] 핵심 명확: 첫 줄에 결론 포함
- [OK] 톤 적합: 기획팀 대상 비기술적 언어 사용
- [WARN] 빠진 맥락: 수신자가 이전 미팅 내용을 모를 수 있음. 배경 한 줄 추가
- **제안**: 이 내용은 제퍼에게도 CC하면 좋겠습니다
수신자의 직군이 다르면 (예: 기획 + 개발) 가장 비기술적인 수준에 맞춤. 기술 세부는 별도 스레드나 첨부로 분리 제안.
장애 보고, 일정 지연, 기능 불가 등:
/analyze-request 직후 호출 시:
/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.local.claude/projects/{project-name}/draft/YYYY-MM-DD-{제목요약}.md.local.claude/draft/YYYY-MM-DD-{제목요약}.mdmkdir -p로 생성| 채널 | 임계 1 (알림) | 임계 2 (강제 분리) |
|---|---|---|
| 슬랙/메신저 | 5줄 초과 | 핵심 3줄 + 상세는 스레드/첨부로 분리 |
| 이메일/보고서 | 1화면 초과 | 요약(TL;DR) 상단 + 본문 절 분리 |
/cs, /review, /briefing/analyze-request (같은 thread로 연결됨)/issue, /prrules/external-doc.md (가독성 5 + 정직성 5). 전달 초안은 본질적으로 외부 독자 대상.공통 3블록(빈 / 부분 / 풀 데이터)은 CONTRACT 6-1절 참조.
[데이터 결함] 수신자 프로필이 90일 이상 경과 (stale)
.local.claude/people/{name}.md 또는 customers/*.md 의 updated 메타가 90일 초과[stale 프로필] 태그 + "프로필 갱신 권장" 안내 + 민감 발언은 보수적 톤으로[사용자 개입 필요] 수신자 미지정