Claude Code 사용법 & 프롬프트 팁

# 로그인 기능 구현 완료 후 대시보드 작업 시작
/clear
# → 깨끗한 상태에서 새 작업 시작

# 어제 하던 작업 이어서
/resume
# → 저장된 세션 목록에서 선택

# 1. 프로젝트 폴더로 이동
! cd ~/projects/my-new-app

# 2. CLAUDE.md 자동 생성
/init
# → Claude가 프로젝트 구조 분석 후
#   언어/프레임워크/테스트 도구를 감지하고
#   CLAUDE.md 초안을 만들어줌

# 3. 세션에 이름 부여
/rename initial-setup

# 터미널 1: 백엔드 API 작업
claude
> /rename backend-auth

# 터미널 2: 프론트엔드 UI 작업 (병렬)
claude
> /rename frontend-login

# 나중에 어느 세션이든 /resume으로 복귀

/context
# → 현재 컨텍스트 사용량 표시 (예: 82% 사용)

/compact "최근 결제 로직 구현과 테스트 결과만 보존하고 나머지는 요약"
# → 중요한 부분만 유지하면서 공간 확보

/btw 그 환경변수 이름이 뭐였더라?
# → 작업 흐름 방해 없이 빠른 확인

# 좋은 예시 — 무엇을 보존할지 구체적으로
/compact 현재 진행 중인 OAuth 구현 코드와
        @src/auth/oauth.ts 의 최신 버전을 보존하고
        나머지 토론 내용은 요약해줘

# 나쁜 예시 — 막연한 지시
/compact 정리해줘  ← 중요 정보가 사라질 수 있음

# Claude가 큰 작업을 하는 중에...

/btw package.json의 react 버전이 뭐야?
# → 빠르게 확인하고 메인 작업으로 복귀
#   히스토리에 남지 않아서 컨텍스트가 깨끗

/btw 방금 만든 함수 이름이 뭐였지?

# 1. 구현이 끝났으면 자동으로 코드 다듬기
/simplify
# → 중복 제거, 더 좋은 패턴 제안

# 2. PR 만들기 전 마지막 점검
/review
# → 누락된 테스트, 위험 패턴 탐지

# 3. 인증 / 결제 / 데이터 처리 코드면 반드시
/security-review
# → 보안 취약점 종합 검토

# 4. 모두 통과하면 커밋
! git add . && git commit -m "feat: OAuth 추가"

# 특정 파일/폴더로 범위 좁히기
@src/api/payment.ts 만 /review 해줘

@src/auth 폴더에 대해 /security-review 진행해줘
특히 토큰 처리 부분을 집중적으로.

# 5분마다 테스트 자동 실행
/loop 5m npm test

# 30초마다 빌드 상태 확인
/loop 30s ! curl -s http://localhost:3000/health

# 1시간마다 PR 상태 점검
/loop 1h gh pr list --author @me

# 1. 시간이 오래 걸리는 작업 시작
@src 전체에 대해 마이그레이션 작업을 진행해줘.
모든 .js 파일을 .ts로 변환.

# 2. Ctrl+B로 백그라운드 전환
# 3. 다른 작업 진행

# 4. 진행 상태 확인
/tasks
# → 실행 중인 백그라운드 작업 목록 표시

/permissions

# UI에서 다음을 설정:
# - npm/pytest/git 명령 자동 허용
# - rm -rf, sudo 차단
# - .env 파일 읽기 차단

/config
# → 일반 작업: Sonnet (균형)
# → 복잡한 알고리즘: Opus
# → 빠른 단순 작업: Haiku

/fast
# → Fast mode 토글 (Opus 5 / 4.8에서만 동작)

/model haiku
# → 단순 작업은 Haiku로 (속도·비용 우선)

/effort xhigh
# → 어려운 설계·검증 구간에서만 추론 강도를 올림

# 문제가 생겼을 때 진단
/doctor
# → CLAUDE.md, 권한, 스킬, MCP 등 설정 검증

/debug
# → 상세 로그 출력 (다음 명령부터)

/hooks
# → 현재 등록된 훅 목록 확인

1. 측정 가능한 종료 상태 — 테스트 결과, 빌드 exit code, lint 0 warnings
2. 검증 방법 명시 — "npm test가 exit 0", "tsc --noEmit 에러 없음"
3. 지켜야 할 제약 — "공개 API는 변경하지 말 것", "DB 스키마는 그대로"

/goal test/auth/* 의 모든 테스트가 통과하고 ESLint warning이 0이 될 것.
검증: `pnpm test:auth` 가 exit 0, `pnpm lint` 가 exit 0.
조건: 공개 export 시그니처는 변경하지 말 것.
턴 상한: 30턴 또는 60분이 경과하면 중단.

# 목표 설정
/goal tests/parser.test.ts 가 전부 통과할 것. 검증: `npm test`가 exit 0.
      제약: parser.ts의 공개 API 시그니처는 유지. 상한: 20턴 또는 30분.

# ── 턴 1 ── Claude가 스스로 시작
npm test 실행 → 3건 실패 (null 입력 처리 누락)
parser.ts의 parse() 에 null 가드 추가
[평가자] ❌ no — 아직 2건 실패 (빈 배열 케이스). 계속.

# ── 턴 2 ── 사용자가 아무것도 안 쳐도 자동 진행
빈 배열 분기 추가 → npm test 재실행 → 1건 실패 (중첩 객체)
[평가자] ❌ no — 1건 남음. 계속.

# ── 턴 3 ──
재귀 파싱 수정 → npm test → exit 0 (전부 통과)
[평가자] ✅ yes — 조건 충족. 공개 API도 그대로.

# → 목표 자동 해제, 제어권이 사용자에게 복귀 (3턴 만에 종료)

# 단일 파일
@app.py 이 파일의 라우트 구조를 설명해줘

# 여러 파일
@src/auth/session.ts 와 @src/api/login.ts 의 관계는?

# 폴더 전체
@src/components 이 폴더의 컴포넌트들을 나열해줘

# 홈 디렉토리
@~/.zshrc 내 셸 설정 확인해줘

# 특정 줄 부근
@src/auth/session.ts 의 47번 줄 로직 설명해줘

@src/api/payment.ts 에서 결제 실패 시 트랜잭션이
롤백되지 않는 버그가 있어. @tests/payment.test.ts 의
테스트 패턴 참고해서 재현 테스트 작성하고 수정해줘.

@src/components/Button.tsx 와 동일한 스타일 패턴으로
@src/components/IconButton.tsx 컴포넌트를 만들어줘.
Props는 @types/icon.ts 의 IconName을 사용.

@src/utils/auth.ts 의 refreshToken 함수가
@src/middleware/session.ts 의 어떤 흐름에서 호출되는지
순서대로 설명해줘. 다이어그램으로 그려도 좋아.

@src/api/users.ts 의 CRUD 패턴을 그대로 따라서
@src/api/products.ts 를 만들어줘. 다만 products는
재고(stock) 필드가 추가로 필요해.

@.env.example 의 환경변수들을 보고 @docs/setup.md 의
설치 가이드 섹션을 업데이트해줘. 누락된 변수가 있으면 추가.

! npm test
! git status
! ls -la
! python app.py
! cat .env.example
! pytest tests/test_auth.py -v

# 1. 에러를 직접 실행
! python app.py

# 2. (에러 출력이 컨텍스트에 추가됨)
# 3. Claude에게 분석 요청
위 에러의 원인이 뭐야? 어떻게 고쳐?

! pytest tests/test_auth.py -v
# → 실패한 테스트 출력

실패한 테스트 케이스만 골라서
원인을 분석하고 수정 방안을 제시해줘.

! pip list | grep -i flask
! npm ls react

# 버전 확인 후
이 버전들로 호환 가능한 OAuth 라이브러리 추천해줘.

! cat .env.example
! find . -name "*.log" -mtime -1
! du -sh node_modules
! git log --oneline -10

! curl -s http://localhost:3000/api/health | jq
! psql -d mydb -c "SELECT COUNT(*) FROM users;"
! redis-cli ping

# 이 프로젝트는 FastAPI를 사용한다 (Flask 아님)
# 모든 테스트는 pytest로 실행
# 가상환경: poetry 사용

1단계: Plan 모드로 이동
Shift+Tab → Plan
→ "@src/auth 분석 후 OAuth 추가 계획 세워줘"

2단계: 계획 검토
Ctrl+G로 에디터에서 계획 수정/보강

3단계: 실행 모드로 전환
Shift+Tab → Auto (안전 검토를 맡김)
   또는 Accept edits (편집만 몰아서 통과시킬 때)

4단계: 구현
"계획대로 구현해줘"

5단계: 정리
/clear (다음 작업 준비)

# 예시 1: 처음 보는 코드를 신중하게 수정
@legacy/billing.py 의 calculate_tax 함수
버그 수정해줘. 각 변경마다 보여줘.

# 예시 2: 프로덕션 코드 수정
@src/payment 의 결제 로직을 수정해야 해.
변경 전후를 확인하면서 진행해줘.

# 예시 1: 큰 리팩토링 (수정 전 분석만)
Shift+Tab → Plan
@src 전체에서 사용 중인 콜백 패턴을
async/await로 마이그레이션하려고 해.
영향받는 파일 목록과 변경 순서를 계획해줘.

# 예시 2: 처음 보는 코드베이스 파악
Shift+Tab → Plan
이 프로젝트의 인증 흐름을 파악해줘.
관련 파일 목록과 각 파일의 역할,
요청 흐름을 다이어그램으로 정리해줘.

# 편집이 대량으로, 예측 가능하게 발생하는 작업
Shift+Tab → Accept edits
@src/components 의 모든 .jsx 파일을
.tsx로 변환하고 타입 추가해줘.

# 이미 Plan에서 승인된 계획을 그대로 밀어붙일 때
방금 검토한 계획대로 구현해줘. 중간에 멈추지 말고 끝까지.

# 무인 CI — allow 목록 밖은 조용히 거부
claude -p "테스트 실패 원인 요약" --permission-mode dontAsk \
        --allowedTools "Read,Grep,Bash(npm test)"

# 격리된 컨테이너 안에서 전체 자동화
claude --permission-mode bypassPermissions

security-reviewer 서브에이전트로 @src/auth 코드를 검토해줘
# 또는
/agents
# → security-reviewer 선택

---
name: test-writer
description: 테스트 작성 전문가. 새 함수/모듈을 추가했거나 "테스트 짜줘"
  라고 할 때 PROACTIVELY 사용. 엣지 케이스와 실패 경로까지 커버한다.
tools: Read, Grep, Glob, Edit, Bash
model: sonnet
---

당신은 테스트 작성 전문 엔지니어입니다.

작업 규칙:
1. 먼저 대상 코드와 기존 테스트 컨벤션(파일 위치·네이밍·assert 스타일)을 읽고 맞춘다.
2. 정상 경로 1~2개 + 엣지 케이스(빈 입력, 경계값, null, 예외)를 반드시 포함한다.
3. 테스트 작성 후 실제로 실행해 통과를 확인하고, 실패 시 원인을 보고한다.
4. 프로덕션 코드는 수정하지 않는다 — 버그를 발견하면 테스트로 드러내고 보고만 한다.

# 메인 컨텍스트를 보존하면서 조사
Explore 서브에이전트로 이 프로젝트의 데이터베이스
모델 구조를 파악해줘. 모든 모델 파일을 찾고,
각 모델의 필드와 관계를 표로 정리해줘.

# → 서브에이전트가 별도 컨텍스트에서 탐색
# → 결과 요약만 메인 세션에 반환
# → 메인 세션 컨텍스트는 깨끗하게 유지

# 한 번에 여러 조사를 병렬로
다음을 병렬로 진행해줘:
1. Explore 에이전트로 @src/api 의 모든 엔드포인트 목록 수집
2. Explore 에이전트로 @tests 의 테스트 커버리지 분석
3. 위 두 결과를 비교해서 테스트 없는 엔드포인트 찾기

# 보안 검토
security-reviewer로 @src/auth 검토해줘

# 성능 분석
performance-engineer로 @src/api/search 의
N+1 쿼리 문제를 찾아줘

# 테스트 작성
test-writer로 @src/utils/parser.ts 의
엣지 케이스 테스트를 추가해줘

# 메인 세션에서 한 줄로 위임
> security-reviewer로 @src/auth/login.ts 를 검토해줘

# ── 서브에이전트가 별도 컨텍스트에서 실행 ──
#   login.ts, 관련 미들웨어, 환경변수 사용처를 읽고 분석
#   (이 과정의 토큰은 메인 세션 컨텍스트에 쌓이지 않음)
#
# ── 메인 세션에는 "요약 결과"만 돌아옴 ──

[High] login.ts:42 — 비밀번호를 평문으로 로깅함
  → console.log 제거, 마스킹 처리 필요
[Medium] login.ts:58 — 로그인 실패 횟수 제한 없음 (brute-force)
  → rate limiter 미들웨어 추가 권장
[Low] login.ts:13 — JWT 만료시간이 30일로 과도하게 김

# → 메인 세션 컨텍스트는 깨끗하게 유지된 채
#   핵심 결론(3건)만 받아 후속 작업을 이어감

---
name: researcher
description: 자료·코드 탐색 전문가. 구현/문서 작업을 시작하기 전, 관련 코드·API
  문서·기존 패턴을 출처와 함께 모을 때 PROACTIVELY 사용. 코드는 작성하지 않는다.
tools: Read, Grep, Glob, WebFetch
model: sonnet
---

당신은 자료 조사 전문가입니다. 코드를 작성하지 않습니다.

작업 규칙:
1. 요청 주제와 관련된 코드·문서·API를 빠짐없이 찾는다.
2. 각 항목에 출처를 반드시 붙인다 (파일:줄 번호, URL, 라이브러리 버전).
3. 확실한 사실과 추정을 구분해 표시한다.
4. 반환 형식: "사실 목록 + 출처 + 아직 미확인인 항목".

---
name: fact-checker
description: 조사 결과 검증 전문가. researcher가 모은 자료의 정확성·최신성을
  교차검증할 때 사용. deprecated API·버전 불일치·근거 없는 주장을 걸러낸다.
tools: Read, Grep, Glob, WebFetch, Bash
model: opus
---

당신은 팩트체커입니다. 주어진 "사실 목록"을 의심하는 것이 임무입니다.

각 항목에 대해:
1. 출처를 직접 확인해 참 / 거짓 / 근거부족으로 판정한다.
2. deprecated 되었거나 더 최신 방법이 있으면 지적한다.
3. 검증된 사실만 통과시키고, 탈락 항목은 사유와 함께 따로 보고한다.

---
name: builder
description: 구현 전문가. fact-checker가 검증한 자료를 바탕으로 실제 코드/문서를
  작성할 때 사용. 전달받은 검증 자료 범위 안에서만 작업하고 추측하지 않는다.
tools: Read, Grep, Glob, Edit, Write, Bash
model: opus
---

당신은 구현 엔지니어입니다.

규칙:
1. 전달받은 '검증된 사실'만 근거로 쓴다. 자료가 부족하면 추측하지 말고
   무엇이 더 필요한지 보고한다 (→ 메인 세션이 researcher를 다시 돌림).
2. 기존 코드 컨벤션·디렉터리 구조를 따른다.
3. 변경한 파일과 그 이유를 요약해 반환한다.

---
name: qa-verifier
description: 산출물 검증 전문가. builder가 만든 결과가 요구사항을 충족하고
  정상 동작하는지 확인할 때 PROACTIVELY 사용. 빌드·테스트·요구사항 대조를 수행한다.
tools: Read, Grep, Glob, Bash
model: sonnet
---

당신은 QA 검증자입니다. 만든 사람을 신뢰하지 않고 직접 확인합니다.

검증 절차:
1. 빌드·테스트·린트를 실제로 실행한다 (npm test, tsc --noEmit 등).
2. 원래 요구사항을 항목별 체크리스트로 하나씩 대조한다.
3. 통과/실패를 명확히 보고한다. 실패 시 builder가 다시 고칠 수 있도록
   구체적 위치·원인을 남긴다 (# → 메인 세션이 ③으로 되돌림).

> 결제(payment) 모듈을 새로 구현해줘. 다음 순서로 진행:
  1. researcher 로 결제 API 문서와 기존 결제 코드를 조사
  2. 그 결과를 fact-checker 로 검증 (deprecated API 거르기)
  3. 검증된 자료로 builder 가 모듈 구현
  4. qa-verifier 로 테스트·요구사항 통과 확인
  5. qa-verifier가 실패를 보고하면 builder로 돌아가 통과까지 3·4 반복

# 세션 A: 마이그레이션 영향 범위를 계속 조사 중
# 세션 B: 실제 구현 담당

# 세션 B에서
@세션A 지금까지 찾은 oldClient 호출 지점 목록을 넘겨줘

{
  "hooks": {
    "PostToolUse": [{
      "matcher": "Write|Edit",
      "hooks": [{
        "type": "command",
        "command": "npm run lint:fix"
      }]
    }],
    "Stop": [{
      "hooks": [{
        "type": "command",
        "command": "osascript -e 'display notification \"Claude 대기 중\"'"
      }]
    }]
  }
}

{
  "hooks": {
    "PostToolUse": [{
      "matcher": "Write|Edit",
      "hooks": [
        { "type": "command", "command": "black ." },
        { "type": "command", "command": "isort ." }
      ]
    }]
  }
}

{
  "hooks": {
    "PreToolUse": [{
      "matcher": "Bash",
      "hooks": [{
        "type": "command",
        "command": "grep -E '(rm -rf /|sudo|git push.*--force)' && exit 1 || exit 0"
      }]
    }]
  }
}
# → 위험 명령이 감지되면 차단됨

{
  "hooks": {
    "SessionStart": [{
      "hooks": [
        { "type": "command", "command": "test -f .env || echo '⚠️  .env 파일 없음'" },
        { "type": "command", "command": "node --version | grep -q v18 || echo '⚠️  Node 18 필요'" }
      ]
    }]
  }
}

# 이슈 자동 구현
이슈 ENG-4521의 요구사항대로 구현하고 PR 만들어줘.
관련 코드 검색 → 구현 → 테스트 → 커밋 → PR 생성까지.

# PR 리뷰 자동화
PR #234의 변경사항을 리뷰하고 댓글로 피드백 남겨줘.

# 이슈 정리
'bug' 라벨이 붙은 오픈 이슈를 우선순위별로 정렬해줘.

# 시나리오: 신규 기능 출시 알림
다음을 순서대로 진행해줘:
1. GitHub에서 v2.0 마일스톤의 머지된 PR 목록 가져오기
2. Notion '릴리즈 노트' DB에 v2.0 페이지 생성
3. PR 제목과 설명을 요약해서 페이지에 정리
4. Slack #releases 채널에 알림 보내기
5. Gmail로 베타 사용자들에게 안내 메일 초안 작성

# PostgreSQL MCP 활용
PostgreSQL DB에서 최근 24시간 이내
가입한 사용자 수와 활성 비율을 조회해줘.

# 결과를 코드에 반영
위 쿼리 결과를 바탕으로 @src/dashboard/stats.ts 의
가입자 통계 표시 로직을 업데이트해줘.

/fix-issue 123

login(email, password): Promise<AuthToken> 구현.

정상: 일치 → 토큰 반환

엣지 케이스 (반드시 처리):
1. 존재하지 않는 사용자 → 404
2. 비밀번호 틀림 → 401
3. 3회 연속 실패 → 30분 잠금
4. 이미 로그인 → 새 토큰 발급 (기존 무효화)
5. 이메일 미인증 → 403 + 인증 메일 재전송
6. 빈 문자열 → 400
7. null/undefined → TypeError

@apps/web/src/pages/profile.tsx 리뉴얼.

디자인 목표:
- 세로 → 가로 2컬럼
- 배경: 흰색 → 그라데이션
- 버튼: 파란색 → 보라색

검증 방법:
1. 스크린샷 비교 (before/after.png)
2. 반응형 (375px/768px/1200px)
3. 접근성: 색상 대비 4.5:1 이상

완성 기준:
- 스크린샷에서 의도와 일치
- npm run test:a11y 통과

TypeScript로 구현. 다음 스타일:

코드 스타일:
- ES2024 modules
- strict 타입 (any 금지)
- 함수형 (mutable 최소화)
- 2칸 들여쓰기, 80자 라인

이름 규칙:
- 함수: camelCase
- 상수: UPPER_SNAKE_CASE
- 클래스/인터페이스: PascalCase

에러:
- 예외 throw (undefined 반환 금지)
- @src/errors의 커스텀 에러 클래스 사용

processPayment()를 TDD로 구현해줘.

1단계: @tests/payment.test.ts에 테스트 작성
- ✅ 정상: amount, currency → 성공
- ❌ 잔액 부족 → PaymentInsufficientError
- ❌ 미지원 통화 → PaymentCurrencyError
- ❌ 부정 거래 → PaymentSuspiciousError
- ⚠️ 네트워크 3회 실패 → 롤백

2단계: 테스트 통과하는 코드 구현
- 각 테스트 먼저 실행 (실패 확인)
- 통과시키는 최소 구현
- 진행 보고: "X/7 통과"

3단계: 전체 테스트 실행
4단계: PR 생성

1차: "로그인 함수 구현해줘"
  → 기본 구현 완료

2차: "DB 쿼리 관점에서 개선점 찾아줘"
  → N+1 쿼리 발견 → 수정

3차: "보안 문제 찾아줘 (입력 검증, 토큰)"
  → XSS 취약점 발견 → 수정

4차: "엣지 케이스 테스트 추가"
  → 테스트 보강

5차: /simplify + JSDoc 추가

# 완전히 다른 작업 시작
/clear

# 같은 작업 계속하되 정리
/compact "최신 auth 구현과 테스트 결과 보존"

# 특정 시점부터 정리
Esc Esc → Summarize 선택

다음 문제 알고리즘 설계 (깊은 사고 단계 포함):

문제: 100만 주문 데이터에서 사기 거래 실시간 탐지
- 지연 < 100ms
- 메모리 < 500MB
- 오탐지율 < 1%
- 온라인 학습 지원

다양한 접근법 검토 → 장단점 분석 → 최선 솔루션 구현

sub-agent로 @src/ 디렉토리를 탐색해줘.
주요 구조, 의존성, 데이터 흐름 파악 후 요약 보고.

# → 메인 컨텍스트 보존, 별도 컨텍스트에서 탐색

[스크린샷 붙여넣기]

이 디자인을 React 컴포넌트로 구현해줘.
- Tailwind CSS
- 반응형 + 호버/포커스 상태
- 구현 후 스크린샷 찍어서 비교

맥 스크린샷: Cmd+Shift+4 → 영역 선택 → Claude Code에서 Ctrl+V

Python 3.11+ 환경:
- poetry로 의존성 관리
- 사용 가능: requests, pandas, numpy, pydantic
- 테스트: pytest

스타일:
- PEP 8 준수
- Type hints 필수 (from typing import ...)
- Docstring: Google 스타일

타입 안정성:
- strict mode (tsconfig.json)
- any 금지
- React.FC 사용 X, 함수 + interface Props
- 제네릭은 extends로 제약

컴포넌트 구조:
UserList/
├── UserList.tsx (컨테이너)
├── UserListItem.tsx
├── UserDetailModal.tsx
└── useUserList.ts (훅)

상태: @src/store의 Zustand

POST /api/payments

요청:
{
  "userId": "uuid",
  "amount": number (센트),
  "currency": "USD" | "EUR" | "KRW",
  "idempotencyKey": "string"
}

응답 (200):
{
  "transactionId": "uuid",
  "status": "completed"
}

에러:
- 400: 형식 오류
- 402: 결제 거절
- 409: idempotencyKey 중복 → 이전 결과
- 503: 결제 서버 장애 + Retry-After

다음 원칙으로 리팩토링:

1. DRY: 중복 로직 추출
2. SOLID:
   - 단일 책임 (한 함수 = 한 일)
   - 개방-폐쇄
   - 인터페이스 분리
3. 가독성:
   - 변수명 명확
   - 함수 길이 < 20줄
   - 중첩 < 3단계

리팩토링 후:
- 기존 테스트 모두 통과 확인
- Before/After 요약

@src/features/search/search.ts 최적화:

측정 항목:
1. 응답 시간 목표 < 100ms
2. 메모리 사용
3. DB 쿼리 (N+1, 인덱스)

기법:
- 쿼리 배치 처리
- 캐싱 (Redis)
- 인덱싱 전략
- 알고리즘 개선

결과:
1. 벤치마크 전/후 비교
2. 메모리 프로파일
3. 쿼리 최적화 설명

보안 전문가로서 검토:

1. 입력 검증 (SQL injection, XSS, CSRF)
2. 인증/인가 (JWT, 권한, 세션)
3. 데이터 보호 (암호화, 로그)
4. API 보안 (rate limit, CORS)

결과:
- 심각도 (High/Medium/Low)
- 수정 방법 (코드 예시)

@src/auth/login.ts PR 리뷰:

항목:
1. 정확성
2. 테스트 커버리지
3. 성능 (병목)
4. 보안 (취약점)
5. 스타일 일관성
6. 문서화

결과:
[ ] 승인 가능
[ ] 변경 필요
[ ] 변경 + 재검토

각 항목별 구체적 피드백 + 코드 예시

# 세션 하나에 프로젝트별 window를 만들고 각각 claude -c 실행
tmux new-session  -d -s work -c ~/projects/app-a   # 창1
tmux send-keys    -t work 'claude -c' C-m
tmux new-window   -t work    -c ~/projects/app-b   # 창2
tmux send-keys    -t work 'claude -c' C-m
tmux attach       -t work                          # 한 화면에서 창 전환하며 사용

# 각 프로젝트를 새 Terminal 탭에서 이어서 열기 (osascript)
for dir in ~/projects/app-a ~/projects/app-b ~/projects/api; do
  osascript -e "tell application \"Terminal\" to do script \"cd $dir && claude -c\""
done

• /schedule 류의 예약 실행(routine) — 정해진 시각/주기에 원격에서 에이전트 실행
• 로컬에서 길게 도는 작업은 /loop(주기 반복) · /background(백그라운드 태스크)와 조합
• 돌아가는 상태를 보고 싶으면 claude agents(Agent view)에서 peek·attach
• 폰에서 확인·조작하려면 Remote Control(claude remote-control) — 단, 커스텀 게이트웨이와는 충돌한다 (18장)
• 조직 인프라 위에서 돌려야 한다면 self-hosted environments(claude self-hosted-runner, Team/Enterprise 퍼블릭 베타)
• 핵심: "사람이 지켜봐야 하는 대화"는 로컬 세션, "스스로 돌아도 되는 일"은 클라우드 예약으로 분리

# 광학 수차 다이어그램의 물리 검수처럼 틀리면 안 되는 작업
ultrathink 비점수차 그림에서 자오/구결 초점선 방향이 표준과 맞는지 검증해줘

# 평범한 작업엔 굳이 붙일 필요 없다 (지연·토큰만 늘어남)
central_bank.html 맨 아래에 page-tools 블록 추가해줘

# 1) obra 마켓플레이스 등록
/plugin marketplace add obra/superpowers-marketplace
# 2) 플러그인 설치
/plugin install superpowers
# 설치 후 /plugin 으로 포함된 스킬·명령 확인

# 남의 저장소를 처음 돌려볼 때
# 설치 스크립트·빌드가 무엇을 하는지 모를 때
# 자율 루프(/goal, /loop)를 오래 돌려둘 때

→ 권한을 느슨하게 풀더라도 샌드박스는 켜두는 편이 낫다.
  "Bypass + 샌드박스 없음"이 가장 위험한 조합이다.

claude -p "테스트 실패 원인을 요약하고 수정 패치를 제안해줘" \
  --bare \
  --output-format json \
  --permission-mode dontAsk \
  --allowedTools "Read,Grep,Glob,Bash(npm test)" \
  --permission-prompts none

1. 새 세션 시작
claude

2. 작업 이름 부여
/rename feature-google-oauth

3. Plan 모드로 이동
Shift+Tab → Plan

4. 분석 및 계획
@src/auth/session.ts 와 @docs/oauth-spec.md 를 보고
Google OAuth를 추가하는 계획을 세워줘.
- 수정할 파일 목록
- 필요한 환경변수
- 새 테스트 케이스
- 배포 시 주의사항

5. 계획 검토 (Ctrl+G로 에디터에서 편집)

6. 실행 모드로 전환
Shift+Tab → Auto (또는 Accept edits)

7. 구현 진행
계획대로 구현해줘. 각 단계마다 테스트 통과 확인.

8. 코드 정리
/simplify

9. 보안 검토 (인증 코드라서)
/security-review

10. 최종 리뷰
/review

11. 커밋 & PR
! git commit -am "feat: Google OAuth 추가"
! gh pr create --fill

1. 에러 재현
! python app.py
# → 에러 출력

2. 원인 분석 (관련 파일 제시)
위 에러의 원인을 @src/api/payment.ts 에서 찾아줘.
스택 트레이스 기준으로 정확한 위치 짚어줘.

3. 재현 테스트 먼저 작성
이 버그를 재현하는 테스트를 @tests/payment.test.ts 에
추가해줘 (실패하는 상태로).

4. 테스트 실행 (실패 확인)
! pytest tests/test_payment.py::test_bug_repro -v

5. 수정 진행
이제 버그를 수정해서 위 테스트가 통과하도록 해줘.

6. 전체 테스트 실행
! pytest

7. 커밋
! git commit -am "fix: 결제 실패 시 트랜잭션 롤백 안 되던 버그"

1. 변경 사항 확인
! git diff main..HEAD --stat
! git diff main..HEAD

2. 종합 리뷰
/review

3. 도메인별 추가 리뷰
security-reviewer 서브에이전트로 검토해줘.

performance-engineer 관점에서
@src/api/search.ts 의 쿼리 최적화 포인트를 찾아줘.

4. 테스트 커버리지 점검
QA engineer로서 @src/api/search.ts 의 엣지 케이스
중 테스트가 누락된 것을 찾아줘.

5. 문서 점검
technical writer로서 @docs/api.md 가
@src/api 의 변경사항과 동기화되어 있는지 확인해줘.

1. 백업
! git checkout -b refactor/callback-to-async

2. Plan Mode로 영향 분석
Shift+Tab → Plan Mode

Explore 서브에이전트로 @src 에서 콜백 패턴을
사용하는 모든 파일을 찾아줘. 다음 정보를 표로:
- 파일 경로
- 콜백 사용 함수
- 외부에서 호출하는 위치
- async/await 마이그레이션 난이도 (상/중/하)

3. 단계 분해
위 결과를 바탕으로 의존성 없는 leaf부터
순서대로 마이그레이션할 계획을 세워줘.
한 PR에 묶을 단위도 나눠줘.

4. 단계별 구현 (각 PR마다)
Shift+Tab → Accept edits
1단계 PR: @src/utils 폴더만 마이그레이션해줘.
기존 테스트가 모두 통과하는지 확인.

5. 검증 후 PR 생성
/review
! gh pr create --fill

6. 다음 단계로 (/clear 후 새 세션)
/clear

1. /init으로 CLAUDE.md 생성
/init

2. Plan Mode로 전체 구조 탐색
Shift+Tab → Plan Mode

이 프로젝트의 아키텍처를 파악해줘:
- 사용 언어/프레임워크
- 디렉토리 구조와 각 폴더의 역할
- 진입점(entry point)과 라우팅
- 데이터베이스 모델
- 인증 흐름
- 외부 의존성

3. 핵심 흐름 다이어그램
사용자가 회원가입을 하면 어떤 순서로 어떤
파일들이 호출되는지 시퀀스 다이어그램으로 그려줘.

4. README 보충
위 분석 결과를 바탕으로 @README.md 의 빠진
부분을 보충해줘 (특히 신규 개발자 온보딩 섹션).

5. CLAUDE.md 업데이트
/memory
# 발견한 패턴, 주의사항, 명령어를 CLAUDE.md에 저장