@wooojin/forgen 0.2.1 → 0.3.1

package/skills/architecture-decision/SKILL.md

@@ -1,305 +1,161 @@
 ---
 name: architecture-decision
-description: This skill should be used when the user asks to "adr,architecture decision,아키텍처 결정,설계 결정,기술 결정". Architecture Decision Record (ADR) creation with alternatives evaluation and consequence analysis
+description: This skill should be used when the user asks to "adr,ch-architecture decision,아키텍처 결정,설계 결정,기술 결정". ADR 생성 -- 대안 평가, 가중 트레이드오프 매트릭스, 결정 라이프사이클 관리
 ---
 
-<!-- forgen-managed -->
-
 <Purpose>
 아키텍처 결정 기록(ADR)을 체계적으로 작성합니다.
-의사결정의 컨텍스트, 대안 평가, 결정, 결과를 구조화하여 기록하고
+의사결정의 컨텍스트, 대안 평가, 가중 트레이드오프 매트릭스, 결과를 구조화하여 기록하고
 미래의 개발자가 "왜 이렇게 결정했는가"를 이해할 수 있도록 합니다.
+
+핵심 차별점:
+- 정량적 가중 트레이드오프 매트릭스 (직관이 아닌 점수)
+- ADR 라이프사이클 관리 (Proposed → Accepted → Deprecated → Superseded)
+- Type 1/Type 2 가역성 분류에 따른 분석 심도 조절
+- Compound를 통한 결정 이력 추적 및 일관성 보장
 </Purpose>
 
-<Steps>
-1. **컨텍스트 수집**: 결정이 필요한 배경을 정리합니다
-   - 해결하려는 문제/요구사항 정의
-   - 현재 시스템 상태 및 제약 조건
-   - 비즈니스 요구사항과 기술 요구사항 구분
-   - 이해관계자 식별 (누가 영향을 받는가)
-   - 결정의 긴급도와 중요도
-   - 관련 기존 ADR 참조
-   - 비기능 요구사항 (성능, 보안, 확장성, 비용)
-
-2. **대안 탐색**: 가능한 선택지를 열거합니다
-   - 최소 3개 이상의 대안 도출
-   - 각 대안에 대한 간략한 설명
-   - "아무것도 하지 않기" 옵션 포함 (현상 유지)
-   - 업계 사례 및 벤치마크 조사
-   - 기존 기술 스택과의 호환성 확인
-   - 팀 역량 및 학습 곡선 고려
-   - 라이선스/비용 확인
-
-3. **대안 평가**: 정량적/정성적 기준으로 비교합니다
-   - 평가 기준 정의:
-     * 기술 적합성 (요구사항 충족도)
-     * 복잡도 (구현 난이도, 운영 부담)
-     * 성능 (응답 시간, 처리량, 리소스)
-     * 확장성 (수평/수직 확장 가능성)
-     * 보안 (취약점, 인증/인가)
-     * 비용 (초기 비용, 운영 비용, 기회 비용)
-     * 생태계 (커뮤니티, 문서, 도구)
-     * 팀 역량 (경험, 학습 곡선)
-   - 가중치 부여 (프로젝트별 우선순위에 따라)
-   - 각 대안의 장단점 분석
-   - PoC(Proof of Concept) 필요 여부 결정
-
-4. **결정**: 최종 선택과 근거를 명시합니다
-   - 선택된 대안과 핵심 이유
-   - 결정을 뒤집을 수 있는 조건 (reversibility)
-   - 수용한 트레이드오프 명시
-   - 거부된 대안과 거부 이유
-   - 결정에 대한 팀 합의 수준
-
-5. **결과 분석**: 결정의 예상 영향을 기록합니다
-   - 긍정적 결과 (해결되는 문제)
-   - 부정적 결과 (새로 발생하는 제약/부담)
-   - 리스크 (무엇이 잘못될 수 있는가)
-   - 리스크 완화 전략
-   - 후속 결정이 필요한 사항
-   - 모니터링 포인트 (결정의 효과를 어떻게 측정할 것인가)
-
-6. **기록 및 공유**: ADR을 작성하고 공유합니다
-   - ADR 번호 및 제목 부여 (ADR-NNN: [제목])
-   - 상태 설정 (Proposed → Accepted → Deprecated → Superseded)
-   - ADR 저장소에 등록 (docs/adr/ 또는 .adr/)
-   - 이해관계자에게 공유 및 피드백 수집
-   - 관련 코드에 ADR 참조 주석 추가
-</Steps>
+<Compound_Integration>
+## 시작 전: 이전 ADR 및 결정 이력 검색
 
-## 에이전트 위임
+결정을 내리기 전에 compound-search MCP 도구로 유사한 과거 결정을 검색합니다.
 
-`architect` 에이전트(Opus 모델)에 위임하여 아키텍처 분석을 수행합니다:
+```
+compound-search("[결정 주제 키워드]")
+compound-search("아키텍처 결정 [관련 기술명]")
+```
 
+### 검색 결과가 있을 경우
+컨텍스트 섹션 앞에 이전 결정을 표시합니다:
 ```
-Agent(
-  subagent_type="architect",
-  model="opus",
-  prompt="ARCHITECTURE DECISION TASK
-
-아키텍처 결정 기록(ADR)을 작성하세요.
-
-Decision: [결정 주제]
-Context: [배경 및 제약 조건]
-
-ADR Checklist:
-1. 컨텍스트 정리 (문제, 제약, 요구사항)
-2. 대안 탐색 (최소 3개 + 현상 유지)
-3. 대안 평가 (기준별 비교표)
-4. 결정 및 근거 (선택 이유, 트레이드오프)
-5. 결과 분석 (긍정/부정, 리스크)
-6. ADR 문서 작성
-
-Output: ADR 문서:
-- 번호 및 제목
-- 상태 (Proposed/Accepted)
-- 컨텍스트
-- 대안 비교표
-- 결정 및 근거
-- 결과 및 리스크"
-)
+이전에 유사한 결정:
+- [ADR 제목]: [핵심 결론 요약] (날짜: YYYY-MM-DD)
+- 당시 선택한 이유: [주요 근거]
+- 현재와의 차이점: [컨텍스트 변화가 있으면 명시]
 ```
 
-## External Consultation (Optional)
+같은 주제의 이전 결정이 있으면:
+"Note: 이전에 이 주제에 대한 결정이 있습니다 (ADR-{N}). 변경하려면 Supersede 사유가 필요합니다."
 
-architect 에이전트는 교차 검증을 위해 Claude Task 에이전트에 자문할 수 있습니다.
+### 완료 후: 결정 축적
+ADR 작성이 완료되면 compound에 결정 핵심 요약을 저장합니다.
+</Compound_Integration>
 
-### Protocol
-1. **자체 분석을 먼저 완료** -- 독립적으로 대안 평가
-2. **검증을 위한 자문** -- Claude Task 에이전트를 통해 분석 교차 확인
-3. **비판적 평가** -- 외부 제안을 맹목적으로 수용하지 않음
-4. **우아한 폴백** -- 위임이 불가능할 경우 절대 차단하지 않음
+<Steps>
+## 6단계 ADR 프로세스
 
-### 자문이 필요한 경우
-- 되돌리기 어려운 결정 (데이터베이스 선택, 프레임워크 변경)
-- 조직 전체에 영향을 미치는 결정
-- 비용이 큰 기술 투자 결정
-- 팀 내 의견이 분분한 결정
+### Step 1: Context (컨텍스트)
+- 해결하려는 문제/요구사항 정의
+- 현재 시스템 상태 및 제약 조건
+- 비기능 요구사항 (성능, 보안, 확장성, 비용)
 
-### 자문을 생략하는 경우
-- 단순 라이브러리 선택 (유사한 기능, 낮은 영향)
-- 내부 구현 세부 사항
-- 잘 알려진 패턴 적용
-- 쉽게 되돌릴 수 있는 결정
+### Step 2: Alternatives (대안 탐색)
+- 최소 2개 실질 대안 (반드시 "최소형"과 "이상형" 각 1개 포함)
+- "현상 유지" 옵션 포함
+- 각 대안의 장단점, 호환성, 비용
 
-## ADR 체크리스트
+### Step 3: Trade-off Matrix (가중 트레이드오프 매트릭스)
+```
+| 기준             | 가중치 | Option A | Option B | Option C |
+|------------------|--------|----------|----------|----------|
+| 성능             | 30%    | ★★★    | ★★      | ★★★★  |
+| 복잡도           | 25%    | ★★      | ★★★★  | ★       |
+| 유지보수성       | 25%    | ★★★    | ★★★    | ★★      |
+| 마이그레이션 비용 | 20%    | ★★★★  | ★★      | ★       |
+| 가중 합계        | 100%   | 2.95     | 2.85     | 2.15     |
+```
+규칙: 기준 4~6개, 가중치 합계 100%, 점수 통일, 산술 검증 필수.
 
-### 완전성 (5개)
-- [ ] 문제/요구사항이 명확히 정의됨
-- [ ] 최소 3개 대안이 탐색됨
-- [ ] 평가 기준이 명시됨
-- [ ] 선택 근거가 구체적으로 설명됨
-- [ ] 트레이드오프가 명시적으로 기록됨
+### Step 4: Decision (결정)
+- 선택된 대안과 핵심 이유
+- 수용한 트레이드오프 명시
+- 거부된 대안과 거부 이유
 
-### 품질 (4개)
-- [ ] 비기능 요구사항 (성능, 보안, 비용)이 고려됨
-- [ ] 리스크와 완화 전략이 포함됨
-- [ ] 결정을 뒤집을 수 있는 조건이 명시됨
-- [ ] 후속 결정 사항이 식별됨
+### Step 5: Consequences (결과 분석)
+- Positive/Negative/Risks + 완화 전략
+- Follow-up decisions
 
-### 프로세스 (3개)
-- [ ] 이해관계자와 공유됨
-- [ ] 피드백이 수집되고 반영됨
-- [ ] 관련 코드에 ADR 참조가 추가됨
+### Step 6: Reversibility (가역성 분류)
+- Type 1 (비가역): 심층 분석, PoC 권장, Reversal condition 필수
+- Type 2 (가역): 신속 결정, 결과로 검증
+</Steps>
 
-## ADR 상태 흐름
+<Failure_Modes>
+## 피해야 할 실패 패턴
 
-```
-[Proposed] → [Accepted] → [Deprecated] (더 이상 관련 없음)
-                       → [Superseded by ADR-NNN] (새 결정으로 대체)
-```
+- 대안 없는 결정: 최소형+이상형을 포함한 2개 이상 실질 대안 없이 단순 선언으로 끝냄.
+- 트레이드오프 누락: 장점만 나열하고 수용한 단점과 리스크를 기록하지 않음.
+- 가역성 미검토: Type 1/Type 2 분류를 생략하여 비가역 결정에 충분한 분석 없이 결론.
+- 가중치 합계 오류: 가중치 합계가 100%가 아니거나 가중 합계 산술이 틀림.
+- 이전 ADR 무시: compound에 같은 주제의 이전 결정이 있는데 참조하지 않음.
+- ADR 상태 미관리: Superseded된 ADR의 상태를 업데이트하지 않아 충돌 발생.
+</Failure_Modes>
 
-## 결정 되돌림 가능성 분류
+<Output>
+```markdown
+# ADR-{N}: {Title}
 
-| 분류 | 설명 | 예시 | 투자 수준 |
-|------|------|------|-----------|
-| **Type 1** (비가역) | 되돌리기 매우 어렵거나 불가능 | DB 엔진, 프로그래밍 언어 | 심층 분석 필요 |
-| **Type 2** (가역) | 비교적 쉽게 되돌릴 수 있음 | 라이브러리, 내부 패턴 | 신속한 결정 가능 |
+**Status**: Proposed | Accepted | Deprecated | Superseded by ADR-{M}
+**Date**: YYYY-MM-DD
+**Reversibility**: Type 1 (비가역) | Type 2 (가역)
 
-## 평가 매트릭스 템플릿
+## Context
+{상황과 배경}
 
-| 기준 (가중치) | 대안 A | 대안 B | 대안 C | 현상 유지 |
-|---------------|--------|--------|--------|-----------|
-| 기술 적합성 (30%) | 9 | 7 | 8 | 3 |
-| 복잡도 (20%) | 6 | 8 | 5 | 10 |
-| 성능 (15%) | 8 | 7 | 9 | 5 |
-| 확장성 (15%) | 9 | 6 | 8 | 4 |
-| 비용 (10%) | 5 | 8 | 6 | 10 |
-| 팀 역량 (10%) | 7 | 9 | 5 | 10 |
-| **가중 합계** | **7.6** | **7.3** | **7.0** | **5.8** |
+## Alternatives Considered
+### Option A: {name} (최소형)
+### Option B: {name} (이상형)
+### Option C: 현상 유지
 
-<Output>
-```
-ARCHITECTURE DECISION RECORD / 아키텍처 결정 기록
-===================================================
-
-ADR-NNN: [결정 제목]
-Status: [Proposed / Accepted / Deprecated / Superseded by ADR-NNN]
-Date: YYYY-MM-DD
-Deciders: [결정 참여자]
-
-CONTEXT / 컨텍스트
---------------------
-[해결하려는 문제와 배경 설명]
-
-Requirements:
-- [기능 요구사항 1]
-- [비기능 요구사항 (성능, 보안, 비용)]
-
-Constraints:
-- [제약 조건 1]
-- [제약 조건 2]
-
-ALTERNATIVES / 대안
----------------------
-### 대안 A: [이름]
-[설명]
-- Pros: [장점]
-- Cons: [단점]
-
-### 대안 B: [이름]
-[설명]
-- Pros: [장점]
-- Cons: [단점]
-
-### 대안 C: [이름] (현상 유지)
-[설명]
-- Pros: [장점]
-- Cons: [단점]
-
-EVALUATION / 평가
--------------------
-| 기준 (가중치) | 대안 A | 대안 B | 대안 C |
-|---------------|--------|--------|--------|
-| [기준 1] (N%) | N/10   | N/10   | N/10   |
-| [기준 2] (N%) | N/10   | N/10   | N/10   |
-| **합계**      | **N**  | **N**  | **N**  |
-
-DECISION / 결정
------------------
-**대안 A를 선택합니다.**
-
-Rationale: [핵심 선택 이유]
-
-Trade-offs accepted:
-- [수용한 트레이드오프 1]
-- [수용한 트레이드오프 2]
-
-Reversibility: [Type 1 (비가역) / Type 2 (가역)]
-Reversal condition: [이 결정을 뒤집어야 하는 조건]
-
-CONSEQUENCES / 결과
----------------------
-Positive:
-- [긍정적 결과 1]
-- [긍정적 결과 2]
-
-Negative:
-- [부정적 결과 1]
-- [부정적 결과 2]
-
-Risks:
-- [리스크 1] → 완화: [완화 전략]
-- [리스크 2] → 완화: [완화 전략]
-
-Follow-up decisions needed:
-- [후속 결정 1]
-- [후속 결정 2]
-
-MONITORING / 모니터링
------------------------
-- [효과 측정 지표 1]
-- [효과 측정 지표 2]
-- Review date: YYYY-MM-DD (3개월 후 재검토)
+## Trade-off Matrix
+| 기준 | 가중치 | Option A | Option B | Option C |
+|------|--------|----------|----------|----------|
+| ...  | ...    | ...      | ...      | ...      |
+
+## Decision
+**Option {X}를 선택합니다.**
+Trade-offs accepted: ...
+Reversal condition: ...
+
+## Consequences
+Positive / Negative / Risks / Follow-up
+
+## Related
+- Supersedes: ADR-{M}
+- Review date: YYYY-MM-DD
 ```
 </Output>
 
 <Policy>
-- 최소 3개 대안을 비교합니다 ("현상 유지" 포함)
-- 정량적 평가 기준을 사용합니다 (직관이 아닌 데이터 기반)
-- 트레이드오프를 명시적으로 기록합니다 -- 모든 결정에는 대가가 있음
-- 결정을 뒤집을 수 있는 조건을 미리 정의합니다
-- ADR은 코드와 함께 버전 관리합니다 (docs/adr/)
-- 폐기된 ADR도 삭제하지 않습니다 -- 역사적 맥락을 보존
+- 최소 2개 실질 대안 비교 (최소형 + 이상형 필수)
+- 가중 트레이드오프 매트릭스 가중치 합계 100%, 산술 검증
+- 트레이드오프를 명시적으로 기록 -- 모든 결정에는 대가가 있음
+- Type 1 결정에는 Reversal condition 필수
+- 이전 ADR 검색 후 관계 명시 (Supersede 등)
+- ADR은 코드와 함께 버전 관리 (docs/adr/)
+- 폐기된 ADR도 삭제하지 않음 -- 역사적 맥락 보존
 </Policy>
 
-## 다른 스킬과의 연동
+## ADR 라이프사이클
 
-**코드 리뷰 연동:**
 ```
-/forgen:code-review ADR에 따른 구현 검증
+[Proposed] → [Accepted] → [Deprecated] | [Superseded by ADR-{M}]
 ```
-아키텍처 결정이 구현에 올바르게 반영되었는지 검증
 
-**문서화 연동:**
-```
-/forgen:documentation ADR 기반 아키텍처 문서
-```
-ADR을 바탕으로 아키텍처 설명 문서 작성
-
-**보안 리뷰 연동:**
-```
-/forgen:security-review ADR의 보안 영향 분석
-```
-아키텍처 결정의 보안 관점 검토
-
-## Best Practices
-
-- **결정 기록** -- 구두 합의보다 문서화된 ADR
-- **미래의 나를 위해** -- 6개월 후 맥락을 잊은 자신을 독자로 상정
-- **간결하게** -- ADR은 1~2페이지가 적당
-- **적시에** -- 결정 시점에 작성, 나중에 "기억해서" 쓰지 않음
-- **갱신** -- 상황 변화 시 ADR 상태를 업데이트
+## 다른 스킬과의 연동
+- `/forgen:code-review` -- ADR에 따른 구현 검증
+- `/forgen:documentation` -- ADR 기반 아키텍처 문서 작성
+- `/forgen:security-review` -- 아키텍처 결정의 보안 관점 검토
 
 <Arguments>
 ## 사용법
-`/forgen:architecture-decision {결정 주제}`
+`/forgen:ch-architecture-decision {결정 주제}`
 
 ### 예시
-- `/forgen:architecture-decision 상태 관리 라이브러리 선택`
-- `/forgen:architecture-decision 모놀리스 → 마이크로서비스 전환`
-- `/forgen:architecture-decision 인증 방식 결정 (JWT vs Session)`
-- `/forgen:architecture-decision 데이터베이스 선택 (PostgreSQL vs MongoDB)`
+- `/forgen:ch-architecture-decision 상태 관리 라이브러리 선택`
+- `/forgen:ch-architecture-decision 모놀리스 → 마이크로서비스 전환`
+- `/forgen:ch-architecture-decision 인증 방식 결정 (JWT vs Session)`
+- `/forgen:ch-architecture-decision 데이터베이스 선택 (PostgreSQL vs MongoDB)`
 
 ### 인자
 - 결정이 필요한 주제, 배경, 제약 조건 등을 설명

package/skills/calibrate/SKILL.md

@@ -0,0 +1,207 @@
+---
+name: calibrate
+description: This skill should be used when the user asks to "calibrate, 캘리브레이트, 프로필 보정, 프로필 조정, 프로필 확인". 축적된 evidence(교정 기록)를 분석하여 4축 프로필 조정을 제안합니다.
+---
+
+<Purpose>
+사용자가 Claude의 행동을 교정한 기록(evidence)을 분석하여
+4축 프로필(quality_safety / autonomy / judgment_philosophy / communication_style)의
+조정 방향을 데이터 기반으로 제안합니다.
+
+이 스킬은 forgen에만 존재하는 고유 기능입니다.
+"Claude가 나의 스타일을 얼마나 잘 학습하고 있는가"를 정량적으로 확인하고,
+축적된 교정 패턴을 바탕으로 프로필을 보정합니다.
+
+핵심 원칙: 추측이 아닌 증거, 점진적 조정, 반드시 사용자 동의.
+</Purpose>
+
+<Compound_Integration>
+## Evidence 수집 및 Compound 교차 검증
+
+calibrate는 두 가지 데이터 소스를 사용합니다:
+
+### 1차 소스: Evidence 파일
+`~/.forgen/me/evidence/` 디렉토리의 JSON 파일을 읽습니다.
+각 파일의 구조:
+```json
+{
+  "kind": "fix-now | prefer-from-now | avoid-this",
+  "axis_hint": "quality_safety | autonomy | judgment_philosophy | communication_style",
+  "description": "사용자가 교정한 내용",
+  "timestamp": "ISO-8601"
+}
+```
+
+### 2차 소스: Compound 교정 패턴
+compound-search MCP 도구로 교정 관련 축적 패턴을 검색합니다:
+```
+compound-search("correction profile")
+compound-search("교정 패턴")
+```
+
+compound에서 발견된 교정 패턴은 evidence와 교차 검증하여
+일관된 방향성이 있는지 확인합니다.
+
+### 데이터 부족 시
+evidence 0건 + compound 교정 패턴 0건이면:
+"아직 교정 데이터가 부족합니다. 더 사용하면서 교정이 쌓이면 다시 실행하세요."
+보고 후 즉시 종료합니다.
+</Compound_Integration>
+
+<Steps>
+## Phase 1: Evidence 로드 및 검증
+
+```bash
+ls ~/.forgen/me/evidence/ 2>/dev/null || echo "EMPTY"
+cat ~/.forgen/me/evidence/*.json 2>/dev/null || echo "NO_FILES"
+```
+
+로드한 JSON 파일마다 다음을 검증합니다:
+- `kind` 필드가 유효한 값인지 (fix-now, prefer-from-now, avoid-this)
+- `axis_hint` 필드가 4축 중 하나인지
+- `timestamp`가 지정된 기간 내인지 (기본 30일)
+
+기간 외의 evidence는 분석에서 제외하되, 총 건수는 참고로 표시합니다.
+
+## Phase 2: 현재 프로필 확인
+
+```bash
+cat ~/.forgen/me/forge-profile.json 2>/dev/null || echo "프로필 파일 없음"
+```
+
+프로필 파일이 없으면 기본값을 사용합니다:
+```json
+{
+  "quality_safety": "balanced",
+  "autonomy": "balanced",
+  "judgment_philosophy": "balanced",
+  "communication_style": "balanced"
+}
+```
+
+## Phase 3: Compound 교차 검색
+
+```
+compound-search("correction profile")
+compound-search("교정 행동 패턴")
+```
+
+compound 솔루션에서 교정 관련 패턴이 발견되면,
+evidence와 방향이 일치하는지 검증합니다.
+일치하면 신뢰도를 높이고, 상충하면 별도 표기합니다.
+
+## Phase 4: 축별 교정 분석 (정량 프로토콜)
+
+각 축에 대해 다음 절차를 수행합니다:
+
+### 4-1. 교정 건수 집계
+지정 기간 내 해당 axis_hint의 evidence 건수를 셉니다.
+
+### 4-2. 방향 감지
+교정 내용의 키워드와 kind를 분석하여 방향을 판별합니다:
+
+**quality_safety**: 보수형("확인 더 해줘","테스트 먼저") vs 속도형("그냥 해","빨리")
+**autonomy**: 자율실행형("왜 물어봐","알아서 해") vs 확인우선형("먼저 물어봐","확인하고")
+**judgment_philosophy**: 최소변경형("너무 많이 바꿨어","최소한만") vs 구조적접근형("근본적으로","구조적으로")
+**communication_style**: 간결형("너무 길어","짧게","코드만") vs 상세형("더 자세히","왜인지 설명")
+
+### 4-3. 방향 점수 계산
+```
+방향 점수 = (해당 방향 교정 건수) - (반대 방향 교정 건수)
+kind 보정: fix-now은 1.5배, prefer-from-now과 avoid-this는 1.0배
+```
+
+### 4-4. 임계값 판정
+- 같은 방향 교정 3건 이상 AND 방향 점수 >= 2 --> 변경 제안
+- 같은 방향 교정 1~2건 --> "데이터 부족, 유지" (관찰 중 표기)
+- 교정 0건 --> "현재 설정 유지"
+
+## Phase 5: 조정 제안 구성 (최대 2축 제한)
+
+변경 제안 대상이 3개 이상이면 방향 점수 상위 2개만 제안합니다.
+한 번에 한 단계만 이동합니다 (balanced→conservative, 두 단계 점프 금지).
+
+## Phase 6: 사용자 확인 및 적용
+
+선택지: Y(전체 적용) / n(취소) / 커스텀(축별 개별 선택)
+동의 시에만 forge-profile.json을 업데이트하고, 변경 이력을 calibration-log로 저장합니다.
+</Steps>
+
+<Failure_Modes>
+## 피해야 할 실패 패턴
+
+- evidence 없이 추측: 교정 데이터 0건이면 분석하지 않는다. "느낌상" 조정을 절대 제안하지 않는다.
+- 단일 교정으로 변경 제안: 같은 방향 3건 이상일 때만 제안한다. 1건은 과적합이다.
+- 모든 축 동시 변경: 한 번에 최대 2개 축만 조정 제안한다.
+- 두 단계 이상 점프: balanced에서 strict로 한 번에 뛰지 않는다.
+- 확인 없이 프로필 변경: 반드시 사용자 동의 후 수정한다. 자동 적용은 절대 없다.
+- 방향 상충 무시: 같은 축에서 양방향 교정이 혼재되면 변경하지 않고 명확화를 요청한다.
+- compound 데이터 맹신: evidence와 교차 검증 후에만 신뢰도 보조로 사용한다.
+</Failure_Modes>
+
+<Output>
+```
+PROFILE CALIBRATION / 프로필 보정
+═════════════════════════════════
+기간: 최근 30일 | 세션: {N}개 | 교정: {N}개
+
+현재 프로필:
+  quality_safety:      {value} ({facet_detail})
+  autonomy:            {value} ({facet_detail})
+  judgment_philosophy: {value} ({facet_detail})
+  communication_style: {value} ({facet_detail})
+
+교정 분석:
+  quality_safety:
+    교정 {N}건: "{example1}", "{example2}"
+    방향: {direction} (점수: +{score})
+    → {new_value}(으)로 변경 제안? [Y/n]
+
+  autonomy:
+    교정 0건 → 현재 설정 유지
+
+  judgment_philosophy:
+    교정 1건 → 충분하지 않음 (3건 이상 필요). 유지 (관찰 중)
+
+  communication_style:
+    교정 4건: "너무 길어", "간결하게", "코드만", "설명 줄여"
+    방향: 간결형 (점수: +4)
+    → 간결형으로 변경 제안? [Y/n]
+
+Compound 교차 검증:
+  quality_safety: compound에서 "테스트 우선" 패턴 2건 발견 → evidence와 일치
+  communication_style: compound에서 "간결 선호" 패턴 1건 발견 → evidence와 일치
+
+변경 요약: 2개 축 조정 제안 (quality_safety, communication_style)
+적용하시겠습니까? [Y/n/커스텀]
+```
+</Output>
+
+<Policy>
+- 교정 데이터 0건이면 "데이터 부족" 보고 후 즉시 종료합니다.
+- 같은 방향 교정 3건 이상, 방향 점수 2 이상일 때만 변경을 제안합니다.
+- 한 번에 최대 2개 축만 조정을 제안합니다.
+- 한 번에 한 단계만 이동합니다 (두 단계 점프 금지).
+- forge-profile.json 수정은 반드시 사용자 동의 후 진행합니다.
+- 방향이 혼재된 축은 변경하지 않고 사용자에게 명확화를 요청합니다.
+- compound 데이터는 evidence와 교차 검증 후에만 신뢰도 보조로 사용합니다.
+</Policy>
+
+<Arguments>
+## 사용법
+`/forgen:calibrate [기간]`
+
+### 기간 옵션
+- 인수 없음: 최근 30일 (기본값)
+- `7d`: 최근 7일
+- `30d`: 최근 30일
+- `90d`: 최근 90일
+- `all`: 전체 기간
+
+### 예시
+- `/forgen:calibrate` -- 최근 30일 기본 분석
+- `/forgen:calibrate 7d` -- 최근 1주일 집중 분석
+- `/forgen:calibrate 90d` -- 분기별 종합 보정
+</Arguments>
+
+$ARGUMENTS