@wooojin/forgen 0.2.1 → 0.3.0

package/commands/refactor.md

@@ -1,105 +0,0 @@
----
-name: refactor
-description: This skill should be used when the user asks to "refactor,리팩토링,리팩터,코드정리". Safe refactoring with test-first approach and SOLID principles
-triggers:
-  - "refactor"
-  - "리팩토링"
-  - "리팩터"
-  - "코드정리"
----
-
-<Purpose>
-테스트 확보→변경→검증의 3단계를 통해 기능을 유지하면서 코드 구조를 개선합니다.
-코드 스멜 식별, SOLID 원칙 적용, 리팩토링 카탈로그를 활용해 체계적으로 진행합니다.
-</Purpose>
-
-<Steps>
-1. **테스트 확보 (Test First)**
-   - 리팩토링 전 기존 동작을 테스트로 고정
-   - 테스트 없는 코드: 특성화 테스트(Characterization Test) 먼저 작성
-     ```typescript
-     // 현재 동작을 그대로 문서화하는 테스트
-     it('현재 동작 특성화', () => {
-       expect(legacyFunction(input)).toMatchSnapshot();
-     });
-     ```
-   - 커버리지 확인: 변경할 코드 경로가 모두 테스트에 포함됐는지 검증
-
-2. **코드 스멜 식별**
-   - **긴 함수**: 50줄 초과 → 추출(Extract) 대상
-   - **중복 코드**: DRY 원칙 위반 → 공통 추출
-   - **복잡한 조건**: 중첩 if/else 3단계 초과 → Early Return 또는 전략 패턴
-   - **긴 매개변수 목록**: 4개 초과 → 객체로 묶기
-   - **거대한 클래스**: 단일 책임 원칙 위반 → 분리
-   - **주석으로 설명이 필요한 코드**: 코드 자체를 명확하게 개선
-
-3. **SOLID 원칙 적용**
-   - **S** (단일 책임): 클래스/함수는 하나의 이유로만 변경
-   - **O** (개방-폐쇄): 확장에 열려 있고 수정에 닫혀 있도록 설계
-   - **L** (리스코프 치환): 하위 타입은 상위 타입을 완전히 대체 가능
-   - **I** (인터페이스 분리): 사용하지 않는 메서드를 강요하지 않음
-   - **D** (의존성 역전): 구체 클래스가 아닌 추상화에 의존
-
-4. **리팩토링 카탈로그 (Fowler)**
-   - **Extract Method**: 코드 블록을 독립적인 함수로 추출
-     ```typescript
-     // Before
-     function processOrder(order) {
-       // 가격 계산 (20줄)
-       let total = 0;
-       for (const item of order.items) { total += item.price * item.qty; }
-       // ...
-     }
-     // After
-     function processOrder(order) {
-       const total = calculateTotal(order.items);
-       // ...
-     }
-     function calculateTotal(items) { /* ... */ }
-     ```
-   - **Move Method**: 다른 클래스에서 더 많이 사용하는 메서드 이동
-   - **Replace Conditional with Polymorphism**: switch/if-else 체인 → 다형성
-     ```typescript
-     // Before: if (type === 'A') ... else if (type === 'B') ...
-     // After: strategy[type].execute()
-     ```
-   - **Introduce Parameter Object**: 매개변수 그룹 → 객체
-   - **Replace Magic Number with Constant**: 리터럴 → 명명된 상수
-   - **Inline Variable**: 불필요한 중간 변수 제거
-
-5. **변경 (Refactor)**
-   - 한 번에 하나의 리팩토링만 적용
-   - 각 단계 후 테스트 실행 (`npm test` / `vitest run`)
-   - 작은 커밋으로 이력 추적: `refactor: Extract calculateTotal from processOrder`
-   - 동작 변경과 구조 변경을 같은 커밋에 섞지 않음
-
-6. **검증 (Verify)**
-   - 전체 테스트 스위트 통과 확인
-   - 타입 검사: `tsc --noEmit`
-   - 린트: `eslint src/`
-   - 성능 회귀 없음 확인 (주요 경로 벤치마크)
-</Steps>
-
-<Policy>
-- 리팩토링과 기능 추가를 동시에 하지 않는다
-- 테스트 없이 리팩토링 시작 금지
-- 각 단계 후 테스트 통과 확인 필수
-- 한 세션에서 수정하는 파일은 최대 5개로 제한
-</Policy>
-
-<Arguments>
-## 사용법
-`/forgen:refactor {리팩토링 대상}`
-
-### 예시
-- `/forgen:refactor src/services/PaymentService.ts — 200줄 함수 분리`
-- `/forgen:refactor 주문 처리 로직의 중복 코드 제거`
-- `/forgen:refactor UserController를 SOLID 원칙에 맞게 재설계`
-
-### 인자
-- 리팩토링할 파일/함수/모듈 명시
-- 목표 (성능, 가독성, 유지보수성, 특정 패턴 적용)
-- 제약 조건 (하위 호환성 유지, 특정 인터페이스 유지 등)
-</Arguments>
-
-$ARGUMENTS

package/commands/security-review.md

@@ -1,288 +0,0 @@
----
-name: security-review
-description: This skill should be used when the user asks to "security review,보안 리뷰,보안 검토,security audit,취약점 점검". Security-focused code audit with OWASP Top 10 and supply chain checks
-triggers:
-  - "security review"
-  - "보안 리뷰"
-  - "보안 검토"
-  - "security audit"
-  - "취약점 점검"
----
-
-<Purpose>
-보안 중심 코드 감사를 수행합니다. OWASP Top 10, 공급망 보안,
-시크릿 노출, 안전하지 않은 패턴을 체계적으로 점검합니다.
-</Purpose>
-
-<Steps>
-1. **OWASP Top 10 전체 스캔**
-   - A01: Broken Access Control — 접근 제어 우회, 권한 에스컬레이션
-   - A02: Cryptographic Failures — 약한 해싱(MD5/SHA1), 평문 전송, 키 노출
-   - A03: Injection — SQL, NoSQL, Command, XSS, LDAP 인젝션
-   - A04: Insecure Design — 보안이 고려되지 않은 설계, 위협 모델링 부재
-   - A05: Security Misconfiguration — 기본 설정 미변경, 불필요한 기능 활성화, 에러 정보 노출
-   - A06: Vulnerable and Outdated Components — 알려진 CVE가 있는 의존성 사용
-   - A07: Identification and Authentication Failures — 약한 인증, 세션 고정, 크리덴셜 스터핑
-   - A08: Software and Data Integrity Failures — 서명 미검증, 안전하지 않은 역직렬화
-   - A09: Security Logging and Monitoring Failures — 로깅 부재, 침입 탐지 미흡
-   - A10: Server-Side Request Forgery (SSRF) — 서버에서 외부 URL 요청 시 검증 부재
-
-2. **시크릿 탐지**
-   - 하드코딩된 API 키, 비밀번호, 토큰
-   - 개인 키(private key)가 레포에 포함되었는지
-   - 커넥션 스트링에 시크릿 포함 여부
-   - .env, credentials 파일 커밋 여부
-   - 로그에 민감 정보 출력
-
-3. **입력 검증**
-   - 모든 외부 입력의 살균/검증 확인
-   - SQL/NoSQL Injection 방지 (파라미터화 쿼리)
-   - Command Injection 방지
-   - XSS 방지 (출력 이스케이핑)
-   - Path Traversal 방지
-   - SSRF 방지 (URL 화이트리스트)
-
-4. **인증/인가**
-   - 비밀번호 해싱 (bcrypt, argon2 등 강력한 알고리즘)
-   - 세션 관리 보안 (토큰 암호학적 난수 생성)
-   - JWT 구현 보안 (서명 검증, 만료 설정)
-   - 접근 제어가 모든 보호 리소스에 적용되는지
-
-5. **암호화**
-   - 강력한 알고리즘 사용 (AES-256, RSA-2048+)
-   - 적절한 키 관리
-   - 암호학적으로 안전한 난수 생성
-   - TLS/HTTPS 강제 적용
-
-6. **의존성 보안**
-   - `npm audit` 실행하여 알려진 취약점 검사
-   - 오래된 의존성 확인
-   - CRITICAL/HIGH CVE 식별
-   - 의존성 출처 검증
-   - 의심스러운 패키지, 과도한 권한 요구 점검
-</Steps>
-
-## 에이전트 위임
-
-`security-reviewer` 에이전트(Opus 모델)에 위임하여 심층 보안 분석을 수행합니다:
-
-```
-Agent(
-  subagent_type="security-reviewer",
-  model="opus",
-  prompt="SECURITY REVIEW TASK
-
-보안 감사를 수행하세요.
-
-Scope: [특정 파일 또는 전체 코드베이스]
-
-Security Checklist:
-1. OWASP Top 10 전체 스캔 (A01~A10)
-2. 하드코딩된 시크릿 탐지
-3. 입력 검증 검토
-4. 인증/인가 검토
-5. 의존성 취약점 스캔 (npm audit)
-
-Output: 보안 리뷰 리포트:
-- 심각도별 발견 사항 요약 (CRITICAL, HIGH, MEDIUM, LOW)
-- 구체적인 파일:라인 위치
-- CVE 참조 (해당 시)
-- 각 이슈별 수정 방안
-- 전체 보안 상태 평가"
-)
-```
-
-## External Consultation (Optional)
-
-security-reviewer 에이전트는 교차 검증을 위해 Claude Task 에이전트에 자문할 수 있습니다.
-
-### Protocol
-1. **자체 보안 분석을 먼저 완료** — 독립적으로 리뷰 수행
-2. **검증을 위한 자문** — Claude Task 에이전트를 통해 발견 사항 교차 확인
-3. **비판적 평가** — 외부 발견 사항을 맹목적으로 수용하지 않음
-4. **우아한 폴백** — 위임이 불가능할 경우 절대 차단하지 않음
-
-### 자문이 필요한 경우
-- 인증/인가 코드
-- 암호화 구현
-- 신뢰할 수 없는 데이터의 입력 검증
-- 고위험 취약점 패턴
-- 프로덕션 배포 코드
-
-### 자문을 생략하는 경우
-- 저위험 유틸리티 코드
-- 이미 감사된 패턴
-- 시간이 촉박한 보안 평가
-- 기존 보안 테스트가 있는 코드
-
-**참고:** 보안 세컨드 오피니언은 높은 가치를 가집니다. CRITICAL/HIGH 발견 시 자문을 고려하세요.
-
-## 보안 체크리스트
-
-### 인증 및 인가
-- [ ] 비밀번호가 강력한 알고리즘으로 해싱 (bcrypt/argon2)
-- [ ] 세션 토큰이 암호학적으로 무작위
-- [ ] JWT 토큰이 적절히 서명 및 검증됨
-- [ ] 모든 보호 리소스에 접근 제어 적용
-- [ ] 인증 우회 취약점 없음
-
-### 입력 검증
-- [ ] 모든 사용자 입력이 검증 및 살균됨
-- [ ] SQL 쿼리가 파라미터화 사용 (문자열 연결 금지)
-- [ ] NoSQL 쿼리 인젝션 방지
-- [ ] 파일 업로드 검증 (타입, 크기, 콘텐츠)
-- [ ] URL 검증으로 SSRF 방지
-
-### 출력 인코딩
-- [ ] HTML 출력이 XSS 방지를 위해 이스케이핑됨
-- [ ] JSON 응답이 적절히 인코딩됨
-- [ ] 에러 메시지에 사용자 데이터 미포함
-- [ ] Content-Security-Policy 헤더 설정
-
-### 시크릿 관리
-- [ ] 하드코딩된 API 키 없음
-- [ ] 소스 코드에 비밀번호 없음
-- [ ] 레포에 개인 키 없음
-- [ ] 시크릿은 환경변수로 관리
-- [ ] 시크릿이 로그나 에러에 노출되지 않음
-
-### 암호화
-- [ ] 강력한 알고리즘 사용 (AES-256, RSA-2048+)
-- [ ] 적절한 키 관리
-- [ ] 암호학적으로 안전한 난수 생성
-- [ ] 민감 데이터에 TLS/HTTPS 강제
-
-### 의존성
-- [ ] 의존성에 알려진 취약점 없음
-- [ ] 의존성이 최신 상태
-- [ ] CRITICAL 또는 HIGH CVE 없음
-- [ ] 의존성 출처 검증됨
-
-## 심각도 정의
-
-| 심각도 | 설명 |
-|--------|------|
-| **CRITICAL** | 악용 가능한 취약점으로 심각한 영향 (데이터 유출, RCE, 크리덴셜 탈취) |
-| **HIGH** | 특정 조건이 필요하지만 심각한 영향을 주는 취약점 |
-| **MEDIUM** | 제한적 영향 또는 악용이 어려운 보안 약점 |
-| **LOW** | 모범 사례 위반 또는 경미한 보안 우려 |
-
-## Remediation Priority (수정 우선순위)
-
-| 우선순위 | 타임라인 | 대상 |
-|----------|----------|------|
-| 1. 노출된 시크릿 교체 | **즉시 (1시간 이내)** | 하드코딩된 키, 비밀번호, 토큰 |
-| 2. CRITICAL 수정 | **긴급 (24시간 이내)** | 악용 가능한 취약점 |
-| 3. HIGH 수정 | **중요 (1주일 이내)** | 조건부 취약점 |
-| 4. MEDIUM 수정 | **계획 (1개월 이내)** | 보안 약점 |
-| 5. LOW 수정 | **백로그 (여유 시)** | 모범 사례 위반 |
-
-<Output>
-```
-SECURITY REVIEW REPORT / 보안 리뷰 리포트
-==========================================
-
-Scope: [전체 코드베이스 / 특정 디렉토리] (N개 파일 스캔)
-Scan Date: YYYY-MM-DDTHH:MM:SSZ
-
-CRITICAL (N)
-------------
-1. src/api/auth.ts:89 - 하드코딩된 API 키
-   Finding: AWS API 키가 소스 코드에 하드코딩됨
-   Impact: 코드 공개 또는 유출 시 크리덴셜 노출
-   Remediation: 환경변수로 이동, 키 즉시 교체
-   Reference: OWASP A02:2021 - Cryptographic Failures
-   CVE: (해당 시 CVE 번호)
-
-2. src/db/query.ts:45 - SQL Injection 취약점
-   Finding: 사용자 입력이 SQL 쿼리에 직접 연결됨
-   Impact: 공격자가 임의의 SQL 명령을 실행 가능
-   Remediation: 파라미터화 쿼리 또는 ORM 사용
-   Reference: OWASP A03:2021 - Injection
-
-HIGH (N)
---------
-...
-
-MEDIUM (N)
-----------
-...
-
-LOW (N)
--------
-...
-
-DEPENDENCY VULNERABILITIES / 의존성 취약점
-------------------------------------------
-Found N vulnerabilities via npm audit:
-
-CRITICAL: axios@0.21.0 - Server-Side Request Forgery (CVE-2021-3749)
-  Installed: axios@0.21.0
-  Fix: npm install axios@0.21.2
-
-HIGH: lodash@4.17.19 - Prototype Pollution (CVE-2020-8203)
-  Installed: lodash@4.17.19
-  Fix: npm install lodash@4.17.21
-
-...
-
-OVERALL ASSESSMENT / 종합 평가
--------------------------------
-Security Posture: [EXCELLENT / GOOD / FAIR / POOR]
-(N CRITICAL, N HIGH issues)
-
-Immediate Actions Required:
-1. [즉시 조치 사항]
-2. [긴급 수정 사항]
-
-Recommendation: [배포 가능 / CRITICAL 및 HIGH 이슈 해결 전 배포 금지]
-```
-</Output>
-
-<Policy>
-- 취약점 발견 시 구체적인 공격 시나리오와 수정 방안을 함께 제시
-- False positive를 최소화하되, 의심스러운 패턴은 빠짐없이 보고
-- 보안 수정은 기능 동작에 영향을 주지 않도록 주의
-- OWASP A01~A10 각 항목에 대해 명시적으로 검사 수행
-- npm audit을 반드시 실행하여 의존성 취약점을 정량적으로 보고
-- CVE 참조를 가능한 한 포함하여 추적 가능성 확보
-</Policy>
-
-## 다른 스킬과의 연동
-
-**Pipeline 연동:**
-```
-/forgen:pipeline security "인증 모듈 리뷰"
-```
-사용 흐름: explore -> security-reviewer -> executor -> security-reviewer (재검증)
-
-**팀 기반 병렬 리뷰:**
-```
-/forgen:team 4:security-reviewer "모든 API 엔드포인트 감사"
-```
-여러 엔드포인트에 대해 병렬 보안 리뷰 수행
-
-## Best Practices
-
-- **조기 리뷰** — 보안은 사후 점검이 아닌 설계 단계부터
-- **자주 리뷰** — 주요 기능 변경이나 API 변경마다
-- **자동화** — CI/CD 파이프라인에서 보안 스캔 실행
-- **즉시 수정** — 보안 부채를 축적하지 않음
-- **수정 검증** — 수정 후 반드시 보안 리뷰 재실행
-
-<Arguments>
-## 사용법
-`/forgen:security-review {점검 대상}`
-
-### 예시
-- `/forgen:security-review` (기본: 전체 프로젝트)
-- `/forgen:security-review src/api/`
-- `/forgen:security-review 인증 관련 코드만 집중 점검`
-- `/forgen:security-review 최근 변경사항의 보안 영향 분석`
-
-### 인자
-- 디렉토리, 파일, 또는 관심 영역을 지정
-- 인자 없으면 프로젝트 전체를 점검
-</Arguments>
-
-$ARGUMENTS

package/commands/specify.md

@@ -1,128 +0,0 @@
----
-name: specify
-description: This skill should be used when the user asks to "specify,명세,요구사항 정리,스펙,spec,requirements". Structured requirement specification with resolved/provisional/unresolved 3-level evaluation
-triggers:
-  - "specify"
-  - "명세"
-  - "요구사항 정리"
-  - "스펙 정리"
-  - "spec"
----
-
-<Purpose>
-사용자의 모호한 요청을 구조화된 요구사항 명세로 변환합니다.
-각 요구사항을 resolved/provisional/unresolved 3단계로 평가하여
-무엇이 확정되었고, 무엇이 아직 불명확한지를 투명하게 보여줍니다.
-</Purpose>
-
-<Steps>
-1. **요청 분해**: 사용자 프롬프트에서 개별 요구사항을 추출합니다
-   - 기능 요구사항 (무엇을 해야 하는가)
-   - 비기능 요구사항 (성능, 보안, 접근성 등)
-   - 제약 조건 (기술 스택, 호환성, 기한 등)
-
-2. **3단계 평가**: 각 요구사항의 명확성을 평가합니다
-
-3. **갭 분석**: unresolved/provisional 항목에 대해 구체적 질문을 생성합니다
-   - 각 질문은 답변 시 해당 항목을 한 단계 승격시킬 수 있어야 함
-   - 예/아니오로 답할 수 있는 폐쇄형 질문 우선
-
-4. **명세서 출력**: 구조화된 형식으로 전체 명세를 제시합니다
-</Steps>
-
-## 3단계 평가 기준
-
-| 상태 | 기호 | 기준 | 예시 |
-|------|------|------|------|
-| **Resolved** | `[R]` | 구현에 필요한 모든 정보가 확정됨. 코드 작성 가능. | "JWT 토큰, 만료 15분, RS256 알고리즘" |
-| **Provisional** | `[P]` | 작업 가능한 가정이 있으나 검증 필요. 가정을 명시. | "인증 방식은 JWT로 가정 (확인 필요)" |
-| **Unresolved** | `[U]` | 핵심 정보 부재. 구현 전 반드시 명확화 필요. | "에러 시 사용자에게 어떻게 알릴지 미정" |
-
-### 승격 규칙
-
-```
-[U] → [P]: 합리적 가정이 도출되면 가정과 함께 승격
-[P] → [R]: 사용자가 가정을 확인하거나 구체적 값을 제공하면 승격
-[R] → [P]: 사용자가 확정 사항을 재검토 요청하면 강등
-```
-
-## 명세서 출력 형식
-
-```
-SPECIFICATION REPORT / 요구사항 명세서
-======================================
-
-Summary: [요구사항 한 줄 요약]
-Status: R:[N] P:[N] U:[N]  — 진행 가능도: [%]
-
-RESOLVED ([N])
---------------
-[R] REQ-01: 로그인 API 엔드포인트 — POST /api/auth/login
-    → 이메일+비밀번호 입력, JWT 반환, 만료 15분
-
-[R] REQ-02: 비밀번호 해싱 — bcrypt, salt rounds 12
-    → 회원가입 시 해싱, 로그인 시 비교
-
-PROVISIONAL ([N])
------------------
-[P] REQ-03: 소셜 로그인 — Google OAuth 2.0 (가정)
-    가정: Google만 지원, 추후 확장 가능
-    → 확인 필요: 지원할 소셜 프로바이더 목록
-
-[P] REQ-04: 세션 관리 — Redis 기반 (가정)
-    가정: 인메모리 대신 Redis 사용
-    → 확인 필요: 인프라에 Redis가 있는지
-
-UNRESOLVED ([N])
-----------------
-[U] REQ-05: 비밀번호 정책
-    → 질문: 최소 길이, 특수문자 요구, 만료 주기는?
-
-[U] REQ-06: 다중 기기 로그인 처리
-    → 질문: 동시 세션 허용? 최대 몇 개?
-
-GAP QUESTIONS (우선순위순)
---------------------------
-Q1. [REQ-05] 비밀번호 최소 요구사항은? (길이, 복잡도)
-Q2. [REQ-06] 한 계정에서 동시 로그인 가능한 기기 수는?
-Q3. [REQ-03] Google 외에 지원할 소셜 로그인은?
-Q4. [REQ-04] 현재 인프라에 Redis가 구성되어 있나요?
-
-NEXT STEP
----------
-[위 질문에 답변하면 명세를 업데이트합니다]
-```
-
-## 진행 가능도 계산
-
-```
-진행 가능도(%) = (R×1.0 + P×0.5 + U×0.0) / 총 요구사항 × 100
-```
-
-- **80% 이상**: 구현 착수 가능 (U 항목은 후순위로)
-- **50-79%**: provisional 항목 검증 후 착수 권장
-- **50% 미만**: 추가 명확화 필수, 구현 착수 비권장
-
-<Policy>
-- 사용자가 답변하면 즉시 해당 항목의 상태를 승격하고 명세를 갱신합니다
-- 가정을 세울 때는 반드시 "가정:" 레이블을 붙여 투명하게 표시합니다
-- 요구사항 ID(REQ-xx)를 부여하여 후속 대화에서 참조 가능하게 합니다
-- 기술적 판단이 가능한 항목은 provisional로 가정을 세워 진행 가능도를 높입니다
-- 비즈니스 판단이 필요한 항목은 unresolved로 유지하고 질문을 생성합니다
-</Policy>
-
-<Arguments>
-## 사용법
-`specify {구현하려는 기능 설명}`
-
-### 예시
-- `specify 사용자 인증 시스템 구현`
-- `specify 결제 API 연동`
-- `specify 대시보드 페이지 리디자인`
-
-### 인자
-- 구현하려는 기능이나 작업의 자연어 설명
-- 기존 코드베이스가 있으면 자동으로 제약 조건 추출
-</Arguments>
-
-$ARGUMENTS

package/commands/tdd.md

@@ -1,183 +0,0 @@
----
-name: tdd
-description: This skill should be used when the user asks to "tdd,test first,테스트 먼저,테스트 주도". Test-Driven Development workflow with Red-Green-Refactor cycle
-triggers:
-  - "tdd"
-  - "test first"
-  - "테스트 먼저"
-  - "테스트 주도"
----
-
-<Purpose>
-TDD(Test-Driven Development) 워크플로우를 실행합니다.
-Red-Green-Refactor 사이클을 통해 견고한 코드를 점진적으로 구축합니다.
-</Purpose>
-
-## The Iron Law / 철의 법칙
-
-**실패하는 테스트 없이 프로덕션 코드를 작성하지 않는다**
-
-테스트 전에 코드를 작성했다면? **삭제하고 처음부터 다시 시작한다.** 예외 없음.
-
-<Steps>
-1. **RED**: 실패하는 테스트를 먼저 작성합니다
-   - 요구사항을 테스트 케이스로 변환
-   - 엣지 케이스와 에러 케이스 포함
-   - 테스트 실행 — **반드시 실패해야 함**
-   - 첫 실행에 통과하면 테스트가 잘못된 것 — 수정 필요
-
-2. **GREEN**: 테스트를 통과하는 최소한의 코드를 작성합니다
-   - 가장 단순한 구현으로 시작
-   - "하는 김에" 추가 기능 금지
-   - 모든 테스트가 통과하는 것을 확인
-   - 불필요한 최적화나 추상화는 하지 않음
-
-3. **REFACTOR**: 코드를 정리합니다
-   - 중복 제거
-   - 네이밍 개선
-   - 필요 시 추상화 도입
-   - **변경할 때마다** 테스트 실행
-   - 모든 테스트가 여전히 통과해야 함
-
-4. **REPEAT**: 다음 요구사항으로 사이클 반복
-</Steps>
-
-## Enforcement Rules / 시행 규칙
-
-| 감지 상황 | 조치 |
-|-----------|------|
-| 테스트보다 코드가 먼저 작성됨 | **중단. 코드 삭제. 테스트 먼저 작성.** |
-| 테스트가 첫 실행에 통과 | **테스트가 잘못됨. 실패하도록 수정.** |
-| 한 사이클에 여러 기능 | **중단. 하나의 테스트, 하나의 기능.** |
-| Refactor 단계 건너뜀 | **돌아가서 정리. 다음 기능 전에 리팩터.** |
-| Refactor에서 동작 변경 | **중단. Refactor는 동작 보존만.** |
-| 테스트를 수정하여 통과시킴 | **금지. 테스트는 요구사항. 코드를 수정.** |
-
-## 에이전트 위임
-
-`test-engineer` 에이전트에 위임하여 TDD 사이클을 수행합니다:
-
-```
-Agent(
-  subagent_type="test-engineer",
-  model="opus",
-  prompt="TDD TASK
-
-Red-Green-Refactor 사이클로 기능을 구현하세요.
-
-Feature: [구현할 기능]
-
-Iron Law: 실패하는 테스트 없이 프로덕션 코드를 절대 작성하지 않는다.
-
-각 사이클에서:
-1. RED: 실패하는 테스트 작성 및 실행 (실패 확인)
-2. GREEN: 최소한의 코드로 테스트 통과
-3. REFACTOR: 코드 정리 (테스트 유지)
-
-Output: 각 사이클별 RED/GREEN/REFACTOR 결과 리포트"
-)
-```
-
-## External Consultation (Optional)
-
-test-engineer 에이전트는 테스트 전략 검증을 위해 Claude Task 에이전트에 자문할 수 있습니다.
-
-### Protocol
-1. **자체 테스트 전략을 먼저 수립** — 독립적으로 테스트 설계
-2. **검증을 위한 자문** — Claude Task 에이전트를 통해 테스트 커버리지 전략 교차 확인
-3. **비판적 평가** — 외부 제안을 맹목적으로 수용하지 않음
-4. **우아한 폴백** — 위임이 불가능할 경우 절대 차단하지 않음
-
-### 자문이 필요한 경우
-- 복잡한 도메인 로직의 포괄적 테스트 커버리지
-- 핵심 경로의 엣지 케이스 식별
-- 대규모 기능의 테스트 아키텍처
-- 익숙하지 않은 테스팅 패턴
-
-### 자문을 생략하는 경우
-- 단순 유닛 테스트
-- 잘 알려진 테스팅 패턴
-- 시간이 촉박한 TDD 사이클
-- 작고 격리된 기능
-
-## Phase별 출력 형식 템플릿
-
-```
-## TDD Cycle: [기능 이름]
-
-=== RED Phase ===
-Test File: [테스트 파일 경로]
-Test Code:
-  [테스트 코드]
-
-Expected Failure: [예상되는 에러 메시지]
-Actual Result:
-  FAIL: [실제 실행 결과]
-  X failing, Y passing
-
-Status: RED (테스트 실패 확인)
-
-=== GREEN Phase ===
-Implementation File: [구현 파일 경로]
-Implementation Code:
-  [최소한의 구현 코드]
-
-Test Result:
-  PASS: [실행 결과]
-  All tests passing
-
-Status: GREEN (테스트 통과 확인)
-
-=== REFACTOR Phase ===
-Changes:
-  - [변경 사항 1]
-  - [변경 사항 2]
-
-Test Result:
-  PASS: All tests still passing
-
-Status: REFACTOR COMPLETE
-
-=== Cycle Summary ===
-Feature: [구현된 기능]
-Tests Added: N
-Tests Passing: N/N
-Next: [다음 사이클 기능]
-```
-
-## 명령어
-
-각 구현 전:
-```bash
-# 프로젝트의 테스트 명령어 실행 — 새 실패 테스트가 하나여야 함
-```
-
-구현 후:
-```bash
-# 프로젝트의 테스트 명령어 실행 — 새 테스트 통과, 기존 테스트도 모두 통과
-```
-
-<Policy>
-- 테스트 없이 프로덕션 코드를 작성하지 않습니다
-- 한 번에 하나의 실패하는 테스트만 추가합니다
-- Refactor 단계에서 동작을 변경하지 않습니다
-- 매 사이클 완료 후 테스트 스위트 전체 실행
-- 테스트를 수정하여 통과시키는 행위는 금지 (test hack 금지)
-- 규율 자체가 가치입니다 — 지름길은 이점을 파괴합니다
-</Policy>
-
-<Arguments>
-## 사용법
-`/forgen:tdd {구현할 기능}`
-
-### 예시
-- `/forgen:tdd 이메일 유효성 검증 함수`
-- `/forgen:tdd 장바구니 할인 계산 로직`
-- `/forgen:tdd src/utils/parser.ts에 JSON 파싱 에러 핸들링 추가`
-
-### 인자
-- 구현할 기능이나 요구사항을 설명
-- 테스트 프레임워크는 프로젝트 설정에서 자동 감지 (jest, vitest 등)
-</Arguments>
-
-$ARGUMENTS