Menu
슬랙/메일/메신저로 받은 업무 요청 메시지를 분석하여 의도, 핵심 내용, 판단, 액션 플랜, 대응 가이드를 정리합니다.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
지정 디렉터리의 문서를 심층 분석하여 지식을 추출하고, 기존 문서 갱신 + 신규 문서 생성으로 프로젝트 지식 베이스에 반영합니다.
기술 의사결정 기록 (Architecture Decision Record). 중요한 기술적 결정의 맥락, 대안, 근거를 구조화하여 기록합니다.
현재 디렉터리의 내용을 분석하여 어떤 목적의 폴더인지 파악
비즈니스 규칙, 도메인 규칙, 상태 전이 규칙을 하나의 문서로 관리합니다. 변경 이력이 누적됩니다.
열린 질문, 문제 해결, 기술 의사결정, 아이디어 발산을 구조화합니다. 회의록이나 메모 파일 경로를 인자로 전달하거나 직접 질문하세요.
아침 브리핑. 최근 커밋을 분석하여 오늘 개발 시작 전에 알아야 할 변경 사항, 영향 범위, 주의 사항을 요약합니다.
| name | analyze-request |
| description | 슬랙/메일/메신저로 받은 업무 요청 메시지를 분석하여 의도, 핵심 내용, 판단, 액션 플랜, 대응 가이드를 정리합니다. |
| when_to_use | 이 요청 분석해줘, 무슨 뜻인지 봐줘, 받은 업무 요청 판단, 어떻게 대응하지. 발신 메시지 작성은 draft, 이슈 생성은 issue. |
| allowed-tools | Read, Write, Glob, Grep, Bash |
수행 단계:
핵심 원칙: 모호한 요청일수록 섣불리 진행하지 않는다. 재확인이 필요한 경우, 명확한 질문 초안을 제공하여 한 번의 확인으로 해결할 수 있게 한다.
톤: 실용적. 판단 명확. 핵심 우선.
| 데이터 | 경로 | 필수/선택 | 부재 시 동작 |
|---|---|---|---|
| 회사와 팀 컨텍스트 | CLAUDE.md (자동 로드) | 선택 | 일반 업무 가정으로 진행, 회사 고유 맥락 미반영 |
| 멤버 매핑 | .local.claude/team.md | 선택 | [요청자 불명확] 태그 유지 + 역할과 권한 추정 비움 ('검증 시나리오' 절의 graceful degrade) |
| 개인 프로필 | .local.claude/people/{닉네임}.md | 선택 | 깊은 협업 메모 없이 team.md 매핑만으로 진행 |
| 고객사 프로필 | .local.claude/customers/{name}.md | 선택 | 고객사 맥락 없이 분석, 임팩트는 정성 추정만 기록 |
| 이전 교환 이력 | .local.claude/**/analyze-request/*.md, .local.claude/**/draft/*.md | 선택 | "0. 맥락" 섹션 생략, 단발 분석으로 진행 |
| 현재 업무 목록 | .local.claude/daily/*, .local.claude/todo/* | 선택 | 2-1단계 스킵, 충돌 미반영 공수감만 제시 |
상세 사용법은 아래 프로젝트 컨텍스트와 멤버 참조 섹션 참조.
다음 파일이 존재하면 우선 read 하여 사용자, 팀, 고객 정보를 파악:
CLAUDE.md (자동 로드, 회사와 팀).local.claude/team.md 또는 .local.claude/people/*.md (팀원과 역할).local.claude/team.md (조직 구조 + 닉네임-실명-부서-대응톤 매핑).local.claude/people/*.md (개인 깊은 프로필, 있을 시).local.claude/customers/*.md (고객사, 있을 시)사용자가 처리 가능한 작업과 위임할 작업의 구분도 위 파일에서 추출. 정보 부족 시 사용자에게 직접 질문.
요청자 식별 시 아래 파일을 Read로 읽어 이름 또는 닉네임을 매핑한다.
| 문서 | 경로 | 용도 |
|---|---|---|
| 멤버 매핑 | .local.claude/team.md | 요청자 소속, 직군, 대응 톤 파악 |
| 개인 프로필 | .local.claude/people/{닉네임}.md (있을 시) | 깊은 협업 메모 |
매핑 전략:
요청이 어떤 채널로 들어왔는지에 따라 대응의 톤, 형식, 분량이 달라진다.
| 채널 | 특성 | 응답 톤 | 형식 | 분량 기준 |
|---|---|---|---|---|
| 이메일 | 공식, 기록 남음, 수신자 다수 가능 | 공식, 구조화 | 인사 + 본문 + 마무리 | 필요한 만큼 |
| 슬랙 채널 | 반공식, 다른 사람도 봄 | 반공식, 간결 | 핵심 먼저 + 스레드 활용 | 3~5줄 |
| DM | 비공식, 1:1 | 비공식, 빠르게 | 바로 본론 | 1~3줄 |
| 메신저 | 비공식~반공식 | 상황에 맞게 | 간결하게 | 1~5줄 |
| 전달형 | 정보 손실 위험 | 원래 요청자 확인 우선 | 맥락에 따라 | 맥락에 따라 |
채널 식별 단서:
대응 가이드 작성 시 식별된 채널에 맞는 형식으로 초안을 생성한다.
파일 경로가 제공된 경우 ($ARGUMENTS):
파일 경로가 없는 경우: 직접 입력된 요청 텍스트를 바로 분석한다.
[1M 활용] 다음을 단일 메시지에서 병렬 호출:
- Read:
.local.claude/team.md,.local.claude/people/{닉네임}.md(있을 시)- Grep (병렬):
.local.claude/**/analyze-request/*.md+.local.claude/**/draft/*.md에서 요청자 이름 + 키워드 동시 검색- Glob:
.local.claude/projects/*/analyze-request/*.md최근 파일
.local.claude/team.md 를 Read로 읽어 요청자를 특정한다.
.local.claude/team.md 참조)의 결정인지, 작업자/기획자 개인의 생각인지 구분. 의사결정 권한자의 요청이면 우선순위가 올라가고, 개인 의견이면 "이 요청의 배경을 확인해도 될까요?" 질문 필요.요청자 + 키워드로 이전 분석/초안 파일을 검색한다. 같은 건에 대한 이전 교환이 있으면 맥락을 수집하여 연속성 있는 분석을 수행한다.
.local.claude/**/analyze-request/*.md, .local.claude/**/draft/*.md.local.claude/projects/**/analyze-request/*.md, .local.claude/projects/**/draft/*.md매칭 기준: 요청자 일치 + 주제 키워드 2개 이상 겹침. 요청자만 같고 주제가 다르면 스킵. 이력 없으면: "0. 맥락" 섹션 생략. 분석에 영향 없음.
1) 문제 검증: 요청자의 진짜 문제가 뭔가?
2) 접근 방식 검증: 이 방법이 맞나?
3) 스코프 방어: 요청에 여러 건이 섞여있으면 분리 제안. "이것도 해주세요"가 기존 진행 중인 작업에 추가되는 형태면 "별개 요청으로 분리하는 게 좋겠습니다"라고 안내.
점검 결과를 판단 섹션(3번)의 "접근 방식" 항목에 반영.
요청 분석 시 아래 항목을 점검하여, 답을 알 수 있으면 분석에 반영하고, 모르면 재확인 질문에 포함한다. 이 정보가 있어야 후속 스킬(PRD/SRS/review/deploy-checklist)에서 빠짐없이 처리할 수 있다.
질문 수준 조절: 요청자가 누구인지에 따라 같은 내용이라도 질문 방식을 바꾼다.
[공통] 모든 요청 유형에서 확인:
.local.claude/customers/ 참조)[기술적 요청일 때 추가] 개발 요청/버그/분석에서 해당 시 (내부 요청자에게만 직접 질문, 외부 고객에게는 내부 분석으로 판단):
확인 가능한 항목은 판단(3번)과 액션 플랜(4번)에 반영. 확인 불가한 항목은 재확인 질문 초안에 포함.
아래 출력 구조에 따라 순서대로 분석한다.
공수감 산출 후, 현재 진행 중인 업무와의 충돌을 확인한다.
.local.claude/daily/ 최신 파일.local.claude/todo/ 또는 프로젝트별 todo파일이 없거나 업무 목록을 확인할 수 없으면: 이 단계를 스킵하고 공수감만 제시.
[메타인지] 판정 ([바로 진행 가능]/[재확인 필요]/[보류]/[리다이렉트]) 확정 직전, 핵심 판단 3건 (요청 유형, 판정, 착수 시점)에 대해:
- 근거 재점검 (요청 본문의 실제 문구 인용이 판정을 뒷받침하는가 vs 추측인가)
- 전제 검증 (요청자 직군, 채널, 의사결정 권한이 제대로 식별됐는가, team.md 매핑 증거로 확인)
- 반대 증거 ("왜 [재확인 필요]가 아닌 [바로 진행]인가? 공수감이 실제로 판단 가능한 근거 위에 서 있나?")
분석 완료 후 마크다운 파일로 저장한다.
요청 내용을 먼저 아래 유형으로 분류한 후, 유형별 판정 기준을 적용한다.
| 요청 유형 | 식별 패턴 | 판정 기준 | 비고 |
|---|---|---|---|
| 버그/장애 | "안 된다", "오류", "에러", 스크린샷 포함 | 증상 + 화면이 특정되면 바로 진행 | 기한 불필요 |
| 분석/파악 | "파악 부탁", "분석", "조사", "확인" | 기존 3가지 중 2개 충족 | 범위가 핵심 |
| 개발 요청 | "기능 추가", "수정", "개발", "구현" | 3가지 모두 필요 | 가장 엄격 |
| 단순 문의 | "이거 어떻게", "알려주세요", 질문형 | 질문이 명확하면 바로 답변 | 별도 판정 불필요 |
| 정보 공유 | "공유드립니다", "참고", "알려드립니다" | 액션 필요 여부만 판단 | 엣지케이스 확장 |
판정 기준 3가지 (분석/파악과 개발 요청에 적용):
비즈니스 임팩트 비교: 여러 요청이 동시에 있으면, 기술적 흥미도가 아닌 비즈니스 가치(매출 규모, 고객 영향, ROI)로 우선순위를 판단. 공수감 산출 시 "이 작업의 비즈니스 가치 대비 투입 공수가 적절한가?"를 함께 제시.
## 요청 분석: [요청 내용 한 줄 요약]
**요청자**: [이름 (닉네임)] / [소속] / [직군]
**채널**: 이메일 / 슬랙 채널 / DM / 메신저 / [알 수 없음]
**요청 유형**: 버그/장애 / 분석/파악 / 개발 요청 / 단순 문의 / 정보 공유
**분석 일시**: YYYY-MM-DD
---
### 0. 맥락 (이전 교환이 있을 때만 표시)
**이전 교환 이력** (thread: {ID}):
1. MM/DD [수신] 요청자: 요청 요약 (판정 결과)
2. MM/DD [발신] 사용자: 응답 요약 (/draft)
3. MM/DD [수신] 요청자: 이번 요청 (현재 분석 대상)
이전 교환과의 관계 한 줄 요약 (후속인지, 새로운 건인지, 맥락 변화가 있는지)
---
### 1. 의도 요약
요청자가 진짜 원하는 것을 1~2문장으로 정리.
표면적 요청 뒤에 숨은 본질적 작업이 있으면 함께 언급.
예: "파악 부탁"은 실제로는 분석 문서 산출물 작성이 필요할 수 있음.
---
### 2. 핵심 내용 추출
- 명시적 요구사항과 조건을 항목별로 정리
- 암시적으로 포함된 조건도 표시 (예: "{누락되기 쉬운 항목} 포함해서 전체"라면 원래 빠질 뻔한 범위까지 포함)
- 전달형 요청이면 정보 손실 가능성 표시
- 이전 교환이 있으면 이번 요청에서 변경/추가된 내용을 별도 표시
---
### 3. 판단
**[바로 진행 가능] / [재확인 필요] / [보류] / [리다이렉트]**
**요청 유형**: [분류된 유형]
유형별 판정 기준 적용 결과를 명시.
**재확인 필요 시** 빠진 정보별로:
- 무엇이 빠졌는가
- 왜 확인해야 하는가
- 확인하지 않으면 어떤 문제가 생기는가
**보류 시** 사유:
- 현재 진행 중인 업무: [업무명]
- 착수 가능 시점: [날짜 또는 조건]
**리다이렉트 시** 사유:
- 본인 업무가 아닌 부분: [내용]
- 적합한 담당자: [이름(닉네임)], [이유]
- 또는 범위가 과도한 경우: 스코프 축소 제안
**착수 가능 시점**: [즉시 / X일 이후 / 조건부] (2-1단계 결과 반영)
---
### 4. 액션 플랜
사용자가 실제로 해야 할 작업을 순서대로 나열.
재확인이 필요한 경우에도 "확인 후 이렇게 진행" 잠정 순서를 제시.
**협업 판단**:
- 사용자 단독 처리 가능
- 사용자가 메인, [담당자] 협조 필요. [누구에게 무엇을 받아야 하는지]
- [담당자]에게 넘기거나 함께 진행해야 하는 작업: [이유]
**공수감**: 소(반나절 이내) / 중(1~3일) / 대(1주 이상) / 판단 불가(범위 확인 필요)
근거: [추정 근거]
---
### 5. 대응 가이드
판정 결과와 채널에 따라 해당하는 항목의 초안을 작성한다.
#### [바로 진행 가능] 시
**착수 알림 초안** ({채널} 형식):
> [채널에 맞는 톤과 형식으로 작성]
> 핵심: 확인했다 + 언제까지 한다 + 궁금한 점 있으면 말해달라
**완료 후 회신 가이드**:
- 완료 사항 요약
- 산출물 위치 또는 전달 방법
- 추가 확인 필요 사항 (있으면)
#### [재확인 필요] 시
**질문 초안** ({채널} 형식):
> [채널에 맞는 톤과 형식으로 작성]
> 선택지나 예시를 포함하여 상대가 부담 없이 답할 수 있게.
> 한 번의 답변으로 해결 가능한 수준의 질문.
#### [보류] 시
**보류 안내 초안** ({채널} 형식):
> [채널에 맞는 톤과 형식으로 작성]
> 핵심: 확인했다 + 현재 OOO 진행 중 + X일 이후 착수 가능 + 급하면 알려달라
#### [리다이렉트/스코프 협상] 시
**담당자 안내 초안** (본인 업무가 아닌 경우):
> [채널에 맞는 톤으로]
> 핵심: 이 부분은 [담당자]가 적합하다 + 이유 + 내가 도울 수 있는 부분은 [범위]
**스코프 축소 제안 초안** (범위가 과도한 경우):
> [채널에 맞는 톤으로]
> 핵심: 전체 범위는 [공수] + 우선순위 높은 [부분]부터 진행하면 [기간] + 나머지는 후속으로
예: "OO님 이거 급해요 확인 부탁"
예: "어제 OOO님이 말한 건데요"
예: "내일 미팅 있어요", "이번 주 OOO 배포 예정이에요"
두 가지 해석을 모두 제시:
어느 쪽인지 확인하는 질문 초안 제공.
분석 완료 후 반드시 마크다운 파일로 저장한다.
Frontmatter (CONTRACT 7-2절 표준 + thread, prev, requester, channel, request_type, verdict, type): category: project-docs, retention: project-end, thread: {주제-키워드}, prev: {이전 파일명, 있으면}, requester: {요청자 닉네임}, channel: {이메일|슬랙|DM|메신저}, request_type: {버그/장애|분석/파악|개발요청|단순문의|정보공유}, verdict: {바로진행|재확인|보류|리다이렉트}, type: analyze-request
thread 결정 기준:
{주제}-{키워드} 형태로 생성 (예: {도메인}-분석, {모듈}-버그)ls .local.claude/projects/로 기존 프로젝트 확인.local.claude/projects/{project-name}/analyze-request/YYYY-MM-DD-{요청요약}.md.local.claude/analyze-request/YYYY-MM-DD-{요청요약}.mdmkdir -p로 생성분석 완료 후 상황에 맞는 다음 스킬 안내:
/draft (분석 결과 기반 초안 작성, 같은 thread로 연결)/cs (분석 파일 경로 전달)/cs 다음에 /draft 체이닝/daily-todos로 작업 추가/prd (요청 분석 파일 경로 전달)/meeting-notes/todo 또는 /srs/brainstorm이 세 스킬은 thread 기반으로 서로 연결되지만 무한 루프 방지 규칙:
prev 파일을 명시적으로 전달하고, 이전 교환 횟수가 3건을 초과하면 "thread 종결 필요, 새 요청으로 재분류" 경고| 질문 | 담당 | 이 스킬 |
|---|---|---|
| 분석 결과 기반 회신과 답장 메시지 초안 작성 | /draft | [다루지 않음] |
| 장애와 버그 신고("안 된다" 계열) 대응 정리 | /cs | [다루지 않음] |
| 하루 업무와 이슈 브리핑 종합 | /briefing | [다루지 않음] |
| 받은 요청 메시지의 의도, 판정, 액션 플랜 분석 | 이 스킬 | [핵심] |
team.md 가 있으면 Read로 읽어 요청자를 확인한 후 분석한다 (부재 시 '검증 시나리오' 절의 graceful degrade).team.md 대응 톤 가이드 및 채널별 대응 가이드 참조.공통 3블록(빈 / 부분 / 풀 데이터)은 CONTRACT 6-1절 참조.
[의존성 부재] team.md 없음
[요청자 불명확] 태그 유지 + 요청자 역할과 권한 추정 섹션 비움, 기획/영업 문의 안내[사용자 개입 필요] 비즈니스 임팩트 정보원 불명확