@wooojin/forgen 0.2.1 → 0.3.0

package/commands/testing-strategy.md

@@ -1,265 +0,0 @@
----
-name: testing-strategy
-description: This skill should be used when the user asks to "testing strategy,테스트 전략,test plan,테스트 계획,coverage plan". Test strategy design, coverage analysis, and quality planning
-triggers:
-  - "testing strategy"
-  - "테스트 전략"
-  - "test plan"
-  - "테스트 계획"
-  - "coverage plan"
----
-<!-- forgen-managed -->
-
-<Purpose>
-테스트 전략을 수립하고 커버리지 계획을 설계합니다.
-TDD 스킬이 Red-Green-Refactor 워크플로우를 다루는 반면,
-이 스킬은 "무엇을 어떻게 테스트할 것인가"의 전략적 관점을 다룹니다.
-테스트 피라미드, 커버리지 갭 분석, 우선순위 결정을 수행합니다.
-</Purpose>
-
-<Steps>
-1. **현재 커버리지 평가**: 기존 테스트 상태를 분석합니다
-   - 라인/브랜치/함수 커버리지 측정
-   - 테스트 피라미드 비율 분석 (unit : integration : e2e)
-   - 테스트 실행 시간 측정
-   - 불안정(flaky) 테스트 식별
-   - 테스트 없는 핵심 경로 식별
-   - 최근 버그의 테스트 커버리지 분석 (커버 되었는가?)
-
-2. **갭 분석**: 테스트가 부족한 영역을 식별합니다
-   - 비즈니스 로직의 테스트 커버리지 확인
-   - 에러 핸들링 경로의 테스트 존재 여부
-   - 엣지 케이스 누락 식별
-     * 빈 입력, null/undefined
-     * 경계값 (최소/최대)
-     * 동시성/경쟁 조건
-     * 타임아웃/네트워크 에러
-   - 보안 관련 로직의 테스트 확인 (인증, 인가, 입력 검증)
-   - 통합 테스트 누락 (모듈 간 상호작용)
-   - 외부 의존성 모킹의 적절성
-
-3. **우선순위 결정**: 테스트 작성 순서를 결정합니다
-   - 위험도 기반 우선순위 매트릭스:
-     * [P0] 결제, 인증, 데이터 무결성 -- 반드시 테스트
-     * [P1] 핵심 비즈니스 로직 -- 높은 우선순위
-     * [P2] 일반 CRUD 작업 -- 중간 우선순위
-     * [P3] 유틸리티, 헬퍼 -- 낮은 우선순위
-   - 변경 빈도가 높은 코드 우선
-   - 최근 버그가 발생한 모듈 우선
-   - 복잡도가 높은 함수 우선
-
-4. **테스트 전략 수립**: 테스트 유형별 전략을 설계합니다
-   - Unit Test 전략:
-     * 순수 함수: 입력/출력 테스트
-     * 사이드 이펙트: 모킹/스터빙
-     * 커버리지 목표: 85%+ (브랜치 기준)
-   - Integration Test 전략:
-     * 모듈 간 상호작용 검증
-     * 외부 서비스 모킹 범위
-     * 데이터베이스 테스트 (인메모리 vs 컨테이너)
-   - E2E Test 전략:
-     * 핵심 사용자 시나리오 선정
-     * 테스트 환경 구성
-     * 데이터 시딩 전략
-   - 성능 Test 전략:
-     * 부하 테스트 시나리오
-     * 성능 기준값 설정
-
-5. **구현 및 추적**: 테스트를 점진적으로 구현합니다
-   - 테스트 작성 태스크 목록 생성
-   - 커버리지 추적 대시보드 설정
-   - CI 파이프라인에 커버리지 게이트 추가
-   - 정기적인 커버리지 리뷰 일정 설정
-   - 뮤테이션 테스트 도입 계획 (핵심 비즈니스 로직)
-</Steps>
-
-## 에이전트 위임
-
-`test-engineer` 에이전트(Opus 모델)에 위임하여 테스트 전략을 수립합니다:
-
-```
-Agent(
-  subagent_type="test-engineer",
-  model="opus",
-  prompt="TESTING STRATEGY TASK
-
-테스트 전략을 수립하고 커버리지 계획을 설계하세요.
-
-Project: [프로젝트 설명]
-Current Coverage: [현재 커버리지 또는 '미측정']
-
-Strategy Checklist:
-1. 현재 커버리지 측정 및 분석
-2. 테스트 갭 식별 (에러 경로, 엣지 케이스)
-3. 위험도 기반 우선순위 결정
-4. 테스트 유형별 전략 (unit/integration/e2e)
-5. 구현 로드맵 및 커버리지 목표
-
-Output: 테스트 전략 문서:
-- 현재 커버리지 분석
-- 갭 분석 결과
-- 우선순위 목록
-- 유형별 전략
-- 커버리지 목표 및 로드맵"
-)
-```
-
-## External Consultation (Optional)
-
-test-engineer 에이전트는 교차 검증을 위해 Claude Task 에이전트에 자문할 수 있습니다.
-
-### Protocol
-1. **자체 전략을 먼저 수립** -- 독립적으로 분석 수행
-2. **검증을 위한 자문** -- Claude Task 에이전트를 통해 전략 교차 확인
-3. **비판적 평가** -- 외부 제안을 맹목적으로 수용하지 않음
-4. **우아한 폴백** -- 위임이 불가능할 경우 절대 차단하지 않음
-
-### 자문이 필요한 경우
-- 복잡한 도메인의 테스트 커버리지 전략
-- 마이크로서비스 간 통합 테스트 설계
-- 성능/부하 테스트 시나리오 설계
-- 뮤테이션 테스트 도입 전략
-
-### 자문을 생략하는 경우
-- 단순 유닛 테스트 계획
-- 명확한 CRUD 테스트
-- 기존 패턴 반복
-- 소규모 모듈의 테스트
-
-## 테스트 피라미드 기준
-
-```
-        /  E2E  \         5~10% (핵심 시나리오만)
-       /----------\
-      / Integration \     15~25% (모듈 간 상호작용)
-     /----------------\
-    /    Unit Tests     \  70~80% (모든 비즈니스 로직)
-   /--------------------\
-```
-
-## 커버리지 목표 가이드
-
-| 코드 유형 | 라인 | 브랜치 | 뮤테이션 |
-|-----------|------|--------|----------|
-| 결제/인증 | 95%+ | 90%+ | 80%+ |
-| 비즈니스 로직 | 85%+ | 80%+ | 70%+ |
-| 유틸리티 | 80%+ | 75%+ | -- |
-| UI 컴포넌트 | 70%+ | 60%+ | -- |
-| 설정/부트스트랩 | 60%+ | -- | -- |
-
-## 테스트 품질 지표
-
-| 지표 | 건강 | 주의 | 위험 |
-|------|------|------|------|
-| 브랜치 커버리지 | > 80% | 60~80% | < 60% |
-| 테스트 실행 시간 | < 30s | 30s~2m | > 2m |
-| Flaky 테스트 비율 | 0% | < 2% | > 2% |
-| 뮤테이션 점수 | > 70% | 50~70% | < 50% |
-
-<Output>
-```
-TESTING STRATEGY / 테스트 전략 문서
-=====================================
-
-Project: [프로젝트명]
-Date: YYYY-MM-DD
-Test Framework: [vitest / jest / playwright]
-
-CURRENT STATE / 현재 상태
----------------------------
-Line Coverage:    72% (target: 85%)
-Branch Coverage:  58% (target: 80%)
-Test Count:       142 (unit: 120, integration: 18, e2e: 4)
-Execution Time:   24s
-Flaky Tests:      2 (src/api/order.test.ts, src/utils/date.test.ts)
-
-GAP ANALYSIS / 갭 분석
-------------------------
-[P0] CRITICAL GAPS (테스트 없는 핵심 경로):
-  - src/services/payment.ts -- 결제 처리 로직 (0% coverage)
-  - src/middleware/auth.ts -- 인증 미들웨어 에러 경로 (30% branch)
-
-[P1] HIGH GAPS (불충분한 커버리지):
-  - src/services/order.ts -- 할인 계산 엣지 케이스 미테스트
-  - src/utils/validation.ts -- 경계값 테스트 부재
-
-[P2] MEDIUM GAPS:
-  - src/api/users.ts -- 통합 테스트 부재
-  - src/components/Cart.tsx -- 상태 변경 테스트 부족
-
-IMPLEMENTATION ROADMAP / 구현 로드맵
---------------------------------------
-Week 1: P0 갭 해소 (결제, 인증)
-  - [ ] payment.ts 유닛 테스트 (15개)
-  - [ ] auth.ts 에러 경로 테스트 (8개)
-
-Week 2: P1 갭 해소 (비즈니스 로직)
-  - [ ] order.ts 엣지 케이스 테스트 (10개)
-  - [ ] validation.ts 경계값 테스트 (12개)
-
-Week 3: 통합 테스트 보강
-  - [ ] API 엔드포인트 통합 테스트 (20개)
-  - [ ] E2E 핵심 시나리오 (3개)
-
-TARGET / 목표
---------------
-Line Coverage:    72% → 85%
-Branch Coverage:  58% → 80%
-Test Count:       142 → 210
-Flaky Tests:      2 → 0
-```
-</Output>
-
-<Policy>
-- 커버리지 숫자보다 테스트 품질을 우선합니다
-- 브랜치 커버리지를 라인 커버리지보다 중요하게 봅니다
-- 핵심 비즈니스 로직에 뮤테이션 테스트를 권장합니다
-- Flaky 테스트는 즉시 수정하거나 격리합니다
-- 테스트는 빠르게 실행되어야 합니다 (전체 30초 이내 목표)
-- 테스트 작성 계획은 스프린트에 통합하여 추적합니다
-</Policy>
-
-## 다른 스킬과의 연동
-
-**TDD 연동:**
-```
-/forgen:tdd 전략에서 식별된 갭 구현
-```
-전략에서 식별된 테스트 갭을 TDD로 구현
-
-**코드 리뷰 연동:**
-```
-/forgen:code-review 테스트 코드 품질 확인
-```
-작성된 테스트 코드의 품질 검증
-
-**CI/CD 연동:**
-```
-/forgen:ci-cd 커버리지 게이트 설정
-```
-CI에서 커버리지 임계값 강제
-
-## Best Practices
-
-- **전략 먼저** -- 무작정 테스트를 쓰기 전에 어디가 중요한지 파악
-- **위험 기반** -- 모든 코드를 균일하게 테스트하지 않음
-- **피라미드 유지** -- E2E에 의존하지 않고 유닛 테스트 기반 구축
-- **Flaky 제로** -- 불안정한 테스트는 신뢰를 해침
-- **지속 추적** -- 커버리지 트렌드를 모니터링
-
-<Arguments>
-## 사용법
-`/forgen:testing-strategy {대상}`
-
-### 예시
-- `/forgen:testing-strategy 전체 프로젝트 커버리지 분석`
-- `/forgen:testing-strategy 결제 모듈 테스트 계획`
-- `/forgen:testing-strategy E2E 테스트 전략 수립`
-- `/forgen:testing-strategy 현재 테스트의 갭 분석`
-
-### 인자
-- 분석 대상 모듈, 테스트 유형, 목표 등을 설명
-- 인자 없으면 프로젝트 전체의 테스트 전략을 수립
-</Arguments>
-
-$ARGUMENTS

package/skills/api-design/SKILL.md

@@ -1,262 +0,0 @@
----
-name: api-design
-description: This skill should be used when the user asks to "api design,api 설계,REST,GraphQL,엔드포인트,endpoint". Design REST/GraphQL APIs with resource modeling, error handling, and versioning
----
-
-<!-- forgen-managed -->
-
-<Purpose>
-REST 또는 GraphQL API를 체계적으로 설계합니다.
-리소스 모델링부터 엔드포인트 설계, 에러 핸들링, 버전 관리, 문서화까지
-API 라이프사이클 전체를 다룹니다.
-</Purpose>
-
-<Steps>
-1. **리소스 모델링**: 도메인 엔티티를 API 리소스로 변환합니다
-   - 핵심 도메인 엔티티 식별 (명사 기반)
-   - 리소스 간 관계 매핑 (1:1, 1:N, N:M)
-   - 중첩 리소스 vs 독립 리소스 결정
-   - 리소스 표현(representation) 스키마 정의
-   - 필수/선택 필드 구분 및 타입 명시
-
-2. **엔드포인트 설계**: URL 구조와 HTTP 메서드를 결정합니다
-   - RESTful URL 컨벤션 적용 (복수형 명사, 계층 구조)
-   - HTTP 메서드 매핑 (GET/POST/PUT/PATCH/DELETE)
-   - 쿼리 파라미터 설계 (필터링, 정렬, 페이지네이션)
-   - 페이지네이션 전략 선택 (cursor vs offset)
-   - 벌크 작업 엔드포인트 필요 여부 결정
-   - HATEOAS 링크 포함 여부 결정
-   - GraphQL의 경우: Query/Mutation/Subscription 분리
-
-3. **에러 핸들링**: 일관된 에러 응답 체계를 구축합니다
-   - HTTP 상태 코드 매핑 (400, 401, 403, 404, 409, 422, 429, 500)
-   - 에러 응답 스키마 정의 (code, message, details, trace_id)
-   - 비즈니스 에러 코드 체계 설계
-   - 유효성 검증 에러 상세 포맷 (필드별 에러 목록)
-   - Rate limiting 응답 헤더 (X-RateLimit-Limit, Remaining, Reset)
-   - 에러 메시지의 국제화(i18n) 전략
-
-4. **버전 관리**: API 진화 전략을 수립합니다
-   - 버전 관리 방식 선택 (URL path vs Header vs Query param)
-   - Breaking change 정의 및 마이그레이션 가이드
-   - Deprecation 정책 (최소 6개월 유예기간 권장)
-   - Sunset 헤더 및 공지 절차
-   - 하위 호환성 유지 전략
-
-5. **보안 설계**: API 보안 정책을 수립합니다
-   - 인증 방식 선택 (Bearer Token, API Key, OAuth 2.0)
-   - 인가 모델 설계 (RBAC, ABAC, Scope 기반)
-   - Rate limiting 정책 (엔드포인트별 차등 적용)
-   - CORS 정책 설정
-   - 입력 검증 규칙 (크기 제한, 타입 검증, 범위 검증)
-   - 민감 데이터 마스킹 규칙
-
-6. **문서화**: API 명세를 작성합니다
-   - OpenAPI 3.0+ (REST) 또는 GraphQL Schema 작성
-   - 각 엔드포인트별 요청/응답 예시
-   - 인증 방법 가이드
-   - SDK 코드 샘플 (curl, JavaScript, Python)
-   - 변경 이력(changelog) 관리
-</Steps>
-
-## 에이전트 위임
-
-`architect` 에이전트(Opus 모델)에 위임하여 API 아키텍처를 설계합니다:
-
-```
-Agent(
-  subagent_type="architect",
-  model="opus",
-  prompt="API DESIGN TASK
-
-API를 체계적으로 설계하세요.
-
-Domain: [도메인/서비스 설명]
-Type: [REST / GraphQL / Both]
-
-Design Checklist:
-1. 리소스 모델링 (엔티티, 관계, 스키마)
-2. 엔드포인트 설계 (URL, 메서드, 파라미터)
-3. 에러 핸들링 (상태 코드, 에러 스키마)
-4. 버전 관리 전략
-5. 보안 설계 (인증, 인가, Rate limiting)
-6. OpenAPI/GraphQL 스키마 초안
-
-Output: API 설계 문서:
-- 리소스 모델 다이어그램
-- 엔드포인트 목록 (메서드, URL, 설명)
-- 요청/응답 스키마
-- 에러 코드 매핑
-- 보안 정책 요약"
-)
-```
-
-## External Consultation (Optional)
-
-architect 에이전트는 교차 검증을 위해 Claude Task 에이전트에 자문할 수 있습니다.
-
-### Protocol
-1. **자체 API 설계를 먼저 완료** -- 독립적으로 설계 수행
-2. **검증을 위한 자문** -- Claude Task 에이전트를 통해 설계 교차 확인
-3. **비판적 평가** -- 외부 제안을 맹목적으로 수용하지 않음
-4. **우아한 폴백** -- 위임이 불가능할 경우 절대 차단하지 않음
-
-### 자문이 필요한 경우
-- 대규모 마이크로서비스 간 API 경계 설계
-- 복잡한 인증/인가 플로우
-- 실시간 통신이 필요한 API (WebSocket, SSE)
-- 외부 파트너 공개 API 설계
-
-### 자문을 생략하는 경우
-- 단순 CRUD API
-- 내부 서비스 간 API
-- 잘 알려진 패턴의 적용
-- 프로토타입 수준의 API
-
-## API 설계 체크리스트
-
-### 리소스 설계 (5개)
-- [ ] 리소스 명명이 복수형 명사로 일관됨
-- [ ] 리소스 간 관계가 명확히 정의됨
-- [ ] 필수/선택 필드가 구분됨
-- [ ] 데이터 타입과 포맷이 명시됨 (ISO 8601 날짜 등)
-- [ ] 리소스 표현이 과도한 중첩 없이 평탄화됨
-
-### 엔드포인트 설계 (5개)
-- [ ] HTTP 메서드가 의미에 맞게 사용됨
-- [ ] URL 경로가 계층적이고 예측 가능함
-- [ ] 페이지네이션이 목록 엔드포인트에 적용됨
-- [ ] 필터링/정렬 파라미터가 일관됨
-- [ ] 멱등성(idempotency)이 보장됨 (PUT, DELETE)
-
-### 에러 핸들링 (4개)
-- [ ] HTTP 상태 코드가 의미에 맞게 사용됨
-- [ ] 에러 응답 포맷이 전체 API에서 일관됨
-- [ ] 유효성 검증 에러에 필드별 상세 정보 포함
-- [ ] 비즈니스 에러 코드가 체계적으로 분류됨
-
-### 보안 (4개)
-- [ ] 인증 방식이 결정되고 문서화됨
-- [ ] Rate limiting이 적용됨
-- [ ] 입력 크기 제한이 설정됨
-- [ ] CORS 정책이 명시됨
-
-<Output>
-```
-API DESIGN DOCUMENT / API 설계 문서
-====================================
-
-Service: [서비스명]
-API Type: [REST / GraphQL]
-Version: v1
-Base URL: https://api.example.com/v1
-
-RESOURCE MODEL / 리소스 모델
------------------------------
-1. [Resource Name]
-   - id: string (UUID)
-   - name: string (required, max 255)
-   - created_at: string (ISO 8601)
-   - [관계]: [관계 타입] -> [대상 리소스]
-
-ENDPOINTS / 엔드포인트
------------------------
-| Method | Path                  | Description       | Auth |
-|--------|-----------------------|-------------------|------|
-| GET    | /resources            | 리소스 목록 조회   | Yes  |
-| POST   | /resources            | 리소스 생성        | Yes  |
-| GET    | /resources/:id        | 리소스 상세 조회   | Yes  |
-| PUT    | /resources/:id        | 리소스 전체 수정   | Yes  |
-| DELETE | /resources/:id        | 리소스 삭제        | Yes  |
-
-ERROR SCHEMA / 에러 스키마
----------------------------
-{
-  "error": {
-    "code": "VALIDATION_ERROR",
-    "message": "입력 데이터가 유효하지 않습니다",
-    "details": [
-      { "field": "email", "message": "유효한 이메일 형식이 아닙니다" }
-    ],
-    "trace_id": "abc-123"
-  }
-}
-
-ERROR CODES / 에러 코드
--------------------------
-| HTTP | Code               | Description              |
-|------|--------------------|--------------------------|
-| 400  | VALIDATION_ERROR   | 입력 유효성 검증 실패     |
-| 401  | UNAUTHORIZED       | 인증 필요                |
-| 403  | FORBIDDEN          | 권한 부족                |
-| 404  | NOT_FOUND          | 리소스 없음              |
-| 409  | CONFLICT           | 리소스 충돌              |
-| 429  | RATE_LIMITED       | 요청 한도 초과           |
-
-VERSIONING / 버전 관리
------------------------
-Strategy: [URL path / Header / Query param]
-Current: v1
-Deprecation Policy: [정책 설명]
-
-SECURITY / 보안
-----------------
-Authentication: [Bearer Token / API Key / OAuth 2.0]
-Rate Limiting: [요청/분]
-CORS: [허용 도메인]
-```
-</Output>
-
-<Policy>
-- RESTful 원칙을 준수하되 실용성을 우선합니다
-- 일관성이 가장 중요합니다 -- 예외 없는 규칙이 이해하기 쉬운 API를 만듭니다
-- 에러 응답은 클라이언트가 자동으로 처리할 수 있을 만큼 구조화합니다
-- 보안은 설계 단계에서 반드시 포함합니다 (사후 추가 금지)
-- OpenAPI 스키마는 코드와 동기화 상태를 유지합니다
-- Breaking change는 반드시 버전 업과 마이그레이션 가이드를 동반합니다
-</Policy>
-
-## 다른 스킬과의 연동
-
-**코드 리뷰 연동:**
-```
-/forgen:code-review src/api/
-```
-설계된 API의 구현 코드를 리뷰
-
-**보안 리뷰 연동:**
-```
-/forgen:security-review src/api/
-```
-API 엔드포인트의 보안 취약점 점검
-
-**TDD 연동:**
-```
-/forgen:tdd API 엔드포인트 통합 테스트
-```
-API 엔드포인트별 테스트 작성
-
-## Best Practices
-
-- **API 먼저 설계** -- 구현 전에 명세를 확정
-- **일관된 컨벤션** -- 네이밍, 에러 포맷, 페이지네이션을 통일
-- **하위 호환성** -- 기존 클라이언트를 깨뜨리지 않는 변경
-- **적절한 상태 코드** -- 200으로 모든 것을 처리하지 않음
-- **과도한 노출 방지** -- 필요한 필드만 응답에 포함
-
-<Arguments>
-## 사용법
-`/forgen:api-design {설계 대상}`
-
-### 예시
-- `/forgen:api-design 사용자 관리 REST API`
-- `/forgen:api-design 상품 주문 시스템 GraphQL API`
-- `/forgen:api-design 기존 /api/users 엔드포인트 v2 설계`
-- `/forgen:api-design 외부 파트너용 공개 API`
-
-### 인자
-- 설계할 API의 도메인, 타입(REST/GraphQL), 요구사항을 설명
-- 인자 없으면 프로젝트 컨텍스트에서 API 설계 요구사항을 파악
-</Arguments>
-
-$ARGUMENTS