--- allowed-tools: [Read, Write, Edit, MultiEdit, Bash, Glob, Grep, TaskCreate, TaskUpdate, TaskList, TaskGet, Task, WebSearch, WebFetch, AskUserQuestion, mcp__context7-mcp__resolve-library-id, mcp__context7-mcp__query-docs, mcp__sequential-thinking__sequentialthinking, mcp__jina__*] description: "Research-first workflow: 리서치 → 분석 → 실행/수정 → 검증 → 커밋 (상황에 맞게 PHASE 자동 조절)" argument-hint: "feature description (예: 'user authentication' 또는 'dashboard UI component')" disable-model-invocation: false --- # /re - Research & Execute **📌 워크플로우**: 리서치 기반 실행 방법론 **철학**: - **"리서치 없이 구현 없다"** - 모든 구현 전에 철저한 조사를 강제 - **사용자 방향과 의도 파악 우선** - 요청이 모호하거나 여러 해석이 가능할 때, 어떤 Phase에 있든 추측하지 말고 AskUserQuestion으로 명확히 확인. 최대한 질문을 많이해서 사용자의 방향과 의도를 디테일하게 정확히 일치시킨 후에 진행. 최소 컨텍스트 파악(Phase 1) 후 질문. - **엔터프라이즈 레벨 품질** - 임시 방편·우회·타협 대신, 대기업이 택할 근본적이고 유지보수 가능한 궁극적 솔루션 - **작업량/시간 무관** - 오래 걸리고 거대한 작업이라도 최종 품질만 고려 - **토큰 절약 금지** - 효율성 핑계로 정확성을 희생하지 않음 - **복수 옵션 제시** - 항상 최소 3가지 접근법 비교 후 최적안 추천 - **타협 금지** - 구현 난이도나 변경 범위를 이유로 차선책 선택 금지, 리스크 과도 시에만 예외 --- **🎨 UI/UX 가이드라인** (권장): **원칙**: shadcn/ui 컴포넌트 + 테마 변수 최대 활용 1. **shadcn 컴포넌트 우선** - 새 UI 구현 전 shadcn/ui에 해당 컴포넌트가 있는지 먼저 확인 - 없으면 `pnpm dlx shadcn@latest add [component]`로 설치 후 사용 - shadcn에 없는 경우에만 커스텀 컴포넌트 제작 (테마 변수 활용하여 통일감 유지) 2. **테마 변수 사용 (하드코딩 금지)** ```tsx // ❌ 피할 것 - Tailwind 기본 색상 직접 사용
// ✅ 권장 - 테마 변수 클래스 사용
``` --- **사용법**: `/re [feature-description]` --- ## 🚨 강제 실행 단계 ### ✅ PHASE 1: 컨텍스트 파악 (MANDATORY) **목적**: 프로젝트 컨텍스트 파악 및 리서치 타겟 식별 **리서치 디렉토리 생성** (PHASE 시작 전): - feature description에서 slug 생성 (소문자, 공백→하이픈, 특수문자 제거, 최대 30자) - 예: `/re user authentication` → `user-authentication` ```bash mkdir -p /tmp/re-research/{feature-slug}/ ``` **탐색 방법**: Claude Code 내장 도구 자유 활용 - Glob으로 프로젝트 구조 파악 (예: `**/*.ts`, `src/**/*.tsx`) - Grep으로 핵심 패턴 검색 (예: `export.*function`, `import.*from`) - Read로 주요 설정 파일 확인 (package.json, tsconfig.json 등) - 필요시 Explore subagent로 병렬 탐색 (대규모 코드베이스) **Git History 확인** (git repo인 경우): **1단계: 직접 관련 커밋 검색** ```bash # 현재 작업 키워드로 검색 (예: auth, payment, dashboard) git log --oneline -50 --grep="키워드" --format="%h %s" ``` **2단계: 프로젝트 공통 교훈 확인** ```bash # 키워드 무관하게 최근 학습 태그 훑어보기 git log --oneline -30 --grep="\[gotcha\]\|\[insight\]\|\[context\]" --format="%s" ``` **3단계: 필요한 커밋만 상세 확인** ```bash git show --format="%B" --no-patch ``` - 1단계: 현재 작업과 **직접** 관련된 커밋 - 2단계: **프로젝트 전반 교훈** (다른 작업에서 배운 것도 적용 가능) - 자율적으로 현재 작업에 적용 가능한 학습 판단 - 관련 없는 커밋은 무시 **필수 산출물**: - 📦 기술 스택 및 라이브러리 버전 - 🏗️ 프로젝트 패턴 (App Router, 상태관리, API 통신, 스타일링 등) - 🏷️ 네이밍 컨벤션 및 디렉토리 구조 - 🎯 리서치 타겟 (Context7 라이브러리, 웹 검색 키워드) - 📜 이전 세션 학습 내용 (Git History에서 추출한 insight/gotcha/decision) **완료 표시**: TaskUpdate로 "PHASE 1 완료" 마크 --- ### ✅ PHASE 2: 리서치 (MANDATORY) **목적**: 공식 문서 권장 패턴(최우선) → 검증된 업계 모범사례 → 커뮤니티 사례 확보 **🚀 병렬 실행 전략** (Scatter-Gather 패턴): ⚠️ **순차 실행 금지** - 독립적인 검색은 반드시 병렬로 실행 **기본: Task subagent 3~7개 병렬화** (작업 복잡도에 따라 조절) 주제 분석 후 subagent에 조사 영역 분배: - **3~7개** subagent 동시 실행 (단순 3개, 중간 4~5개, 복잡 6~7개) - 각 subagent가 충분한 소스를 확보 - 주제 특성에 맞게 조사 영역 세분화 - 모델: `model: "haiku"` 고정 ``` # 예시: "Next.js 인증 구현" 주제 → 4개 subagent 분배 (model: "haiku") Task("Next.js App Router 공식 인증 패턴 + OAuth 2.0 프로토콜", model: "haiku") Task("세션 vs JWT 토큰 전략 비교", model: "haiku") Task("NextAuth.js vs Lucia 비교 분석", model: "haiku") Task("인증 보안 취약점 및 대응 (OWASP)", model: "haiku") ``` → 각 subagent: Context7 + WebSearch + Jina MCP 사용 (WebFetch 금지) → 각 subagent: 핵심 결론과 구체적 식별자를 포함하여 반환. 상세(원문 인용/URL/코드)는 /tmp/re-research/{feature-slug}/ 파일에 작성 → subagent 프롬프트에 "상세는 /tmp/re-research/{feature-slug}/[주제명].md에 작성." 지시 → TaskOutput으로 결과 수집 후 통합 **보조: 도구 직접 호출** (간단한 확인 작업 시) ``` WebSearch("특정 키워드") + Context7("라이브러리", topic="주제") ``` → 1-2개 빠른 확인 시에만 사용 **필수 워크플로우** (Context7): 1. `resolve-library-id`로 관련 라이브러리 **여러 개 동시** 식별 2. `query-docs`로 공식 문서 **병렬** 조회 - 자율 선택: 조회할 라이브러리 선택, topic 파라미터 **필수 조건**: - **Context7 워크플로우**: 필수 실행 - **subagent 수**: 3~7개 (단순 3개, 중간 4~5개, 복잡 6~7개) - **소스 수**: 각 subagent가 충분한 소스를 확보 - **병렬 실행**: 모든 subagent 동시 실행 (순차 금지) - **모델**: `model: "haiku"` 고정 **리서치 전략**: - Context7 + WebSearch + Jina MCP로 공식 문서 → 검증된 업계 모범사례 → 커뮤니티 사례 동시 수집 - 교차 검증: 핵심 결정 사항은 2+ 독립 소스로 확인 - 신뢰 가능 소스 우선 (공식 블로그, 프레임워크 문서, 개발자 커뮤니티 등) **리서치 도구 (교차 검증용, 공식 문서 신뢰도 최우선)**: - **Context7 MCP** (`resolve-library-id` → `query-docs`) — 공식 문서 조회, 데이터 신뢰도 최우선 - **WebSearch** — 최신 업계 동향 및 모범사례 검색 (예: "Next.js 15 auth patterns 2026") - **Jina MCP** — 웹페이지 본문 추출 (깔끔한 마크다운, Cloudflare 우회) - **WebFetch** — ⚠️ **사용 금지** (병목 원인: 타임아웃 미구현, hang 시 인터럽트 불가) **웹 접근 규칙**: - ⚠️ **WebFetch 사용 금지** — subagent/메인 모두. Jina MCP로 대체 - subagent(haiku)에서 Jina MCP 사용 가능 (WebFetch와 달리 타임아웃 지원) - GitHub 이슈/PR은 **gh CLI 우선** 사용 - 자율성: Context7 topic, WebSearch 쿼리, Jina MCP 활용 전략은 자율 판단 **결과 집계 전략**: - 여러 소스에서 동일 정보 = 신뢰도 상승 (교차 검증 원칙) - 출처별 우선순위: 공식 문서 > 검증된 업계 모범사례 > 커뮤니티 - 상충 정보는 최신 날짜 우선 **필수 산출물**: - 📚 **공식 권장 패턴**: 공식 문서 기반 베스트 프랙티스 - 🌐 **검증된 업계 모범사례**: 커뮤니티 검증된 최신 모범사례 (현재 연도 기준) - ❌ **안티패턴**: 회피해야 할 접근법 및 주의사항 - 🎯 **사용자 명령 수행 정보**: 현재 작업에 필요한 모든 관련 정보 **완료 표시**: TaskUpdate로 "PHASE 2 완료" 마크 --- ### ✅ PHASE 3: 코드베이스 전체 분석 (MANDATORY) **목적**: 구현 전 관련 코드를 **전부** 파악하여 일관성 있는 구현 보장 **⚠️ 핵심 원칙: 정확성 최우선** 코드를 일부분만 대충 훑어보는 것은 **절대 금지**. 관련 코드는 반드시 **전체를 읽어야** 한다. 일부만 보고 추측하면 기존 패턴과 충돌하거나 중복 구현이 발생한다. **분석 방법**: 1. **관련 파일 전수 조사**: Glob으로 관련 파일을 **모두** 찾아낸다 2. **전체 코드 읽기**: 찾은 파일은 **전부 Read**로 완독한다 (일부만 읽기 금지) 3. **패턴 추출**: 읽은 코드에서 기존 패턴을 정확히 파악한다 **구체적 실행**: - 새 기능과 관련된 기존 컴포넌트/함수/타입 **전체** 읽기 - 비슷한 기능이 이미 있는지 **전체 코드베이스** 확인 - import/export 관계, 의존성 **완전히** 파악 - 필요시 Explore subagent로 병렬 탐색 (대규모 코드베이스) **왜 전체를 읽어야 하는가**: - 일부만 보면 기존 유틸/헬퍼 함수를 못 찾고 중복 구현함 - 네이밍 컨벤션, 에러 처리 패턴 등을 놓침 - 기존 코드와 스타일이 불일치하는 코드를 작성함 **필수 산출물**: - 📂 프로젝트 구조 맵 - 🏗️ 기존 아키텍처 패턴 (실제 코드 기반, 추측 아님) - 🔗 통합 지점 (새 기능 삽입 위치) - 📝 읽은 파일 목록 (전체 코드 파악 증빙) - ✔️ PHASE 2 검증 결과 (리서치 패턴 vs 프로젝트 구현) **완료 표시**: TaskUpdate로 "PHASE 3 완료" 마크 --- ### ✅ PHASE 4: 구현 계획 및 최적 솔루션 선정 1. **PHASE 1, 2, 3 완료 확인** (미완료 시 구현 불가) 2. **Sequential Thinking MCP로 종합 분석**: - Context7 공식 가이드라인 - 웹 최신모범사례 vs 안티패턴 - 프로젝트 패턴 vs 통합 지점 - 리스크 및 대안 평가 **🔍 자기검증 3질문** (Sequential Thinking 완료 전 반드시 포함): - "이 분석에서 **가장 어려운 결정**은 무엇이었나?" - "어떤 **대안을 거부**했고, **왜** 그랬나?" - "**가장 확신이 없는 부분**은?" → 목적: 옵션이 답정너가 되지 않고 진정으로 competitive하게 + 판단의 신중성 확보 3. **코딩 핵심 체크**: - **중복 제거 (SSOT)**: 같은 로직/상수 중복 여부 - **보안 검증**: 민감 정보 노출, 입력 검증 누락 - **컨텍스트 일관성**: 프로젝트 패턴 준수 4. **최소 3가지 구현 옵션 도출** (필수): - ⚠️ 모든 옵션은 엔터프라이즈 레벨 품질 기준 충족 필수 (임시 방편/우회 방법 제외) - 각 옵션마다 반드시 포함: - **개요**: 접근 방식 한 줄 요약 - **변경 영역**: 수정할 컴포넌트/모듈/레이어 명시 (파일명 아닌 영역 수준) - **기술적 Trade-off**: 성능 vs 복잡도, 유연성 vs 학습비용 등 - **리스크/주의사항**: 선택 시 주의할 점 - **유지보수/확장성**: 장기적 관점에서의 영향 - **사용자 영향**: 최종 결과물/UX 차이 - **향후 변경 시**: 기능 추가/수정 시 영향 - **권장 상황**: 어떤 경우에 이 옵션이 적합한지 5. **최적 솔루션 추천 + 객관적 비교**: - 평가 기준 명시: SSOT, 확장성, 유지보수성, 공식 권장사항, 업계 표준 등 - 각 옵션을 기준별로 비교한 후 최적안 도출 (주관적 추천 아닌 객관적 비교) - ⚠️ **중요**: 작업량은 평가 대상 아님 (최종 품질만 고려) - ⚠️ **선정 원칙**: 리스크가 과도하지 않은 한, 항상 가장 근본적이고 완전한 솔루션 선택 (중간 타협안/절충안 지양) 6. **구현 계획 상세화** (필수): - 단순 체크리스트가 아닌 **변경 영역별 상세 설명** - 각 단계마다: 무엇을, 왜, 어떤 순서로 변경하는지 명시 - 필요 시 10개 이상 항목도 OK (상세함 우선) 7. TaskUpdate로 "옵션 A/B/C 도출, 최적 솔루션: [X]" 마크 ⏸️ **승인 대기** (PHASE 5 진행 전 필수) - 옵션 비교표 + 최적 솔루션 제시 - 선택지: **"1) 추천안 진행 / 2) 다른 옵션 선택 / 3) 수정 요청 / 4) 추가 탐색"** ✅ **승인 후 실행 흐름**: - 사용자 승인 시 → PHASE 5 (구현 및 검증) 진행 - PHASE 5 완료 후 사용자에게 다음 단계 선택 요청 **필수 산출물**: 옵션 비교, 최적안 추천, 구체적 근거, 단계별 계획, 리스크 대응 --- ### ✅ PHASE 5: 구현 및 검증 1. 승인된 계획에 따라 단계별 구현 2. 각 단계마다 TaskUpdate 업데이트 3. PHASE 2, 3, 4 결과 준수 확인: - 공식 가이드라인 적용 - 검증된 업계 모범사례 반영 - 프로젝트 패턴 일관성 - 핵심 체크 통과 4. 구현 완료 후 자동 품질 검증: #### 🔍 1차: 기계적 검증 (verify→fix 루프) **TypeCheck + Lint 병렬 실행** (단일 응답에서 2개 Bash 동시 호출) - 실패 시 → 자동 수정 → 재검증 (최대 3회 루프) - 이번 세션에서 수정한 파일의 오류만 수정 #### 🔍 2차: 의미적 리뷰 - 이번 세션에서 수정한 파일 전체를 Read로 완독 - 논리적 오류, 일관성, 엣지케이스, 보안 취약점 점검 - 발견 시 자동 수정 → 1차(기계적 검증) 재실행 - 모든 검증 통과 → 사용자 선택 대기 --- ⏸️ **PHASE 5 완료 후 사용자 선택** (AskUserQuestion) 검증 통과 후 사용자에게 다음 단계 선택 요청: - **1) Cleanup → Commit → /rrr** (GLM-5 코드 리뷰) - **2) Cleanup → Commit → Push** - **3) Cleanup → Commit만** (Push 없음) - **4) 추가 작업 (직접 입력)** --- ### 🚀 PHASE 6: Commit & Push **실행 조건**: 사용자가 옵션 1, 2, 또는 3 선택 시 #### 🧹 STEP 1: Code Cleanup **목적**: Commit 전 최종 정리 - 이번 세션에서 발생한 모든 정리 필요 사항을 자율 판단하여 처리 **정리 대상** (자율 판단): - 미사용 import/변수/함수 제거 - 임시 주석 및 디버그 코드 제거 - 불필요한 console.log 제거 - 세션 중 남겨둔 TODO 처리 - `pnpm lint --fix` 실행 --- #### 🚢 STEP 2: Commit & Push **조건**: Git 환경 확인 후 실행 (`.git` 없으면 스킵) **커밋 형식**: Conventional Commits + 학습 태그 ``` feat(auth): Add Google OAuth with refresh token rotation - OAuth 2.0 authorization code grant 구현 - Access/Refresh token 자동 갱신 로직 [context] auth 모듈은 next-auth 없이 직접 구현 (경량화 목적) [insight] OAuth state 파라미터는 CSRF 방지 필수 [gotcha] Google은 prompt=consent 있어야만 refresh_token 반환 [decision] JWT 대신 httpOnly 쿠키 선택 - XSS 공격 표면 최소화 [followup] silent refresh 미구현 - 토큰 만료 시 UX 영향 🤖 Generated with Claude Code Co-Authored-By: Claude ``` **학습 태그 가이드**: | 태그 | 용도 | |------|------| | `[context]` | 향후 세션에 필요한 배경/맥락 | | `[insight]` | 새로 배운 사실, 패턴, 베스트 프랙티스 | | `[gotcha]` | 함정, 삽질 원인, 문서에 없는 주의사항 | | `[decision]` | 설계/아키텍처 결정과 그 이유 | | `[followup]` | 미완성 작업, 기술 부채, 후속 필요 사항 | ⚠️ **필수 아님** - 의미 있는 학습이 있을 때만 기록 (모든 커밋에 강제 X) **워크플로우**: - 옵션 1: `git commit` → `/rrr` (GLM-5 코드 리뷰 스킬 호출) - 옵션 2: `git commit` → `git push origin main` - 옵션 3: `git commit`만 --- ## 🎉 완료 시 출력 커밋 정보, 주요 변경사항, 검증 결과 --- ## 🛡️ 체크포인트 - PHASE 1, 2, 3: **MANDATORY** (미완료 시 구현 불가) - PHASE 4: 사용자 승인 필수 → 승인 후 PHASE 5 실행 - PHASE 5 완료: 사용자 선택 필수 (Commit+/rrr / Commit+Push / Commit만 / 추가작업 직접 입력) - 각 PHASE 완료 시 TaskUpdate 필수 --- ## ⚠️ 멀티 세션 작업 규칙 **상황**: 여러 Claude 세션이 동시에 같은 프로젝트 작업 시 ### 핵심 원칙: 내 작업 범위만 책임진다 1. **TypeCheck/Lint 오류**: 이번 세션에서 수정한 파일이 아니면 **절대 고치지 않음** (다른 세션 작업 중일 수 있음) 2. **Git 커밋**: 이번 세션에서 직접 수정한 파일만 커밋 (`git add .` 금지) 3. **Working Tree 보호**: `git diff`에 내가 수정하지 않은 파일이 보여도 **다른 세션 작업**일 수 있음. `git restore`/`git checkout --`는 bash-guard hook이 차단. 에이전트의 실수가 의심되면 사용자에게 확인 후 조치. ```bash # ✅ 개별 파일 명시 git add src/components/Button.tsx src/hooks/useAuth.ts # ❌ 금지 (bash-guard hook이 차단) git restore -- <파일> git checkout -- <파일> # ❌ 금지 git add . git add -A ``` --- **버전**: 13.5.0 **출처**: https://github.com/dgk-dev/dgk-claude