@wooojin/forgen 0.2.1 → 0.3.0

package/skills/ci-cd/SKILL.md

@@ -1,264 +0,0 @@
----
-name: ci-cd
-description: This skill should be used when the user asks to "ci cd,ci/cd,파이프라인,github actions,배포 자동화,pipeline design". CI/CD pipeline design, implementation, and optimization
----
-
-<!-- forgen-managed -->
-
-<Purpose>
-CI/CD 파이프라인을 설계하고 구현합니다.
-빌드, 테스트, 린트, 보안 스캔, 배포까지의 자동화 파이프라인을 구축하고
-안정적이고 빠른 배포 사이클을 확립합니다.
-</Purpose>
-
-<Steps>
-1. **요구사항 분석**: 프로젝트의 CI/CD 요구사항을 파악합니다
-   - 현재 배포 프로세스 파악 (수동/자동)
-   - 배포 대상 환경 (staging, production, preview)
-   - 브랜치 전략 확인 (gitflow, trunk-based, GitHub flow)
-   - 필요한 품질 게이트 식별
-   - 배포 빈도 목표
-   - 롤백 요구사항
-   - 시크릿 관리 방식
-   - 알림/모니터링 연동 대상
-
-2. **파이프라인 스테이지 설계**: 단계별 작업을 정의합니다
-   - **Install**: 의존성 설치 (캐시 활용)
-   - **Lint**: 코드 스타일 검사 (ESLint, Prettier)
-   - **Type Check**: 타입 검사 (TypeScript)
-   - **Unit Test**: 유닛 테스트 실행 + 커버리지
-   - **Integration Test**: 통합 테스트 (DB, 외부 서비스)
-   - **Build**: 프로덕션 빌드
-   - **Security Scan**: 의존성 취약점 검사 (npm audit, Snyk)
-   - **E2E Test**: End-to-End 테스트 (Playwright, Cypress)
-   - **Deploy**: 배포 (환경별 차등)
-   - **Smoke Test**: 배포 후 기본 동작 확인
-   - **Notify**: 결과 알림 (Slack, Discord)
-
-3. **구현**: 파이프라인 설정 파일을 작성합니다
-   - CI 플랫폼 선택 (GitHub Actions, GitLab CI, CircleCI)
-   - 워크플로우 파일 작성
-   - 병렬 실행 가능한 작업 식별 및 설정
-   - 캐싱 전략 (node_modules, 빌드 아티팩트)
-   - 매트릭스 빌드 (여러 Node 버전, OS)
-   - 환경별 배포 조건 설정
-   - 시크릿 설정 (환경 변수, 시크릿 스토어)
-   - 재사용 가능한 워크플로우 분리
-
-4. **품질 게이트 설정**: 머지/배포 차단 조건을 설정합니다
-   - 테스트 커버리지 임계값 (85%+)
-   - 린트 에러 제로
-   - 타입 에러 제로
-   - 보안 취약점 제로 (CRITICAL/HIGH)
-   - 빌드 성공 필수
-   - PR 리뷰 승인 필수
-   - 커밋 메시지 컨벤션 검사
-
-5. **모니터링 및 최적화**: 파이프라인 성능을 관리합니다
-   - 파이프라인 실행 시간 추적
-   - 실패율 모니터링
-   - Flaky 테스트 추적 및 제거
-   - 캐시 히트율 최적화
-   - 불필요한 재실행 방지 (경로 필터링)
-   - 비용 최적화 (러너 크기, 병렬화)
-</Steps>
-
-## 에이전트 위임
-
-`executor` 에이전트(Sonnet 모델)에 위임하여 파이프라인을 구현합니다:
-
-```
-Agent(
-  subagent_type="executor",
-  model="sonnet",
-  prompt="CI/CD PIPELINE TASK
-
-CI/CD 파이프라인을 설계하고 구현하세요.
-
-Project: [프로젝트 설명]
-Platform: [GitHub Actions / GitLab CI / etc.]
-Branch Strategy: [gitflow / trunk-based / GitHub flow]
-
-Pipeline Checklist:
-1. 스테이지 설계 (lint, test, build, deploy)
-2. 워크플로우 파일 작성
-3. 캐싱 및 병렬화 최적화
-4. 품질 게이트 설정
-5. 시크릿 및 환경 변수 관리
-6. 배포 전략 (환경별)
-
-Output: CI/CD 구성 파일 및 문서:
-- 워크플로우 파일(들)
-- 환경별 배포 설정
-- 품질 게이트 목록
-- 파이프라인 다이어그램"
-)
-```
-
-## External Consultation (Optional)
-
-executor 에이전트는 교차 검증을 위해 Claude Task 에이전트에 자문할 수 있습니다.
-
-### Protocol
-1. **자체 파이프라인 설계를 먼저 완료** -- 독립적으로 구현
-2. **검증을 위한 자문** -- Claude Task 에이전트를 통해 설계 교차 확인
-3. **비판적 평가** -- 외부 제안을 맹목적으로 수용하지 않음
-4. **우아한 폴백** -- 위임이 불가능할 경우 절대 차단하지 않음
-
-### 자문이 필요한 경우
-- 멀티 환경 배포 전략 (dev/staging/prod)
-- Blue-Green 또는 Canary 배포 설정
-- 모노레포 CI 최적화
-- 보안이 중요한 배포 파이프라인
-
-### 자문을 생략하는 경우
-- 단순 린트/테스트 파이프라인
-- 단일 환경 배포
-- 잘 알려진 CI 템플릿 적용
-- 기존 파이프라인의 경미한 수정
-
-## 파이프라인 체크리스트
-
-### CI (Continuous Integration) (6개)
-- [ ] 의존성 설치에 캐시 적용
-- [ ] 린트가 모든 PR에서 실행됨
-- [ ] 타입 체크가 모든 PR에서 실행됨
-- [ ] 테스트가 커버리지와 함께 실행됨
-- [ ] 보안 스캔이 포함됨
-- [ ] 빌드가 성공해야 머지 가능
-
-### CD (Continuous Deployment) (5개)
-- [ ] staging 환경에 자동 배포
-- [ ] production 배포에 수동 승인 또는 자동 게이트
-- [ ] 배포 후 스모크 테스트 실행
-- [ ] 롤백 절차가 문서화/자동화됨
-- [ ] 배포 알림이 설정됨
-
-### 보안 (4개)
-- [ ] 시크릿이 CI 플랫폼의 시크릿 스토어에 저장됨
-- [ ] 워크플로우 파일에 하드코딩된 시크릿 없음
-- [ ] 의존성 취약점 스캔 포함
-- [ ] 최소 권한 원칙으로 배포 토큰 설정
-
-### 성능 (3개)
-- [ ] 병렬 실행으로 총 실행 시간 최소화
-- [ ] 경로 필터로 불필요한 실행 방지
-- [ ] 캐시 히트율이 80% 이상
-
-## 배포 전략 비교
-
-| 전략 | 다운타임 | 롤백 속도 | 복잡도 | 적합한 경우 |
-|------|----------|-----------|--------|-------------|
-| **Rolling** | 없음 | 느림 | 낮음 | 일반 웹 서비스 |
-| **Blue-Green** | 없음 | 즉시 | 중간 | 빠른 롤백 필요 |
-| **Canary** | 없음 | 빠름 | 높음 | 대규모 트래픽 |
-| **Recreate** | 있음 | 느림 | 낮음 | 비프로덕션 환경 |
-
-<Output>
-```
-CI/CD PIPELINE DOCUMENT / CI/CD 파이프라인 문서
-================================================
-
-Project: [프로젝트명]
-Platform: [GitHub Actions / GitLab CI]
-Branch Strategy: [gitflow / trunk-based]
-
-PIPELINE DIAGRAM / 파이프라인 다이어그램
------------------------------------------
-PR → [Install] → [Lint + Type Check + Unit Test] → [Build] → [Security Scan]
-                         (parallel)
-main → [Install] → [Full Test] → [Build] → [Deploy Staging] → [Smoke Test]
-                                                    ↓ (manual approve)
-                                            [Deploy Production] → [Smoke Test]
-
-STAGES / 스테이지
-------------------
-| Stage         | Trigger      | Duration | Parallel |
-|---------------|-------------|----------|----------|
-| Install       | PR, push    | ~30s     | -        |
-| Lint          | PR, push    | ~15s     | Yes      |
-| Type Check    | PR, push    | ~20s     | Yes      |
-| Unit Test     | PR, push    | ~45s     | Yes      |
-| Build         | PR, push    | ~60s     | -        |
-| Security Scan | PR, push    | ~30s     | Yes      |
-| Deploy Staging| main push   | ~120s    | -        |
-| Smoke Test    | after deploy| ~30s     | -        |
-| Deploy Prod   | manual      | ~120s    | -        |
-
-QUALITY GATES / 품질 게이트
------------------------------
-- Test Coverage: >= 85%
-- Lint Errors: 0
-- Type Errors: 0
-- Security Vulnerabilities (CRITICAL/HIGH): 0
-- Build: Success
-- PR Review: >= 1 approval
-
-WORKFLOW FILES / 워크플로우 파일
----------------------------------
-.github/workflows/
-  ci.yml          -- PR 검증 (lint, test, build)
-  cd-staging.yml  -- staging 자동 배포
-  cd-prod.yml     -- production 수동 배포
-  security.yml    -- 주간 보안 스캔
-
-ESTIMATED TOTAL RUNTIME / 예상 총 실행 시간
----------------------------------------------
-PR Pipeline: ~2m30s
-Deploy Pipeline: ~5m
-```
-</Output>
-
-<Policy>
-- 파이프라인은 10분 이내에 완료되어야 합니다 (PR 기준 5분 목표)
-- 시크릿은 절대 워크플로우 파일에 하드코딩하지 않습니다
-- 프로덕션 배포에는 반드시 승인 프로세스를 포함합니다
-- 롤백 절차를 반드시 문서화하고 테스트합니다
-- Flaky 테스트는 파이프라인 신뢰성을 해치므로 즉시 수정합니다
-- 비용 효율성을 고려하여 불필요한 실행을 방지합니다
-</Policy>
-
-## 다른 스킬과의 연동
-
-**테스트 전략 연동:**
-```
-/forgen:testing-strategy CI에서 실행할 테스트 구성
-```
-테스트 전략에 맞는 CI 테스트 단계 구성
-
-**보안 리뷰 연동:**
-```
-/forgen:security-review .github/workflows/
-```
-워크플로우 파일의 보안 점검
-
-**Docker 연동:**
-```
-/forgen:docker CI에서 컨테이너 빌드
-```
-CI 파이프라인에 Docker 이미지 빌드 통합
-
-## Best Practices
-
-- **빠르게 실패** -- 가장 빠른 검사를 먼저 실행 (lint > type > test > build)
-- **병렬화** -- 독립적인 작업은 동시에 실행
-- **캐시 활용** -- 의존성과 빌드 아티팩트를 캐싱
-- **경로 필터링** -- 관련 파일 변경 시에만 실행
-- **알림 최적화** -- 실패 시에만 알림 (성공 알림은 노이즈)
-
-<Arguments>
-## 사용법
-`/forgen:ci-cd {파이프라인 대상}`
-
-### 예시
-- `/forgen:ci-cd GitHub Actions 파이프라인 설계`
-- `/forgen:ci-cd staging 자동 배포 설정`
-- `/forgen:ci-cd 기존 파이프라인 실행 시간 최적화`
-- `/forgen:ci-cd Vercel 배포 + Preview 환경 구성`
-
-### 인자
-- CI 플랫폼, 배포 대상, 최적화 목표 등을 설명
-- 인자 없으면 프로젝트에 적합한 CI/CD 파이프라인을 설계
-</Arguments>
-
-$ARGUMENTS

package/skills/database/SKILL.md

@@ -1,257 +0,0 @@
----
-name: database
-description: This skill should be used when the user asks to "database,db 설계,schema,migration,마이그레이션,스키마". Database schema design, migration planning, and optimization
----
-
-<!-- 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

package/skills/debug-detective/SKILL.md

@@ -1,95 +0,0 @@
----
-name: debug-detective
-description: This skill should be used when the user asks to "debug-detective,디버그탐정,체계적디버깅". Systematic debugging with reproduce-isolate-fix-verify loop
----
-
-<Purpose>
-재현→격리→수정→검증의 4단계 루프를 통해 버그를 체계적으로 추적합니다.
-에러 분류, git bisect, 최소 재현 사례 구성으로 근본 원인을 신속히 파악합니다.
-</Purpose>
-
-<Steps>
-1. **재현 (Reproduce)**
-   - 버그 재현 조건을 최대한 구체적으로 문서화
-     ```
-     환경: Node 20.x, macOS 14.3
-     입력값: { userId: null, action: "delete" }
-     예상 동작: 422 Validation Error
-     실제 동작: 500 Internal Server Error
-     재현율: 100% / 간헐적 (~30%)
-     ```
-   - 간헐적 버그: 로그 레벨 높이고 반복 실행으로 패턴 포착
-   - 환경 차이 확인: 로컬 vs CI vs 프로덕션
-
-2. **격리 (Isolate)**
-   - **에러 분류**:
-     - **런타임 에러**: TypeError, ReferenceError → 스택 트레이스 추적
-     - **타입 에러**: TS 컴파일 에러 → 타입 정의 불일치 확인
-     - **논리 에러**: 잘못된 계산/조건 → 중간값 로깅
-     - **비동기 에러**: Promise rejection, race condition → async/await 추적
-   - **Bisect 전략**:
-     ```bash
-     # git bisect로 버그 도입 커밋 이진 탐색
-     git bisect start
-     git bisect bad                    # 현재 커밋은 버그 있음
-     git bisect good <마지막_정상_sha>  # 정상 커밋 지정
-     # Git이 자동으로 중간 커밋 체크아웃
-     # 테스트 후 good/bad 판정 반복
-     git bisect run npm test           # 자동화 가능
-     git bisect reset                  # 완료 후 원상복구
-     ```
-   - **최소 재현 사례 구성**: 관련 없는 코드를 제거해 가장 단순한 형태로 축소
-
-3. **로그 분석 패턴**
-   ```typescript
-   // 구조화 로그로 맥락 추가
-   logger.error('결제 처리 실패', {
-     userId, orderId, amount,
-     stack: err.stack,
-     timestamp: new Date().toISOString(),
-   });
-
-   // 조건부 디버그 로그 (프로덕션 영향 최소화)
-   if (process.env.DEBUG_PAYMENT) {
-     console.log('[DEBUG]', JSON.stringify({ state, payload }, null, 2));
-   }
-   ```
-   - 타임스탬프 정렬 → 이벤트 순서 파악
-   - 상관관계 ID(correlation ID)로 분산 로그 추적
-
-4. **수정 (Fix)**
-   - 근본 원인(root cause)을 먼저 명시
-   - 증상만 치료하는 패치 금지 → 원인 제거
-   - 수정 범위를 최소화 (side effect 방지)
-   - 수정 전후 코드 diff를 커밋 메시지에 설명
-
-5. **검증 (Verify)**
-   - 버그 재현 시나리오를 회귀 테스트로 추가
-   - 원래 문제가 해결됐는지 확인
-   - 관련 기능에 새 버그가 생기지 않았는지 확인
-   - 스테이징 → 프로덕션 순서로 검증
-</Steps>
-
-<Policy>
-- 추측 기반 수정 금지 — 반드시 재현 먼저
-- 로그 추가 시 민감 정보(비밀번호, 토큰) 절대 출력 금지
-- 수정 후 해당 버그의 회귀 테스트 1개 이상 추가
-- 간헐적 버그는 최소 10회 연속 통과 후 수정 완료 판정
-</Policy>
-
-<Arguments>
-## 사용법
-`/forgen:debug-detective {버그 설명}`
-
-### 예시
-- `/forgen:debug-detective 로그인 후 가끔 401 에러가 발생함 (재현율 20%)`
-- `/forgen:debug-detective 최근 배포 후 결제 API 응답 시간이 3배 증가`
-- `/forgen:debug-detective TypeScript 컴파일은 되는데 런타임에서 undefined 에러`
-
-### 인자
-- 버그 증상과 재현 조건
-- 발생 환경 (로컬/스테이징/프로덕션)
-- 관련 에러 메시지나 스택 트레이스
-</Arguments>
-
-$ARGUMENTS