@wooojin/forgen 0.2.0 → 0.3.0

package/commands/code-review.md

@@ -1,233 +1,218 @@
 ---
 name: code-review
-description: This skill should be used when the user asks to "code review,코드 리뷰,리뷰해줘,review this". Systematic code review with severity-rated feedback
+description: This skill should be used when the user asks to "code review,코드 리뷰,리뷰해줘,review this". 신뢰도 보정 기반 체계적 코드 리뷰 — compound 이력 연동, auto-fix, 20개 체크리스트.
+argument-hint: "[file, PR number, or git range]"
+model: opus
+allowed-tools:
+  - Read
+  - Grep
+  - Glob
+  - Bash
+  - Edit
+  - Write
+  - Agent
 triggers:
   - "code review"
   - "코드 리뷰"
   - "리뷰해줘"
   - "review this"
+  - "리뷰"
+  - "review"
 ---
 
 <Purpose>
-체계적인 코드 리뷰를 수행하여 품질, 보안, 유지보수성을 검증합니다.
-심각도별로 분류된 피드백을 제공합니다.
+변경된 코드의 품질, 보안, 유지보수성을 체계적으로 검증합니다.
+모든 발견에 신뢰도 점수(1-10)를 부여하여 false positive를 최소화합니다.
+auto-fix 가능한 항목은 직접 수정하고, 판단이 필요한 항목만 사용자에게 보고합니다.
 </Purpose>
 
+<Compound_Integration>
+## Compound-In: 이전 리뷰 이력 로드
+
+```
+compound-search("{모듈명} {파일 경로 키워드} review 리뷰 이슈")
+```
+
+검색 결과가 있으면 보고서 상단에 표시합니다:
+
+```
+이전에 이 모듈에서 발견된 이슈:
+- [{제목}] (심각도: {level}, 날짜: {date})
+  해결 여부: {해결됨 / 미해결 / 재발}
+```
+
+재발 패턴: 같은 이슈 2회 이상 -> 심각도 자동 상향 (MEDIUM -> HIGH)
+
+## Compound-Out: 발견사항 기록
+
+- CRITICAL/HIGH -> compound troubleshoot 기록 제안
+- 새 anti-pattern -> compound anti-pattern 기록 제안
+</Compound_Integration>
+
+<Confidence_Calibration>
+## 신뢰도 보정 (모든 발견에 적용)
+
+```
+9-10: 코드를 읽고 검증함. 구체적 버그/취약점 시연 가능.
+7-8:  높은 확신 패턴 매치. 거의 확실히 실제 이슈.
+5-6:  중간. false positive 가능. 주의하여 플래그.
+3-4:  낮음. 부록에만 포함.
+1-2:  추측. P0 심각도일 때만 보고.
+```
+
+보고 임계값:
+- 본문: 5 이상
+- 부록: 3-4
+- 1-2: P0 아니면 생략
+</Confidence_Calibration>
+
 <Steps>
-1. **스코프 파악**: 변경된 파일과 영향 범위를 식별합니다
-   - git diff 또는 지정된 파일 확인
-   - 변경의 목적과 컨텍스트 이해
-
-2. **정확성 검증**: 로직이 의도대로 동작하는지 확인합니다
-   - 엣지 케이스 처리 여부
-   - 에러 핸들링 적절성
-   - 동시성/경쟁 조건
-
-3. **보안 검토**: OWASP Top 10 기준으로 취약점을 점검합니다
-   - 입력 검증/살균
-   - 인증/인가 로직
-   - 민감 정보 노출
-
-4. **유지보수성**: 코드 품질과 가독성을 평가합니다
-   - 네이밍 컨벤션
-   - SOLID 원칙 준수
-   - 적절한 추상화 수준
-
-5. **피드백 작성**: 심각도별로 분류하여 리포트합니다
-</Steps>
+## Phase 1: 스코프 파악
 
-## 에이전트 위임
+```bash
+# 인수가 파일 경로 -> cat {path}
+# 인수가 PR 번호 -> gh pr diff {number}
+# 인수가 git range -> git diff {range}
+# 인수 없음 -> git diff HEAD (또는 git diff --staged)
+```
 
-`code-reviewer` 에이전트(Opus 모델)에 위임하여 심층 코드 분석을 수행합니다:
+## Phase 2: Compound-In (이전 이력 확인)
 
 ```
-Agent(
-  subagent_type="code-reviewer",
-  model="opus",
-  prompt="CODE REVIEW TASK
-
-코드 변경 사항의 품질, 보안, 유지보수성을 리뷰하세요.
-
-Scope: [git diff 또는 특정 파일]
-
-Review Checklist:
-- Security 취약점 (OWASP Top 10)
-- Code Quality (복잡도, 중복)
-- Performance 이슈 (N+1, 비효율 알고리즘)
-- Best Practices (네이밍, 문서화, 에러 핸들링)
-- Maintainability (결합도, 테스트 가능성)
-
-Output: 코드 리뷰 리포트:
-- 리뷰한 파일 수
-- 심각도별 이슈 (CRITICAL, HIGH, MEDIUM, LOW)
-- 구체적인 파일:라인 위치
-- 수정 권고
-- 승인 권고 (APPROVE / REQUEST CHANGES / COMMENT)"
-)
+compound-search("{모듈명 또는 핵심 키워드}")
 ```
 
-## 리뷰 체크리스트 (20개 항목)
+## Phase 3: 체계적 검토 (20개 체크리스트)
 
 ### Security (6개)
-- [ ] 하드코딩된 시크릿 없음 (API 키, 비밀번호, 토큰)
-- [ ] 모든 사용자 입력이 살균됨
-- [ ] SQL/NoSQL 인젝션 방지
-- [ ] XSS 방지 (출력 이스케이핑)
-- [ ] CSRF 보호 (상태 변경 작업)
-- [ ] 인증/인가가 적절히 적용됨
+- [ ] 하드코딩된 시크릿 없음
+- [ ] 입력 살균 (SQL/NoSQL injection 방지)
+- [ ] XSS 방지
+- [ ] CSRF 보호
+- [ ] 인증/인가 적용
+- [ ] 민감 정보 로그 노출 없음
+
+### Critical Category (5개)
+- [ ] SQL/데이터 안전성
+- [ ] 경쟁 조건
+- [ ] LLM 신뢰 경계 (LLM 출력 살균 확인)
+- [ ] 시크릿 노출 (코드 + 로그 + 에러 메시지)
+- [ ] Enum 완전성 (새 값 -> 모든 switch/match 업데이트)
 
 ### Code Quality (5개)
-- [ ] 함수가 50줄 미만 (가이드라인)
+- [ ] 함수 50줄 미만
 - [ ] 순환 복잡도 10 미만
-- [ ] 깊은 중첩 없음 (4단계 초과 시 early return 적용)
-- [ ] 중복 로직 없음 (DRY 원칙)
-- [ ] 명확하고 서술적인 네이밍
+- [ ] 깊은 중첩 없음 (4단계 -> early return)
+- [ ] DRY 원칙
+- [ ] 서술적 네이밍
 
 ### Performance (4개)
-- [ ] N+1 쿼리 패턴 없음
-- [ ] 적절한 캐싱 적용
-- [ ] 효율적인 알고리즘 (O(n^2) 대신 O(n) 가능한 경우)
-- [ ] 불필요한 리렌더링 없음 (React/Vue)
-
-### Best Practices (5개)
-- [ ] 에러 핸들링이 적절히 구현됨
-- [ ] 적절한 레벨의 로깅
-- [ ] 공개 API에 대한 문서화
-- [ ] 핵심 경로에 대한 테스트 존재
-- [ ] 주석 처리된 코드 없음
-
-## 승인 기준
-
-| 판정 | 조건 | 설명 |
-|------|------|------|
-| **APPROVE** | CRITICAL/HIGH 이슈 없음 | 경미한 개선 사항만 있음, 머지 가능 |
-| **REQUEST CHANGES** | CRITICAL 또는 HIGH 이슈 존재 | 반드시 수정 후 재리뷰 필요 |
-| **COMMENT** | LOW/MEDIUM 이슈만 존재 | 차단 사항 없음, 선택적 개선 권장 |
-
-## External Consultation (Optional)
-
-code-reviewer 에이전트는 교차 검증을 위해 Claude Task 에이전트에 자문할 수 있습니다.
-
-### Protocol
-1. **자체 리뷰를 먼저 완료** — 독립적으로 분석 수행
-2. **검증을 위한 자문** — Claude Task 에이전트를 통해 발견 사항 교차 확인
-3. **비판적 평가** — 외부 발견 사항을 맹목적으로 수용하지 않음
-4. **우아한 폴백** — 위임이 불가능할 경우 절대 차단하지 않음
-
-### 자문이 필요한 경우
-- 보안에 민감한 코드 변경
-- 복잡한 아키텍처 패턴
-- 익숙하지 않은 코드베이스나 언어
-- 고위험 프로덕션 코드
-
-### 자문을 생략하는 경우
-- 단순 리팩토링
-- 잘 알려진 패턴
-- 시간이 촉박한 리뷰
-- 작고 격리된 변경
-
-## 심각도 정의
-
-| 심각도 | 설명 |
-|--------|------|
-| **CRITICAL** | 보안 취약점 (머지 전 반드시 수정) |
-| **HIGH** | 버그 또는 주요 코드 스멜 (머지 전 수정 권장) |
-| **MEDIUM** | 경미한 이슈 (가능할 때 수정) |
-| **LOW** | 스타일/제안 (수정 고려) |
+- [ ] N+1 없음
+- [ ] 적절한 캐싱
+- [ ] 효율적 알고리즘
+- [ ] 불필요한 리렌더링 없음
+
+## Phase 4: Auto-Fix 적용
+
+**AUTO-FIX** (묻지 않고 수정):
+- 데드 코드, 미사용 import, stale 주석, 빈 catch 블록
+
+**ASK** (사용자 판단):
+- 로직 변경, 아키텍처 리팩토링, 동작 변경
+
+## Phase 5: 보고서 작성
+
+신뢰도 점수 + 심각도별 분류.
+</Steps>
+
+<Finding_Format>
+```
+[P{N}] (confidence: {N}/10) `{file}:{line}`
+  Issue: {구체적 문제}
+  Impact: {영향}
+  Fix: {수정 방안}
+```
+</Finding_Format>
+
+<Failure_Modes>
+**스타일만 리뷰하고 로직 생략**: 네이밍/들여쓰기만 지적하고 비즈니스 로직, 엣지 케이스, 동시성은 검토하지 않는다.
+**파일:라인 없는 피드백**: 모든 이슈에 `파일명:라인번호` 필수.
+**숨겨진 BLOCKER + APPROVE**: CRITICAL/HIGH 발견 시 APPROVE 불가.
+**신뢰도 없는 발견**: 모든 발견에 1-10 신뢰도 필수.
+**Auto-fix에서 로직 변경**: 데드 코드/import/주석만 자동 수정. 비즈니스 로직 자동 변경 금지.
+**LLM 출력 무조건 신뢰**: LLM 출력 처리 코드는 신뢰 경계 검사 필수.
+</Failure_Modes>
 
 <Output>
 ```
 CODE REVIEW REPORT / 코드 리뷰 리포트
 ======================================
+Scope: {리뷰 대상}
+Files: {N}개 | Lines: +{N} / -{N}
 
-Files Reviewed: N
-Total Issues: N
-
-CRITICAL (N)
-------------
-(없음 / 이슈 상세)
+[COMPOUND HISTORY]
+- {이전 이슈} ({날짜}) -- {상태}
 
-HIGH (N)
---------
-1. src/api/auth.ts:42
-   Issue: 사용자 입력이 SQL 쿼리 전에 살균되지 않음
-   Risk: SQL 인젝션 취약점
-   Fix: 파라미터화 쿼리 또는 ORM 사용
+CRITICAL ({N})
+──────────────
+[P0] (confidence: {N}/10) `{file}:{line}`
+  Issue: ...
+  Impact: ...
+  Fix: ...
 
-2. src/components/UserProfile.tsx:89
-   Issue: 비밀번호가 로그에 평문으로 출력됨
-   Risk: 크리덴셜 노출
-   Fix: 로그 구문에서 비밀번호 제거
-
-3. src/utils/validation.ts:15
-   Issue: 이메일 정규식이 잘못된 형식을 허용
-   Risk: 잘못된 이메일 수용
-   Fix: 검증된 이메일 유효성 검사 라이브러리 사용
+HIGH ({N})
+──────────
+...
 
-MEDIUM (N)
-----------
+MEDIUM ({N})
+────────────
 ...
 
-LOW (N)
--------
+LOW ({N})
+─────────
 ...
 
-RECOMMENDATION: [APPROVE / REQUEST CHANGES / COMMENT]
+AUTO-FIXED ({N})
+────────────────
+- {수정 내용} ({file}:{line})
+
+APPENDIX (confidence 3-4)
+─────────────────────────
+- {낮은 신뢰도 항목}
 
-[수정이 필요한 경우 요약 코멘트]
+VERDICT: {APPROVE / REQUEST CHANGES / COMMENT}
+{판정 근거}
 ```
+
+| 판정 | 조건 |
+|------|------|
+| APPROVE | CRITICAL/HIGH 0개 |
+| REQUEST CHANGES | CRITICAL 1+ 또는 HIGH 2+ |
+| COMMENT | HIGH 1개 또는 MEDIUM만 |
 </Output>
 
 <Policy>
-- 변경된 코드만 리뷰합니다 (기존 코드의 기술 부채는 별도 이슈로)
-- 구체적인 코드 라인을 참조하여 피드백합니다
-- 문제 지적 시 해결 방안도 함께 제시합니다
-- 잘된 부분도 언급하여 균형 잡힌 피드백을 제공합니다
-- 20개 체크 항목을 빠짐없이 검토합니다
-- APPROVE/REQUEST CHANGES/COMMENT 3단계 판정을 반드시 포함합니다
+- 변경된 코드만 리뷰 (기존 기술 부채는 별도 이슈).
+- 모든 이슈에 `파일:라인` + 신뢰도 필수.
+- 문제 + 수정 방안을 함께 제시.
+- 20개 체크 항목 빠짐없이 검토.
+- Auto-fix는 안전한 항목에만.
+- CRITICAL/HIGH 발견 시 APPROVE 불가.
 </Policy>
 
-## 다른 스킬과의 연동
-
-**Pipeline 연동:**
-```
-/forgen:pipeline review "사용자 인증 구현"
-```
-구현 워크플로우의 일부로 코드 리뷰 포함
-
-**Ralph 연동:**
-```
-/forgen:ralph code-review then fix all issues
-```
-코드 리뷰 후 피드백 수정, 승인될 때까지 반복
-
-**팀 기반 병렬 리뷰:**
-```
-/forgen:team 4:code-reviewer "src/ 전체 파일 리뷰"
-```
-여러 파일에 대해 병렬 코드 리뷰 수행
-
-## Best Practices
-
-- **조기 리뷰** — 이슈가 누적되기 전에 잡기
-- **자주 리뷰** — 크고 드문 리뷰보다 작고 빈번한 리뷰
-- **CRITICAL/HIGH 우선** — 보안과 버그부터 즉시 수정
-- **컨텍스트 고려** — 일부 "이슈"는 의도적 트레이드오프일 수 있음
-- **리뷰에서 학습** — 피드백을 활용하여 코딩 관행 개선
-
 <Arguments>
 ## 사용법
-`/forgen:code-review {리뷰 대상}`
+`/code-review {대상}`
 
 ### 예시
-- `/forgen:code-review` (기본: 최근 변경사항 리뷰)
-- `/forgen:code-review src/auth/login.ts`
-- `/forgen:code-review 최근 3개 커밋`
-- `/forgen:code-review PR #42`
+- `/code-review` (git diff HEAD)
+- `/code-review src/auth/login.ts`
+- `/code-review 42` (PR #42)
+- `/code-review HEAD~3..HEAD`
 
 ### 인자
-- 파일 경로, 커밋 범위, PR 번호 등을 지정
-- 인자 없으면 `git diff`로 변경사항을 자동 감지
+- 파일 경로, PR 번호, git range
+- 생략 시 git diff 자동 감지
 </Arguments>
 
 $ARGUMENTS

package/commands/compound.md

@@ -1,6 +1,7 @@
 ---
 name: compound
 description: This skill should be used when the user asks to "복리화,compound,패턴 추출,솔루션 축적,what did we learn". Compound Engineering — extract reusable patterns from this session's work
+argument-hint: "[solution description]"
 model: inherit
 allowed-tools:
   - Bash
@@ -25,93 +26,151 @@ triggers:
 참고: CLI `forgen compound`는 최근 코드/세션을 자동 분석한 결과를 미리보기하고, `--save`일 때만 저장합니다. 이 slash skill은 대화 전체 맥락을 바탕으로 수동 추출할 때 사용합니다.
 </Purpose>
 
-<Steps>
-## Phase 1: 세션 분석
-
-이 세션의 대화를 돌아보며 다음을 식별하세요:
-
-### 솔루션 (재사용 가능한 패턴)
-- 어떤 기술적 결정을 내렸는가? 왜?
-- 어떤 접근법이 효과적이었는가?
-- 시도했다가 실패한 것은? (anti-pattern)
-- 반복될 수 있는 패턴이 있는가?
-
-### 트러블슈팅 (문제 해결 지식)
-- 어떤 에러/문제를 만났는가?
-- 근본 원인은 무엇이었는가?
-- 해결 방법은?
-- 다음에 같은 문제를 만나면 바로 적용할 수 있는 해결 절차는?
-
-### 의사결정 (선택의 근거)
-- 기술 스택/라이브러리 선택의 이유
-- 아키텍처 결정의 배경
-- 트레이드오프와 그 판단 근거
-
-### 안티패턴 (피해야 할 것)
-- 이 세션에서 시도했다가 실패한 접근법은?
-- 왜 실패했는가? (근본 원인)
-- 다음에 같은 실수를 피하려면?
-
-### 영향 범위 분석
-- 이 변경/결정이 다른 모듈/파일에 미치는 영향은?
-- 의존하는 코드가 깨질 수 있는가?
-- 어떤 테스트가 추가로 필요한가?
-
-### 기존 항목 교차 참조
-축적 전에 기존 compound 항목과 비교하세요:
-```bash
-forgen compound list
+<Compound_Integration>
+## Phase 0: Compound-In (중복 방지 검색)
+
+추출 전 기존 compound 패턴을 검색하여 중복을 방지합니다.
+
 ```
-- 이미 유사한 솔루션/규칙이 있는가? → 업데이트 또는 보완
-- 기존 항목과 모순되는가? → 둘 다 기록하고 비교
+compound-search("[핵심 키워드]")
+compound-stats
+```
+
+결과 기반:
+- 동일 패턴 존재 → 업데이트 vs 신규 판단
+- 유사하지만 다른 맥락 → 별도 항목 + 기존 항목 관계 명시
+- 완전히 새로운 → 신규 저장
+</Compound_Integration>
+
+<Steps>
+## Phase 1: 세션 분석 (4개 구조화 카테고리)
 
-### 확신도 자기 평가
-각 추출 항목에 대해 확신도를 평가하세요:
-- **높음**: 명확한 인과관계, 반복 검증됨
+### pattern (HOW to do something)
+- 재사용 가능한 접근법, 효과적이었던 기법
+- 제목: `"{topic}-{approach}"` (예: "prisma-upsert-pattern")
+
+### troubleshoot (WHAT went wrong)
+- 에러 → 근본 원인 → 해결 절차
+- 제목: `"{error}-{solution}"` (예: "hmac-mismatch-fix")
+
+### decision (WHY this way)
+- 기술 선택의 근거, 트레이드오프
+- 제목: `"adr-{topic}"` (예: "adr-redis-vs-memcached")
+
+### anti-pattern (What NOT to do)
+- 시도했다가 실패한 접근, 근본 원인
+- 제목: `"avoid-{pattern}"` (예: "avoid-barrel-exports")
+
+### 확신도 평가
+- **높음**: 명확한 인과, 반복 검증
 - **중간**: 합리적 추론, 1회 검증
-- **낮음**: 가설 수준, 추가 검증 필요
+- **낮음**: 가설 수준
 
-## Phase 2: 품질 게이트
+## Phase 2: 품질 게이트 (5-Question Filter)
 
-추출 전 각 항목을 검증하세요:
+| # | 질문 | YES일 때 | NO일 때 |
+|---|------|---------|---------|
+| Q1 | Google에서 5분 안에 찾을 수 있는가? | 저장 안 함 | 통과 |
+| Q2 | 이 코드베이스에만 해당하는가? | scope: project | scope: me |
+| Q3 | WHY가 포함되어 있는가? | 통과 | WHY 추가 후 저장 |
+| Q4 | 컨텍스트 없이 이해 가능한가? | 통과 | 컨텍스트 추가 |
+| Q5 | 이미 compound에 있는가? | 기존 항목 업데이트 | 신규 저장 |
 
-1. **재사용 가능한가?** — 이 프로젝트에만 해당하는 것은 제외 (scope: project로 표시)
-2. **구체적인가?** — "좋은 코드를 작성하자" 같은 일반론은 제외
-3. **실행 가능한가?** — 다음에 적용할 수 있는 구체적 내용이 있는가?
-4. **독성이 없는가?** — @ts-ignore, --force, 임시 우회 같은 패턴은 제외
+추가 거부: 일반론, 독성 패턴(@ts-ignore, --force), 단순 변경 세션
 
 ## Phase 3: 축적
 
-추출한 각 인사이트를 CLI 명령어로 저장합니다:
-
 ```bash
-# 솔루션 (재사용 가능한 패턴)
-forgen compound --solution "제목" "왜 이 접근법을 사용했고, 언제 적용하는지 포함한 상세 설명"
+# pattern
+forgen compound --solution "{topic}-{approach}" "상세 설명 (WHY 포함)"
 
-# 트러블슈팅 (에러 → 원인 → 해결)
-forgen compound --solution "에러명-해결법" "에러 상황, 근본 원인, 해결 절차를 포함"
+# troubleshoot
+forgen compound --solution "{error}-{solution}" "에러 상황, 원인, 해결 절차"
 
-# 의사결정 (선택의 근거)
-forgen compound --solution "기술선택-이유" "어떤 대안이 있었고 왜 이것을 선택했는지"
+# decision
+forgen compound --solution "adr-{topic}" "대안, 선택 이유, 트레이드오프"
 
-# 안티패턴 (피해야 할 것)
-forgen compound --solution "피해야-할-패턴" "왜 이 접근이 실패했고 대신 무엇을 해야 하는지"
+# anti-pattern
+forgen compound --solution "avoid-{pattern}" "실패 원인, 대체 접근법"
 ```
 
-**중요**:
-- 각 솔루션의 내용에 **"왜"**를 반드시 포함하세요
-- 제목은 구체적으로 (예: "React-useCallback-memo-최적화" O, "성능개선" X)
-- 내용은 다른 세션에서 이 솔루션을 보고 바로 적용할 수 있을 정도로 상세하게
-- 단순 타이포/1줄 수정 세션이면 → "복리화 불필요" 후 종료
-
 ## Phase 4: 리포트
 
 ```
-📊 세션 복리화 완료
-├─ 추출: N개 솔루션
-├─ 유형: pattern X개, troubleshoot Y개, decision Z개
-└─ 저장: ~/.forgen/me/solutions/
+세션 복리화 완료
+─────────────────────────────────
+추출: N개 솔루션
+유형: pattern X개, troubleshoot Y개, decision Z개, anti-pattern W개
+저장: ~/.forgen/me/solutions/
 ```
+
+## Phase 5: Health Dashboard
+
+```
+COMPOUND HEALTH
+════════════════════════════════════════════════════
+Total: {N} solutions
+|- mature (3+ hits):    {N} ({N}%)
+|- verified (2 hits):   {N} ({N}%)
+|- candidate (1 hit):   {N} ({N}%)
++- experiment (0 hits): {N} ({N}%) <- cleanup candidates
+
+Hit Rate (7d): {N}%
+Top Patterns: "{name}" ({N} hits), "{name}" ({N} hits)
+Stale (30d+ unused): {N} -> /learn prune
+
+Category: pattern {N} | troubleshoot {N} | decision {N} | anti-pattern {N}
+Trend: {analysis}
+════════════════════════════════════════════════════
+```
+
+### 건강 지표
+
+| 지표 | 건강 | 주의 | 위험 |
+|------|------|------|------|
+| mature 비율 | > 30% | 15-30% | < 15% |
+| experiment 비율 | < 20% | 20-40% | > 40% |
+| hit rate (7d) | > 30% | 15-30% | < 15% |
+| stale 수 | < 5 | 5-15 | > 15 |
 </Steps>
 
+<Failure_Modes>
+NEVER: **일반론 추출**: 추상적 교훈 저장 금지. Q1에서 걸러집니다.
+
+NEVER: **프로젝트 전용을 범용으로**: scope: project 명시 필수.
+
+NEVER: **중복 추출**: Phase 0에서 기존 항목 확인 필수. Q5에서 걸러집니다.
+
+NEVER: **"왜" 없는 추출**: Q3에서 걸러집니다.
+
+NEVER: **단순 세션 억지 추출**: "복리화 불필요"로 종료.
+
+NEVER: **카테고리 무시**: 4개 카테고리별 제목 형식 준수.
+
+NEVER: **Health Dashboard 건너뛰기**: 추출 후 반드시 Phase 5 실행.
+</Failure_Modes>
+
+<Policy>
+- Phase 0 중복 방지 검색을 반드시 먼저 실행
+- 4개 카테고리로 분류 (pattern, troubleshoot, decision, anti-pattern)
+- 5-Question Filter 모든 항목에 적용
+- "왜" 없는 항목 저장 금지
+- 카테고리별 제목 형식 준수
+- 기존 항목 중복 시 업데이트 제안
+- 단순 세션이면 "복리화 불필요"로 종료
+- 추출 후 Health Dashboard 표시
+</Policy>
+
+<Arguments>
+## 사용법
+`compound {선택적 설명}`
+
+### 예시
+- `compound` — 전체 세션 분석
+- `compound 인증 구현 관련` — 특정 주제 집중
+
+### 인자
+- 선택적: 특정 주제 키워드. 생략 시 전체 세션 분석.
+</Arguments>
+
 $ARGUMENTS