docs(ko-KR): add Korean translation for commands and agents

- commands: 18 files (build-fix, checkpoint, code-review, e2e, eval,
  go-build, go-review, go-test, learn, orchestrate, plan, refactor-clean,
  setup-pm, tdd, test-coverage, update-codemaps, update-docs, verify)
- agents: 12 files (architect, build-error-resolver, code-reviewer,
  database-reviewer, doc-updater, e2e-runner, go-build-resolver,
  go-reviewer, planner, refactor-cleaner, security-reviewer, tdd-guide)

docs/ko-KR/commands/build-fix.md

@@ -0,0 +1,63 @@
+# Build 오류 수정
+
+최소한의 안전한 변경으로 build 및 타입 오류를 점진적으로 수정합니다.
+
+## 1단계: Build 시스템 감지
+
+프로젝트의 build 도구를 식별하고 build를 실행합니다:
+
+| 식별 기준 | Build 명령어 |
+|-----------|---------------|
+| `package.json`에 `build` 스크립트 포함 | `npm run build` 또는 `pnpm build` |
+| `tsconfig.json` (TypeScript 전용) | `npx tsc --noEmit` |
+| `Cargo.toml` | `cargo build 2>&1` |
+| `pom.xml` | `mvn compile` |
+| `build.gradle` | `./gradlew compileJava` |
+| `go.mod` | `go build ./...` |
+| `pyproject.toml` | `python -m py_compile` 또는 `mypy .` |
+
+## 2단계: 오류 파싱 및 그룹화
+
+1. Build 명령어를 실행하고 stderr를 캡처합니다
+2. 파일 경로별로 오류를 그룹화합니다
+3. 의존성 순서에 따라 정렬합니다 (import/타입 오류를 로직 오류보다 먼저 수정)
+4. 진행 상황 추적을 위해 전체 오류 수를 셉니다
+
+## 3단계: 수정 루프 (한 번에 하나의 오류씩)
+
+각 오류에 대해:
+
+1. **파일 읽기** — Read 도구를 사용하여 오류 전후 10줄의 컨텍스트를 확인합니다
+2. **진단** — 근본 원인을 식별합니다 (누락된 import, 잘못된 타입, 구문 오류)
+3. **최소한으로 수정** — Edit 도구를 사용하여 오류를 해결하는 최소한의 변경을 적용합니다
+4. **Build 재실행** — 오류가 해결되었고 새로운 오류가 발생하지 않았는지 확인합니다
+5. **다음으로 이동** — 남은 오류를 계속 처리합니다
+
+## 4단계: 안전장치
+
+다음 경우 사용자에게 확인을 요청합니다:
+
+- 수정이 **해결하는 것보다 더 많은 오류를 발생**시키는 경우
+- **동일한 오류가 3번 시도 후에도 지속**되는 경우 (더 깊은 문제일 가능성)
+- 수정에 **아키텍처 변경이 필요**한 경우 (단순 build 수정이 아님)
+- Build 오류가 **누락된 의존성**에서 비롯된 경우 (`npm install`, `cargo add` 등이 필요)
+
+## 5단계: 요약
+
+결과를 표시합니다:
+- 수정된 오류 (파일 경로 포함)
+- 남아있는 오류 (있는 경우)
+- 새로 발생한 오류 (0이어야 함)
+- 미해결 문제에 대한 다음 단계 제안
+
+## 복구 전략
+
+| 상황 | 조치 |
+|-----------|--------|
+| 모듈/import 누락 | 패키지가 설치되어 있는지 확인하고 설치 명령어를 제안합니다 |
+| 타입 불일치 | 양쪽 타입 정의를 확인하고 더 좁은 타입을 수정합니다 |
+| 순환 의존성 | import 그래프로 순환을 식별하고 분리를 제안합니다 |
+| 버전 충돌 | `package.json` / `Cargo.toml`의 버전 제약 조건을 확인합니다 |
+| Build 도구 설정 오류 | 설정 파일을 확인하고 정상 동작하는 기본값과 비교합니다 |
+
+안전을 위해 한 번에 하나의 오류씩 수정하세요. 리팩토링보다 최소한의 diff를 선호합니다.

docs/ko-KR/commands/checkpoint.md

@@ -0,0 +1,74 @@
+# Checkpoint 명령어
+
+워크플로우에서 checkpoint를 생성하거나 검증합니다.
+
+## 사용법
+
+`/checkpoint [create|verify|list] [name]`
+
+## Checkpoint 생성
+
+Checkpoint를 생성할 때:
+
+1. `/verify quick`를 실행하여 현재 상태가 깨끗한지 확인합니다
+2. Checkpoint 이름으로 git stash 또는 commit을 생성합니다
+3. `.claude/checkpoints.log`에 checkpoint를 기록합니다:
+
+```bash
+echo "$(date +%Y-%m-%d-%H:%M) | $CHECKPOINT_NAME | $(git rev-parse --short HEAD)" >> .claude/checkpoints.log
+```
+
+4. Checkpoint 생성 완료를 보고합니다
+
+## Checkpoint 검증
+
+Checkpoint와 대조하여 검증할 때:
+
+1. 로그에서 checkpoint를 읽습니다
+2. 현재 상태를 checkpoint와 비교합니다:
+   - Checkpoint 이후 추가된 파일
+   - Checkpoint 이후 수정된 파일
+   - 현재와 당시의 테스트 통과율
+   - 현재와 당시의 커버리지
+
+3. 보고:
+```
+CHECKPOINT COMPARISON: $NAME
+============================
+Files changed: X
+Tests: +Y passed / -Z failed
+Coverage: +X% / -Y%
+Build: [PASS/FAIL]
+```
+
+## Checkpoint 목록
+
+모든 checkpoint를 다음 정보와 함께 표시합니다:
+- 이름
+- 타임스탬프
+- Git SHA
+- 상태 (current, behind, ahead)
+
+## 워크플로우
+
+일반적인 checkpoint 흐름:
+
+```
+[시작] --> /checkpoint create "feature-start"
+   |
+[구현] --> /checkpoint create "core-done"
+   |
+[테스트] --> /checkpoint verify "core-done"
+   |
+[리팩토링] --> /checkpoint create "refactor-done"
+   |
+[PR] --> /checkpoint verify "feature-start"
+```
+
+## 인자
+
+$ARGUMENTS:
+- `create <name>` - 이름이 지정된 checkpoint를 생성합니다
+- `verify <name>` - 이름이 지정된 checkpoint와 검증합니다
+- `list` - 모든 checkpoint를 표시합니다
+- `clear` - 이전 checkpoint를 제거합니다 (최근 5개만 유지)

docs/ko-KR/commands/code-review.md

@@ -0,0 +1,40 @@
+# 코드 리뷰
+
+커밋되지 않은 변경사항에 대한 포괄적인 보안 및 품질 리뷰를 수행합니다:
+
+1. 변경된 파일 목록 조회: git diff --name-only HEAD
+
+2. 각 변경된 파일에 대해 다음을 검사합니다:
+
+**보안 이슈 (CRITICAL):**
+- 하드코딩된 인증 정보, API 키, 토큰
+- SQL 인젝션 취약점
+- XSS 취약점
+- 누락된 입력 유효성 검사
+- 안전하지 않은 의존성
+- 경로 탐색(Path Traversal) 위험
+
+**코드 품질 (HIGH):**
+- 50줄 초과 함수
+- 800줄 초과 파일
+- 4단계 초과 중첩 깊이
+- 누락된 에러 처리
+- console.log 문
+- TODO/FIXME 주석
+- 공개 API에 대한 JSDoc 누락
+
+**모범 사례 (MEDIUM):**
+- 변이(Mutation) 패턴 (불변 패턴을 사용하세요)
+- 코드/주석의 이모지 사용
+- 새 코드에 대한 테스트 누락
+- 접근성(a11y) 문제
+
+3. 다음을 포함한 보고서를 생성합니다:
+   - 심각도: CRITICAL, HIGH, MEDIUM, LOW
+   - 파일 위치 및 줄 번호
+   - 이슈 설명
+   - 수정 제안
+
+4. CRITICAL 또는 HIGH 이슈가 발견되면 commit을 차단합니다
+
+보안 취약점이 있는 코드는 절대 승인하지 마세요!

docs/ko-KR/commands/e2e.md

@@ -0,0 +1,56 @@
+---
+description: Playwright로 E2E 테스트를 생성하고 실행합니다. 테스트 여정을 만들고, 테스트를 실행하며, 스크린샷/비디오/트레이스를 캡처하고, 아티팩트를 업로드합니다.
+---
+
+# E2E 커맨드
+
+이 커맨드는 **e2e-runner** 에이전트를 호출하여 Playwright를 사용한 E2E 테스트를 생성, 유지, 실행합니다.
+
+## 이 커맨드가 하는 것
+
+1. **테스트 여정 생성** - 사용자 흐름에 대한 Playwright 테스트 생성
+2. **E2E 테스트 실행** - 여러 브라우저에서 테스트 실행
+3. **아티팩트 캡처** - 실패 시 스크린샷, 비디오, 트레이스
+4. **결과 업로드** - HTML 보고서 및 JUnit XML
+5. **불안정한 테스트 식별** - 불안정한 테스트를 격리
+
+## 사용 시점
+
+`/e2e`를 사용해야 할 때:
+- 핵심 사용자 여정 테스트 (로그인, 거래, 결제)
+- 다단계 흐름이 E2E로 작동하는지 검증
+- UI 인터랙션 및 네비게이션 테스트
+- 프론트엔드와 백엔드 간 통합 검증
+- 프로덕션 배포 준비
+
+## 작동 방식
+
+e2e-runner 에이전트가 수행하는 작업:
+
+1. **사용자 흐름 분석** 및 테스트 시나리오 식별
+2. Page Object Model 패턴을 사용한 **Playwright 테스트 생성**
+3. 여러 브라우저(Chrome, Firefox, Safari)에서 **테스트 실행**
+4. 스크린샷, 비디오, 트레이스로 **실패 캡처**
+5. 결과와 아티팩트로 **보고서 생성**
+6. **불안정한 테스트 식별** 및 수정 권장
+
+## 모범 사례
+
+**해야 할 것:**
+- Page Object Model을 사용하여 유지보수성 향상
+- data-testid 속성을 셀렉터로 사용
+- 임의의 타임아웃 대신 API 응답을 대기
+- 핵심 사용자 여정을 E2E로 테스트
+- main에 merge하기 전에 테스트 실행
+
+**하지 말아야 할 것:**
+- 취약한 셀렉터 사용 (CSS 클래스는 변경될 수 있음)
+- 구현 세부사항 테스트
+- 프로덕션에 대해 테스트 실행
+- 불안정한 테스트 무시
+- E2E로 모든 엣지 케이스 테스트 (단위 테스트 사용)
+
+## 관련 에이전트
+
+이 커맨드는 `e2e-runner` 에이전트를 호출합니다:
+`~/.claude/agents/e2e-runner.md`

docs/ko-KR/commands/eval.md

@@ -0,0 +1,48 @@
+# Eval 커맨드
+
+평가 기반 개발 워크플로우를 관리합니다.
+
+## 사용법
+
+`/eval [define|check|report|list] [feature-name]`
+
+## 평가 정의
+
+`/eval define feature-name`
+
+새로운 평가 정의를 생성합니다:
+
+1. `.claude/evals/feature-name.md`에 템플릿 생성
+2. 사용자에게 구체적인 기준을 입력하도록 안내
+
+## 평가 확인
+
+`/eval check feature-name`
+
+기능에 대한 평가를 실행합니다:
+
+1. `.claude/evals/feature-name.md`에서 평가 정의 읽기
+2. 각 기능 평가: 기준 검증 시도, PASS/FAIL 기록
+3. 각 회귀 평가: 관련 테스트 실행, 기준선과 비교
+4. 현재 상태 보고
+
+## 평가 보고
+
+`/eval report feature-name`
+
+포괄적인 평가 보고서를 생성합니다.
+
+## 평가 목록
+
+`/eval list`
+
+모든 평가 정의를 표시합니다.
+
+## 인자
+
+$ARGUMENTS:
+- `define <name>` - 새 평가 정의 생성
+- `check <name>` - 평가 실행 및 확인
+- `report <name>` - 전체 보고서 생성
+- `list` - 모든 평가 표시
+- `clean` - 오래된 평가 로그 제거 (최근 10회 유지)

docs/ko-KR/commands/go-build.md

@@ -0,0 +1,38 @@
+---
+description: Go build 에러, go vet 경고, 린터 이슈를 점진적으로 수정합니다. 최소한의 정밀한 수정을 위해 go-build-resolver 에이전트를 호출합니다.
+---
+
+# Go Build and Fix
+
+이 커맨드는 **go-build-resolver** 에이전트를 호출하여 최소한의 변경으로 Go build 에러를 점진적으로 수정합니다.
+
+## 이 커맨드가 하는 것
+
+1. **진단 실행**: `go build`, `go vet`, `staticcheck` 실행
+2. **에러 분석**: 파일별로 그룹화하고 심각도순 정렬
+3. **점진적 수정**: 한 번에 하나의 에러씩
+4. **각 수정 검증**: 각 변경 후 build 재실행
+5. **요약 보고**: 수정된 것과 남은 것 표시
+
+## 사용 시점
+
+`/go-build`를 사용해야 할 때:
+- `go build ./...`가 에러로 실패할 때
+- `go vet ./...`가 이슈를 보고할 때
+- `golangci-lint run`이 경고를 보여줄 때
+- 모듈 의존성이 깨졌을 때
+- 변경사항을 pull한 후 build가 깨졌을 때
+
+## 수정 전략
+
+1. **Build 에러 먼저** - 코드가 컴파일되어야 함
+2. **Vet 경고 두 번째** - 의심스러운 구조 수정
+3. **Lint 경고 세 번째** - 스타일과 모범 사례
+4. **한 번에 하나씩** - 각 변경 검증
+5. **최소한의 변경** - 리팩토링이 아닌 수정만
+
+## 관련 커맨드
+
+- `/go-test` - build 성공 후 테스트 실행
+- `/go-review` - 코드 품질 리뷰
+- `/verify` - 전체 검증 루프

docs/ko-KR/commands/go-review.md

@@ -0,0 +1,49 @@
+---
+description: 관용적 패턴, 동시성 안전성, 에러 처리, 보안에 대한 포괄적인 Go 코드 리뷰. go-reviewer 에이전트를 호출합니다.
+---
+
+# Go 코드 리뷰
+
+이 커맨드는 **go-reviewer** 에이전트를 호출하여 Go 전용 포괄적 코드 리뷰를 수행합니다.
+
+## 이 커맨드가 하는 것
+
+1. **Go 변경사항 식별**: `git diff`로 수정된 `.go` 파일 찾기
+2. **정적 분석 실행**: `go vet`, `staticcheck`, `golangci-lint` 실행
+3. **보안 스캔**: SQL 인젝션, 커맨드 인젝션, 레이스 컨디션 검사
+4. **동시성 리뷰**: 고루틴 안전성, 채널 사용, 뮤텍스 패턴 분석
+5. **관용적 Go 검사**: Go 컨벤션과 모범 사례 준수 여부 확인
+6. **보고서 생성**: 심각도별 이슈 분류
+
+## 사용 시점
+
+`/go-review`를 사용해야 할 때:
+- Go 코드를 작성하거나 수정한 후
+- Go 변경사항을 커밋하기 전
+- Go 코드가 포함된 PR 리뷰 시
+- 새 Go 코드베이스에 온보딩할 때
+
+## 리뷰 카테고리
+
+### CRITICAL (반드시 수정)
+- SQL/커맨드 인젝션 취약점
+- 동기화 없는 레이스 컨디션
+- 고루틴 누수
+- 하드코딩된 인증 정보
+
+### HIGH (수정 권장)
+- 컨텍스트 없는 에러 래핑 누락
+- 에러 반환 대신 panic 사용
+- 컨텍스트 전파 누락
+- 데드락을 유발하는 버퍼 없는 채널
+
+### MEDIUM (고려)
+- 비관용적 코드 패턴
+- 공개 항목에 godoc 주석 누락
+- 비효율적인 문자열 연결
+
+## 관련 커맨드
+
+- `/go-test` - 먼저 테스트 통과 확인
+- `/go-build` - build 에러 발생 시
+- `/code-review` - Go 외 일반적인 관심사항

docs/ko-KR/commands/go-test.md

@@ -0,0 +1,48 @@
+---
+description: Go용 TDD 워크플로우 강제. 테이블 기반 테스트를 먼저 작성한 후 구현. go test -cover로 80% 이상 커버리지 검증.
+---
+
+# Go TDD 커맨드
+
+이 커맨드는 관용적 Go 테스팅 패턴을 사용하여 Go 코드에 테스트 주도 개발 방법론을 강제합니다.
+
+## 이 커맨드가 하는 것
+
+1. **타입/인터페이스 정의**: 함수 시그니처를 먼저 스캐폴딩
+2. **테이블 기반 테스트 작성**: 포괄적인 테스트 케이스 생성 (RED)
+3. **테스트 실행**: 올바른 이유로 테스트가 실패하는지 확인
+4. **코드 구현**: 통과하기 위한 최소한의 코드 작성 (GREEN)
+5. **리팩토링**: 테스트를 통과시키면서 개선
+6. **커버리지 확인**: 80% 이상 커버리지 확보
+
+## 사용 시점
+
+`/go-test`를 사용해야 할 때:
+- 새로운 Go 함수 구현
+- 기존 코드에 테스트 커버리지 추가
+- 버그 수정 (실패하는 테스트를 먼저 작성)
+- 핵심 비즈니스 로직 구현
+
+## TDD 사이클
+
+```
+RED     → 실패하는 테이블 기반 테스트 작성
+GREEN   → 통과하기 위한 최소한의 코드 구현
+REFACTOR → 코드 개선, 테스트는 통과 유지
+REPEAT  → 다음 테스트 케이스
+```
+
+## 커버리지 목표
+
+| 코드 유형 | 목표 |
+|-----------|------|
+| 핵심 비즈니스 로직 | 100% |
+| 공개 API | 90%+ |
+| 일반 코드 | 80%+ |
+| 생성된 코드 | 제외 |
+
+## 관련 커맨드
+
+- `/go-build` - build 에러 수정
+- `/go-review` - 구현 후 코드 리뷰
+- `/verify` - 전체 검증 루프

docs/ko-KR/commands/learn.md

@@ -0,0 +1,47 @@
+# /learn - 재사용 가능한 패턴 추출
+
+현재 세션을 분석하고 스킬로 저장할 가치가 있는 패턴을 추출합니다.
+
+## 트리거
+
+세션 중 중요한 문제를 해결했을 때 `/learn`을 실행합니다.
+
+## 추출 대상
+
+다음을 찾습니다:
+
+1. **에러 해결 패턴**
+   - 어떤 에러가 발생했는가?
+   - 근본 원인은 무엇이었는가?
+   - 무엇이 해결했는가?
+   - 유사한 에러에 재사용 가능한가?
+
+2. **디버깅 기법**
+   - 직관적이지 않은 디버깅 단계
+   - 효과적인 도구 조합
+   - 진단 패턴
+
+3. **해결 방법**
+   - 라이브러리 특이 사항
+   - API 제한 사항
+   - 버전별 수정 사항
+
+4. **프로젝트 특화 패턴**
+   - 발견된 코드베이스 컨벤션
+   - 내려진 아키텍처 결정
+   - 통합 패턴
+
+## 프로세스
+
+1. 세션에서 추출 가능한 패턴 검토
+2. 가장 가치 있고 재사용 가능한 인사이트 식별
+3. 스킬 파일 초안 작성
+4. 저장 전 사용자 확인 요청
+5. `~/.claude/skills/learned/`에 저장
+
+## 참고 사항
+
+- 사소한 수정은 추출하지 않기 (오타, 단순 구문 에러)
+- 일회성 이슈는 추출하지 않기 (특정 API 장애 등)
+- 향후 세션에서 시간을 절약할 수 있는 패턴에 집중
+- 스킬은 집중적으로 - 스킬당 하나의 패턴

docs/ko-KR/commands/orchestrate.md

@@ -0,0 +1,59 @@
+# Orchestrate 커맨드
+
+복잡한 작업을 위한 순차적 에이전트 워크플로우입니다.
+
+## 사용법
+
+`/orchestrate [workflow-type] [task-description]`
+
+## 워크플로우 유형
+
+### feature
+전체 기능 구현 워크플로우:
+```
+planner -> tdd-guide -> code-reviewer -> security-reviewer
+```
+
+### bugfix
+버그 조사 및 수정 워크플로우:
+```
+planner -> tdd-guide -> code-reviewer
+```
+
+### refactor
+안전한 리팩토링 워크플로우:
+```
+architect -> code-reviewer -> tdd-guide
+```
+
+### security
+보안 중심 리뷰:
+```
+security-reviewer -> code-reviewer -> architect
+```
+
+## 실행 패턴
+
+워크플로우의 각 에이전트에 대해:
+
+1. 이전 에이전트의 컨텍스트로 **에이전트 호출**
+2. 구조화된 핸드오프 문서로 **출력 수집**
+3. 체인의 **다음 에이전트에 전달**
+4. **결과를 종합**하여 최종 보고서 작성
+
+## 인자
+
+$ARGUMENTS:
+- `feature <description>` - 전체 기능 워크플로우
+- `bugfix <description>` - 버그 수정 워크플로우
+- `refactor <description>` - 리팩토링 워크플로우
+- `security <description>` - 보안 리뷰 워크플로우
+- `custom <agents> <description>` - 사용자 정의 에이전트 순서
+
+## 팁
+
+1. 복잡한 기능에는 **planner부터 시작**
+2. merge 전에는 **항상 code-reviewer 포함**
+3. 인증/결제/개인정보에는 **security-reviewer 사용**
+4. **핸드오프는 간결하게** - 다음 에이전트에 필요한 것에 집중
+5. 필요하면 에이전트 사이에 **검증 실행**

docs/ko-KR/commands/plan.md

@@ -0,0 +1,50 @@
+---
+description: 요구사항을 재확인하고, 위험을 평가하며, 단계별 구현 계획을 작성합니다. 코드를 건드리기 전에 사용자 확인을 기다립니다.
+---
+
+# Plan 커맨드
+
+이 커맨드는 **planner** 에이전트를 호출하여 코드를 작성하기 전에 포괄적인 구현 계획을 만듭니다.
+
+## 이 커맨드가 하는 것
+
+1. **요구사항 재확인** - 무엇을 만들어야 하는지 명확히 함
+2. **위험 식별** - 잠재적 이슈와 차단 요소 도출
+3. **단계별 계획 작성** - 구현을 단계로 분해
+4. **확인 대기** - 진행 전 반드시 사용자 승인을 받음
+
+## 사용 시점
+
+`/plan`을 사용해야 할 때:
+- 새 기능 시작
+- 중요한 아키텍처 변경
+- 복잡한 리팩토링 작업
+- 여러 파일/컴포넌트에 영향을 미칠 때
+- 요구사항이 불명확하거나 모호할 때
+
+## 작동 방식
+
+planner 에이전트가 수행하는 작업:
+
+1. 요청을 **분석**하고 요구사항을 명확하게 재확인
+2. 구체적이고 실행 가능한 단계로 **분해**
+3. 컴포넌트 간 **의존성 식별**
+4. **위험 평가** 및 잠재적 차단 요소 파악
+5. **복잡도 추정** (High/Medium/Low)
+6. 계획을 **제시**하고 명시적 확인을 **대기**
+
+## 중요 참고 사항
+
+**핵심**: planner 에이전트는 "yes"나 "proceed" 같은 긍정적 응답으로 명시적으로 확인하기 전까지 코드를 **작성하지 않습니다.**
+
+## 다른 커맨드와의 연계
+
+계획 수립 후:
+- `/tdd`를 사용하여 테스트 주도 개발로 구현
+- `/build-fix`로 build 에러 발생 시 수정
+- `/code-review`로 완성된 구현 리뷰
+
+## 관련 에이전트
+
+이 커맨드는 `planner` 에이전트를 호출합니다:
+`~/.claude/agents/planner.md`

docs/ko-KR/commands/refactor-clean.md

@@ -0,0 +1,42 @@
+# Refactor Clean
+
+사용하지 않는 코드를 안전하게 식별하고 매 단계마다 테스트 검증을 수행합니다.
+
+## 1단계: 사용하지 않는 코드 감지
+
+프로젝트 유형에 따라 분석 도구 실행:
+
+| 도구 | 감지 대상 | 커맨드 |
+|------|----------|--------|
+| knip | 미사용 exports, 파일, 의존성 | `npx knip` |
+| depcheck | 미사용 npm 의존성 | `npx depcheck` |
+| ts-prune | 미사용 TypeScript exports | `npx ts-prune` |
+| vulture | 미사용 Python 코드 | `vulture src/` |
+| deadcode | 미사용 Go 코드 | `deadcode ./...` |
+
+## 2단계: 결과 분류
+
+안전 등급별 분류:
+
+| 등급 | 예시 | 조치 |
+|------|------|------|
+| **안전** | 미사용 유틸리티, 테스트 헬퍼, 내부 함수 | 확신을 가지고 삭제 |
+| **주의** | 컴포넌트, API 라우트, 미들웨어 | 동적 임포트나 외부 소비자가 없는지 확인 |
+| **위험** | 설정 파일, 엔트리 포인트, 타입 정의 | 건드리기 전에 조사 |
+
+## 3단계: 안전한 삭제 루프
+
+각 안전 항목에 대해:
+
+1. **전체 테스트 실행** — 기준선 확립 (모두 통과)
+2. **사용하지 않는 코드 삭제** — Edit 도구로 정밀 삭제
+3. **테스트 재실행** — 깨진 것이 없는지 확인
+4. **테스트 실패 시** — 즉시 `git checkout -- <file>`로 되돌리고 건너뜀
+5. **테스트 통과 시** — 다음 항목으로 이동
+
+## 규칙
+
+- **테스트를 먼저 실행하지 않고 절대 삭제하지 않기**
+- **한 번에 하나씩 삭제** — 원자적 변경으로 롤백 용이
+- **확실하지 않으면 건너뛰기** — 프로덕션을 깨뜨리는 것보다 사용하지 않는 코드를 유지하는 것이 나음
+- **정리하면서 리팩토링하지 않기** — 관심사 분리 (먼저 정리, 나중에 리팩토링)

docs/ko-KR/commands/setup-pm.md

@@ -0,0 +1,35 @@
+---
+description: 선호하는 패키지 매니저(npm/pnpm/yarn/bun) 설정
+disable-model-invocation: true
+---
+
+# 패키지 매니저 설정
+
+프로젝트 또는 전역으로 선호하는 패키지 매니저를 설정합니다.
+
+## 사용법
+
+```bash
+# 현재 패키지 매니저 감지
+node scripts/setup-package-manager.js --detect
+
+# 전역 설정
+node scripts/setup-package-manager.js --global pnpm
+
+# 프로젝트 설정
+node scripts/setup-package-manager.js --project bun
+
+# 사용 가능한 패키지 매니저 목록
+node scripts/setup-package-manager.js --list
+```
+
+## 감지 우선순위
+
+패키지 매니저를 결정할 때 다음 순서로 확인합니다:
+
+1. **환경 변수**: `CLAUDE_PACKAGE_MANAGER`
+2. **프로젝트 설정**: `.claude/package-manager.json`
+3. **package.json**: `packageManager` 필드
+4. **락 파일**: package-lock.json, yarn.lock, pnpm-lock.yaml, bun.lockb
+5. **전역 설정**: `~/.claude/package-manager.json`
+6. **폴백**: 사용 가능한 첫 번째 패키지 매니저 (pnpm > bun > yarn > npm)

docs/ko-KR/commands/tdd.md

@@ -0,0 +1,56 @@
+---
+description: 테스트 주도 개발 워크플로우 강제. 인터페이스를 스캐폴딩하고, 테스트를 먼저 생성한 후 통과할 최소한의 코드를 구현합니다. 80% 이상 커버리지를 보장합니다.
+---
+
+# TDD 커맨드
+
+이 커맨드는 **tdd-guide** 에이전트를 호출하여 테스트 주도 개발 방법론을 강제합니다.
+
+## 이 커맨드가 하는 것
+
+1. **인터페이스 스캐폴딩** - 타입/인터페이스를 먼저 정의
+2. **테스트 먼저 생성** - 실패하는 테스트 작성 (RED)
+3. **최소한의 코드 구현** - 통과하기에 충분한 코드만 작성 (GREEN)
+4. **리팩토링** - 테스트를 통과시키면서 코드 개선 (REFACTOR)
+5. **커버리지 확인** - 80% 이상 테스트 커버리지 보장
+
+## 사용 시점
+
+`/tdd`를 사용해야 할 때:
+- 새 기능 구현
+- 새 함수/컴포넌트 추가
+- 버그 수정 (버그를 재현하는 테스트를 먼저 작성)
+- 기존 코드 리팩토링
+- 핵심 비즈니스 로직 구현
+
+## TDD 사이클
+
+```
+RED → GREEN → REFACTOR → REPEAT
+
+RED:      실패하는 테스트 작성
+GREEN:    통과할 최소한의 코드 작성
+REFACTOR: 코드 개선, 테스트 계속 통과 유지
+REPEAT:   다음 기능/시나리오
+```
+
+## 모범 사례
+
+**해야 할 것:**
+- 구현 전에 테스트를 먼저 작성
+- 각 변경 후 테스트 실행 및 실패 확인
+- 테스트를 통과하기 위한 최소한의 코드 작성
+- 테스트가 통과한 후에만 리팩토링
+- 80% 이상 커버리지 목표 (핵심 코드는 100%)
+
+**하지 말아야 할 것:**
+- 테스트 전에 구현 작성
+- RED 단계 건너뛰기
+- 한 번에 너무 많은 코드 작성
+- 실패하는 테스트 무시
+- 구현 세부사항 테스트 (동작을 테스트)
+
+## 관련 에이전트
+
+이 커맨드는 `tdd-guide` 에이전트를 호출합니다:
+`~/.claude/agents/tdd-guide.md`

docs/ko-KR/commands/test-coverage.md

@@ -0,0 +1,42 @@
+# 테스트 커버리지
+
+테스트 커버리지를 분석하고, 갭을 식별하며, 80% 이상 커버리지 달성을 위해 누락된 테스트를 생성합니다.
+
+## 1단계: 테스트 프레임워크 감지
+
+| 지표 | 커버리지 커맨드 |
+|------|----------------|
+| `jest.config.*` 또는 `package.json` jest | `npx jest --coverage --coverageReporters=json-summary` |
+| `vitest.config.*` | `npx vitest run --coverage` |
+| `pytest.ini` / `pyproject.toml` pytest | `pytest --cov=src --cov-report=json` |
+| `Cargo.toml` | `cargo llvm-cov --json` |
+| `go.mod` | `go test -coverprofile=coverage.out ./...` |
+
+## 2단계: 커버리지 보고서 분석
+
+1. 커버리지 커맨드 실행
+2. 출력 파싱 (JSON 요약 또는 터미널 출력)
+3. **80% 미만인 파일**을 최저순으로 정렬하여 목록화
+4. 각 미달 파일에서 미테스트 함수, 누락된 분기 커버리지, 데드 코드 식별
+
+## 3단계: 누락된 테스트 생성
+
+우선순위에 따라 테스트 생성:
+
+1. **Happy path** — 유효한 입력의 핵심 기능
+2. **에러 처리** — 잘못된 입력, 누락된 데이터, 네트워크 실패
+3. **엣지 케이스** — 빈 배열, null/undefined, 경계값 (0, -1, MAX_INT)
+4. **분기 커버리지** — 각 if/else, switch case, 삼항 연산자
+
+## 4단계: 검증
+
+1. 전체 테스트 실행 — 모든 테스트 통과 확인
+2. 커버리지 재실행 — 개선 확인
+3. 여전히 80% 미만이면 나머지 갭에 대해 3단계 반복
+
+## 집중 영역
+
+- 복잡한 분기가 있는 함수 (높은 순환 복잡도)
+- 에러 핸들러와 catch 블록
+- 코드베이스 전반에서 사용되는 유틸리티 함수
+- API 엔드포인트 핸들러 (요청 → 응답 흐름)

docs/ko-KR/commands/update-codemaps.md

@@ -0,0 +1,29 @@
+# 코드맵 업데이트
+
+코드베이스 구조를 분석하고 토큰 효율적인 아키텍처 문서를 생성합니다.
+
+## 1단계: 프로젝트 구조 스캔
+
+1. 프로젝트 유형 식별 (모노레포, 단일 앱, 라이브러리, 마이크로서비스)
+2. 모든 소스 디렉토리 찾기 (src/, lib/, app/, packages/)
+3. 엔트리 포인트 매핑 (main.ts, index.ts, app.py, main.go 등)
+
+## 2단계: 코드맵 생성
+
+`docs/CODEMAPS/`에 코드맵 생성 또는 업데이트:
+
+| 파일 | 내용 |
+|------|------|
+| `architecture.md` | 상위 시스템 다이어그램, 서비스 경계, 데이터 흐름 |
+| `backend.md` | API 라우트, 미들웨어 체인, 서비스 → 리포지토리 매핑 |
+| `frontend.md` | 페이지 트리, 컴포넌트 계층, 상태 관리 흐름 |
+| `data.md` | 데이터베이스 테이블, 관계, 마이그레이션 히스토리 |
+| `dependencies.md` | 외부 서비스, 서드파티 통합, 공유 라이브러리 |
+
+## 팁
+
+- **구현 세부사항이 아닌 상위 구조**에 집중
+- 전체 코드 블록 대신 **파일 경로와 함수 시그니처** 사용
+- 효율적인 컨텍스트 로딩을 위해 각 코드맵을 **1000 토큰 미만**으로 유지
+- 장황한 설명 대신 데이터 흐름에 ASCII 다이어그램 사용
+- 주요 기능 추가 또는 리팩토링 세션 후 실행

docs/ko-KR/commands/update-docs.md

@@ -0,0 +1,33 @@
+# 문서 업데이트
+
+문서를 코드베이스와 동기화하고, 원본 소스 파일에서 생성합니다.
+
+## 1단계: 원본 소스 식별
+
+| 소스 | 생성 대상 |
+|------|----------|
+| `package.json` scripts | 사용 가능한 커맨드 참조 |
+| `.env.example` | 환경 변수 문서 |
+| `openapi.yaml` / 라우트 파일 | API 엔드포인트 참조 |
+| 소스 코드 exports | 공개 API 문서 |
+| `Dockerfile` / `docker-compose.yml` | 인프라 설정 문서 |
+
+## 2단계: 스크립트 참조 생성
+
+1. `package.json` (또는 `Makefile`, `Cargo.toml`, `pyproject.toml`) 읽기
+2. 모든 스크립트/커맨드와 설명 추출
+3. 참조 테이블 생성
+
+## 3단계: 환경 변수 문서 생성
+
+1. `.env.example` 읽기
+2. 모든 변수와 용도 추출
+3. 필수 vs 선택으로 분류
+4. 예상 형식과 유효 값 문서화
+
+## 규칙
+
+- **단일 원본**: 항상 코드에서 생성, 생성된 섹션을 수동으로 편집하지 않기
+- **수동 섹션 보존**: 생성된 섹션만 업데이트; 수기 작성 내용은 그대로 유지
+- **생성된 콘텐츠 표시**: 생성된 섹션 주변에 `<!-- AUTO-GENERATED -->` 마커 사용
+- **요청 없이 문서 생성하지 않기**: 커맨드가 명시적으로 요청한 경우에만 새 문서 파일 생성

docs/ko-KR/commands/verify.md

@@ -0,0 +1,59 @@
+# 검증 커맨드
+
+현재 코드베이스 상태에 대한 포괄적인 검증을 실행합니다.
+
+## 지시사항
+
+정확히 이 순서로 검증을 실행하세요:
+
+1. **Build 검사**
+   - 이 프로젝트의 build 커맨드 실행
+   - 실패 시 에러를 보고하고 중단
+
+2. **타입 검사**
+   - TypeScript/타입 체커 실행
+   - 모든 에러를 파일:줄번호로 보고
+
+3. **Lint 검사**
+   - 린터 실행
+   - 경고와 에러 보고
+
+4. **테스트 실행**
+   - 모든 테스트 실행
+   - 통과/실패 수 보고
+   - 커버리지 비율 보고
+
+5. **Console.log 감사**
+   - 소스 파일에서 console.log 검색
+   - 위치 보고
+
+6. **Git 상태**
+   - 커밋되지 않은 변경사항 표시
+   - 마지막 커밋 이후 수정된 파일 표시
+
+## 출력
+
+간결한 검증 보고서를 생성합니다:
+
+```
+VERIFICATION: [PASS/FAIL]
+
+Build:    [OK/FAIL]
+Types:    [OK/X errors]
+Lint:     [OK/X issues]
+Tests:    [X/Y passed, Z% coverage]
+Secrets:  [OK/X found]
+Logs:     [OK/X console.logs]
+
+Ready for PR: [YES/NO]
+```
+
+치명적 이슈가 있으면 수정 제안과 함께 목록화합니다.
+
+## 인자
+
+$ARGUMENTS:
+- `quick` - build + 타입만
+- `full` - 모든 검사 (기본값)
+- `pre-commit` - 커밋에 관련된 검사
+- `pre-pr` - 전체 검사 + 보안 스캔