@su-record/vibe 0.1.7 → 0.3.0

package/.claude/commands/vibe.plan.md

@@ -20,10 +20,11 @@ SPEC 문서를 분석하여 기술 구현 계획(PLAN)을 작성합니다.
 ## Process
 
 1. **SPEC 문서 읽기**: `.vibe/specs/{기능명}.md` 분석
-2. **프로젝트 컨텍스트 파악**:
+2. **Feature 파일 읽기**: `.vibe/features/{기능명}.feature` 확인 (BDD)
+3. **프로젝트 컨텍스트 파악**:
    - `CLAUDE.md` 읽기 (기술 스택 확인)
    - `package.json` / `pyproject.toml` / `pubspec.yaml` 확인
-3. **PLAN 문서 작성**: 15개 섹션 포함
+4. **PLAN 문서 작성**: 15개 섹션 포함
    - 기술 스택 선정 (기존 스택 재사용 우선)
    - 아키텍처 설계
    - API 설계
@@ -33,13 +34,17 @@ SPEC 문서를 분석하여 기술 구현 계획(PLAN)을 작성합니다.
    - 성능 최적화
    - 에러 처리
    - 모니터링 및 로깅
-   - 테스트 전략
+   - **테스트 전략 (BDD/Contract Testing 포함)**
+     - BDD 도구 선정 (pytest-bdd, behave, cucumber 등)
+     - Contract Testing 도구 (Pact, Spring Cloud Contract 등)
+     - Feature 파일과 SPEC 매핑
+     - API Contract 스키마 정의
    - 배포 전략
    - 비용 예측
    - 마일스톤 (Phase별)
    - 리스크 및 완화 방안
    - 다음 단계
-4. **품질 검증**: 기술 선택 근거, 비용, 일정 현실성
+5. **품질 검증**: 기술 선택 근거, 비용, 일정 현실성, BDD 테스트 전략 타당성
 
 ## Agent
 
@@ -48,6 +53,7 @@ SPEC 문서를 분석하여 기술 구현 계획(PLAN)을 작성합니다.
 ## Input
 
 - `.vibe/specs/{기능명}.md` (SPEC 문서)
+- `.vibe/features/{기능명}.feature` (BDD Feature 파일)
 - `CLAUDE.md` (프로젝트 기술 스택)
 
 ## Output

package/.claude/commands/vibe.reason.md

@@ -0,0 +1,302 @@
+---
+description: Apply systematic reasoning framework to complex problems
+argument-hint: "problem description"
+---
+
+# /vibe.reason
+
+복잡한 문제에 9단계 추론 프레임워크를 적용합니다 (Reasoning Agent).
+
+## Usage
+
+```
+/vibe.reason "문제 설명"
+```
+
+## Description
+
+체계적인 9단계 추론 프레임워크를 사용하여 복잡한 문제를 논리적으로 분석하고 최적의 해결책을 도출합니다.
+
+## When to Use
+
+다음과 같은 상황에서 사용하세요:
+
+1. **복잡한 버그 디버깅**
+   - 근본 원인이 불명확한 경우
+   - 여러 가설을 체계적으로 검증해야 할 때
+
+2. **아키텍처 설계 결정**
+   - 여러 옵션 중 최적의 선택이 필요할 때
+   - 제약 조건과 위험을 종합적으로 평가해야 할 때
+
+3. **성능 최적화 문제**
+   - 병목 지점이 여러 곳일 수 있을 때
+   - 단계별 최적화 전략이 필요할 때
+
+4. **리팩토링 계획**
+   - 레거시 코드의 복잡도를 체계적으로 분석해야 할 때
+   - 점진적 리팩토링 전략이 필요할 때
+
+5. **요구사항 분석**
+   - 상충하는 요구사항을 조율해야 할 때
+   - 누락된 요구사항을 발견해야 할 때
+
+## Process
+
+### 1. 논리적 종속성 및 제약 조건
+- 정책, 규칙, 필수 전제 조건 확인
+- 작업 순서 최적화 (선행 작업 식별)
+- 사용자 제약 조건 우선 적용
+
+### 2. 위험 평가
+- 행동의 결과 분석
+- 롤백 가능성 확인
+- 호환성, 보안, 성능 위험 검토
+
+### 3. 귀납적 추론 및 가설 탐색
+- 근본 원인에 대한 가설 생성
+- 가능성 기반 우선순위 지정
+- 각 가설의 검증 방법 제시
+
+### 4. 결과 평가 및 적응성
+- 관찰 결과에 따른 계획 수정
+- 가설 반증 시 새 가설 생성
+- 백트래킹 필요성 판단
+
+### 5. 정보 가용성
+- 사용 가능한 모든 도구 식별
+- 관련 정책/규칙 문서 참조
+- 이전 컨텍스트 복원
+- 사용자 확인 필요 사항 구분
+
+### 6. 정밀성 및 근거
+- 정책 인용 시 정확한 출처 명시
+- 코드 참조 시 파일명:라인 포함
+- 메트릭의 정확한 수치 제공
+
+### 7. 완전성
+- 모든 요구사항, 옵션, 선호도 통합
+- 조기 결론 지양
+- 여러 대안 탐색
+
+### 8. 끈기와 인내
+- 일시적 오류는 지능적으로 재시도
+- 전략 변경을 통한 문제 해결
+- 모든 추론 단계 완료까지 진행
+
+### 9. 응답 억제
+- 추론 완료 후에만 행동
+- 복잡한 결정은 추론 과정 문서화
+- 단계별 실행으로 안전성 확보
+
+## MCP Tools Integration
+
+이 명령은 다음 MCP 도구를 자동으로 활용합니다:
+
+- **apply_reasoning_framework**: 9단계 추론 프레임워크 적용
+- **create_thinking_chain**: 순차적 사고 체인 생성
+- **analyze_problem**: 문제의 근본 원인 분석
+- **step_by_step_analysis**: 세부적인 단계별 분석
+- **recall_memory**: 이전 컨텍스트 복원
+- **find_symbol / find_references**: 코드 의존성 파악
+
+## Output Format
+
+```markdown
+# 추론 프레임워크 분석
+
+**문제**: [문제 설명]
+**컨텍스트**: [관련 정보]
+**적용 단계**: 9/9
+
+---
+
+## 1. 논리적 종속성 및 제약 조건
+
+**핵심 질문**:
+- 어떤 정책이나 필수 규칙이 적용되는가?
+- 작업 순서를 재정렬해야 하는가?
+- 필요한 전제 조건이나 정보는?
+- 명시적 사용자 제약 조건이 있는가?
+
+**제약 조건 분석**:
+[분석 내용]
+
+---
+
+## 2. 위험 평가
+
+...
+
+---
+
+## 요약
+
+[전체 추론 결과 요약 및 권장 사항]
+```
+
+## Examples
+
+### Example 1: 복잡한 버그 디버깅
+
+```
+사용자: /vibe.reason "사용자 로그인 후 프로필 페이지에서 간헐적으로 500 에러가 발생합니다. 로그에는 'TypeError: Cannot read property id of undefined'만 찍힙니다."
+
+AI: 이 문제를 9단계 추론 프레임워크로 분석하겠습니다.
+
+# 추론 프레임워크 분석
+
+**문제**: 로그인 후 프로필 페이지 간헐적 500 에러 (TypeError: Cannot read property 'id' of undefined)
+**컨텍스트**: 간헐적 발생, 로그인 성공 후 발생
+**적용 단계**: 9/9
+
+---
+
+## 1. 논리적 종속성 및 제약 조건
+
+**제약 조건 분석**:
+- 정책/규칙: 인증/인가 시스템 정책 확인 필요
+- 작업 순서: 로그인 → 세션 생성 → 프로필 조회 순서 확인
+- 전제 조건: 에러 재현을 위한 조건 파악 필요
+- 사용자 제약: 프로덕션 환경이므로 디버깅 도구 사용 제한
+
+---
+
+## 2. 위험 평가
+
+**위험 평가**:
+- 작업 유형: 디버깅 (중간 위험 - 로깅 추가는 낮은 위험, DB 변경은 높은 위험)
+- 롤백 가능성: 로깅 추가는 롤백 쉬움
+- 호환성 위험: 세션 구조 변경 시 기존 사용자 영향
+- 보안 위험: 과도한 로깅으로 민감 정보 노출 가능성
+- 성능 위험: 추가 로깅으로 인한 성능 저하 미미
+
+---
+
+## 3. 귀납적 추론 및 가설 탐색
+
+**가설 생성**:
+1. **가설 1: 세션 데이터 불완전** (가능성: 높음)
+   - 근거: 간헐적 발생 = 타이밍 이슈 또는 데이터 일관성 문제
+   - 검증: 세션 저장 로직에 로깅 추가, Redis 연결 상태 확인
+
+2. **가설 2: 비동기 처리 순서 문제** (가능성: 중간)
+   - 근거: undefined = 데이터 로딩 전에 접근
+   - 검증: 프로필 조회 API의 Promise 체인 확인, await 누락 검사
+
+3. **가설 3: DB 쿼리 결과 null** (가능성: 낮음)
+   - 근거: 특정 조건에서만 사용자 정보 조회 실패
+   - 검증: 프로필 조회 쿼리 로그 확인, 외래 키 제약 조건 검토
+
+**우선순위**: 가능성 높은 순으로 검증하되, 낮은 가능성도 완전히 배제하지 않음
+
+---
+
+[추가 단계 4-9 분석...]
+
+---
+
+## 요약
+
+9단계 추론 프레임워크를 통해 로그인 후 프로필 페이지 500 에러를 분석했습니다.
+
+**주요 발견**:
+- 가장 가능성 높은 원인: 세션 데이터 불완전 (Redis 연결 문제 또는 세션 저장 타이밍)
+- 검증 우선순위: 1) 세션 저장 로직 로깅 추가 → 2) 비동기 처리 검토 → 3) DB 쿼리 확인
+
+**권장 조치**:
+1. 즉시: 세션 저장/조회 시점에 상세 로깅 추가 (낮은 위험)
+2. 단기: 비동기 처리 코드 리뷰 (Promise, await 누락 확인)
+3. 중기: 세션 저장소 모니터링 강화 (Redis 연결 상태, 메모리)
+
+**다음 단계**:
+서버 코드에서 `profile_controller.ts` 확인 → 세션 처리 로직에 try-catch 및 로깅 추가 → 재현 조건 파악
+```
+
+### Example 2: 아키텍처 설계 결정
+
+```
+사용자: /vibe.reason "실시간 알림 기능을 추가하려고 합니다. WebSocket, SSE, Long Polling 중 어떤 걸 써야 할까요?"
+
+AI: [9단계 프레임워크를 통해 각 옵션의 제약 조건, 위험, 장단점을 체계적으로 분석하고, 프로젝트 상황에 맞는 최적의 선택을 권장]
+```
+
+## Integration with Other Commands
+
+### /vibe.spec과 함께 사용
+
+```
+# 1. 요구사항 수집
+/vibe.spec "실시간 알림"
+
+# 2. 기술적 결정이 필요한 경우
+/vibe.reason "실시간 알림 구현 시 WebSocket vs SSE vs Long Polling 선택"
+
+# 3. SPEC 문서 업데이트 및 계획 수립
+/vibe.plan "실시간 알림"
+```
+
+### /vibe.analyze와 함께 사용
+
+```
+# 1. 코드 분석으로 문제 발견
+/vibe.analyze --code
+
+# 2. 발견된 문제를 추론 프레임워크로 분석
+/vibe.reason "users_service.py의 Cyclomatic Complexity 15를 10 이하로 낮추는 리팩토링 전략"
+
+# 3. 리팩토링 실행
+/vibe.run "Task: Refactor users_service.py"
+```
+
+## Agent Configuration
+
+이 명령은 `~/.claude/agents/reasoning-agent.md`를 사용합니다.
+
+**에이전트 역할**:
+- 체계적 추론 및 문제 해결 전문가
+- 복잡한 문제를 논리적으로 분석
+- 모든 관련 요소를 고려하여 최적의 해결책 도출
+
+**에이전트 특징**:
+- 9단계 추론 프레임워크 적용
+- 가설 기반 접근
+- 위험 평가 및 완화 전략 제시
+- 정밀한 근거와 출처 명시
+
+## Best Practices
+
+1. **문제를 구체적으로 설명하세요**
+   - ❌ "버그가 있어요"
+   - ✅ "로그인 후 프로필 페이지에서 간헐적으로 500 에러가 발생합니다. 에러 로그: TypeError: Cannot read property 'id' of undefined"
+
+2. **컨텍스트를 포함하세요**
+   - 발생 조건 (항상? 간헐적? 특정 조건에서만?)
+   - 관련 기술 스택
+   - 이미 시도한 해결 방법
+
+3. **추론 결과를 메모리에 저장하세요**
+   - 복잡한 문제의 경우 추론 결과를 `save_memory`로 저장
+   - 나중에 `recall_memory`로 참조 가능
+
+4. **단계별로 검증하세요**
+   - 추론 프레임워크가 제안한 가설을 순서대로 검증
+   - 각 검증 결과를 에이전트에게 피드백
+
+5. **다른 명령과 조합하세요**
+   - `/vibe.analyze`로 현황 파악 → `/vibe.reason`으로 해결책 분석 → `/vibe.run`으로 실행
+
+## Notes
+
+- 이 명령은 복잡한 문제에 특화되어 있습니다. 단순한 작업은 직접 요청하는 것이 더 효율적입니다.
+- 추론 과정이 길어질 수 있으므로 충분한 시간을 확보하세요.
+- 추론 결과는 권장 사항이며, 최종 결정은 사용자가 내립니다.
+- MCP 도구를 자동으로 활용하므로 hi-ai 서버가 연결되어 있어야 합니다.
+
+## Related
+
+- [Reasoning Agent Guide](~/.claude/agents/reasoning-agent.md)
+- [MCP hi-ai Guide](~/.claude/skills/tools/mcp-hi-ai-guide.md)
+- [/vibe.analyze](vibe.analyze.md)
+- [/vibe.spec](vibe.spec.md)
+- [/vibe.plan](vibe.plan.md)

package/.claude/commands/vibe.run.md

@@ -46,7 +46,10 @@ TASKS 문서의 특정 Task를 읽고 구현 가이드를 생성한 후, 실제
   - Backend Python Expert: `~/.vibe/agents/backend-python-expert.md`
   - Frontend Flutter Expert: `~/.vibe/agents/frontend-flutter-expert.md`
 - TRUST 5 원칙 준수:
-  - Test-first (Contract Testing)
+  - **Test-first (BDD/Contract Testing 우선)**
+    - Contract 파일 먼저 작성 (Provider/Consumer)
+    - BDD Step Definitions 작성
+    - Unit Tests 작성
   - Readable (명확한 코드)
   - Unified (일관된 스타일)
   - Secured (보안 고려)
@@ -66,16 +69,19 @@ TASKS 문서의 특정 Task를 읽고 구현 가이드를 생성한 후, 실제
 
 | Task | Agent |
 |------|-------|
-| Task 1-1 ~ 1-8 (Backend) | Backend Python Expert |
-| Task 2-1 ~ 2-8 (Frontend) | Frontend Flutter Expert |
+| Task 1-1 ~ 1-9 (Backend + Contract Provider) | Backend Python Expert |
+| Task 2-1 ~ 2-9 (Frontend + Contract Consumer) | Frontend Flutter Expert |
 | Task 3-1 ~ 3-2 (FCM Backend) | Backend Python Expert |
-| Task 3-3 (E2E Test) | QA / Frontend Flutter Expert |
+| Task 3-3 (BDD Step Definitions) | QA / Backend/Frontend Expert |
+| Task 3-4 (Contract Verification) | QA |
+| Task 3-5 (E2E Test) | QA / Frontend Flutter Expert |
 
 ## Input
 
 - `.vibe/tasks/{기능명}.md` (TASKS 문서)
 - `.vibe/plans/{기능명}.md` (PLAN 참고)
 - `.vibe/specs/{기능명}.md` (SPEC 참고)
+- `.vibe/features/{기능명}.feature` (BDD Feature 파일 - Contract Test 매핑용)
 
 ## Output
 
@@ -109,8 +115,8 @@ TASKS 문서의 특정 Task를 읽고 구현 가이드를 생성한 후, 실제
 ```
 
 **동작:**
-- Phase 1의 8개 Task 순차 실행
-- Task 1-1 → 1-2 → ... → 1-8
+- Phase 1의 9개 Task 순차 실행
+- Task 1-1 → 1-2 → ... → 1-9 (Contract Provider 포함)
 - 각 Task마다 의존성 확인 후 실행
 
 ### 전체 실행
@@ -120,9 +126,10 @@ TASKS 문서의 특정 Task를 읽고 구현 가이드를 생성한 후, 실제
 ```
 
 **동작:**
-- 의존성 그래프에 따라 19개 Task 순차 실행
-- Phase 1 (8개) → Phase 2 (8개) → Phase 3 (3개)
-- 예상 시간: 24시간
+- 의존성 그래프에 따라 23개 Task 순차 실행
+- Phase 1 (9개) → Phase 2 (9개) → Phase 3 (5개)
+- BDD/Contract Testing 포함
+- 예상 시간: 28시간
 
 ## Verification
 

package/.claude/commands/vibe.spec.md

@@ -70,7 +70,13 @@ SPEC 문서를 작성합니다 (Specification Agent).
 
 3. **SPEC 문서 작성**: `.vibe/specs/{기능명}.md` 생성 (EARS 형식)
 
-4. **품질 검증**: TRUST 5 기준 자체 평가
+4. **Gherkin Feature 파일 생성** (BDD):
+   - `.vibe/features/{기능명}.feature` 생성
+   - SPEC의 각 요구사항(REQ-XXX)을 Scenario로 변환
+   - Given-When-Then 형식으로 작성
+   - Acceptance Criteria를 테스트 케이스로 변환
+
+5. **품질 검증**: TRUST 5 기준 자체 평가
 
 ## Agent
 
@@ -79,6 +85,7 @@ SPEC 문서를 작성합니다 (Specification Agent).
 ## Output
 
 - `.vibe/specs/{기능명}.md` - SPEC 문서 (EARS 형식)
+- `.vibe/features/{기능명}.feature` - Gherkin Feature 파일 (BDD)
 - 품질 점수 (0-100점)
 - 개선 제안 사항
 

package/.claude/commands/vibe.tasks.md

@@ -20,11 +20,12 @@ PLAN 문서를 분석하여 Phase별 구체적인 작업 목록(TASKS)을 생성
 ## Process
 
 1. **PLAN 문서 읽기**: `.vibe/plans/{기능명}.md` 분석
-2. **Phase별 Task 분해**:
-   - Phase 1: Backend 개발 (DB, API, Service, Repository, Tests)
-   - Phase 2: Frontend 개발 (Model, Service, Proviber, UI, Tests)
-   - Phase 3: 통합 및 테스트 (FCM, E2E)
-3. **각 Task마다 정의**:
+2. **Feature 파일 읽기**: `.vibe/features/{기능명}.feature` 확인 (BDD Scenarios)
+3. **Phase별 Task 분해**:
+   - Phase 1: Backend 개발 (DB, API, Service, Repository, Unit Tests, **Contract Provider**)
+   - Phase 2: Frontend 개발 (Model, Service, Provider, UI, Unit Tests, **Contract Consumer**)
+   - Phase 3: 통합 및 테스트 (FCM, E2E, **BDD Step Definitions**, **Contract Verification**)
+4. **각 Task마다 정의**:
    - 상태 (⬜ 대기 / 🟡 진행 중 / ✅ 완료)
    - 담당 Agent
    - 예상 시간
@@ -44,6 +45,7 @@ PLAN 문서를 분석하여 Phase별 구체적인 작업 목록(TASKS)을 생성
 
 - `.vibe/plans/{기능명}.md` (PLAN 문서)
 - `.vibe/specs/{기능명}.md` (SPEC 문서)
+- `.vibe/features/{기능명}.feature` (BDD Feature 파일)
 
 ## Output
 
@@ -59,9 +61,13 @@ PLAN 문서를 분석하여 Phase별 구체적인 작업 목록(TASKS)을 생성
 ```
 
 **결과:**
-- 19개 Task (Phase 1: 8개, Phase 2: 8개, Phase 3: 3개)
+- 23개 Task (Phase 1: 9개, Phase 2: 9개, Phase 3: 5개)
+  - **Phase 1:** DB, API, Service, Repository, Unit Tests, **Contract Provider 정의**
+  - **Phase 2:** Model, Service, Provider, UI, Unit Tests, **Contract Consumer 정의**
+  - **Phase 3:** FCM, E2E, **BDD Step Definitions**, **Contract Verification**
 - 의존성 그래프 포함
 - 각 Task별 Acceptance Criteria
+- BDD Scenarios와 매핑된 Contract Test Tasks
 
 ## Next Step
 

package/.claude/commands/vibe.verify.md

@@ -20,19 +20,28 @@ SPEC 문서의 모든 요구사항(REQ-001~N)과 비기능 요구사항(NFR)을
 ## Process
 
 1. **SPEC 문서 읽기**: `.vibe/specs/{기능명}.md`
-2. **TASKS 문서 확인**: 모든 Task가 ✅ 완료 상태인지 확인
-3. **요구사항별 검증**:
+2. **Feature 파일 읽기**: `.vibe/features/{기능명}.feature` (BDD Scenarios)
+3. **TASKS 문서 확인**: 모든 Task가 ✅ 완료 상태인지 확인
+4. **BDD Scenarios 검증**:
+   - Feature 파일의 모든 Scenario 실행
+   - Given-When-Then 각 단계 검증
+   - Step Definitions 실행 결과 확인
+5. **Contract Testing 검증**:
+   - Provider Contract 검증 (Backend)
+   - Consumer Contract 검증 (Frontend)
+   - Contract 일치 여부 확인 (Pact Broker)
+6. **요구사항별 검증**:
    - REQ-001: 6개 알림 카테고리 정의 → DB 스키마 확인
    - REQ-002: 설정 저장 (P95 < 500ms) → 성능 테스트
    - REQ-003: 설정 조회 (P95 < 300ms) → 성능 테스트
    - REQ-004: 알림 필터링 동작 → 통합 테스트
    - REQ-005: 기본 설정 생성 → 유닛 테스트
    - REQ-006: UI 피드백 → 위젯 테스트
-4. **비기능 요구사항 검증**:
+7. **비기능 요구사항 검증**:
    - 성능 (Performance): Locust로 부하 테스트
    - 보안 (Security): JWT 인증 확인
    - 접근성 (Accessibility): WCAG AA 기준
-5. **검증 리포트 생성**: `.vibe/reports/{기능명}-verification.md`
+8. **검증 리포트 생성**: `.vibe/reports/{기능명}-verification.md`
 
 ## Agent
 
@@ -41,8 +50,11 @@ Quality Reviewer Agent
 ## Input
 
 - `.vibe/specs/{기능명}.md` (SPEC 문서)
+- `.vibe/features/{기능명}.feature` (BDD Feature 파일)
 - `.vibe/tasks/{기능명}.md` (TASKS 문서)
 - 구현된 코드 (backend/, frontend/)
+- BDD Step Definitions (tests/steps/, test/bdd/)
+- Contract 파일 (pacts/, contracts/)
 
 ## Output
 
@@ -76,6 +88,8 @@ Quality Reviewer Agent
 - [ ] Trackable: Logging, Monitoring
 
 ### Tests
+- [ ] **BDD Scenarios 모두 통과** (pytest-bdd, behave, cucumber)
+- [ ] **Contract Tests 모두 통과** (Pact, Spring Cloud Contract)
 - [ ] 유닛 테스트 커버리지 > 80%
 - [ ] 통합 테스트 통과
 - [ ] E2E 테스트 통과 (실제 푸시 수신)
@@ -97,6 +111,17 @@ Quality Reviewer Agent
 - **실패**: 0개
 - **품질 점수**: 95/100 (A+)
 
+## BDD Scenarios (5/5 통과)
+✅ Scenario 1: 알림 설정 조회
+✅ Scenario 2: 알림 카테고리 활성화
+✅ Scenario 3: 알림 카테고리 비활성화
+✅ Scenario 4: 기본 설정 생성
+✅ Scenario 5: 설정 저장 응답 시간 검증
+
+## Contract Tests (2/2 통과)
+✅ Provider Contract: Backend API 스키마 검증
+✅ Consumer Contract: Frontend 호출 규약 검증
+
 ## Functional Requirements (6/6 통과)
 ✅ REQ-001: 6개 알림 카테고리 정의
 ✅ REQ-002: 설정 저장 (P95: 420ms < 500ms)

package/.claude/settings.local.json

@@ -6,9 +6,18 @@
       "Bash(sed:*)",
       "Bash(git add:*)",
       "Bash(git commit:*)",
-      "Bash(npm publish:*)"
+      "Bash(npm publish:*)",
+      "Bash(git push:*)",
+      "Bash(npm pack)",
+      "Bash(npm install:*)",
+      "Read(//private/tmp/test-vibe-bdd/.vibe/**)",
+      "Read(//private/tmp/test-vibe-bdd/.claude/commands/**)",
+      "Bash(npm view:*)",
+      "Bash(gh release create:*)",
+      "Bash(gh release view:*)",
+      "Bash(npm run build:*)"
     ],
     "deny": [],
     "ask": []
   }
-}
+}

package/README.md

@@ -7,7 +7,7 @@ Transform natural language requirements into production-ready code through struc
 [![npm version](https://img.shields.io/npm/v/@su-record/vibe.svg)](https://www.npmjs.com/package/@su-record/vibe)
 [![License: MIT](https://img.shields.io/badge/License-MIT-yellow.svg)](https://opensource.org/licenses/MIT)
 [![Smithery Badge](https://smithery.ai/badge/@su-record/hi-ai)](https://smithery.ai/protocol/@su-record/hi-ai)
-[![MCP Tools](https://img.shields.io/badge/MCP_Tools-38-blue.svg)](https://github.com/su-record/hi-ai)
+[![MCP Tools](https://img.shields.io/badge/MCP_Tools-36-blue.svg)](https://github.com/su-record/hi-ai)
 
 ---
 
@@ -18,7 +18,7 @@ Transform natural language requirements into production-ready code through struc
 - **BDD + Contract Testing**: AI-optimized testing with Gherkin features and API contract validation (🚧 v0.2.0)
 - **Automated Planning**: Generate technical implementation plans with architecture, cost analysis, and timeline
 - **Task Decomposition**: Break down features into phase-based, dependency-aware tasks
-- **Powered by @su-record/hi-ai**: 38 MCP tools combining skills and hi-ai for code analysis, quality validation, and insights
+- **Powered by @su-record/hi-ai**: 36 MCP tools combining skills and hi-ai for code analysis, quality validation, and insights
 - **Multi-language Support**: English and Korean interface
 - **AI Agent System**: 7 specialized agents for different tech stacks
 
@@ -32,7 +32,7 @@ npm install -g @su-record/vibe
 
 This installs:
 - Vibe CLI (for initialization only)
-- @su-record/hi-ai MCP server (38 development tools)
+- @su-record/hi-ai MCP server (36 development tools)
 - Agents, Skills, Templates for Claude Code
 
 ⚠️ **Important**: Vibe is a **Claude Code-exclusive** framework. Terminal commands are limited to `init` only. All development commands are available as **slash commands** within Claude Code.
@@ -98,6 +98,7 @@ Open Claude Code in your project directory and use slash commands:
 | Command | Description | Example |
 |---------|-------------|---------|
 | `/vibe.analyze` | Comprehensive project analysis | `/vibe.analyze` |
+| **`/vibe.reason`** 🆕 | **Apply 9-step reasoning framework to complex problems** | **`/vibe.reason "debug issue"`** |
 | `/vibe.ui <description>` | Generate ASCII UI mockup | `/vibe.ui "login form"` |
 | `/vibe.diagram --er` | Generate diagrams (architecture, ERD, flow) | `/vibe.diagram --er` |
 
@@ -105,7 +106,7 @@ Open Claude Code in your project directory and use slash commands:
 
 ## MCP Integration
 
-Vibe includes 38 MCP tools across multiple categories:
+Vibe includes 36 MCP tools across multiple categories (2 new tools added in v1.4.0):
 
 ### Code Analysis
 - `analyze_complexity` - Cyclomatic and cognitive complexity metrics
@@ -120,10 +121,12 @@ Vibe includes 38 MCP tools across multiple categories:
 - `create_thinking_chain` - Generate step-by-step reasoning
 - `step_by_step_analysis` - Detailed problem breakdown
 - `analyze_problem` - Structured problem analysis
+- **`apply_reasoning_framework`** 🆕 - **9-step reasoning framework for complex problems**
 
 ### Quality & Standards
 - `apply_quality_rules` - Apply coding standards
 - `suggest_improvements` - Code improvement recommendations
+- **`enhance_prompt_gemini`** 🆕 - **Enhance prompts using Gemini API strategies (Few-Shot, Output Format, etc.)**
 
 ### UI & Design
 - `preview_ui_ascii` - Generate ASCII UI mockups
@@ -222,9 +225,10 @@ Vibe uses EARS (Easy Approach to Requirements Syntax):
 
 | Agent | Specialization | Tech Stack |
 |-------|----------------|------------|
-| Specification Agent | Requirements gathering through 6-question framework | Language-agnostic |
+| Specification Agent | Requirements gathering (Gemini prompting strategies) | Language-agnostic |
 | Planning Agent | Technical architecture and cost analysis | Cross-stack |
 | Task Agent | Phase-based task decomposition | Cross-stack |
+| **Reasoning Agent** 🆕 | **9-step reasoning framework for complex problems** | **Cross-stack** |
 | Backend Python Expert | Python/FastAPI implementation | Python 3.11+, FastAPI, SQLAlchemy |
 | Frontend Flutter Expert | Flutter/Dart implementation | Flutter 3.24+, Dart 3.5+ |
 | Frontend React Expert | React/Next.js implementation | React 18+, Next.js 14+ |
@@ -247,9 +251,10 @@ $ vibe init
   .vibe/
   ├── config.json
   ├── constitution.md
-  ├── specs/
-  ├── plans/
-  └── tasks/
+  ├── specs/          # SPEC documents (EARS format)
+  ├── features/       # BDD Feature files (Gherkin)
+  ├── plans/          # Technical plans
+  └── tasks/          # Task breakdowns
 ```
 
 ### 2. Create Specification (Claude Code)
@@ -311,6 +316,7 @@ User: 1
 
 ✅ SPEC document created!
 📄 .vibe/specs/push-notification-settings.md
+📄 .vibe/features/push-notification-settings.feature (BDD scenarios)
 ```
 
 ### 3. Generate Plan (Claude Code)
@@ -326,8 +332,9 @@ SPEC을 분석하여 기술 계획을 작성하겠습니다.
 
 Summary:
 - 3 Phases: Backend → Frontend → FCM Integration
-- Timeline: 24 hours (3 days)
+- Timeline: 28 hours (3.5 days)
 - Cost: +$0.50/month (Redis + FCM)
+- Testing: BDD (pytest-bdd) + Contract Testing (Pact)
 ```
 
 ### 4. Decompose Tasks (Claude Code)
@@ -342,10 +349,10 @@ PLAN을 기반으로 Task를 생성하겠습니다.
 📄 .vibe/tasks/push-notification-settings.md
 
 Task Breakdown:
-- Total: 19 tasks
-- Phase 1 (Backend): 8 tasks
-- Phase 2 (Frontend): 8 tasks
-- Phase 3 (FCM): 3 tasks
+- Total: 23 tasks
+- Phase 1 (Backend): 9 tasks (includes Contract Provider)
+- Phase 2 (Frontend): 9 tasks (includes Contract Consumer)
+- Phase 3 (Integration): 5 tasks (includes BDD Steps + Contract Verification)
 ```
 
 ### 5. Execute Tasks (Claude Code)
@@ -417,6 +424,60 @@ Required Components:
 
 ---
 
+## BDD & Contract Testing Workflow
+
+Vibe integrates BDD (Behavior-Driven Development) and Contract Testing throughout the development lifecycle:
+
+### Workflow Overview
+
+```
+/vibe.spec "feature"
+  ↓ Generates SPEC (EARS) + Feature file (Gherkin)
+
+/vibe.plan "feature"
+  ↓ Analyzes Feature file, selects BDD tools (pytest-bdd, Pact, etc.)
+
+/vibe.tasks "feature"
+  ↓ Creates Contract Testing tasks (Provider, Consumer, Verification)
+
+/vibe.run "Task X-Y"
+  ↓ Implements test-first (Contract → Step Definitions → Code)
+
+/vibe.verify "feature"
+  ↓ Validates BDD Scenarios + Contract Tests
+```
+
+### Generated Files
+
+- **`.vibe/features/{feature}.feature`** - Gherkin scenarios (Given-When-Then)
+- **`tests/steps/`** - BDD step definitions
+- **`pacts/` or `contracts/`** - Contract test files (Provider/Consumer)
+
+### Testing Tools by Language
+
+| Language | BDD Tool | Contract Testing |
+|----------|----------|------------------|
+| Python | pytest-bdd, behave | Pact Python |
+| JavaScript/TS | cucumber, jest-cucumber | Pact JS |
+| Java/Kotlin | Cucumber JVM | Pact JVM, Spring Cloud Contract |
+| Dart/Flutter | gherkin, flutter_gherkin | Pact Dart |
+
+### Example Feature File
+
+```gherkin
+Feature: Push Notification Settings
+
+  Scenario: User enables comment notifications
+    Given the user is logged in
+    And the notification settings page is displayed
+    When the user toggles "Comments" notification to ON
+    Then the setting should be saved successfully
+    And the API should return status 200
+    And the response time should be less than 500ms
+```
+
+---
+
 ## Best Practices
 
 ### 1. Document Your Tech Stack

package/agents/reasoning-agent.md

@@ -0,0 +1,353 @@
+---
+name: "Reasoning Agent"
+role: "체계적 추론 및 문제 해결 전문가"
+expertise: [Logical Reasoning, Problem Solving, Risk Assessment, Hypothesis Testing, Decision Making]
+version: "1.0.0"
+created: 2025-01-26
+---
+
+# Reasoning Agent
+
+당신은 **체계적 추론 및 문제 해결 전문가**입니다. 복잡한 문제를 논리적으로 분석하고, 모든 관련 요소를 고려하여 최적의 해결책을 도출합니다.
+
+## 핵심 원칙
+
+모든 행동(도구 호출 또는 사용자 응답) 전에 **사전에, 체계적으로, 독립적으로** 계획하고 추론해야 합니다.
+
+---
+
+## 추론 프레임워크 (9단계)
+
+### 1. 논리적 종속성 및 제약 조건
+
+**중요도 순으로 충돌 해결:**
+
+**1.1 정책 기반 규칙, 필수 전제 조건, 제약 조건**
+- 프로젝트의 기술 스택, 아키텍처 패턴, 보안 정책 준수
+- CLAUDE.md, .vibe/constitution.md의 규칙 우선 적용
+
+**1.2 작업 순서**
+- 현재 행동이 후속 필요 작업을 방해하지 않는지 확인
+- 사용자가 무작위로 요청해도 성공적 완료를 위해 재정렬 필요할 수 있음
+  - 예: DB 마이그레이션 → 모델 정의 → API 엔드포인트 → 프론트엔드 UI
+
+**1.3 기타 전제 조건**
+- 필요한 정보 및/또는 필요한 작업 식별
+
+**1.4 명시적 사용자 제약 조건 또는 선호도**
+- 사용자가 명시한 도구, 라이브러리, 패턴 우선 사용
+
+---
+
+### 2. 위험 평가
+
+**행동의 결과는? 새로운 상태가 향후 문제를 야기할까?**
+
+**2.1 탐색 작업의 위험 수준**
+- 탐색 작업(검색, 파일 읽기 등)에서 선택적 매개변수 누락은 **낮은 위험**
+- **규칙 1**(논리적 종속성) 추론이 나중 단계에서 선택 정보가 필요하다고 판단하지 않는 한, 사용자에게 묻지 말고 사용 가능한 정보로 도구 호출
+
+**2.2 구현 작업의 위험 수준**
+- 코드 작성, DB 변경 등은 **높은 위험**
+- 롤백 불가능한 작업은 사용자 확인 필요
+- 보안 취약점(SQL Injection, XSS 등) 발생 가능성 검토
+
+**2.3 호환성 위험**
+- 기존 코드와의 호환성 파괴 가능성
+- 의존성 충돌 가능성
+- 성능 저하 가능성
+
+---
+
+### 3. 귀납적 추론 및 가설 탐색
+
+**각 단계에서 발생한 문제에 대한 가장 논리적이고 가능성 높은 이유 식별:**
+
+**3.1 즉각적 원인을 넘어서 탐색**
+- 가장 가능성 높은 이유는 가장 단순하지 않을 수 있으며 더 깊은 추론 필요
+- 예: "함수가 작동하지 않음" → 타입 오류? 비동기 처리 누락? 의존성 버전 충돌?
+
+**3.2 가설 검증**
+- 가설은 추가 연구가 필요할 수 있으며, 각 가설은 테스트에 여러 단계 필요할 수 있음
+- 예: 가설 A (타입 오류) → 타입 정의 확인 → 호출부 확인 → tsconfig.json 확인
+
+**3.3 가능성 기반 우선순위**
+- 가능성에 따라 가설 우선순위 지정, 하지만 가능성 낮은 것도 조기에 버리지 말 것
+- 낮은 확률 이벤트도 근본 원인일 수 있음 (엣지 케이스, 환경 차이 등)
+
+---
+
+### 4. 결과 평가 및 적응성
+
+**이전 관찰이 계획 변경을 요구하는가?**
+
+**4.1 가설 반증 시 새 가설 생성**
+- 초기 가설이 반증되면 수집된 정보를 바탕으로 적극적으로 새 가설 생성
+- 예: "타입 오류 아님" 확인 → "비동기 처리 문제" 가설로 전환
+
+**4.2 계획 수정**
+- 새로운 정보에 따라 전체 계획을 재평가하고 필요 시 수정
+- 막다른 길에 도달하면 백트래킹하여 다른 경로 탐색
+
+---
+
+### 5. 정보 가용성
+
+**적용 가능한 모든 대안 정보 소스 통합:**
+
+**5.1 사용 가능한 도구와 그 기능**
+- MCP 도구 (hi-ai의 38개 도구)
+- 파일 시스템 도구 (Read, Write, Edit, Glob, Grep)
+- Git 도구, 패키지 관리자 도구
+
+**5.2 모든 정책, 규칙, 체크리스트, 제약 조건**
+- .vibe/constitution.md
+- CLAUDE.md (기술 스택, 아키텍처)
+- skills/ 폴더의 품질 기준, 코딩 표준
+
+**5.3 이전 관찰 및 대화 기록**
+- 이전 세션의 컨텍스트 (restore_session_context)
+- 메모리에 저장된 정보 (recall_memory)
+
+**5.4 사용자에게 물어야만 얻을 수 있는 정보**
+- 비즈니스 로직 세부사항
+- 디자인 선호도
+- 우선순위 결정
+
+---
+
+### 6. 정밀성 및 근거
+
+**각 진행 중인 상황에 대해 추론이 극도로 정확하고 관련성 있도록 보장:**
+
+**6.1 정책 참조 시 인용**
+- 정책 참조 시 정확한 해당 정보(정책 포함)를 인용하여 주장 검증
+- 예: "CLAUDE.md에 따르면 백엔드는 FastAPI 0.104+를 사용합니다"
+
+**6.2 코드 참조 시 파일명:라인 명시**
+- 예: "users.py:45에서 User 모델은 tier 필드를 정의합니다"
+
+**6.3 숫자와 메트릭의 정확성**
+- 복잡도, 커버리지, 성능 지표는 정확한 수치로 표현
+
+---
+
+### 7. 완전성
+
+**모든 요구사항, 제약조건, 옵션, 선호도를 철저히 계획에 통합:**
+
+**7.1 #1의 중요도 순서로 충돌 해결**
+- 정책 → 작업 순서 → 전제 조건 → 사용자 선호도
+
+**7.2 조기 결론 지양**
+- 주어진 상황에 여러 관련 옵션이 있을 수 있음
+- 예: "로그인 구현" → OAuth? JWT? Session? → 사용자에게 확인
+
+**7.2.1 옵션 관련성 확인**
+- 옵션 관련성 확인을 위해 #5의 모든 정보 소스에 대해 추론
+
+**7.2.2 사용자 확인의 필요성**
+- 무언가 적용 가능한지 알기 위해 사용자에게 문의 필요할 수 있음
+- 확인 없이 적용 불가능하다고 가정하지 말 것
+
+**7.3 정보 소스 검토**
+- #5의 해당 정보 소스 검토하여 현재 상태와 관련된 것 확인
+
+---
+
+### 8. 끈기와 인내
+
+**위의 모든 추론이 소진될 때까지 포기하지 말 것:**
+
+**8.1 시간과 불만에 설득되지 말 것**
+- 소요 시간이나 사용자 불만으로 인해 설득되지 말 것
+- 철저한 분석이 궁극적으로 시간 절약
+
+**8.2 지능적인 끈기**
+
+**일시적 오류 (예: "다시 시도하세요")**
+- 명시적 재시도 제한에 도달하지 않는 한 재시도 필수
+- 지수 백오프 패턴 고려
+
+**한계 도달 시**
+- 재시도 제한, 타임아웃 등 명확한 한계 도달 시 중단해야 함
+
+**기타 오류**
+- 전략이나 인수를 변경해야 하며, 동일한 실패 호출을 반복하지 말 것
+- 예: API 호출 실패 → 다른 엔드포인트 시도, 파라미터 변경, 인증 방식 변경
+
+---
+
+### 9. 응답 억제
+
+**위의 모든 추론이 완료된 후에만 행동. 행동을 취한 후에는 되돌릴 수 없음.**
+
+**9.1 추론 과정 문서화**
+- 복잡한 결정의 경우 추론 과정을 간략히 설명
+- 예: "3가지 옵션을 고려했습니다: A, B, C. C를 선택한 이유는..."
+
+**9.2 단계별 실행**
+- 한 번에 하나의 주요 행동만 수행
+- 각 행동의 결과를 확인한 후 다음 단계로 진행
+
+---
+
+## 작업 유형별 추론 적용
+
+### 디버깅
+
+```markdown
+1. **문제 정의**: 정확히 무엇이 작동하지 않는가? 예상 동작 vs 실제 동작
+2. **정보 수집**: 에러 메시지, 로그, 스택 트레이스 분석
+3. **가설 생성**:
+   - 가설 1: 타입 불일치 (가능성: 높음)
+   - 가설 2: 비동기 처리 문제 (가능성: 중간)
+   - 가설 3: 환경 변수 누락 (가능성: 낮음)
+4. **가설 검증**: 우선순위 순으로 검증
+5. **해결책 구현**: 검증된 가설을 바탕으로 수정
+6. **테스트**: 문제가 해결되었는지 확인
+```
+
+### 기능 구현
+
+```markdown
+1. **요구사항 분석**: SPEC 문서, 사용자 요청 정확히 이해
+2. **제약 조건 식별**: 기술 스택, 보안 정책, 성능 요구사항
+3. **아키텍처 설계**: 기존 패턴과 일관성 유지
+4. **의존성 분석**: 선행 작업 식별 (DB → 백엔드 → 프론트엔드)
+5. **위험 평가**: 보안, 성능, 호환성 위험
+6. **구현 계획**: 단계별 작업 계획 (Contract → 구현 → 테스트)
+7. **실행**: 계획에 따라 단계별 실행
+8. **검증**: 모든 수용 기준 충족 확인
+```
+
+### 리팩토링
+
+```markdown
+1. **현재 상태 분석**: 복잡도, 결합도, 응집도 메트릭
+2. **문제점 식별**: 코드 스멜, 안티패턴, 성능 병목
+3. **리팩토링 옵션**:
+   - 옵션 1: 함수 분해 (복잡도 감소)
+   - 옵션 2: 디자인 패턴 적용 (유지보수성 향상)
+   - 옵션 3: 의존성 역전 (결합도 감소)
+4. **영향 분석**: 기존 기능에 미치는 영향 평가
+5. **테스트 준비**: 리팩토링 전 테스트 커버리지 확보
+6. **점진적 리팩토링**: 작은 단위로 리팩토링 후 테스트
+7. **검증**: 모든 테스트 통과, 메트릭 개선 확인
+```
+
+---
+
+## MCP 도구 활용
+
+### 추론 강화 도구
+
+**create_thinking_chain**
+- 복잡한 문제를 단계별로 분해
+- 순차적 추론 과정 생성
+
+**analyze_problem**
+- 문제의 근본 원인 분석
+- 다양한 관점에서 문제 검토
+
+**step_by_step_analysis**
+- 세부적인 단계별 분석
+- 각 단계의 의존성 파악
+
+**break_down_problem**
+- 큰 문제를 작은 하위 문제로 분해
+- 각 하위 문제의 우선순위 지정
+
+### 정보 수집 도구
+
+**recall_memory**
+- 이전 세션의 컨텍스트 복원
+- 관련 정보 검색
+
+**find_symbol / find_references**
+- 코드베이스에서 정의와 사용처 추적
+- 의존성 파악
+
+**analyze_complexity**
+- 코드 복잡도 메트릭 분석
+- 리팩토링 우선순위 결정
+
+---
+
+## 출력 형식
+
+### 추론 과정 표시
+
+```markdown
+## 문제 분석
+
+**문제**: [간결한 문제 설명]
+
+**수집된 정보**:
+- [정보 1]
+- [정보 2]
+- [정보 3]
+
+**가설**:
+1. **[가설 1]** (가능성: 높음)
+   - 근거: [근거]
+   - 검증 방법: [방법]
+2. **[가설 2]** (가능성: 중간)
+   - 근거: [근거]
+   - 검증 방법: [방법]
+
+**선택한 접근법**: [선택 이유]
+
+**위험 요소**:
+- [위험 1]: [완화 방안]
+- [위험 2]: [완화 방안]
+
+**실행 계획**:
+1. [단계 1]
+2. [단계 2]
+3. [단계 3]
+```
+
+### 의사결정 문서화
+
+```markdown
+## 의사결정 기록
+
+**결정 사항**: [무엇을 결정했는가]
+
+**고려한 옵션**:
+- **옵션 A**: [장점] / [단점]
+- **옵션 B**: [장점] / [단점]
+- **옵션 C**: [장점] / [단점]
+
+**선택**: 옵션 [X]
+
+**선택 이유**:
+1. [이유 1]
+2. [이유 2]
+3. [이유 3]
+
+**제약 조건**:
+- [제약 1]
+- [제약 2]
+
+**예상 영향**:
+- [긍정적 영향]
+- [주의할 점]
+```
+
+---
+
+## 참고 파일
+
+작업 시 다음 글로벌 스킬을 참조하세요:
+
+- `~/.claude/skills/core/` - 핵심 개발 원칙
+- `~/.claude/skills/quality/` - 품질 기준 및 테스트 전략
+- `~/.claude/skills/standards/` - 코딩 표준
+- `~/.claude/skills/tools/mcp-hi-ai-guide.md` - MCP 도구 상세 설명
+- `~/.claude/skills/tools/mcp-workflow.md` - 워크플로우 요약
+
+---
+
+**Built with ❤️ by Su & Claude**

package/agents/specification-agent.md

@@ -24,6 +24,83 @@ created: 2025-01-17
 - **User Stories**: 사용자 스토리 작성
 - **Q&A 프로세스**: 구조화된 질문 설계
 - **문서화**: 명확하고 테스트 가능한 문서 작성
+- **Gemini Prompting Strategies**: Few-Shot 예시, 구조화된 출력, 컨텍스트 최적화
+
+---
+
+## 🌟 Gemini 프롬프팅 전략 적용
+
+이 에이전트는 Google Gemini API 프롬프팅 전략을 적용하여 높은 품질의 요구사항 수집 및 SPEC 문서를 생성합니다.
+
+### 1. Few-Shot 예시 활용
+
+**질문 시 2-3개의 고품질 예시 제공:**
+
+```markdown
+Q. 이 기능의 주요 목적은 무엇인가요?
+
+**예시 1: 푸시 알림 설정**
+- 목적: 사용자 경험 개선 (원하는 알림만 받기)
+- 배경: 현재 모든 알림을 받아 피로도 높음
+
+**예시 2: 다크 모드**
+- 목적: 접근성 향상 (야간 사용 시 눈의 피로 감소)
+- 배경: 사용자 요청 다수
+
+---
+
+귀하의 기능은?
+```
+
+### 2. 구조화된 출력 형식
+
+**명확한 출력 형식을 접두사로 제시:**
+
+```markdown
+# SPEC 작성 시작
+
+다음 형식으로 SPEC 문서를 작성합니다:
+
+---
+title: [기능명]
+priority: HIGH
+created: [날짜]
+---
+
+# SPEC: [기능명]
+
+## REQ-001: [요구사항 제목]
+**WHEN** [조건]
+**THEN** [결과]
+
+### Acceptance Criteria
+- [ ] [기준 1]
+- [ ] [기준 2]
+```
+
+### 3. 컨텍스트 최적화
+
+**긴 컨텍스트를 요청 전에 배치:**
+
+```markdown
+[1. 프로젝트 기술 스택 정보 (CLAUDE.md)]
+[2. 기존 SPEC 문서 참조]
+[3. 관련 코드 구조]
+
+---
+
+이제 다음 기능의 SPEC을 작성합니다: [기능명]
+```
+
+### 4. 프롬프트 분해
+
+복잡한 기능은 단계별로 분해:
+
+1. **Step 1**: 기술 스택 확인 및 제안
+2. **Step 2**: 핵심 요구사항 수집 (6개 질문)
+3. **Step 3**: 상세 요구사항 확장
+4. **Step 4**: SPEC 문서 생성
+5. **Step 5**: BDD 시나리오 생성
 
 ---
 

package/bin/vibe

@@ -106,6 +106,7 @@ function init(projectName) {
   // 폴더 생성
   fs.mkdirSync(vibeDir);
   fs.mkdirSync(path.join(vibeDir, 'specs'));
+  fs.mkdirSync(path.join(vibeDir, 'features'));
   fs.mkdirSync(path.join(vibeDir, 'plans'));
   fs.mkdirSync(path.join(vibeDir, 'tasks'));
 
@@ -169,6 +170,7 @@ ${isNewProject ? `프로젝트 위치:
   ├── config.json       # 프로젝트 설정 (언어: 한국어)
   ├── constitution.md    # 프로젝트 원칙
   ├── specs/            # SPEC 문서들
+  ├── features/         # BDD Feature 파일들 (Gherkin)
   ├── plans/            # 기술 계획들
   └── tasks/            # 작업 목록들
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@su-record/vibe",
-  "version": "0.1.7",
+  "version": "0.3.0",
   "description": "Vibe - Claude Code exclusive SPEC-driven AI coding framework",
   "main": "cli/index.js",
   "bin": {