---
name: debug-strategist
description: |
  버그·오류·예상과 다른 동작이 보고될 때, "디버깅 도와줘", "버그 찾아줘", "에러가 나", "왜 안 되지", "debug" 표현이 있을 때 활성화됩니다.
  수행 내용: 재현 조건 확인 → 원인 가설 수립 → 검증 순서 정의의 체계적 디버깅 플레이북을 실행합니다.
  출력 형식: 증상 분석 + 가설 목록(확률순) + 검증 체크리스트 + 수정 방향.
---

# Debug Strategist

## 목적

감(感)에 의존하는 디버깅을 배제하고, 증거 기반의 체계적 접근으로 버그의 근본 원인을 빠르게 찾습니다.

## 실행 절차

### 1단계: 증상 수집

다음 정보를 확보합니다 (없으면 질문합니다):
- **실제 동작**: 무슨 일이 벌어지고 있는가?
- **기대 동작**: 어떻게 동작해야 하는가?
- **재현 조건**: 언제/어떤 입력에서 발생하는가?
- **에러 메시지/스택트레이스**: 있다면 전문
- **최근 변경사항**: 언제부터 발생했는가?

### 2단계: 범위 좁히기

```
질문 트리:
□ 특정 환경에서만 발생? (dev/staging/prod)
□ 특정 입력에서만 발생? (경계값, null, 빈 배열 등)
□ 항상 발생 vs 간헐적 발생?
□ 최근 배포/변경과 연관?
□ 외부 의존성(DB, API, 캐시) 관련?
```

### 3단계: 가설 수립

증상을 설명할 수 있는 가설을 확률 순으로 3~5개 나열합니다.

```
가설 1 (확률: 높음): [설명]
  검증 방법: [구체적인 확인 방법]

가설 2 (확률: 중간): [설명]
  검증 방법: [구체적인 확인 방법]

가설 3 (확률: 낮음): [설명]
  검증 방법: [구체적인 확인 방법]
```

### 4단계: 검증 체크리스트

가설을 빠르게 기각/채택할 수 있는 순서로 검증 단계를 정렬합니다.

```
□ [검증 1] — 방법: console.log / 로그 확인 / 쿼리 실행
□ [검증 2] — 방법: 단위 테스트 작성
□ [검증 3] — 방법: 브레이크포인트 / 스텝 실행
```

### 5단계: 수정 방향

원인이 확인된 후 수정 방향과 재발 방지 방안을 제시합니다.

## 출력 형식

```
## 🔍 Debug Report

### 증상 요약
- 실제: ...
- 기대: ...
- 재현: ...

### 가설 (확률순)
1. [높음] ...
   → 검증: ...
2. [중간] ...
   → 검증: ...

### 검증 체크리스트
□ Step 1: ...
□ Step 2: ...

### 수정 방향 (원인 확인 후)
...

### 재발 방지
- 테스트 케이스 추가: ...
- 모니터링 포인트: ...
```

## 사용 예시

**입력:**
> 로그인은 되는데 특정 유저만 404가 뜨고 있어. 에러 로그는 없어.

**출력:**
> ## 🔍 Debug Report
> ### 증상 요약
> - 실제: 특정 유저 요청 시 404 반환
> - 기대: 정상 응답
> - 재현: 특정 유저 ID에서만 발생
> ### 가설
> 1. [높음] 해당 유저의 DB 레코드가 없거나 soft-delete 상태
> ...

## 주의사항

- 스택트레이스나 에러 메시지가 있으면 반드시 분석합니다.
- 간헐적 버그는 타이밍·레이스컨디션·캐시 문제를 먼저 의심합니다.
- "최근에 바꾼 게 없는데요"는 신뢰하지 않습니다 — git log를 확인합니다.