버그 조사 스킬. 가설 3개를 먼저 세우고, 각각을 검증한 뒤, 사용자 승인 전까지 프로덕션 코드를 수정하지 않는 읽기 전용(freeze) 조사 모드. 이 스킬은 investigate, 버그, bug, debug, 조사, 디버깅, error, crash, 장애, incident, "왜 이러지", "원인 파악", "에러 나는데", "뭐가 문제야", "왜 실패하지", "이거 왜 안 돼", root cause, 근본 원인, "디버그 해줘" 등 버그/에러/장애 조사가 필요한 모든 상황에서 반드시 사용해야 한다. 테스트 실패를 보고 바로 코드를 수정하려 하기보다 먼저 이 스킬로 원인을 조사하라. mstack SDLC 파이프라인에서 /qa 실패 시 호출되며, 수정 후 /qa로 돌아간다.
파이프라인 위치: plan → review → ship → qa → [investigate] → retro
조사 모드에서는 프로덕션 코드를 수정하지 않는다.
테스트 파일이나 디버그 스크립트는 생성할 수 있지만,
src/, lib/, app/ 등 프로덕션 디렉토리의 파일은 읽기만 한다.
이 규칙이 존재하는 이유: 원인을 정확히 파악하기 전에 코드를 수정하면 증상만 가리고 근본 원인을 놓치는 경우가 많다.
사용자가 "수정해", "fix it" 등으로 명시적으로 요청하면 freeze를 해제한다.
git log --oneline -10)반드시 3개의 가설을 세운다. 1개만 세우면 확증 편향에 빠지기 쉽다.
## 가설
### H1: [가장 가능성 높은 원인]
근거: ...
검증 방법: ...
### H2: [두 번째 가능성]
근거: ...
검증 방법: ...
### H3: [덜 명백하지만 가능한 원인]
근거: ...
검증 방법: ...
가설은 구체적이어야 한다. "코드가 잘못됐다"는 가설이 아니다.
"parse_date()가 timezone-naive datetime을 반환하여 UTC 비교에서 실패한다"가 가설이다.
각 가설에 대해:
tests/debug/ 아래에 가설을 검증하는 테스트를 만든다# 읽기 전용 — 소스 코드 분석
grep -rn "parse_date" src/
git log --all -p -- src/utils/date.py # 최근 변경 히스토리
# Investigation Report
Date: YYYY-MM-DD
Bug: [한줄 설명]
## 증상
- 에러: ...
- 재현: ...
## 가설 검증 결과
### H1: [가설] → ✅ 확인 / ❌ 반증
증거: ...
### H2: [가설] → ✅ 확인 / ❌ 반증
증거: ...
### H3: [가설] → ✅ 확인 / ❌ 반증
증거: ...
## 근본 원인
[확인된 가설 기반 상세 설명]
## 수정 제안
1. [구체적 수정 방법]
2. [회귀 방지 테스트]
3. [유사 패턴 다른 위치 점검]
## 수정 대기
⚠️ 프로덕션 코드 미수정 상태. 승인 후 수정 진행.
사용자가 승인하면:
Agent Teams 모드에서는 .claude-prompts/03-debug.md의 팀 구성을 활용:
수정 완료 후:
"수정 적용 완료.
/qa로 회귀 테스트를 실행하시겠습니까?"
/careful 활성화 시 freeze가 더 엄격해진다:
tests/debug/ 외의 모든 파일 쓰기가 차단됨