selfish-pipeline 1.0.0

package/commands/init.md

@@ -0,0 +1,97 @@
+# /selfish:init — 프로젝트 초기 설정
+
+> 현재 프로젝트에 `.claude/selfish.config.md` 설정 파일을 생성한다.
+> package.json, 디렉토리 구조, 설정 파일 등을 분석하여 프로젝트에 맞는 설정을 자동 추론한다.
+
+## 인자
+
+- `$ARGUMENTS` — (선택) 템플릿 프리셋 이름 (예: `nextjs-fsd`)
+  - 미지정 시: 프로젝트 구조를 분석하여 자동 추론
+  - 프리셋 지정 시: `${CLAUDE_PLUGIN_ROOT}/templates/selfish.config.{preset}.md` 사용
+
+## 실행 절차
+
+### 1. 기존 설정 확인
+
+`.claude/selfish.config.md`가 이미 존재하면:
+- 사용자에게 확인: "설정 파일이 이미 존재합니다. 덮어쓰시겠습니까?"
+- 거부 시 **중단**
+
+### 2. 프리셋 분기
+
+#### A. 프리셋 지정 (`$ARGUMENTS`가 있는 경우)
+
+1. `${CLAUDE_PLUGIN_ROOT}/templates/selfish.config.{$ARGUMENTS}.md` 존재 확인
+2. 있으면: 해당 파일을 `.claude/selfish.config.md`로 복사
+3. 없으면: "프리셋 `{$ARGUMENTS}`을 찾을 수 없습니다. 사용 가능: {목록}" 출력 후 **중단**
+
+#### B. 자동 추론 (`$ARGUMENTS` 없는 경우)
+
+프로젝트 구조를 분석하여 설정을 자동 추론:
+
+**Step 1. 패키지 매니저 / 스크립트 감지**
+- `package.json` 읽기 → `scripts` 필드에서 CI 관련 커맨드 추출
+- lockfile로 패키지 매니저 판별 (yarn.lock / pnpm-lock.yaml / package-lock.json)
+- 감지된 스크립트를 `CI Commands` 섹션에 반영
+
+**Step 2. 프레임워크 감지**
+- `package.json`의 dependencies/devDependencies에서 판별:
+  - `next` → Next.js (App Router/Pages Router는 `app/` 디렉토리 존재 여부로 판별)
+  - `nuxt` → Nuxt
+  - `@sveltejs/kit` → SvelteKit
+  - `vite` → Vite
+  - 등
+- `tsconfig.json` 유무 → TypeScript 여부
+
+**Step 3. 아키텍처 감지**
+- 디렉토리 구조 분석:
+  - `src/app/`, `src/features/`, `src/entities/`, `src/shared/` → FSD
+  - `src/domain/`, `src/application/`, `src/infrastructure/` → Clean Architecture
+  - `src/modules/` → Modular
+  - 기타 → Layered
+- `tsconfig.json`의 `paths` → path_alias 추출
+
+**Step 4. 상태 관리 감지**
+- dependencies에서:
+  - `zustand` → Zustand
+  - `@reduxjs/toolkit` → Redux Toolkit
+  - `@tanstack/react-query` → React Query
+  - `swr` → SWR
+  - `pinia` → Pinia
+
+**Step 5. 스타일링 / 테스팅 감지**
+- `tailwindcss` → Tailwind CSS
+- `styled-components` → styled-components
+- `jest` / `vitest` / `playwright` → 각각 매핑
+
+**Step 6. 코드 스타일 감지**
+- `.eslintrc*` / `eslint.config.*` 확인 → 린트 규칙 파악
+- `tsconfig.json`의 `strict` → strict_mode
+- 기존 코드 샘플 2-3개 읽어 네이밍 패턴 확인
+
+### 3. 설정 파일 생성
+
+1. `${CLAUDE_PLUGIN_ROOT}/templates/selfish.config.template.md`를 기반으로 설정 생성
+2. 자동 추론된 값으로 빈칸 채우기
+3. 추론 불가 항목은 템플릿 기본값 유지 + 주석으로 `# TODO: 프로젝트에 맞게 수정` 표시
+4. `.claude/selfish.config.md`에 저장
+
+### 4. 최종 출력
+
+```
+⚙️ 프로젝트 설정 완료
+├─ 파일: .claude/selfish.config.md
+├─ 프레임워크: {감지된 프레임워크}
+├─ 아키텍처: {감지된 스타일}
+├─ 패키지 매니저: {감지된 매니저}
+├─ 자동 추론: {추론된 항목 수}개
+├─ TODO: {수동 확인 필요 항목 수}개
+└─ 다음 단계: 설정 파일 확인 후 /selfish:spec 또는 /selfish:auto
+```
+
+## 주의사항
+
+- **덮어쓰기 주의**: 기존 설정 파일이 있으면 반드시 사용자 확인.
+- **추론 한계**: 자동 추론은 최선의 추정. 사용자가 검토 후 수정해야 할 수 있음.
+- **프리셋 경로**: 프리셋은 플러그인 내 `templates/` 디렉토리에서 로드.
+- **`.claude/` 디렉토리**: 없으면 자동 생성.

package/commands/plan.md

@@ -0,0 +1,161 @@
+# /selfish:plan — 구현 설계
+
+> 기능 명세(spec.md)를 기반으로 구현 계획(plan.md)을 생성한다.
+> Critic Loop 3회로 품질을 보장하고, 필요 시 리서치를 병렬 수행한다.
+
+## 인자
+
+- `$ARGUMENTS` — (선택) 추가 컨텍스트 또는 제약 조건
+
+## 설정 로드
+
+**반드시** `.claude/selfish.config.md`를 먼저 읽는다. 설정 파일이 없으면 중단.
+
+## 실행 절차
+
+### 1. 컨텍스트 로드
+
+1. **현재 브랜치** 확인 → `BRANCH_NAME`
+2. **specs/{feature}/spec.md** 탐색:
+   - `specs/` 하위에서 현재 브랜치명 또는 `$ARGUMENTS`와 매칭되는 디렉토리 찾기
+   - 없으면: "spec.md가 없습니다. `/selfish:spec`을 먼저 실행하세요." 출력 후 **중단**
+3. **spec.md** 전체 읽기
+4. **memory/principles.md** 읽기 (있으면)
+5. **CLAUDE.md** 프로젝트 컨텍스트 읽기
+
+### 2. 명확화 확인
+
+- spec.md에 `[NEEDS CLARIFICATION]` 태그가 있으면:
+  - 사용자에게 경고: "미해결 명확화 항목이 있습니다. 계속하시겠습니까?"
+  - 사용자가 중단 선택 시 → `/selfish:clarify` 안내 후 **중단**
+
+### 3. Phase 0 — 리서치 (필요 시)
+
+spec.md에서 기술적 불확실성을 추출한다:
+
+1. 사용하지 않은 라이브러리/API가 있는가?
+2. 성능 요구사항이 검증되지 않았는가?
+3. 기존 코드베이스와의 통합 방식이 불확실한가?
+
+불확실 항목이 **있으면**:
+- 각 항목을 WebSearch/코드베이스 탐색으로 해결
+- 결과를 `specs/{feature}/research.md`에 기록:
+  ```markdown
+  ## {주제}
+  **결정**: {선택한 방식}
+  **근거**: {이유}
+  **대안**: {검토한 다른 방식}
+  **출처**: {URL 또는 파일 경로}
+  ```
+
+불확실 항목이 **없으면**: Phase 0 스킵.
+
+### 4. Phase 1 — 설계 작성
+
+`specs/{feature}/plan.md`를 생성한다. 아래 구조를 **반드시** 따른다:
+
+```markdown
+# Implementation Plan: {기능명}
+
+## Summary
+{spec의 핵심 요구사항 + 기술적 접근 요약, 3-5문장}
+
+## Technical Context
+{selfish.config.md에서 로드한 프로젝트 설정 요약}
+- **Language**: {config.code_style.language}
+- **Framework**: {config.framework.name}
+- **State**: {config.state_management 요약}
+- **Architecture**: {config.architecture.style}
+- **Styling**: {config.styling.framework}
+- **Testing**: {config.testing.framework}
+- **Constraints**: {spec에서 추출한 제약사항}
+
+## Principles Check
+{memory/principles.md가 있으면 MUST 원칙 대비 검증 결과}
+{위반 가능성 있으면 명시 + 정당화}
+
+## Architecture Decision
+### 접근 방식
+{선택한 설계의 핵심 아이디어}
+
+### 아키텍처 배치
+| 계층 | 경로 | 역할 |
+|------|------|------|
+| {entities/features/widgets/shared} | {경로} | {설명} |
+
+### 상태 관리 전략
+{Zustand store / React Query / Context 등 어떤 조합을 어디에 쓸지}
+
+### API 설계
+{새로운 API 엔드포인트 또는 기존 API 사용 계획}
+
+## File Change Map
+{변경/생성할 파일 목록. 각 파일에 대해:}
+| 파일 | 작업 | 설명 |
+|------|------|------|
+| {경로} | 생성/수정/삭제 | {변경 내용 요약} |
+
+## Risk & Mitigation
+| 리스크 | 영향 | 완화 방안 |
+|--------|------|-----------|
+| {리스크} | {H/M/L} | {방안} |
+
+## Phase 구분
+### Phase 1: Setup
+{프로젝트 구조, 타입 정의, 설정}
+
+### Phase 2: Core Implementation
+{핵심 비즈니스 로직, 상태 관리}
+
+### Phase 3: UI & Integration
+{UI 컴포넌트, API 연동}
+
+### Phase 4: Polish
+{에러 처리, 성능 최적화, 테스트}
+```
+
+### 5. Critic Loop (3회)
+
+plan.md 초안 작성 후, **최대 3회** 자가 비판을 수행한다.
+
+각 회차마다 아래 5가지 기준을 검증:
+
+| 기준 | 검증 내용 |
+|------|-----------|
+| **COMPLETENESS** | spec.md의 모든 요구사항(FR-*)이 plan에 반영되었는가? |
+| **FEASIBILITY** | 기존 코드베이스와 호환 가능한가? 의존성이 사용 가능한가? |
+| **ARCHITECTURE** | {config.architecture} 규칙을 준수하는가? |
+| **RISK** | 식별되지 않은 리스크가 있는가? |
+| **PRINCIPLES** | principles.md의 MUST 원칙을 위반하지 않는가? |
+
+**사용자 출력 규칙**:
+- **FAIL 항목이 있으면**: `⚠ {기준}: {문제 요약}. 수정 중...` 표시 → plan.md 수정 → 다음 회차
+- **FAIL 항목이 없으면**: `✓ Critic {N}/3 통과` 한 줄
+- **최종**: `Critic Loop 완료 ({N}회). 주요 수정: {변경 요약}` 또는 `Critic Loop 완료 (1회). 수정 없음.`
+
+### 6. Agent Teams (필요 시)
+
+리서치 항목이 3개 이상이면, Task 도구로 병렬 리서치 에이전트를 위임:
+
+```
+TaskCreate("Research: {주제1}", subagent_type: Explore)
+TaskCreate("Research: {주제2}", subagent_type: Explore)
+→ 결과 수집 → research.md에 통합
+```
+
+### 7. 최종 출력
+
+```
+📋 Plan 생성 완료
+├─ specs/{feature}/plan.md
+├─ specs/{feature}/research.md (리서치 있었으면)
+├─ Critic: {N}회, 주요 수정: {요약}
+└─ 다음 단계: /selfish:tasks
+```
+
+## 주의사항
+
+- plan.md는 **실행 가능한 수준**으로 작성. 모호한 "적절히 처리" 같은 표현 금지.
+- File Change Map의 파일 경로는 **실제 프로젝트 구조**에 기반해야 함 (추측 금지).
+- {config.architecture} 규칙에 따라 배치하며, 기존 코드베이스 패턴을 확인하고 따름.
+- CLAUDE.md의 프로젝트 설정과 충돌하면 CLAUDE.md가 우선.

package/commands/principles.md

@@ -0,0 +1,94 @@
+# /selfish:principles — 프로젝트 원칙 관리
+
+> 프로젝트의 핵심 원칙(constitution)을 생성하고 관리한다.
+> memory/principles.md에 저장되어 모든 세션에서 참조된다.
+
+## 인자
+
+- `$ARGUMENTS` — (선택) 동작 지시:
+  - 미지정: 현재 원칙 조회
+  - `add {원칙}`: 새 원칙 추가
+  - `remove {번호}`: 원칙 제거
+  - `init`: 대화형 초기 설정
+
+## 설정 로드
+
+**반드시** `.claude/selfish.config.md`를 먼저 읽는다. 설정 파일이 없으면 중단.
+
+## 실행 절차
+
+### 1. 현재 상태 확인
+
+`memory/principles.md` 읽기:
+- 있으면: 기존 원칙 로드
+- 없으면: 빈 상태 (init 안내)
+
+### 2. 동작 분기
+
+#### A. 조회 (인자 없음)
+현재 원칙 목록을 표시:
+```
+📜 프로젝트 원칙
+├─ MUST-001: {원칙}
+├─ MUST-002: {원칙}
+├─ SHOULD-001: {원칙}
+└─ 마지막 수정: {날짜}
+```
+
+#### B. 초기 설정 (`init`)
+
+대화형으로 원칙 수집:
+
+1. **프로젝트 컨텍스트** 분석 (CLAUDE.md, package.json, 코드 구조)
+2. 자동 추출 가능한 원칙 제안:
+   - {config.architecture} 규칙 준수
+   - {config.code_style} 준수
+   - 린트 경고 0 ({config.lint} 기준)
+   - 등
+3. 사용자에게 추가 원칙 질문 (AskUserQuestion)
+4. 수집된 원칙을 구조화
+
+#### C. 추가 (`add`)
+1. 새 원칙의 강도 결정 (MUST / SHOULD / MAY)
+2. principles.md에 추가
+3. 버전 업데이트
+
+#### D. 제거 (`remove`)
+1. 해당 원칙 확인
+2. 사용자 확인 후 제거
+3. 버전 업데이트 (MAJOR)
+
+### 3. 저장 형식
+
+```markdown
+# Project Principles
+
+> Version: {MAJOR.MINOR.PATCH}
+> Last Updated: {YYYY-MM-DD}
+
+## MUST (위반 불가)
+- **MUST-001**: {원칙} — {근거}
+- **MUST-002**: {원칙} — {근거}
+
+## SHOULD (강력 권장)
+- **SHOULD-001**: {원칙} — {근거}
+
+## MAY (선택적)
+- **MAY-001**: {원칙} — {근거}
+
+## Changelog
+- {날짜}: {변경 내용}
+```
+
+### 4. 버전 규칙
+
+- **MAJOR**: MUST 원칙 추가/제거/재정의
+- **MINOR**: SHOULD/MAY 원칙 추가, MUST 명확화
+- **PATCH**: 오타 수정, 근거 보완
+
+## 주의사항
+
+- **영속 저장**: memory/principles.md에 저장되어 세션 간 유지.
+- **자동 참조**: /selfish:plan, /selfish:architect에서 자동으로 로드하여 검증.
+- **간결하게**: 원칙은 10개 이내로 유지. 너무 많으면 실효성 저하.
+- **CLAUDE.md와 중복 방지**: CLAUDE.md에 이미 있는 규칙은 원칙으로 중복 등록하지 않음.

package/commands/research.md

@@ -0,0 +1,94 @@
+# /selfish:research — 기술 리서치
+
+> 기술적 질문을 조사하고 결론을 정리한다.
+> 결과를 memory/research/{topic}.md에 영속 저장한다.
+
+## 인자
+
+- `$ARGUMENTS` — (필수) 리서치 주제 (예: "Zustand v5 마이그레이션", "WebCodecs API 비교")
+
+## 실행 절차
+
+### 1. 주제 분석
+
+`$ARGUMENTS`에서 추출:
+- **핵심 질문**: 무엇을 알아야 하는가?
+- **컨텍스트**: 왜 필요한가? (현재 프로젝트와의 관련성)
+- **범위**: 깊이 vs 넓이 (특정 라이브러리 비교? 전반적 기술 동향?)
+
+### 2. 기존 리서치 확인
+
+`memory/research/` 디렉토리에서 관련 기존 리서치 확인:
+- 있으면: 기존 내용 로드 후 업데이트 필요 여부 판단
+- 없으면: 신규 리서치 진행
+
+### 3. 정보 수집
+
+Agent Teams 활용 — 독립적 조사를 병렬 수행:
+
+```
+Task("WebSearch: {주제} 공식 문서", subagent_type: general-purpose)
+Task("코드베이스: 현재 사용 패턴 분석", subagent_type: Explore)
+```
+
+정보원 우선순위:
+1. **공식 문서** (WebSearch/WebFetch)
+2. **코드베이스** (현재 프로젝트의 기존 패턴)
+3. **커뮤니티** (GitHub Issues, 블로그)
+
+### 4. 결론 정리
+
+```markdown
+# Research: {주제}
+
+> 날짜: {YYYY-MM-DD}
+> 관련 기능: {관련 feature 또는 "일반"}
+
+## 핵심 질문
+{무엇을 알아야 했는가}
+
+## 발견사항
+
+### {소주제 1}
+{내용}
+**출처**: {URL} ({날짜} 확인)
+
+### {소주제 2}
+{내용}
+
+## 옵션 비교 (해당 시)
+| 기준 | {옵션A} | {옵션B} | {옵션C} |
+|------|---------|---------|---------|
+| {기준1} | {평가} | {평가} | {평가} |
+| {기준2} | {평가} | {평가} | {평가} |
+
+## 결론
+**추천**: {선택 또는 결론}
+**근거**: {핵심 이유}
+**주의사항**: {함정 또는 제약}
+
+## 프로젝트 적용
+{이 프로젝트에서 어떻게 적용할 수 있는지}
+```
+
+### 5. 저장
+
+- `memory/research/{topic-kebab-case}.md`에 저장
+- 기존 파일이면 업데이트 (날짜 갱신)
+
+### 6. 최종 출력
+
+```
+🔬 리서치 완료
+├─ 주제: {주제}
+├─ 저장: memory/research/{filename}.md
+├─ 결론: {한 줄 요약}
+└─ 출처: {주요 출처 수}개
+```
+
+## 주의사항
+
+- **현재 날짜 기준**: Knowledge cutoff에 의존하지 않고 WebSearch로 최신 정보 확인.
+- **출처 필수**: 모든 기술적 주장에 출처 명시.
+- **프로젝트 맥락**: 일반적 리서치가 아닌, 이 프로젝트에 적용 가능한 결론 도출.
+- **영속 저장**: memory/research/에 저장하여 다른 세션에서 재활용 가능.

package/commands/resume.md

@@ -0,0 +1,69 @@
+# /selfish:resume — 세션 복원
+
+> memory/checkpoint.md에서 이전 세션 상태를 복원하고 작업을 재개한다.
+
+## 인자
+
+- `$ARGUMENTS` — (선택) 없음
+
+## 실행 절차
+
+### 1. 체크포인트 로드
+
+`memory/checkpoint.md` 읽기:
+- 없으면: "저장된 체크포인트가 없습니다." 출력 후 **중단**
+- 있으면: 전체 내용 파싱
+
+### 2. 환경 검증
+
+체크포인트의 상태와 현재 환경을 비교:
+
+1. **브랜치 확인**: 체크포인트의 브랜치와 현재 브랜치가 같은가?
+   - 다르면: 경고 + 전환 제안
+2. **파일 상태**: 체크포인트 이후 변경된 파일이 있는가?
+   - `git log {체크포인트 해시}..HEAD --oneline` 으로 새 커밋 확인
+3. **Feature 디렉토리**: specs/{feature}/ 가 여전히 존재하는가?
+
+### 3. 상태 보고
+
+```markdown
+## 세션 복원
+
+### 이전 체크포인트
+- **저장 시간**: {시간}
+- **메시지**: {체크포인트 메시지}
+- **브랜치**: {브랜치} {(현재와 동일 ✓ / 다름 ⚠)}
+
+### 활성 Feature
+| Feature | 상태 | 진행률 |
+|---------|------|--------|
+| {이름} | {상태} | {진행률} |
+
+### 체크포인트 이후 변경
+{새 커밋이 있으면 목록, 없으면 "변경 없음"}
+
+### 미완료 작업
+{checkpoint.md의 미완료 작업 목록}
+
+### 추천 다음 단계
+{상태에 따른 추천 커맨드}
+- tasks 진행 중 → `/selfish:implement` 재개
+- plan 완료 → `/selfish:tasks`
+- spec만 → `/selfish:plan`
+```
+
+### 4. 최종 출력
+
+```
+🔄 세션 복원 완료
+├─ 체크포인트: {시간}
+├─ Feature: {이름} ({상태})
+├─ 진행률: {완료}/{전체}
+└─ 추천: {다음 커맨드}
+```
+
+## 주의사항
+
+- **읽기 전용**: 환경을 변경하지 않음 (브랜치 전환도 제안만, 실행은 사용자 확인 후).
+- **불일치 경고**: 체크포인트와 현재 환경이 다르면 명확히 경고.
+- **컨텍스트 복원**: 체크포인트의 "컨텍스트 노트"를 반드시 표시하여 기억 보조.

package/commands/review.md

@@ -0,0 +1,120 @@
+# /selfish:review — 코드 리뷰
+
+> 변경된 코드를 종합적으로 리뷰한다 (품질, 보안, 성능, 아키텍처 준수).
+> Critic Loop 1회로 리뷰 자체의 완전성을 검증한다.
+
+## 인자
+
+- `$ARGUMENTS` — (선택) 리뷰 범위 지정 (파일 경로, PR 번호, 또는 "staged")
+  - 미지정 시: 현재 브랜치의 `git diff` (unstaged + staged) 전체
+
+## 설정 로드
+
+**반드시** `.claude/selfish.config.md`를 먼저 읽는다. 설정 파일이 없으면 중단.
+
+## 실행 절차
+
+### 1. 리뷰 대상 수집
+
+1. **범위 결정**:
+   - `$ARGUMENTS` = 파일 경로 → 해당 파일만
+   - `$ARGUMENTS` = PR 번호 → `gh pr diff {번호}` 실행
+   - `$ARGUMENTS` = "staged" → `git diff --cached`
+   - 미지정 → `git diff HEAD` (커밋되지 않은 모든 변경)
+2. **변경 파일 목록** 추출
+3. 각 변경 파일의 **전체 내용** 읽기 (diff만이 아닌 전체 컨텍스트)
+
+### 2. Agent Teams (파일 5개 초과 시)
+
+변경 파일이 5개 초과면 병렬 리뷰 에이전트 분배:
+
+```
+Task("Review: {file1, file2}", subagent_type: general-purpose)
+Task("Review: {file3, file4}", subagent_type: general-purpose)
+→ 결과 수집 → 통합 리뷰 작성
+```
+
+### 3. 리뷰 수행
+
+각 변경 파일에 대해 아래 관점으로 검토:
+
+#### A. 코드 품질
+- {config.code_style} 준수 (any 사용, 타입 누락)
+- 네이밍 컨벤션 (handleX, isX, UPPER_SNAKE)
+- 중복 코드
+- 불필요한 복잡성
+
+#### B. {config.architecture}
+- 계층 의존성 방향 위반 (하위→상위 import)
+- 세그먼트 규칙 (api/, model/, ui/, lib/)
+- 적절한 계층 배치
+
+#### C. 보안
+- XSS 취약점 (dangerouslySetInnerHTML, 미검증 사용자 입력)
+- 민감 정보 노출
+- SQL/Command Injection
+
+#### D. 성능
+- 불필요한 리렌더링 (useCallback/useMemo 누락)
+- 무한 루프 가능성 (useEffect 의존성)
+- 대용량 데이터 처리
+
+#### E. 프로젝트 패턴 준수
+- {config.state_management} 사용 패턴
+- 서버/클라이언트 상태 관리 패턴 ({config.state_management} 참조)
+- 컴포넌트 구조 (Props 타입 위치, hook 순서)
+
+### 4. 리뷰 출력
+
+```markdown
+## 코드 리뷰 결과
+
+### 요약
+| 심각도 | 개수 | 항목 |
+|--------|------|------|
+| 🔴 Critical | {N} | {요약} |
+| 🟡 Warning | {N} | {요약} |
+| 🔵 Info | {N} | {요약} |
+
+### 상세 발견사항
+
+#### 🔴 C-{N}: {제목}
+- **파일**: {경로}:{라인}
+- **문제**: {설명}
+- **수정 제안**: {코드 예시}
+
+#### 🟡 W-{N}: {제목}
+{같은 형식}
+
+#### 🔵 I-{N}: {제목}
+{같은 형식}
+
+### 긍정적 부분
+- {잘된 점 1-2개}
+```
+
+### 5. Critic Loop (1회)
+
+| 기준 | 검증 내용 |
+|------|-----------|
+| **COMPLETENESS** | 모든 변경 파일을 리뷰했는가? 누락된 관점이 있는가? |
+| **PRECISION** | 발견사항이 오탐(false positive)이 아닌가? 실제 문제인가? |
+
+FAIL 시: 리뷰 수정 후 최종 출력 갱신.
+
+### 6. 최종 출력
+
+```
+🔍 리뷰 완료
+├─ 파일: {변경 파일 수}개
+├─ 발견: 🔴 {N} / 🟡 {N} / 🔵 {N}
+├─ Critic: 1회 완료
+└─ 결론: {한 줄 요약}
+```
+
+## 주의사항
+
+- **읽기 전용**: 코드를 수정하지 않음. 발견사항만 보고.
+- **전체 컨텍스트**: diff 줄만이 아닌 파일 전체를 읽고 맥락 파악 후 리뷰.
+- **오탐 주의**: 확실하지 않은 문제는 🔵 Info로 분류.
+- **패턴 존중**: 기존 코드베이스 패턴과 다르다고 무조건 지적하지 않음. CLAUDE.md 및 selfish.config.md 기준.