@wooojin/forgen 0.1.0

package/commands/code-review.md

@@ -0,0 +1,233 @@
+---
+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
+triggers:
+  - "code review"
+  - "코드 리뷰"
+  - "리뷰해줘"
+  - "review this"
+---
+
+<Purpose>
+체계적인 코드 리뷰를 수행하여 품질, 보안, 유지보수성을 검증합니다.
+심각도별로 분류된 피드백을 제공합니다.
+</Purpose>
+
+<Steps>
+1. **스코프 파악**: 변경된 파일과 영향 범위를 식별합니다
+   - git diff 또는 지정된 파일 확인
+   - 변경의 목적과 컨텍스트 이해
+
+2. **정확성 검증**: 로직이 의도대로 동작하는지 확인합니다
+   - 엣지 케이스 처리 여부
+   - 에러 핸들링 적절성
+   - 동시성/경쟁 조건
+
+3. **보안 검토**: OWASP Top 10 기준으로 취약점을 점검합니다
+   - 입력 검증/살균
+   - 인증/인가 로직
+   - 민감 정보 노출
+
+4. **유지보수성**: 코드 품질과 가독성을 평가합니다
+   - 네이밍 컨벤션
+   - SOLID 원칙 준수
+   - 적절한 추상화 수준
+
+5. **피드백 작성**: 심각도별로 분류하여 리포트합니다
+</Steps>
+
+## 에이전트 위임
+
+`code-reviewer` 에이전트(Opus 모델)에 위임하여 심층 코드 분석을 수행합니다:
+
+```
+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)"
+)
+```
+
+## 리뷰 체크리스트 (20개 항목)
+
+### Security (6개)
+- [ ] 하드코딩된 시크릿 없음 (API 키, 비밀번호, 토큰)
+- [ ] 모든 사용자 입력이 살균됨
+- [ ] SQL/NoSQL 인젝션 방지
+- [ ] XSS 방지 (출력 이스케이핑)
+- [ ] CSRF 보호 (상태 변경 작업)
+- [ ] 인증/인가가 적절히 적용됨
+
+### Code Quality (5개)
+- [ ] 함수가 50줄 미만 (가이드라인)
+- [ ] 순환 복잡도 10 미만
+- [ ] 깊은 중첩 없음 (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** | 스타일/제안 (수정 고려) |
+
+<Output>
+```
+CODE REVIEW REPORT / 코드 리뷰 리포트
+======================================
+
+Files Reviewed: N
+Total Issues: N
+
+CRITICAL (N)
+------------
+(없음 / 이슈 상세)
+
+HIGH (N)
+--------
+1. src/api/auth.ts:42
+   Issue: 사용자 입력이 SQL 쿼리 전에 살균되지 않음
+   Risk: SQL 인젝션 취약점
+   Fix: 파라미터화 쿼리 또는 ORM 사용
+
+2. src/components/UserProfile.tsx:89
+   Issue: 비밀번호가 로그에 평문으로 출력됨
+   Risk: 크리덴셜 노출
+   Fix: 로그 구문에서 비밀번호 제거
+
+3. src/utils/validation.ts:15
+   Issue: 이메일 정규식이 잘못된 형식을 허용
+   Risk: 잘못된 이메일 수용
+   Fix: 검증된 이메일 유효성 검사 라이브러리 사용
+
+MEDIUM (N)
+----------
+...
+
+LOW (N)
+-------
+...
+
+RECOMMENDATION: [APPROVE / REQUEST CHANGES / COMMENT]
+
+[수정이 필요한 경우 요약 코멘트]
+```
+</Output>
+
+<Policy>
+- 변경된 코드만 리뷰합니다 (기존 코드의 기술 부채는 별도 이슈로)
+- 구체적인 코드 라인을 참조하여 피드백합니다
+- 문제 지적 시 해결 방안도 함께 제시합니다
+- 잘된 부분도 언급하여 균형 잡힌 피드백을 제공합니다
+- 20개 체크 항목을 빠짐없이 검토합니다
+- APPROVE/REQUEST CHANGES/COMMENT 3단계 판정을 반드시 포함합니다
+</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 {리뷰 대상}`
+
+### 예시
+- `/forgen:code-review` (기본: 최근 변경사항 리뷰)
+- `/forgen:code-review src/auth/login.ts`
+- `/forgen:code-review 최근 3개 커밋`
+- `/forgen:code-review PR #42`
+
+### 인자
+- 파일 경로, 커밋 범위, PR 번호 등을 지정
+- 인자 없으면 `git diff`로 변경사항을 자동 감지
+</Arguments>
+
+$ARGUMENTS

package/commands/compound.md

@@ -0,0 +1,117 @@
+---
+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
+model: inherit
+allowed-tools:
+  - Bash
+  - Read
+  - Write
+  - mcp__forgen-compound__compound-search
+  - mcp__forgen-compound__compound-read
+  - mcp__forgen-compound__compound-list
+  - mcp__forgen-compound__compound-stats
+triggers:
+  - "복리화"
+  - "compound"
+  - "패턴 추출"
+  - "솔루션 축적"
+  - "what did we learn"
+  - "배운 것 정리"
+---
+
+<Purpose>
+이 세션에서 수행한 작업을 분석하여 재사용 가능한 지식을 추출하고 축적합니다.
+당신은 이 대화의 전체 맥락을 갖고 있으므로, git diff만으로는 알 수 없는 "왜"를 포함할 수 있습니다.
+참고: CLI `forgen compound`는 최근 코드/세션을 자동 분석한 결과를 미리보기하고, `--save`일 때만 저장합니다. 이 slash skill은 대화 전체 맥락을 바탕으로 수동 추출할 때 사용합니다.
+</Purpose>
+
+<Steps>
+## Phase 1: 세션 분석
+
+이 세션의 대화를 돌아보며 다음을 식별하세요:
+
+### 솔루션 (재사용 가능한 패턴)
+- 어떤 기술적 결정을 내렸는가? 왜?
+- 어떤 접근법이 효과적이었는가?
+- 시도했다가 실패한 것은? (anti-pattern)
+- 반복될 수 있는 패턴이 있는가?
+
+### 트러블슈팅 (문제 해결 지식)
+- 어떤 에러/문제를 만났는가?
+- 근본 원인은 무엇이었는가?
+- 해결 방법은?
+- 다음에 같은 문제를 만나면 바로 적용할 수 있는 해결 절차는?
+
+### 의사결정 (선택의 근거)
+- 기술 스택/라이브러리 선택의 이유
+- 아키텍처 결정의 배경
+- 트레이드오프와 그 판단 근거
+
+### 안티패턴 (피해야 할 것)
+- 이 세션에서 시도했다가 실패한 접근법은?
+- 왜 실패했는가? (근본 원인)
+- 다음에 같은 실수를 피하려면?
+
+### 영향 범위 분석
+- 이 변경/결정이 다른 모듈/파일에 미치는 영향은?
+- 의존하는 코드가 깨질 수 있는가?
+- 어떤 테스트가 추가로 필요한가?
+
+### 기존 항목 교차 참조
+축적 전에 기존 compound 항목과 비교하세요:
+```bash
+forgen compound list
+```
+- 이미 유사한 솔루션/규칙이 있는가? → 업데이트 또는 보완
+- 기존 항목과 모순되는가? → 둘 다 기록하고 비교
+
+### 확신도 자기 평가
+각 추출 항목에 대해 확신도를 평가하세요:
+- **높음**: 명확한 인과관계, 반복 검증됨
+- **중간**: 합리적 추론, 1회 검증
+- **낮음**: 가설 수준, 추가 검증 필요
+
+## Phase 2: 품질 게이트
+
+추출 전 각 항목을 검증하세요:
+
+1. **재사용 가능한가?** — 이 프로젝트에만 해당하는 것은 제외 (scope: project로 표시)
+2. **구체적인가?** — "좋은 코드를 작성하자" 같은 일반론은 제외
+3. **실행 가능한가?** — 다음에 적용할 수 있는 구체적 내용이 있는가?
+4. **독성이 없는가?** — @ts-ignore, --force, 임시 우회 같은 패턴은 제외
+
+## Phase 3: 축적
+
+추출한 각 인사이트를 CLI 명령어로 저장합니다:
+
+```bash
+# 솔루션 (재사용 가능한 패턴)
+forgen compound --solution "제목" "왜 이 접근법을 사용했고, 언제 적용하는지 포함한 상세 설명"
+
+# 트러블슈팅 (에러 → 원인 → 해결)
+forgen compound --solution "에러명-해결법" "에러 상황, 근본 원인, 해결 절차를 포함"
+
+# 의사결정 (선택의 근거)
+forgen compound --solution "기술선택-이유" "어떤 대안이 있었고 왜 이것을 선택했는지"
+
+# 안티패턴 (피해야 할 것)
+forgen compound --solution "피해야-할-패턴" "왜 이 접근이 실패했고 대신 무엇을 해야 하는지"
+```
+
+**중요**:
+- 각 솔루션의 내용에 **"왜"**를 반드시 포함하세요
+- 제목은 구체적으로 (예: "React-useCallback-memo-최적화" O, "성능개선" X)
+- 내용은 다른 세션에서 이 솔루션을 보고 바로 적용할 수 있을 정도로 상세하게
+- 단순 타이포/1줄 수정 세션이면 → "복리화 불필요" 후 종료
+
+## Phase 4: 리포트
+
+```
+📊 세션 복리화 완료
+├─ 추출: N개 솔루션
+├─ 유형: pattern X개, troubleshoot Y개, decision Z개
+└─ 저장: ~/.forgen/me/solutions/
+```
+</Steps>
+
+$ARGUMENTS

package/commands/database.md

@@ -0,0 +1,263 @@
+---
+name: database
+description: This skill should be used when the user asks to "database,db 설계,schema,migration,마이그레이션,스키마". Database schema design, migration planning, and optimization
+triggers:
+  - "database"
+  - "db 설계"
+  - "schema"
+  - "migration"
+  - "마이그레이션"
+  - "스키마"
+---
+<!-- forgen-managed -->
+
+<Purpose>
+데이터베이스 스키마 설계와 마이그레이션을 체계적으로 수행합니다.
+요구사항 분석부터 정규화, 인덱싱, 마이그레이션 스크립트 작성,
+롤백 계획까지 데이터 레이어의 전체 라이프사이클을 다룹니다.
+</Purpose>
+
+<Steps>
+1. **요구사항 분석**: 데이터 요구사항을 수집하고 정리합니다
+   - 비즈니스 엔티티와 관계 식별
+   - 읽기/쓰기 비율 추정 (read-heavy vs write-heavy)
+   - 예상 데이터 볼륨 추정 (행 수, 증가율)
+   - 트랜잭션 요구사항 (ACID, eventual consistency)
+   - 보존 정책 (데이터 수명, 아카이빙 규칙)
+   - 규제 요구사항 (GDPR, 개인정보보호법)
+
+2. **스키마 설계**: 정규화된 스키마를 설계합니다
+   - ERD(Entity-Relationship Diagram) 작성
+   - 정규화 수준 결정 (3NF 기본, 필요 시 역정규화)
+   - 데이터 타입 선택 (정확한 크기, nullable 여부)
+   - 기본 키 전략 (UUID vs auto-increment vs ULID)
+   - 외래 키 제약 조건 및 cascade 정책
+   - 소프트 삭제(soft delete) vs 하드 삭제 결정
+   - 감사(audit) 필드 포함 (created_at, updated_at, created_by)
+   - enum 값의 저장 전략 (DB enum vs string vs lookup table)
+
+3. **인덱싱 전략**: 쿼리 성능을 위한 인덱스를 설계합니다
+   - 주요 쿼리 패턴 분석 (WHERE, JOIN, ORDER BY)
+   - 단일 컬럼 인덱스 vs 복합 인덱스 결정
+   - 커버링 인덱스 활용 가능성 검토
+   - 부분 인덱스(partial index) 적용 가능성
+   - 인덱스 카디널리티와 선택도 분석
+   - 인덱스의 쓰기 성능 영향 평가
+   - EXPLAIN ANALYZE로 쿼리 플랜 검증 계획
+
+4. **마이그레이션 스크립트 작성**: 안전한 마이그레이션을 구현합니다
+   - 마이그레이션 도구 선택 (Prisma, Knex, TypeORM, raw SQL)
+   - UP 마이그레이션 작성 (스키마 변경 적용)
+   - DOWN 마이그레이션 작성 (변경 롤백)
+   - 데이터 마이그레이션 포함 (기존 데이터 변환)
+   - 대용량 테이블 변경 시 무중단 전략 (온라인 DDL)
+   - 마이그레이션 순서 의존성 확인
+
+5. **롤백 계획**: 장애 시 복구 절차를 수립합니다
+   - 롤백 스크립트 테스트 (UP -> DOWN -> UP 사이클)
+   - 데이터 손실 없는 롤백 가능 여부 확인
+   - 백업/복원 절차 문서화
+   - 마이그레이션 실패 시 수동 복구 절차
+   - Point-in-Time Recovery 설정 확인
+
+6. **성능 검증**: 스키마 변경의 성능 영향을 검증합니다
+   - 마이그레이션 실행 시간 추정
+   - 테이블 잠금(lock) 영향 범위 확인
+   - 인덱스 생성의 동시성 영향 (CONCURRENTLY 옵션)
+   - 스테이징 환경에서 실데이터 볼륨 테스트
+</Steps>
+
+## 에이전트 위임
+
+`architect` 에이전트(Opus 모델)에 위임하여 데이터베이스 아키텍처를 설계합니다:
+
+```
+Agent(
+  subagent_type="architect",
+  model="opus",
+  prompt="DATABASE DESIGN TASK
+
+데이터베이스 스키마를 설계하고 마이그레이션 계획을 수립하세요.
+
+Domain: [도메인/서비스 설명]
+Database: [PostgreSQL / MySQL / MongoDB / etc.]
+
+Design Checklist:
+1. ERD 및 엔티티 관계 설계
+2. 정규화 및 데이터 타입 결정
+3. 인덱싱 전략 수립
+4. 마이그레이션 스크립트 (UP/DOWN)
+5. 롤백 계획 및 백업 절차
+6. 성능 영향 분석
+
+Output: 데이터베이스 설계 문서:
+- ERD (텍스트 기반)
+- 테이블/컬렉션 정의
+- 인덱스 목록
+- 마이그레이션 스크립트
+- 롤백 절차"
+)
+```
+
+## External Consultation (Optional)
+
+architect 에이전트는 교차 검증을 위해 Claude Task 에이전트에 자문할 수 있습니다.
+
+### Protocol
+1. **자체 스키마 설계를 먼저 완료** -- 독립적으로 설계 수행
+2. **검증을 위한 자문** -- Claude Task 에이전트를 통해 설계 교차 확인
+3. **비판적 평가** -- 외부 제안을 맹목적으로 수용하지 않음
+4. **우아한 폴백** -- 위임이 불가능할 경우 절대 차단하지 않음
+
+### 자문이 필요한 경우
+- 대규모 스키마 마이그레이션 (10+ 테이블 변경)
+- 성능이 중요한 인덱싱 전략
+- 프로덕션 환경의 무중단 마이그레이션
+- 데이터 일관성이 중요한 트랜잭션 설계
+
+### 자문을 생략하는 경우
+- 단순 테이블 추가/수정
+- 잘 알려진 스키마 패턴 적용
+- 개발 환경의 마이그레이션
+- 소규모 인덱스 추가
+
+## 데이터베이스 설계 체크리스트
+
+### 스키마 설계 (6개)
+- [ ] 모든 테이블에 적절한 기본 키 존재
+- [ ] 외래 키 제약 조건이 설정됨
+- [ ] 데이터 타입이 정확한 크기로 선택됨
+- [ ] nullable 필드가 명시적으로 결정됨
+- [ ] 감사 필드 포함 (created_at, updated_at)
+- [ ] 소프트 삭제 전략이 결정됨
+
+### 인덱싱 (4개)
+- [ ] 주요 쿼리 패턴에 인덱스 적용됨
+- [ ] 복합 인덱스의 컬럼 순서가 최적화됨
+- [ ] 과도한 인덱스로 인한 쓰기 성능 저하 없음
+- [ ] 유니크 제약 조건이 비즈니스 규칙과 일치
+
+### 마이그레이션 (4개)
+- [ ] UP/DOWN 마이그레이션 모두 작성됨
+- [ ] 데이터 마이그레이션이 포함됨 (필요 시)
+- [ ] 롤백 테스트 완료
+- [ ] 마이그레이션 실행 시간이 허용 범위 내
+
+### 보안 (4개)
+- [ ] 민감 데이터가 암호화됨
+- [ ] 접근 권한이 최소 권한 원칙으로 설정됨
+- [ ] PII 데이터의 보존/삭제 정책이 정의됨
+- [ ] 감사 로그가 중요 변경에 대해 기록됨
+
+<Output>
+```
+DATABASE DESIGN DOCUMENT / 데이터베이스 설계 문서
+==================================================
+
+Service: [서비스명]
+Database: [PostgreSQL / MySQL / MongoDB]
+Migration Tool: [Prisma / Knex / TypeORM]
+
+ERD / 엔티티 관계
+-------------------
+[User] 1---N [Order] N---M [Product]
+  |                         |
+  1---N [Address]           1---N [Review]
+
+TABLES / 테이블 정의
+---------------------
+Table: users
+  id          UUID        PK, DEFAULT gen_random_uuid()
+  email       VARCHAR(255) NOT NULL, UNIQUE
+  name        VARCHAR(100) NOT NULL
+  password    VARCHAR(255) NOT NULL
+  role        VARCHAR(20)  NOT NULL, DEFAULT 'user'
+  created_at  TIMESTAMPTZ  NOT NULL, DEFAULT NOW()
+  updated_at  TIMESTAMPTZ  NOT NULL, DEFAULT NOW()
+  deleted_at  TIMESTAMPTZ  NULL
+
+INDEXES / 인덱스
+-----------------
+| Table  | Name                | Columns        | Type   | Reason              |
+|--------|---------------------|----------------|--------|---------------------|
+| users  | idx_users_email     | email          | UNIQUE | 로그인 조회          |
+| orders | idx_orders_user_date| user_id, date  | BTREE  | 사용자별 주문 조회   |
+
+MIGRATION / 마이그레이션
+-------------------------
+File: 20260402_001_create_users.sql
+
+-- UP
+CREATE TABLE users ( ... );
+CREATE INDEX idx_users_email ON users(email);
+
+-- DOWN
+DROP TABLE IF EXISTS users;
+
+ROLLBACK PLAN / 롤백 계획
+---------------------------
+1. 마이그레이션 실패 시: DOWN 스크립트 실행
+2. 데이터 손실 위험 시: pg_dump 백업에서 복원
+3. 긴급 시: Point-in-Time Recovery 사용
+
+PERFORMANCE IMPACT / 성능 영향
+-------------------------------
+- 마이그레이션 예상 시간: [N분]
+- 테이블 잠금: [있음/없음]
+- 인덱스 생성: [CONCURRENTLY 사용 여부]
+```
+</Output>
+
+<Policy>
+- 마이그레이션은 반드시 UP/DOWN 양방향으로 작성합니다
+- 프로덕션 마이그레이션 전 스테이징에서 실행 테스트 필수
+- 데이터 손실 가능성이 있는 변경은 백업 확인 후 진행
+- 인덱스 변경은 EXPLAIN ANALYZE로 효과를 검증합니다
+- 대용량 테이블의 ALTER는 무중단 전략을 사용합니다
+- 롤백 불가능한 마이그레이션은 명시적으로 경고합니다
+</Policy>
+
+## 다른 스킬과의 연동
+
+**API 설계 연동:**
+```
+/forgen:api-design 데이터 모델 기반 REST API
+```
+데이터베이스 스키마와 일관된 API 설계
+
+**보안 리뷰 연동:**
+```
+/forgen:security-review 마이그레이션 스크립트
+```
+마이그레이션의 보안 영향 점검
+
+**성능 최적화 연동:**
+```
+/forgen:performance 쿼리 성능 분석
+```
+인덱스 효과 및 쿼리 최적화
+
+## Best Practices
+
+- **점진적 마이그레이션** -- 대규모 변경을 작은 단계로 분할
+- **데이터 먼저 백업** -- 프로덕션 변경 전 반드시 백업
+- **테스트 환경 검증** -- 실 데이터 볼륨으로 성능 확인
+- **문서화** -- 스키마 변경 이유와 영향을 기록
+- **무중단 우선** -- 서비스 중단 없는 마이그레이션 전략
+
+<Arguments>
+## 사용법
+`/forgen:database {설계/마이그레이션 대상}`
+
+### 예시
+- `/forgen:database 사용자 관리 시스템 스키마 설계`
+- `/forgen:database orders 테이블에 discount 컬럼 추가 마이그레이션`
+- `/forgen:database 기존 스키마의 인덱싱 최적화`
+- `/forgen:database PostgreSQL에서 MongoDB로 마이그레이션 계획`
+
+### 인자
+- 설계할 도메인, 변경할 스키마, 마이그레이션 목적 등을 설명
+- 인자 없으면 프로젝트의 현재 스키마를 분석
+</Arguments>
+
+$ARGUMENTS