aiwf 0.3.7 → 0.3.12

package/.claude/commands/aiwf/aiwf_create_prd.md

@@ -1,280 +0,0 @@
-# Generate Product Documentation Workflow
-
-이 규칙은 AI가 몇 가지 핵심 질문을 통해 입력을 수집한 뒤, PRD → IA → UCD → UI/UX 문서를 **순차적으로** 생성하도록 안내합니다. 모든 출력은 **Markdown** 형식을 사용하며 **한국어**로 작성됩니다.
-
----
-
-## 1. 질문 단계
-
-AI는 다음 정보를 **질문**을 통해 사용자에게서 수집합니다.
-
-1. `<product-overview>`
-2. `<references>` (URL 목록)
-3. `<must-features>` (필수 기능 목록)
-4. `<target-user-persona>`
-5. `<target-platforms>`
-6. `<storage-type>`
-7. `<tech-stack>`
-
-> ⚠️ 모든 질문은 한글로 하며, 필요 시 추가적인 참고 서비스·경쟁 제품 정보를 요청합니다.
-
----
-
-## 2. PRD 작성 단계
-
-사용자로부터 모든 입력을 받은 뒤, 아래 **샘플 프롬프트** 구조를 참고하여 PRD를 생성합니다.
-
-```prompt
-Write a PRD document based on the following information:
-<product-overview>
-${productOverview}
-</product-overview>
-<references>
-${references}
-</references>
-<must-features>
-${mustFeatures}
-</must-features>
-<target-user-persona>
-${persona}
-</target-user-persona>
-<target-platforms>
-${platforms}
-</target-platforms>
-<storage-type>
-${storageType}
-</storage-type>
-<tech-stack>
-${techStack}
-</tech-stack>
-PRD must include the following contents:
-<table-of-contents>
-- Detailed product description
-- Reference Services with detailed rationale
-- Core features and specifications
-- Suggested additional features
-- User persona and scenarios
-- Technical stack recommendations
-</table-of-contents>
-<response-format>
-Use markdown format
-</response-format>
-<guidelines>
-- Use tables or lists where appropriate to organize information systematically.
-- All user interactions, including inputs and outputs, must be in Korean.
-- Provide accurate answers with reliable references
-- Write in Korean
-- Clearly separate each section
-- Collect additional reference services and provide detailed rationale
-- Do not include detailed data structure and storage design
-</guidelines>
-```
-
-문서에 포함해야 할 **추가 지침**:
-
-- 표와 리스트를 활용해 정보를 구조화할 것.
-- 참고 서비스는 최소 3개 이상, 각 서비스 사용 이유를 2~3줄로 기술.
-
-PRD 작성을 완료하면 "✅ PRD 완료" 메시지와 함께 IA 단계 진행 여부를 묻는 **한글** 질문을 덧붙입니다.
-
----
-
-## 3. IA(Information Architecture) 작성 단계
-
-사용자가 **계속**을 선택하면 IA 문서를 생성합니다.
-
-IA 문서는 다음을 포함합니다:
-
-1. **사이트맵** – 트리 형태로 표현
-2. **콘텐츠 인벤토리** – 페이지별 주요 콘텐츠 표
-3. **사용자 흐름** – 순서도(텍스트 기반)로 최소 2개 핵심 시나리오 제공
-4. **내비게이션 구조 및 URL 패턴**
-
-문서 형식: Markdown, 한국어
-
-### IA 샘플 프롬프트
-
-```prompt
-Write an Information Architecture document based on PRD, and following information:
-<navigation-type>
-${navigationType}
-</navigation-type>
-<auth-type>
-${authType}
-</auth-type>
-IA document must include the following contents:
-<table-of-contents>
-- Site Map
-- User Flow
-- Navigation Structure
-- Page Hierarchy
-- Content Organization
-- Interaction Patterns
-- URL Structure
-- Component Hierarchy
-</table-of-contents>
-<response-format>
-Use markdown format
-</response-format>
-<guidelines>
-- Use tables or lists where appropriate to organize information systematically
-- All user interactions, including inputs and outputs, must be in Korean
-- Provide accurate answers with reliable references
-- Write in Korean
-- Clearly separate each section
-- Consider user experience and accessibility
-- Include responsive design considerations
-- Consider SEO best practices
-</guidelines>
-```
-
-IA 작성 후 "✅ IA 완료" 메시지와 함께 UCD 단계 진행 여부 질의.
-
----
-
-## 4. UCD(User-Centered Design) 작성 단계
-
-UCD 문서는 다음을 포함합니다:
-
-1. **주요 페르소나 2–3개** – 표로 정리 (목표, 동기, pain point)
-2. **시나리오** – 페르소나별 핵심 사용 시나리오 2개 이상
-3. **요구사항 매트릭스** – 기능 ↔ 페르소나 매핑
-
-문서 형식: Markdown, 한국어
-
-### UCD 샘플 프롬프트
-
-```prompt
-Write a detailed use case document based on PRD, IA, and following information:
-Use case document must include the following contents:
-<table-of-contents>
-- Actor Definitions
-- Use Case Scenarios
-- Main Steps
-- Exception Handling
-- Comprehensive Actor Definitions
-- Detailed Use Case Scenarios
-- Main Steps and Flow of Events
-- Alternative Flows and Edge Cases
-- Preconditions and Postconditions
-- Business Rules and Constraints
-- Exception Handling Procedures
-- User Interface Considerations
-- Data Requirements and Data Flow
-- Security and Privacy Considerations
-</table-of-contents>
-<response-format>
-Use markdown format
-</response-format>
-<guidelines>
-- Use tables or lists where appropriate to organize information systematically
-- All user interactions, including inputs and outputs, must be in Korean
-- Provide accurate answers with reliable references
-- Write in Korean
-- Clearly separate each section
-- Include detailed step-by-step descriptions
-- Consider error cases and alternative flows
-- Include technical considerations
-</guidelines>
-```
-
-완료 후 "✅ UCD 완료" 메시지와 함께 UI/UX 단계 진행 여부 질의.
-
----
-
-## 5. UI/UX 가이드 작성 단계
-
-내용:
-
-1. **와이어프레임 설명** – 각 핵심 화면의 레이아웃과 구성 요소(텍스트 설명)
-2. **네비게이션 원칙** – 일관된 UI 패턴 설명
-3. **스타일 가이드 초안** – 컬러 팔레트, 타이포그래피, 컴포넌트 규칙
-4. **접근성 고려사항** – WCAG 2.1 준수 핵심 포인트
-
-문서 형식: Markdown, 한국어
-
-### UI/UX 샘플 프롬프트
-
-```prompt
-<role>
-senior UI/UX designer.
-</role>
-<task>
-Write a comprehensive UI/UX design guide based on the following information:
-</task>
-<design-preferences>
-Theme details: Please analyze the reference service and suggest appropriate:
-- Design style
-- Color scheme
-- Primary colors
-</design-preferences>
-<references>
-${references}
-</references>
-<additional-instructions>
-Please analyze the reference service's design system and suggest appropriate:
-- Overall design style and patterns
-- Color scheme and palette
-- Primary colors
-- Mood and atmosphere
-</additional-instructions>
-Design guide must include the following contents:
-<table-of-contents>
-- Design System Overview
-- Color Palette for tailwindcss (primary, secondary, accent, neutral, etc.)
-- Page Implementations
-  detailed design guide for each pages
-  - core purpose of the page
-  - key components
-  - layout structure
-- Layout Components
-  - applicable routes
-  - core components
-  - responsive behavior
-- Interaction Patterns
-- Breakpoints
-</table-of-contents>
-<breakpoints>
-$breakpoints: (
-├── 'mobile': 320px,
-├── 'tablet': 768px,
-├── 'desktop': 1024px,
-└── 'wide': 1440px
-);
-</breakpoints>
-<response-format>
-Use markdown format
-</response-format>
-<guidelines>
-- Use tables or lists where appropriate to organize information systematically
-- All descriptions must be in Korean
-- Considering color scheme, select proper color for each color in tailwindcss palette
-- Provide specific color codes
-- Provide rationale for design decisions
-- Always include responsive design considerations
-- Include all text content in UI
-- If needed, use enough images in each components
-- provide each image's url. Use stock photos from picsum.photos where appropriate, only valid URLs you know exist
-- Write in Korean
-- must handle root route
-- consider proper grid system for all components
-</guidelines>
-```
-
-완료 후 "🎉 모든 문서 생성 완료" 메시지와 함께 다음 단계(스프린트/태스크 분해) 안내.
-
----
-
-## 6. 스프린트/태스크 분해 준비
-
-모든 문서가 완료되면, AI는 `yolo` 또는 `create_sprints_from_milestone` 명령을 사용해 개발 스프린트와 태스크를 자동으로 생성할 수 있음을 사용자에게 알립니다.
-
----
-
-### 사용 예
-
-1. AI → 질문 단계 진행
-2. 사용자 → 정보 제공
-3. AI → PRD 생성, IA 진행 여부 질문
-4. 사용자 → "계속"
-5. AI → IA 생성, UCD 진행 여부 질문 … 반복

package/.claude/commands/aiwf/aiwf_create_sprint_tasks.md

@@ -1,189 +0,0 @@
-# 스프린트 태스크 생성 - 탑 다운 실행
-
-통합된 구현 가이드와 함께 기존 스프린트에 대한 상세한 태스크를 생성합니다.
-
-## 정확히 다음 8개 항목으로 TODO 생성
-
-1. 대상 스프린트 식별 및 존재 확인
-2. 스프린트 컨텍스트 및 관련 문서 로드
-3. 기존 ADR 및 기술 가이드 확인
-4. 태스크 분할을 위한 스프린트 결과물 분석
-5. 구현 가이드와 함께 개별 태스크 파일 생성
-6. 관련 태스크에 ADR 연결
-7. 태스크 참조로 스프린트 메타 업데이트
-8. 작업 품질 확인
-
-단계별로 따라가며 각 단계에 대한 다음 지침을 엄격히 준수하세요.
-
-## 모든 TODO 항목에 대한 세부사항
-
-### 1. 대상 스프린트 식별 및 존재 확인
-
-확인: <$ARGUMENTS>
-
-**필수:** 스프린트 ID가 제공되어야 함 (예: S02). 비어있다면 사용자에게 상세화할 스프린트를 지정하도록 요청.
-
-- `.aiwf/03_SPRINTS/`에 스프린트 디렉토리 존재 확인
-- 스프린트 메타 파일 존재 확인 (예: `S02_sprint_meta.md`)
-- 스프린트 상태가 이미 "completed"가 아닌지 확인
-- 태스크가 이미 존재한다면, 사용자에게 재생성할지 또는 다른 가이드가 필요한지 문의
-
-### 2. 스프린트 컨텍스트 및 관련 문서 로드
-
-병렬 서브에이전트를 사용하여 프로젝트 컨텍스트를 읽고 이해:
-
-- 프로젝트 컨텍스트를 위해 `.aiwf/00_PROJECT_MANIFEST.md` 읽기
-- 목표와 결과물을 이해하기 위해 스프린트 메타 파일 완전히 읽기
-- `.aiwf/02_REQUIREMENTS/`에서 상위 마일스톤 요구사항 읽기
-- 기술적 컨텍스트를 위해 `.aiwf/01_PROJECT_DOCS/ARCHITECTURE.md` 읽기
-- 아키텍처 결정을 이해하기 위해 `.aiwf/01_PROJECT_DOCS/LONG_TERM_VISION.md` 읽기
-
-**중요:** 스프린트 태스크는 문서화된 스프린트 목표와 일치해야 하며, 범위를 확장하면 안 됨.
-
-### 3. 기존 ADR 및 기술 가이드 확인
-
-**병렬 서브에이전트 사용**하여 다음 명령 실행:
-
-- 스프린트 ID와 일치하는 ADR을 위해 `.aiwf/05_ARCHITECTURE_DECISIONS/` 검색 (예: `ADR*_S02_*.md`)
-- 기술적 결정을 이해하기 위해 발견된 모든 ADR 읽기
-- ADR 참조 섹션에 대한 스프린트 메타 확인
-- 태스크 구현에 영향을 줄 기술적 결정 주목
-- 태스크와 서브태스크에서 관계 구축하고 구현할 내용을 명확히 하기
-
-**범위에서 충돌**이 ADR과 스프린트 목표 사이에 있다면, 고민해보고 사용자에게 충돌 해결을 요청.
-
-**ADR이 발견되지 않은 경우:** 진행하되 구현 중에 태스크가 명확화가 필요할 수 있음을 주목.
-
-### 4. 태스크 분할을 위한 스프린트 결과물 분석
-
-스프린트 목표와 결과물을 바탕으로 (병렬 서브에이전트에서 실행):
-
-- 고수준 결과물을 구체적이고 구현 가능한 태스크로 분할
-- 각 태스크가 일관된 기능이나 구성요소를 나타내도록 보장
-- 태스크 간의 논리적 종속성 고려
-- 기술 가이드를 위해 태스크를 관련 ADR에 매핑
-- 서브태스크와 함께 태스크가 완전히 생성된 후까지 복잡성 평가 연기
-
-### 5. 구현 가이드와 함께 개별 태스크 파일 생성
-
-**이제** 식별된 각 태스크에 대해 다음 지침과 함께 병렬 서브에이전트를 시작:
-
-    #### 각 태스크에 대한 TODO 생성
-
-    1. 기본 태스크 구조 생성
-    2. 코드베이스 인터페이스 조사
-    3. 기술 가이드 추가
-    4. 태스크 완전성 검증
-
-    ### 1. 기본 태스크 구조 생성
-
-    - 모든 태스크 파일은 스프린트 디렉토리(스프린트 메타 파일이 있는 곳)에 생성되어야 함
-    - `T<NN>_S<NN>_<설명적_이름>.md` 명명으로 파일 생성
-    - T01부터 시작하는 순차적 번호 사용
-    - `.aiwf/99_TEMPLATES/task_template.md`의 태스크 템플릿 구조를 정확히 따름
-    - 스프린트 목표에서 기본 설명과 목표 추가
-
-    ### 2. 코드베이스 인터페이스 조사
-
-    - 유사한 패턴과 인터페이스를 위해 기존 코드베이스 검토
-    - 필요한 특정 클래스, 함수, 임포트 식별
-    - 기존 모듈과의 통합 지점 찾기
-    - 인터페이스할 데이터베이스 모델, API 엔드포인트 또는 서비스 주목
-    - 기존 오류 처리 및 로깅 패턴 확인
-
-    ### 3. 기술 가이드 추가
-
-    태스크 파일에 다음 섹션 추가 (템플릿에 없으면 추가):
-
-    **기술 가이드 섹션:**
-
-    - 코드베이스의 주요 인터페이스 및 통합 지점
-    - 특정 임포트 및 모듈 참조
-    - 따라야 할 기존 패턴
-    - 작업할 데이터베이스 모델 또는 API 계약
-    - 유사한 코드에서 사용되는 오류 처리 접근법
-
-    **구현 노트 섹션:**
-
-    - 단계별 구현 접근법
-    - 존중해야 할 주요 아키텍처 결정
-    - 기존 테스트 패턴을 바탕으로 한 테스트 접근법
-    - 관련된 경우 성능 고려사항
-
-    **중요:** 코드 예제를 포함하지 마세요. 구조적 가이드와 참조만 제공.
-
-    #### 4. 태스크 완전성 검증
-
-    - 태스크가 명확한 구현 경로를 가지는지 확인
-    - 모든 통합 지점이 문서화되었는지 확인
-    - 가이드가 실제 코드베이스 요소를 참조하는지 확인
-    - 태스크가 자체 완결적이고 실행 가능한지 확인
-
-    **반복** `### 5. 구현 가이드와 함께 개별 태스크 파일 생성`을 모든 태스크에 대해
-
-### 6. 관련 태스크에 ADR 연결
-
-- 관련 ADR이 존재하는 경우
-- 관련된 ADR 참조
-- 각 ADR이 어떻게 적용되는지에 대한 설명을 기술 가이드 섹션에 추가
-- 태스크가 구현에 영향을 주는 ADR만 참조하도록 보장
-
-### 7. 태스크 참조로 스프린트 메타 업데이트
-
-- 태스크 목록을 추가/업데이트하기 위해 스프린트 메타 파일 편집
-- 논리적 그룹화 또는 종속성 순서로 태스크 구성
-- 각 태스크에 대한 간단한 설명 추가
-
-### 8. 작업 품질 확인
-
-복잡성에 대해 생성된 모든 태스크를 검토하고 높은 복잡성 태스크를 분할:
-
-**복잡성 평가 프로세스:**
-
-- 설명, 목표, 수용 기준, 서브태스크를 포함하여 각 태스크 파일을 완전히 읽기
-- 전체 범위와 도전에 대한 판단을 사용하여 복잡성 평가
-- 파일 수나 예상 시간과 같은 단순한 지표를 기반으로 복잡성을 평가하지 마세요
-- 개념적 어려움, 통합 도전, 미지수 고려
-- 태스크 프론트매터에서 복잡성을 낮음, 보통, 높음으로 표시
-
-**어떤 태스크든 높은 복잡성으로 표시된 경우:**
-
-- 태스크를 낮음 또는 보통 복잡성의 2-3개 작은 태스크로 분할
-- 적절한 순차적 번호로 새 태스크 파일 생성
-- 원래 높은 복잡성 태스크 파일을 업데이트하거나 삭제
-- 분할된 태스크들이 함께 원래 목표를 달성하도록 보장
-- 논리적 그룹화와 종속성 유지
-
-**모든 태스크가 완료된 후:**
-
-- 모든 태스크가 낮음 또는 보통 복잡성만 있는지 확인
-- 태스크 번호가 순차적인지 확인 (T01, T02, T03...)
-- 최종 태스크 목록으로 스프린트 메타 파일 업데이트
-- 실제로 생성된 태스크를 반영하도록 프로젝트 매니페스트 스프린트 섹션 업데이트
-- 완료 보고서 생성
-
-**출력 형식:**
-
-    ```Markdown
-    ## 스프린트 상세화 완료 - [YYYY-MM-DD HH:MM]
-
-    **스프린트:** [스프린트 ID] - [스프린트 이름]
-    **상태:** 계획 완료
-
-    **생성된 태스크:** [분할 후 최종 개수]
-    - 보통 복잡성: [개수]
-    - 낮은 복잡성: [개수]
-
-    **태스크 분할 요약:**
-    - [원래 T03이 범위로 인해 T03과 T04로 분할됨]
-    - [다른 분할 필요 없음]
-
-    **최종 태스크 목록:**
-    1. T01_S02 - [제목] (복잡성: [수준])
-    2. T02_S02 - [제목] (복잡성: [수준])
-    [모든 태스크에 대해 계속]
-
-    **다음 단계:**
-    - 완전성에 대한 태스크 검토
-    - 구현을 시작하기 위해 `/do_task [스프린트의_첫_번째_태스크]` 실행
-    ```

package/.claude/commands/aiwf/aiwf_create_sprints_from_milestone.md

@@ -1,121 +0,0 @@
-# 마일스톤에서 스프린트 생성 - 탑 다운 실행
-
-마일스톤의 범위를 스프린트로 분할하기 위해 다음 지침을 따르세요
-
-## 정확히 다음 8개 항목으로 TODO 생성
-
-1. 현재 마일스톤 상태 분석
-2. 완료된 작업과 마일스톤 요구사항 평가
-3. 남은 작업과 종속성 식별
-4. 논리적 스프린트 경계 설계
-5. 스프린트 디렉토리와 메타 파일 생성
-6. 스프린트 로드맵으로 PROJECT_MANIFEST 업데이트
-7. 스프린트 일관성과 종속성 검증
-8. 마일스톤 계획 보고
-
----
-
-## 1 · 현재 마일스톤 상태 분석
-
-**치명적:** 추가 인수가 제공됩니다: <$ARGUMENTS>
-
-**병렬 서브에이전트 사용**하여 다음 태스크 수행:
-
-- 마일스톤 ID에 대한 인수 파싱 (PROJECT_MANIFEST의 현재 마일스톤이 기본값)
-- 현재 진행 상황을 이해하기 위해 `.aiwf/00_PROJECT_MANIFEST.md` 읽기
-- 대상 마일스톤의 기존 스프린트를 식별하기 위해 `.aiwf/03_SPRINTS/` 스캔
-- 각 기존 스프린트에 대해, YAML 프론트매터에서 상태를 확인하기 위해 스프린트 메타 파일 읽기
-- 완료된 작업을 이해하기 위해 스프린트의 태스크를 분석 (서브태스크에서)
-
-## 2 · 완료된 작업과 마일스톤 요구사항 평가
-
-- `.aiwf/02_REQUIREMENTS/$MILESTONE_ID/`에서 마일스톤 메타 파일 읽기
-- **치명적:** 마일스톤 메타에서 연결된 모든 문서를 따라가며 읽기:
-  - 제품 요구사항 (PRD.md)
-  - 데이터베이스 사양 (SPECS_DB.md)
-  - API 사양 (SPECS_API.md)
-  - 도구 사양 (SPECS_TOOLS.md)
-  - 기타 연결된 사양들
-- 마일스톤의 완료 정의(DoD)를 신중히 학습하고 각 DoD 기준이 실제로 특정 결과물 측면에서 무엇을 요구하는지 **깊이 생각**하기
-- 각 기존 스프린트에 대해, 스프린트 메타와 태스크 파일을 읽어 완료된 결과물 분석
-- 격차 분석에 대해 **더 신중히 생각하기**: 완료된 각 결과물을 특정 DoD 요구사항에 대응시키고 진정으로 누락된 것과 이미 다뤄진 것을 식별
-- 명확한 그림 생성: "완료된 것 vs 마일스톤 완성을 위해 필요한 것"에 대해 식별된 각 격차에 대한 구체적 근거 제시
-
-## 3 · 남은 작업과 종속성 식별
-
-- 격차 분석을 바탕으로, 마일스톤 완성을 위한 남은 결과물 식별
-- 자연스러운 종속성을 가진 관련 결과물을 그룹화
-- **치명적:** 각 결과물 그룹은 다음과 같아야 함:
-  - **독립적으로 가치 있음** (배포 가능한 증분)
-  - **한 사람이 ~1주일 내에 완료 가능**
-  - **명확한 검증 기준 보유**
-- 기술적 종속성 고려 (예: UI 전에 인증, 도구 전에 LLM 통합)
-
-## 4 · 논리적 스프린트 경계 설계
-
-- 마일스톤을 완성하기 위한 스프린트 구조 설계
-- 각 스프린트는 다음을 보유해야 함:
-  - **명확한 집중점**: 하나의 주요 결과물 테마
-  - **자연스러운 경계**: 스프린트 간 최소한의 종속성
-  - **점진적 가치**: 각 스프린트가 마일스톤 DoD를 향해 전진
-- 스프린트 명명: `S<nn>_$milestone_id_$focus_slug`
-- **중요:** 이미 완료된 작업에 대한 스프린트를 생성하지 마세요
-
-## 5 · 스프린트 디렉토리와 메타 파일 생성
-
-- 존재하지 않는 각 계획된 스프린트에 대해:
-  - 디렉토리 생성 `.aiwf/03_SPRINTS/$FULL_SPRINT_NAME/` ("S02_M01_LLM_Integration"과 같은 완전한 스프린트 이름 사용)
-  - `.aiwf/99_TEMPLATES/sprint_meta_template.md`에서 템플릿 사용
-  - 스프린트 메타를 다음으로 채우기:
-    - 고수준 목표와 범위
-    - 주요 결과물 (자세한 태스크가 아닌 불릿 포인트)
-    - 스프린트에 대한 명확한 완료 정의
-    - 상태: "planned"
-
-## 6 · 스프린트 로드맵으로 PROJECT_MANIFEST 업데이트
-
-- `.aiwf/00_PROJECT_MANIFEST.md` 업데이트:
-  - `highest_sprint_in_milestone`을 계획된 가장 높은 스프린트로 설정
-  - 남은 스프린트의 개요로 스프린트 요약 섹션 업데이트
-  - 완료된 스프린트를 ✅ COMPLETED로 표시
-  - 계획된 스프린트를 그들의 집중 영역과 함께 표시
-  - `last_updated` 타임스탬프 업데이트
-
-## 7 · 스프린트 일관성과 종속성 검증
-
-- 논리적 흐름을 위해 계획된 스프린트 순서 검토
-- 각 스프린트가 이전 작업을 자연스럽게 구축하는지 확인
-- 불가능한 종속성을 가진 스프린트가 없는지 확인
-- 스프린트 순서가 마일스톤 DoD 완성으로 이어지는지 확인
-- 각 스프린트가 독립적으로 테스트 가능하고 가치 있는지 **생각하기**
-
-## 8 · 마일스톤 계획 보고
-
-포괄적인 요약 제공:
-
-**마일스톤 상태:**
-
-- 대상 마일스톤: $milestone_id
-- 완료된 스프린트: $count
-- 계획된 스프린트: $count
-- 예상 완료: $sprint_sequence
-
-**스프린트 로드맵:**
-
-각 스프린트에 대해 (기존 및 계획된):
-
-- **$Sprint_ID**: $status - $focus_description
-- 주요 결과물: $bullet_list
-- 종속성: $if_any
-
-**다음 단계:**
-
-- 상세화할 즉시 다음 스프린트: $sprint_id
-
-**검증:**
-
-다음을 포함한 검증 분석 요약:
-
-- 모든 마일스톤 DoD 항목이 스프린트 계획에 포함됨
-- 스프린트 종속성이 논리적이고 최소한임
-- 각 스프린트가 독립적인 가치를 제공함

package/.claude/commands/aiwf/aiwf_default_mode.md

@@ -1,44 +0,0 @@
-# 기본 모드로 복원
-
-AI를 기본 모드로 복원합니다.
-
-```bash
-cd .aiwf && node ../claude-code/aiwf/ko/commands/ai-persona.js default
-```
-
-## 설명
-이 명령어는 현재 활성화된 페르소나를 비활성화하고 AI를 기본 범용 모드로 복원합니다.
-
-## 동작
-- 현재 페르소나 비활성화
-- 페르소나별 컨텍스트 규칙 해제
-- 기본 AI 동작 모드로 전환
-- 세션 통계 저장
-
-## 사용 시나리오
-- 특정 페르소나가 더 이상 필요하지 않을 때
-- 일반적인 개발 작업으로 돌아갈 때
-- 다른 페르소나로 전환하기 전
-- 페르소나 관련 문제 해결 시
-
-## 출력 예시
-```
-🎭 페르소나 모드 해제
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-이전 페르소나: [페르소나명]
-세션 시간: [시간]
-기본 모드로 복원되었습니다.
-```
-
-## 참고사항
-- 페르소나 세션 통계는 자동으로 저장됩니다
-- 언제든지 다른 페르소나를 활성화할 수 있습니다
-- 기본 모드에서도 모든 AI 기능을 사용할 수 있습니다
-
-## 관련 명령어
-- `/project:aiwf:persona_status` - 페르소나 상태 확인
-- `/project:aiwf:architect` - Architect 페르소나 활성화
-- `/project:aiwf:security` - Security 페르소나 활성화
-- `/project:aiwf:frontend` - Frontend 페르소나 활성화
-- `/project:aiwf:backend` - Backend 페르소나 활성화
-- `/project:aiwf:data_analyst` - Data Analyst 페르소나 활성화

package/.claude/commands/aiwf/aiwf_discuss_review.md

@@ -1,29 +0,0 @@
-# 리뷰 결과 논의
-
-Engage in technical discussion about recent review findings based on discussion starter.
-
-Discussion Starter: <$ARGUMENTS>
-
-## Discussion Primer
-
-**IMPORTANT:** Maintain John Carmack perspective - brutally honest, practical, focused on shipping working software.
-
-### Discussion Tone
-
-- **Be conversational** but maintain technical depth
-- **Challenge assumptions** - question if issues are real problems for current development stage
-- **Explore trade-offs** - suggest multiple approaches with pros/cons
-- **Focus on decisions** - what to do next, not just analysis
-- **Consider context** - balance technical perfection vs delivery timeline
-
-### Potential Discussion Outcomes
-
-Based on the conversation, you may suggest:
-
-- **Amending review findings** if new context changes severity/priority
-- **Updating documentation** in `.aiwf/01_PROJECT_DOCS/` if architectural decisions need clarification
-- **Revising requirements** in `.aiwf/02_REQUIREMENTS/` if scope understanding was incorrect
-- **Creating tasks** for specific technical debt items that need addressing
-- **Adjusting sprint priorities** based on refined understanding
-
-**IMPORTANT:** Help make practical engineering decisions. Be John Carmack: direct, experienced, and focused on what actually matters for shipping.