analyze-request

name	analyze-request
description	슬랙/메일/메신저로 받은 업무 요청 메시지를 분석하여 의도, 핵심 내용, 판단, 액션 플랜, 대응 가이드를 정리합니다.
when_to_use	이 요청 분석해줘, 무슨 뜻인지 봐줘, 받은 업무 요청 판단, 어떻게 대응하지. 발신 메시지 작성은 draft, 이슈 생성은 issue.
allowed-tools	Read, Write, Glob, Grep, Bash

역할

수행 단계:

1. 요청자를 식별하고 직군에 맞는 맥락을 파악
2. 채널(이메일/슬랙/DM/메신저)을 식별하고 채널 특성에 맞는 대응 방식을 결정
3. 이전 교환 이력이 있으면 맥락을 수집하여 연속성 있는 분석을 수행
4. 요청의 표면적 내용 뒤에 있는 본질적 작업을 파악
5. 요청 유형에 맞는 판정 기준으로 바로 진행/재확인/보류/리다이렉트를 판정
6. 사용자가 직접 처리할 범위와 다른 담당자에게 넘겨야 할 범위를 구분
7. 현재 업무 부하를 고려한 착수 가능 시점을 제시
8. 상대의 직군, 말투, 채널에 맞는 대응 메시지 초안 제공

핵심 원칙: 모호한 요청일수록 섣불리 진행하지 않는다. 재확인이 필요한 경우, 명확한 질문 초안을 제공하여 한 번의 확인으로 해결할 수 있게 한다.

톤: 실용적. 판단 명확. 핵심 우선.

외부 데이터 의존

데이터	경로	필수/선택	부재 시 동작
회사와 팀 컨텍스트	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)

다음 파일이 존재하면 우선 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줄
전달형	정보 손실 위험	원래 요청자 확인 우선	맥락에 따라	맥락에 따라

채널 식별 단서:

• 이메일: "안녕하세요" 인사, 줄바꿈 구조, 서명, 수신/참조자 명시
• 슬랙 채널: 짧은 문장, 멘션(@), 이모지, 스레드 참조
• DM: 1:1 톤, 격식 없음, "OO님" 호칭 직접 사용
• 전달형: "어제 OOO님이 말한 건데", "전달드립니다"

대응 가이드 작성 시 식별된 채널에 맞는 형식으로 초안을 생성한다.

입력 처리

파일 경로가 제공된 경우 ($ARGUMENTS):

1. Read로 파일을 읽는다 (슬랙 메시지 복사본, 이메일 본문 등)
2. 내용을 분석하여 출력 구조에 따라 출력

파일 경로가 없는 경우: 직접 입력된 요청 텍스트를 바로 분석한다.

프로세스

[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 최근 파일

1단계: 요청자 식별

.local.claude/team.md 를 Read로 읽어 요청자를 특정한다.

• 이름/닉네임이 있으면 소속, 직군, 대응 톤 확인
• 없으면 내용에서 추론 (고객사 언급, 직군 특유의 표현 패턴 등)
• 전달형 요청 ("어제 OOO님이 말한 건데")이면 원래 요청자와 전달자를 분리
• 의사결정 권한 확인: 이 요청이 의사결정 권한자(직책과 조직 매핑은 .local.claude/team.md 참조)의 결정인지, 작업자/기획자 개인의 생각인지 구분. 의사결정 권한자의 요청이면 우선순위가 올라가고, 개인 의견이면 "이 요청의 배경을 확인해도 될까요?" 질문 필요.

1-1단계: 이전 교환 이력 조회

요청자 + 키워드로 이전 분석/초안 파일을 검색한다. 같은 건에 대한 이전 교환이 있으면 맥락을 수집하여 연속성 있는 분석을 수행한다.

1. Grep으로 analyze-request/ + draft/ 양쪽에서 요청자 이름 검색
   • 대상: .local.claude/**/analyze-request/*.md, .local.claude/**/draft/*.md
   • 프로젝트 디렉터리 포함: .local.claude/projects/**/analyze-request/*.md, .local.claude/projects/**/draft/*.md
2. 같은 요청자 + 유사 주제(키워드 매칭) 파일을 시간순 정렬
3. 최근 3건까지만 frontmatter + 의도 요약 읽기 (전부 읽으면 컨텍스트 낭비)
4. 관련 이력이 있으면 출력의 "0. 맥락" 섹션에 요약

매칭 기준: 요청자 일치 + 주제 키워드 2개 이상 겹침. 요청자만 같고 주제가 다르면 스킵. 이력 없으면: "0. 맥락" 섹션 생략. 분석에 영향 없음.

Step 0: 멈추고 생각하기 (수용 전에)

1) 문제 검증: 요청자의 진짜 문제가 뭔가?

• "왜 이게 필요한가?" 먼저 확인: "X 기능 추가해주세요"는 솔루션(How)이지 문제(What)가 아니다. "왜 X가 필요한가?"를 물어야 진짜 문제가 드러남. 특히 IT를 조금 아는 요청자가 구현 방법까지 지정할 때 빈발.
• 부산물 아닌가? 이 요청은 다른 곳의 문제에서 파생된 것일 수 있다. 근본을 해결하면 이 요청 자체가 불필요해지지 않나?

2) 접근 방식 검증: 이 방법이 맞나?

• 이미 있는 기능으로 안 되나? 요청자가 모르는 기존 기능이 있을 수 있다. "이미 ~에서 가능합니다"가 최고의 답일 수 있음.
• 이 규모가 맞나? "기능 개발"처럼 보이지만 실은 설정 변경 1건, 데이터 패치 1건으로 끝나는 건 아닌가?
• 비기술적 해결은? 사용 가이드 안내, 프로세스 변경으로 끝나는 건 아닌가?

3) 스코프 방어: 요청에 여러 건이 섞여있으면 분리 제안. "이것도 해주세요"가 기존 진행 중인 작업에 추가되는 형태면 "별개 요청으로 분리하는 게 좋겠습니다"라고 안내.

점검 결과를 판단 섹션(3번)의 "접근 방식" 항목에 반영.

1-2단계: 다운스트림 스킬을 위한 사전 확인

요청 분석 시 아래 항목을 점검하여, 답을 알 수 있으면 분석에 반영하고, 모르면 재확인 질문에 포함한다. 이 정보가 있어야 후속 스킬(PRD/SRS/review/deploy-checklist)에서 빠짐없이 처리할 수 있다.

질문 수준 조절: 요청자가 누구인지에 따라 같은 내용이라도 질문 방식을 바꾼다.

• 내부 개발자/기획팀: 기술 용어 그대로 ("DB 스키마 변경 필요한가요?")
• 외부 고객/비기술 직군: 업무 언어로 번역 ("현재 관리하시는 항목 외에 새로 추가해야 하는 정보가 있나요?") 재확인 질문 초안 작성 시 1단계에서 식별한 요청자 직군과 채널에 맞춰 톤을 조절한다.

[공통] 모든 요청 유형에서 확인:

• 현재 이 문제의 빈도/영향 규모를 아는가? (모르면 측정/로깅이 선행되어야 할 수 있음)
  • 외부 고객에게: "이 상황이 얼마나 자주 발생하나요?" / "영향받는 분이 몇 분 정도 되시나요?"
• 적용 범위가 전체 대상인가, 특정 대상만인가? (고객사 구분이 있는 프로젝트는 .local.claude/customers/ 참조)
• 이 기능/시스템이 안 되면 현업이 멈추나? (업무 연속성, 비상 탈출구 필요 여부)
  • 외부 고객에게: "이게 안 되면 업무가 중단되나요, 아니면 다른 방법으로 처리 가능한가요?"
• 이 변경은 되돌릴 수 있나? (스키마 삭제, 데이터 마이그레이션 등 비가역 변경 여부)

[기술적 요청일 때 추가] 개발 요청/버그/분석에서 해당 시 (내부 요청자에게만 직접 질문, 외부 고객에게는 내부 분석으로 판단):

• DB 스키마 변경이 필요한가? (컬럼/타입 추가는 운영 DB 반영 필요)
• 공통 코드 (코드 테이블) 추가가 필요한가?
• 외부 시스템 연동이 있나? (새 연동 vs 기존 변경, 타임아웃/IP 화이트리스트/CORS)
• 프로젝트 기능 플래그 에 의존하는가?
• 다른 모듈에 영향을 주는 상태 변경/이벤트 발행이 있나?

확인 가능한 항목은 판단(3번)과 액션 플랜(4번)에 반영. 확인 불가한 항목은 재확인 질문 초안에 포함.

2단계: 6개 섹션 분석 및 출력

아래 출력 구조에 따라 순서대로 분석한다.

2-1단계: 현재 업무 상황 확인

공수감 산출 후, 현재 진행 중인 업무와의 충돌을 확인한다.

1. Glob으로 최근 daily-todos, todo 파일 확인
   • .local.claude/daily/ 최신 파일
   • .local.claude/todo/ 또는 프로젝트별 todo
2. 현재 업무 목록과 이번 요청의 공수를 대조
3. 판단 섹션의 "착수 가능 시점"에 반영
4. 충돌이 크면 판정을 **[보류]**로 조정하고, 보류 안내 초안 제공

파일이 없거나 업무 목록을 확인할 수 없으면: 이 단계를 스킵하고 공수감만 제시.

[메타인지] 판정 ([바로 진행 가능]/[재확인 필요]/[보류]/[리다이렉트]) 확정 직전, 핵심 판단 3건 (요청 유형, 판정, 착수 시점)에 대해:

1. 근거 재점검 (요청 본문의 실제 문구 인용이 판정을 뒷받침하는가 vs 추측인가)
2. 전제 검증 (요청자 직군, 채널, 의사결정 권한이 제대로 식별됐는가, team.md 매핑 증거로 확인)
3. 반대 증거 ("왜 [재확인 필요]가 아닌 [바로 진행]인가? 공수감이 실제로 판단 가능한 근거 위에 서 있나?")

3단계: 파일 저장

분석 완료 후 마크다운 파일로 저장한다.

요청 유형 분류

요청 내용을 먼저 아래 유형으로 분류한 후, 유형별 판정 기준을 적용한다.

요청 유형	식별 패턴	판정 기준	비고
버그/장애	"안 된다", "오류", "에러", 스크린샷 포함	증상 + 화면이 특정되면 바로 진행	기한 불필요
분석/파악	"파악 부탁", "분석", "조사", "확인"	기존 3가지 중 2개 충족	범위가 핵심
개발 요청	"기능 추가", "수정", "개발", "구현"	3가지 모두 필요	가장 엄격
단순 문의	"이거 어떻게", "알려주세요", 질문형	질문이 명확하면 바로 답변	별도 판정 불필요
정보 공유	"공유드립니다", "참고", "알려드립니다"	액션 필요 여부만 판단	엣지케이스 확장

판정 기준 3가지 (분석/파악과 개발 요청에 적용):

1. 작업 범위가 특정되어 있는가 (대상, 경계가 명확한가)
2. 산출물 형태가 파악 가능한가 (명시 또는 합리적 추론 가능)
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)와 전달자를 분리하여 각각 표시.
• 전달 과정에서 정보 손실 가능성을 판단 섹션에 명시.
• 필요하면 "원래 요청자에게 직접 확인이 필요"를 액션 플랜에 포함.

요청인지 정보 공유인지 모호한 경우

예: "내일 미팅 있어요", "이번 주 OOO 배포 예정이에요"

두 가지 해석을 모두 제시:

• 해석 A: 정보 공유. 사용자의 후속 액션 명시 (캘린더 등록, 영향도 체크, 준비 사항 등)
• 해석 B: 특정 요청 포함. [추정 내용]

어느 쪽인지 확인하는 질문 초안 제공.

파일 저장

분석 완료 후 반드시 마크다운 파일로 저장한다.

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 결정 기준:

• 이전 교환 이력이 있고 같은 건이면 기존 thread 유지
• 새로운 건이면 {주제}-{키워드} 형태로 생성 (예: {도메인}-분석, {모듈}-버그)
• prev는 같은 thread의 직전 파일명 (analyze-request 또는 draft 모두 가능)

프로젝트 연관 판단

1. 요청 내용이 특정 프로젝트와 관련되면 해당 프로젝트 디렉터리
2. ls .local.claude/projects/로 기존 프로젝트 확인
3. 해당 없으면 독립 저장

저장 경로

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

저장 시점

• 분석 완료 시 자동 저장
• 저장 후 파일 경로 안내

다음 스킬 연결

분석 완료 후 상황에 맞는 다음 스킬 안내:

• 답장/회신이 필요하면 /draft (분석 결과 기반 초안 작성, 같은 thread로 연결)
• 장애/버그 신고, "안 된다" 계열이면 /cs (분석 파일 경로 전달)
• CS 후 고객 응대가 필요하면 /cs 다음에 /draft 체이닝
• 작업이 시스템 분석/파악이면 직접 코드 탐색 시작, 완료 후 /daily-todos로 작업 추가
• 기획 문서 작성으로 이어지면 /prd (요청 분석 파일 경로 전달)
• 회의/미팅 내용이 포함되어 있으면 /meeting-notes
• 개발 작업 목록이 필요하면 /todo 또는 /srs
• 아이디어 발산이 필요하면 /brainstorm

순환 참조 탈출 조건 (analyze-request, cs, draft 상호 간)

이 세 스킬은 thread 기반으로 서로 연결되지만 무한 루프 방지 규칙:

• 같은 thread 에서 analyze-request, cs, draft 순서로 한 번 완주 시 종료 기본값 (다시 analyze-request 호출 금지)
• 재호출이 필요하면 prev 파일을 명시적으로 전달하고, 이전 교환 횟수가 3건을 초과하면 "thread 종결 필요, 새 요청으로 재분류" 경고
• analyze-request 자체 재귀는 금지 (같은 thread 에서 analyze-request 2회 호출 불가)

다른 스킬과의 경계

질문	담당	이 스킬
분석 결과 기반 회신과 답장 메시지 초안 작성	/draft	[다루지 않음]
장애와 버그 신고("안 된다" 계열) 대응 정리	/cs	[다루지 않음]
하루 업무와 이슈 브리핑 종합	/briefing	[다루지 않음]
받은 요청 메시지의 의도, 판정, 액션 플랜 분석	이 스킬	[핵심]

제약조건

• team.md 가 있으면 Read로 읽어 요청자를 확인한 후 분석한다 (부재 시 '검증 시나리오' 절의 graceful degrade).
• 요청자가 불명확해도 건너뛰지 않는다. [요청자 불명확]으로 표시하고 판단에 반영.
• 요청 유형을 먼저 분류하고, 유형별 판정 기준을 적용한다. 모든 유형에 동일 기준 적용 금지.
• 재확인 질문은 선택지나 예시를 포함하여 한 번의 답변으로 해결 가능하게.
• 협업 판단에서 "사용자 단독"으로 처리할 수 없는 작업은 담당자와 이유를 명시.
• 공수감은 근거와 함께 제시. "판단 불가"도 이유를 설명.
• 대응 메시지 톤은 요청자의 직군과 말투 + 채널 특성을 함께 반영. team.md 대응 톤 가이드 및 채널별 대응 가이드 참조.
• 비동기 커뮤니케이션 원칙: 요청에 바로바로 응답하지 않아도 된다. 장애가 아닌 이상 비동기로 처리 가능하도록 대응 초안을 구성한다. "확인했습니다. X일까지 검토 후 공유드리겠습니다" 형태가 기본.
• 요청 텍스트가 길어도 의도 요약을 가장 먼저, 부가 정보는 뒤에 배치.
• 이전 교환 이력 조회는 최근 3건으로 제한. 전부 읽지 않는다.
• 스레드 연결 시 요청자 + 키워드 2개 이상 매칭을 기준으로 한다. 요청자만 같고 주제가 다르면 별도 스레드.

검증 시나리오

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

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

[의존성 부재] team.md 없음

• 신호: 요청자 식별에 필요한 팀 구성 파일 부재
• 대응: [요청자 불명확] 태그 유지 + 요청자 역할과 권한 추정 섹션 비움, 기획/영업 문의 안내

[사용자 개입 필요] 비즈니스 임팩트 정보원 불명확

• 신호: 매출, 고객 수, SLA 영향 등을 판단할 출처(고객 프로필, 계약, OKR) 없음
• 대응: 기획/영업에 직접 문의 안내. "임팩트 정량화는 비즈니스팀 확인 필요, 현재는 정성 추정만 기록"