@wooojin/forgen 0.1.0

package/skills/incident-response/SKILL.md

@@ -0,0 +1,286 @@
+---
+name: incident-response
+description: This skill should be used when the user asks to "incident,장애 대응,postmortem,장애 분석,사후 분석,outage". Incident response workflow with triage, mitigation, root cause analysis, and postmortem
+---
+
+<!-- forgen-managed -->
+
+<Purpose>
+장애 대응과 사후 분석(포스트모텀)을 체계적으로 수행합니다.
+트리아지, 긴급 완화, 근본 원인 분석, 수정, 사후 분석 보고서 작성,
+재발 방지 액션 아이템까지 인시던트 대응의 전체 라이프사이클을 다룹니다.
+</Purpose>
+
+<Steps>
+1. **트리아지**: 장애 심각도와 영향 범위를 신속히 판단합니다
+   - 장애 증상 수집 (에러 로그, 모니터링 알림, 사용자 보고)
+   - 심각도 분류:
+     * **SEV-1** (Critical): 서비스 전체 중단, 데이터 손실
+     * **SEV-2** (Major): 핵심 기능 장애, 일부 사용자 영향
+     * **SEV-3** (Minor): 비핵심 기능 장애, 우회 가능
+     * **SEV-4** (Low): 성능 저하, 미미한 영향
+   - 영향 범위 파악 (사용자 수, 기능, 지역)
+   - 타임라인 시작 (발생 시각 기록)
+   - 커뮤니케이션 채널 설정 (Slack 채널, 상태 페이지)
+   - 담당자 지정 (Incident Commander, Communication Lead)
+
+2. **긴급 완화**: 즉각적인 피해를 줄입니다
+   - 최근 배포 확인 (배포가 원인인가?)
+   - 롤백 가능 여부 판단 및 실행
+   - 장애 서비스 격리 (트래픽 차단, 서킷 브레이커)
+   - 임시 조치 적용 (캐시 비우기, 서비스 재시작, 스케일 아웃)
+   - 상태 페이지 업데이트 (사용자 공지)
+   - 완화 효과 확인 (모니터링 지표 정상화 여부)
+
+3. **근본 원인 분석**: 장애의 진짜 원인을 찾습니다
+   - 타임라인 재구성 (분 단위)
+   - 로그 분석 (에러 로그, 액세스 로그, 감사 로그)
+   - 메트릭 분석 (CPU, 메모리, 네트워크, 요청/에러율)
+   - 배포 이력 확인 (코드 변경, 설정 변경, 인프라 변경)
+   - 5 Whys 기법 적용:
+     * Why 1: 직접 원인은?
+     * Why 2: 왜 그 원인이 발생했는가?
+     * Why 3: 왜 감지하지 못했는가?
+     * Why 4: 왜 방지하지 못했는가?
+     * Why 5: 근본적으로 무엇이 부족했는가?
+   - 기여 요인 식별 (코드, 인프라, 프로세스, 인적 요소)
+
+4. **수정 적용**: 근본 원인을 해결합니다
+   - 코드 수정 작성
+   - 코드 리뷰 (간소화된 긴급 리뷰)
+   - 테스트 작성 (장애 재현 테스트)
+   - 스테이징 검증
+   - 프로덕션 배포
+   - 모니터링 강화 (해당 지표 임계값 조정)
+   - 수정 효과 확인 (장애 증상 완전 해소)
+
+5. **포스트모텀 작성**: 사후 분석 보고서를 작성합니다
+   - 비난 없는 분석 (blameless postmortem)
+   - 타임라인 정리 (발생 → 감지 → 완화 → 해결)
+   - 근본 원인 요약
+   - 잘된 점 (What went well)
+   - 개선할 점 (What could be improved)
+   - 행운이었던 점 (Where we got lucky)
+
+6. **액션 아이템 도출**: 재발 방지 대책을 수립합니다
+   - 단기 조치 (1주 이내): 즉각적인 보호 장치
+   - 중기 조치 (1개월 이내): 시스템 개선
+   - 장기 조치 (분기 내): 아키텍처/프로세스 개선
+   - 각 액션 아이템에 담당자와 기한 지정
+   - 액션 아이템 추적 체계 설정 (이슈 트래커)
+</Steps>
+
+## 에이전트 위임
+
+`debugger` 에이전트(Opus 모델)에 위임하여 근본 원인 분석을 수행합니다:
+
+```
+Agent(
+  subagent_type="debugger",
+  model="opus",
+  prompt="INCIDENT RESPONSE TASK
+
+장애 대응 및 근본 원인 분석을 수행하세요.
+
+Incident: [장애 설명]
+Severity: [SEV-1 / SEV-2 / SEV-3 / SEV-4]
+Symptoms: [관찰된 증상]
+
+Response Checklist:
+1. 트리아지 (심각도, 영향 범위)
+2. 긴급 완화 (롤백, 격리, 임시 조치)
+3. 근본 원인 분석 (로그, 메트릭, 5 Whys)
+4. 수정 적용 (코드 수정, 테스트, 배포)
+5. 포스트모텀 초안
+6. 액션 아이템 도출
+
+Output: 인시던트 대응 리포트:
+- 타임라인
+- 근본 원인
+- 완화/수정 조치
+- 포스트모텀 요약
+- 액션 아이템 목록"
+)
+```
+
+## External Consultation (Optional)
+
+debugger 에이전트는 교차 검증을 위해 Claude Task 에이전트에 자문할 수 있습니다.
+
+### Protocol
+1. **자체 분석을 먼저 완료** -- 독립적으로 근본 원인 조사
+2. **검증을 위한 자문** -- Claude Task 에이전트를 통해 분석 교차 확인
+3. **비판적 평가** -- 외부 제안을 맹목적으로 수용하지 않음
+4. **우아한 폴백** -- 위임이 불가능할 경우 절대 차단하지 않음
+
+### 자문이 필요한 경우
+- 데이터 손실이 발생한 SEV-1 장애
+- 보안 침해 의심
+- 재현이 어려운 간헐적 장애
+- 인프라 레벨의 복합 장애
+
+### 자문을 생략하는 경우
+- 명확한 배포 실패 (롤백으로 해결)
+- 단순 설정 오류
+- 알려진 패턴의 장애
+- SEV-3/SEV-4 수준의 경미한 이슈
+
+## 인시던트 대응 체크리스트
+
+### 즉시 대응 (5개)
+- [ ] 장애 심각도가 분류됨
+- [ ] 영향 범위가 파악됨
+- [ ] 커뮤니케이션 채널이 설정됨
+- [ ] 담당자가 지정됨
+- [ ] 타임라인 기록이 시작됨
+
+### 완화 (4개)
+- [ ] 최근 배포 확인 및 롤백 여부 판단됨
+- [ ] 임시 조치가 적용됨
+- [ ] 사용자에게 상태가 공지됨
+- [ ] 완화 효과가 확인됨
+
+### 근본 원인 (4개)
+- [ ] 로그 및 메트릭이 분석됨
+- [ ] 5 Whys가 적용됨
+- [ ] 기여 요인이 식별됨
+- [ ] 근본 원인이 확정됨
+
+### 사후 조치 (5개)
+- [ ] 수정이 코드 리뷰됨
+- [ ] 재현 테스트가 작성됨
+- [ ] 포스트모텀이 작성됨
+- [ ] 액션 아이템에 담당자/기한이 지정됨
+- [ ] 액션 아이템이 이슈 트래커에 등록됨
+
+## 대응 시간 기준
+
+| 심각도 | 감지 | 대응 시작 | 완화 | 해결 |
+|--------|------|-----------|------|------|
+| **SEV-1** | < 5분 | < 15분 | < 1시간 | < 4시간 |
+| **SEV-2** | < 15분 | < 30분 | < 4시간 | < 24시간 |
+| **SEV-3** | < 1시간 | < 4시간 | < 24시간 | < 1주 |
+| **SEV-4** | < 24시간 | 다음 스프린트 | -- | 백로그 |
+
+<Output>
+```
+INCIDENT REPORT / 인시던트 리포트
+===================================
+
+Incident ID: INC-YYYY-NNN
+Severity: [SEV-1 / SEV-2 / SEV-3 / SEV-4]
+Status: [INVESTIGATING / MITIGATING / RESOLVED / POSTMORTEM]
+Duration: [발생 → 해결 총 시간]
+
+TIMELINE / 타임라인
+---------------------
+HH:MM - [이벤트 설명]
+HH:MM - 장애 감지 (모니터링 알림)
+HH:MM - 트리아지 완료, SEV-N 선언
+HH:MM - 긴급 완화 적용 (롤백/격리)
+HH:MM - 서비스 정상화 확인
+HH:MM - 근본 원인 확정
+HH:MM - 영구 수정 배포
+
+IMPACT / 영향
+--------------
+- 영향 받은 사용자: ~N명
+- 영향 받은 기능: [기능 목록]
+- 데이터 손실: [있음/없음]
+- 수익 영향: [추정치]
+
+ROOT CAUSE / 근본 원인
+------------------------
+[근본 원인 설명]
+
+5 Whys:
+1. Why: [직접 원인]
+2. Why: [이유]
+3. Why: [이유]
+4. Why: [이유]
+5. Why: [근본 원인]
+
+Contributing Factors:
+- [기여 요인 1]
+- [기여 요인 2]
+
+POSTMORTEM / 사후 분석
+-----------------------
+What went well:
+- [잘된 점 1]
+- [잘된 점 2]
+
+What could be improved:
+- [개선할 점 1]
+- [개선할 점 2]
+
+Where we got lucky:
+- [행운이었던 점]
+
+ACTION ITEMS / 액션 아이템
+----------------------------
+[단기 - 1주 이내]
+- [ ] [조치 1] @담당자 (기한: YYYY-MM-DD)
+- [ ] [조치 2] @담당자 (기한: YYYY-MM-DD)
+
+[중기 - 1개월 이내]
+- [ ] [조치 3] @담당자 (기한: YYYY-MM-DD)
+
+[장기 - 분기 내]
+- [ ] [조치 4] @담당자 (기한: YYYY-MM-DD)
+```
+</Output>
+
+<Policy>
+- 비난 없는 문화를 유지합니다 -- 사람이 아닌 시스템과 프로세스에 집중
+- 완화가 분석보다 우선입니다 -- 먼저 불을 끄고 원인을 찾습니다
+- 타임라인은 정확하고 상세하게 기록합니다
+- 포스트모텀은 장애 후 48시간 이내에 작성합니다
+- 액션 아이템은 반드시 담당자와 기한을 지정합니다
+- 동일한 장애가 두 번 발생하는 것은 허용되지 않습니다
+</Policy>
+
+## 다른 스킬과의 연동
+
+**디버그 탐정 연동:**
+```
+/forgen:debug-detective 간헐적 장애 원인 분석
+```
+체계적 디버깅으로 근본 원인 추적
+
+**보안 리뷰 연동:**
+```
+/forgen:security-review 장애 원인이 보안 취약점인 경우
+```
+보안 관련 장애의 취약점 분석
+
+**테스트 전략 연동:**
+```
+/forgen:testing-strategy 장애 재발 방지 테스트
+```
+장애 재현 테스트 및 회귀 테스트 설계
+
+## Best Practices
+
+- **즉시 대응** -- 장애 감지 후 최대한 빨리 대응 시작
+- **커뮤니케이션** -- 이해관계자에게 정기적으로 상태 업데이트
+- **비난 금지** -- 시스템과 프로세스를 개선하는 데 집중
+- **기록 유지** -- 모든 조치와 판단의 근거를 기록
+- **후속 추적** -- 액션 아이템이 실제로 완료되었는지 추적
+
+<Arguments>
+## 사용법
+`/forgen:incident-response {장애 상황}`
+
+### 예시
+- `/forgen:incident-response API 500 에러 급증`
+- `/forgen:incident-response 데이터베이스 연결 타임아웃`
+- `/forgen:incident-response 어제 배포 후 로그인 실패 보고`
+- `/forgen:incident-response INC-2026-042 포스트모텀 작성`
+
+### 인자
+- 장애 증상, 에러 메시지, 영향 범위 등을 설명
+- 인자 없으면 현재 시스템 상태를 점검
+</Arguments>
+
+$ARGUMENTS

package/skills/migrate/SKILL.md

@@ -0,0 +1,96 @@
+---
+name: migrate
+description: This skill should be used when the user asks to "migrate,마이그레이션,업그레이드,upgrade". Safe migration workflow for DB, API, and framework upgrades
+---
+
+<Purpose>
+데이터베이스 스키마 변경, API 버전 업그레이드, 프레임워크 마이그레이션을
+안전하게 수행하는 5단계 워크플로우를 제공합니다.
+각 단계에서 롤백 지점을 확보하여 위험을 최소화합니다.
+</Purpose>
+
+<Steps>
+1. **분석 (Analyze)**
+   - 현재 상태 스냅샷: 의존성 트리, 스키마 버전, API 계약 문서화
+   - 변경 영향 범위 파악: `grep -r "import.*{패키지}" --include="*.ts"`
+   - Breaking Change 목록 작성 (CHANGELOG, 공식 마이그레이션 가이드 확인)
+   - 영향받는 파일/컴포넌트/테이블 전수 조사
+
+2. **계획 (Plan)**
+   - 마이그레이션 단계를 원자적 작업으로 분해
+   - 각 단계별 성공 기준(Done Criteria) 정의
+   - 롤백 트리거 조건 명시 (에러율 > N%, 레이턴시 > Nms)
+   - 다운타임 허용 여부 결정 → Zero-downtime 전략 수립
+
+3. **백업 (Backup)**
+   ```bash
+   # DB 백업
+   pg_dump -h localhost -U user dbname > backup_$(date +%Y%m%d_%H%M%S).sql
+   mysqldump -u user -p dbname > backup_$(date +%Y%m%d_%H%M%S).sql
+
+   # 코드 상태 태깅
+   git tag pre-migration-$(date +%Y%m%d) -m "Migration 전 백업 포인트"
+   git push origin --tags
+   ```
+
+4. **실행 (Execute)**
+   - **DB 마이그레이션**: 스키마 변경 → 데이터 변환 → 인덱스 재구성
+     ```sql
+     -- Expand-Contract 패턴 (Zero-downtime)
+     -- Phase 1: 새 컬럼 추가 (nullable)
+     ALTER TABLE users ADD COLUMN new_field VARCHAR(255);
+     -- Phase 2: 데이터 채우기 (백그라운드)
+     UPDATE users SET new_field = legacy_field WHERE new_field IS NULL;
+     -- Phase 3: 애플리케이션 배포 후 기존 컬럼 제거
+     ALTER TABLE users DROP COLUMN legacy_field;
+     ```
+   - **API 업그레이드**: 하위호환성 레이어 → 새 버전 배포 → 구버전 deprecation
+   - **프레임워크 업그레이드**:
+     ```bash
+     npx npm-check-updates -u     # 의존성 일괄 업데이트 확인
+     npx <framework> codemods     # 공식 코드모드 실행
+     ```
+
+5. **검증 (Verify)**
+   - 마이그레이션 전후 데이터 무결성 검증
+   - E2E 테스트 전체 실행
+   - 성능 회귀 벤치마크 (p95 레이턴시 비교)
+   - 롤백 절차 실제 테스트 (스테이징 환경)
+
+### 롤백 전략
+```bash
+# DB 롤백
+psql -h localhost -U user dbname < backup_20240101_120000.sql
+
+# 코드 롤백
+git checkout pre-migration-20240101
+git push --force-with-lease origin main  # 팀 동의 후만
+
+# 컨테이너/배포 롤백
+kubectl rollout undo deployment/app-name
+```
+</Steps>
+
+<Policy>
+- 프로덕션 마이그레이션 전 스테이징에서 반드시 전체 절차 검증
+- 대용량 테이블 마이그레이션은 배치 처리로 분할 (한 번에 MAX 10,000행)
+- Breaking Change는 최소 한 버전 deprecation 기간 제공
+- 마이그레이션 스크립트는 멱등성(idempotent) 보장
+</Policy>
+
+<Arguments>
+## 사용법
+`/forgen:migrate {마이그레이션 대상}`
+
+### 예시
+- `/forgen:migrate PostgreSQL users 테이블 스키마 변경 (email 컬럼 unique 추가)`
+- `/forgen:migrate React 17 → 19 업그레이드`
+- `/forgen:migrate REST API v1 → v2 마이그레이션 계획`
+
+### 인자
+- 마이그레이션 대상 (DB/API/프레임워크)
+- 현재 버전과 목표 버전
+- 다운타임 허용 여부 등 제약 조건
+</Arguments>
+
+$ARGUMENTS

package/skills/performance/SKILL.md

@@ -0,0 +1,282 @@
+---
+name: performance
+description: This skill should be used when the user asks to "performance,성능,profiling,최적화,프로파일링,bottleneck". Performance profiling, bottleneck identification, and optimization
+---
+
+<!-- forgen-managed -->
+
+<Purpose>
+애플리케이션의 성능을 체계적으로 프로파일링하고 최적화합니다.
+측정 기반 접근법으로 병목 지점을 식별하고, 최적화를 적용한 후
+개선 효과를 정량적으로 검증합니다.
+</Purpose>
+
+<Steps>
+1. **베이스라인 측정**: 현재 성능 지표를 수집합니다
+   - 응답 시간 측정 (P50, P95, P99)
+   - 처리량(throughput) 측정 (RPS, TPS)
+   - 메모리 사용량 프로파일링 (힙 크기, GC 빈도)
+   - CPU 사용률 측정 (사용자/시스템 시간)
+   - I/O 대기 시간 (디스크, 네트워크)
+   - 번들 크기 측정 (프론트엔드)
+   - Core Web Vitals 수집 (LCP, FID, CLS)
+   - 측정 환경 기록 (하드웨어, OS, 런타임 버전)
+
+2. **병목 지점 식별**: 성능 저하의 근본 원인을 찾습니다
+   - CPU 프로파일링 (핫 함수 식별)
+   - 메모리 프로파일링 (힙 스냅샷, 리크 탐지)
+   - 네트워크 분석 (요청 waterfall, 느린 API 호출)
+   - 데이터베이스 쿼리 분석 (EXPLAIN, 슬로우 쿼리 로그)
+   - N+1 쿼리 패턴 탐지
+   - 불필요한 리렌더링 탐지 (React Profiler)
+   - 이벤트 루프 블로킹 탐지 (Node.js)
+   - 동기/비동기 혼용 문제 확인
+
+3. **최적화 적용**: 식별된 병목을 해결합니다
+   - 알고리즘 최적화 (시간/공간 복잡도 개선)
+   - 캐싱 전략 적용 (인메모리, Redis, CDN)
+   - 쿼리 최적화 (인덱스 추가, 쿼리 리팩토링)
+   - 지연 로딩(lazy loading) 적용
+   - 코드 스플리팅 (동적 import)
+   - 이미지/에셋 최적화 (압축, WebP, CDN)
+   - 커넥션 풀링 최적화
+   - 비동기/병렬 처리 도입
+   - 메모이제이션 적용 (useMemo, React.memo)
+   - 불필요한 직렬화/역직렬화 제거
+
+4. **검증**: 최적화 효과를 정량적으로 측정합니다
+   - 동일 조건에서 베이스라인 대비 비교
+   - 개선율 계산 (% 단위)
+   - 회귀 테스트 -- 기능 동작이 변경되지 않았는지 확인
+   - 부하 테스트 (k6, Artillery, autocannon)
+   - 메모리 리크 없음 확인 (장시간 실행)
+   - 엣지 케이스 성능 확인 (빈 데이터, 대용량 데이터)
+
+5. **문서화**: 최적화 결과와 가이드를 기록합니다
+   - 이전/이후 성능 비교표
+   - 적용한 최적화 기법과 근거
+   - 향후 성능 모니터링 포인트
+   - 성능 예산(performance budget) 설정
+   - 회귀 방지를 위한 성능 테스트 추가
+</Steps>
+
+## 에이전트 위임
+
+`performance-reviewer` 에이전트(Opus 모델)에 위임하여 성능 분석을 수행합니다:
+
+```
+Agent(
+  subagent_type="performance-reviewer",
+  model="opus",
+  prompt="PERFORMANCE ANALYSIS TASK
+
+성능 프로파일링 및 최적화를 수행하세요.
+
+Target: [분석 대상 코드/서비스]
+Concern: [구체적인 성능 문제 또는 전반적 분석]
+
+Analysis Checklist:
+1. 베이스라인 측정 (응답 시간, 메모리, CPU)
+2. 병목 지점 식별 (프로파일링)
+3. 최적화 방안 제시 (우선순위별)
+4. 최적화 적용 및 효과 검증
+5. 성능 예산 및 모니터링 계획
+
+Output: 성능 분석 리포트:
+- 베이스라인 지표
+- 병목 지점 목록 (영향도 순)
+- 최적화 방안 및 예상 개선율
+- 적용 결과 (이전/이후 비교)
+- 권장 성능 예산"
+)
+```
+
+## External Consultation (Optional)
+
+performance-reviewer 에이전트는 교차 검증을 위해 Claude Task 에이전트에 자문할 수 있습니다.
+
+### Protocol
+1. **자체 성능 분석을 먼저 완료** -- 독립적으로 프로파일링 수행
+2. **검증을 위한 자문** -- Claude Task 에이전트를 통해 최적화 전략 교차 확인
+3. **비판적 평가** -- 외부 제안을 맹목적으로 수용하지 않음
+4. **우아한 폴백** -- 위임이 불가능할 경우 절대 차단하지 않음
+
+### 자문이 필요한 경우
+- 복잡한 알고리즘 최적화 (시간/공간 트레이드오프)
+- 데이터베이스 쿼리 튜닝 (복잡한 JOIN, 서브쿼리)
+- 분산 시스템의 성능 문제
+- 메모리 리크 진단
+
+### 자문을 생략하는 경우
+- 단순 캐싱 적용
+- 명확한 N+1 쿼리 해결
+- 번들 크기 최적화
+- 이미지/에셋 최적화
+
+## 성능 분석 체크리스트
+
+### 서버 사이드 (5개)
+- [ ] 슬로우 쿼리가 식별되고 최적화됨
+- [ ] N+1 쿼리 패턴이 제거됨
+- [ ] 적절한 캐싱이 적용됨
+- [ ] 커넥션 풀 크기가 적절히 설정됨
+- [ ] 비동기 처리가 활용됨 (I/O 바운드 작업)
+
+### 클라이언트 사이드 (5개)
+- [ ] Core Web Vitals가 "Good" 등급
+- [ ] 번들 크기가 예산 이내
+- [ ] 코드 스플리팅이 적용됨
+- [ ] 불필요한 리렌더링이 제거됨
+- [ ] 이미지가 최적화됨 (WebP, lazy load)
+
+### 인프라 (4개)
+- [ ] CDN이 적절히 활용됨
+- [ ] 캐시 히트율이 측정됨
+- [ ] 오토스케일링 임계값이 설정됨
+- [ ] 리소스 사용량이 모니터링됨
+
+### 검증 (4개)
+- [ ] 베이스라인 대비 개선율이 측정됨
+- [ ] 부하 테스트로 한계 확인됨
+- [ ] 메모리 리크가 없음이 확인됨
+- [ ] 기능 회귀가 없음이 확인됨
+
+## 성능 등급 기준
+
+| 등급 | 응답 시간 (P95) | 메모리 | 번들 크기 |
+|------|-----------------|--------|-----------|
+| **EXCELLENT** | < 100ms | 안정적, 리크 없음 | < 200KB (gzip) |
+| **GOOD** | < 300ms | 안정적 | < 500KB (gzip) |
+| **FAIR** | < 1000ms | 점진적 증가 | < 1MB (gzip) |
+| **POOR** | > 1000ms | 리크 의심 | > 1MB (gzip) |
+
+## 최적화 우선순위 가이드
+
+| 우선순위 | 대상 | 예상 효과 |
+|----------|------|-----------|
+| 1 | 슬로우 쿼리/N+1 제거 | 10x~100x |
+| 2 | 캐싱 도입 | 5x~50x |
+| 3 | 알고리즘 최적화 | 2x~10x |
+| 4 | 번들/에셋 최적화 | 20~50% 감소 |
+| 5 | 불필요한 리렌더링 제거 | 체감 개선 |
+
+<Output>
+```
+PERFORMANCE REPORT / 성능 분석 리포트
+======================================
+
+Target: [분석 대상]
+Environment: [Node.js 20 / Chrome 120 / etc.]
+Date: YYYY-MM-DDTHH:MM:SSZ
+
+BASELINE / 베이스라인
+----------------------
+| Metric           | Value    | Grade     |
+|------------------|----------|-----------|
+| Response (P50)   | 120ms    | GOOD      |
+| Response (P95)   | 850ms    | FAIR      |
+| Response (P99)   | 2100ms   | POOR      |
+| Memory (avg)     | 256MB    | GOOD      |
+| CPU (avg)        | 45%      | GOOD      |
+| Bundle (gzip)    | 380KB    | GOOD      |
+
+BOTTLENECKS / 병목 지점
+-------------------------
+1. [CRITICAL] src/api/orders.ts:45 - N+1 쿼리
+   Impact: P95 응답 시간의 60%를 차지
+   Evidence: 주문 1건당 상품 쿼리 N회 발생
+   Fix: JOIN 또는 DataLoader 패턴 적용
+
+2. [HIGH] src/utils/transform.ts:120 - O(n^2) 알고리즘
+   Impact: 데이터 1000건 이상에서 급격한 성능 저하
+   Evidence: CPU 프로파일링에서 핫스팟
+   Fix: Map 기반 O(n) 알고리즘으로 변경
+
+3. [MEDIUM] src/components/List.tsx - 불필요한 리렌더링
+   Impact: 스크롤 시 프레임 드롭
+   Evidence: React Profiler에서 불필요한 렌더 감지
+   Fix: React.memo + useMemo 적용
+
+OPTIMIZATIONS APPLIED / 적용된 최적화
+---------------------------------------
+1. N+1 쿼리 제거: JOIN 적용
+   Before: 850ms (P95)  →  After: 120ms (P95)
+   Improvement: 86% 감소
+
+2. 알고리즘 최적화: O(n^2) → O(n)
+   Before: 450ms (1000건)  →  After: 12ms (1000건)
+   Improvement: 97% 감소
+
+AFTER / 최적화 후
+-------------------
+| Metric           | Before   | After    | Change   |
+|------------------|----------|----------|----------|
+| Response (P95)   | 850ms    | 150ms    | -82%     |
+| Memory (avg)     | 256MB    | 230MB    | -10%     |
+| Bundle (gzip)    | 380KB    | 310KB    | -18%     |
+
+PERFORMANCE BUDGET / 성능 예산
+-------------------------------
+- API Response (P95): < 200ms
+- Bundle Size (gzip): < 400KB
+- LCP: < 2.5s
+- FID: < 100ms
+- CLS: < 0.1
+
+GRADE: [EXCELLENT / GOOD / FAIR / POOR]
+```
+</Output>
+
+<Policy>
+- 추측 기반 최적화 금지 -- 반드시 측정 결과에 근거
+- 최적화 전후 비교를 정량적으로 제시합니다
+- 가독성/유지보수성을 해치는 미시 최적화는 지양합니다
+- 성능 예산을 설정하여 회귀를 방지합니다
+- 프로덕션 환경과 유사한 조건에서 측정합니다
+- 최적화의 부작용(메모리 증가, 복잡도 증가)을 명시합니다
+</Policy>
+
+## 다른 스킬과의 연동
+
+**데이터베이스 연동:**
+```
+/forgen:database 슬로우 쿼리 인덱싱
+```
+쿼리 성능 문제를 인덱스로 해결
+
+**코드 리뷰 연동:**
+```
+/forgen:code-review 성능 최적화 코드
+```
+최적화 코드의 정확성 검증
+
+**TDD 연동:**
+```
+/forgen:tdd 성능 회귀 테스트
+```
+성능 기준을 테스트로 보장
+
+## Best Practices
+
+- **측정 우선** -- "느린 것 같다"는 최적화 근거가 아님
+- **큰 것부터** -- 10% 개선보다 10x 개선을 먼저 찾기
+- **회귀 방지** -- 성능 테스트를 CI에 포함
+- **예산 설정** -- 성능 예산을 팀과 합의
+- **지속 모니터링** -- 프로덕션 성능을 실시간 추적
+
+<Arguments>
+## 사용법
+`/forgen:performance {분석 대상}`
+
+### 예시
+- `/forgen:performance API 응답 시간 최적화`
+- `/forgen:performance 프론트엔드 번들 크기 분석`
+- `/forgen:performance src/services/order.ts 쿼리 성능`
+- `/forgen:performance 메모리 리크 진단`
+
+### 인자
+- 분석할 대상, 성능 문제, 최적화 목표를 설명
+- 인자 없으면 프로젝트 전반의 성능을 프로파일링
+</Arguments>
+
+$ARGUMENTS