aiwf 0.3.7 → 0.3.12

package/.claude/commands/aiwf/aiwf_add_task_to_sprint.md

@@ -1,283 +0,0 @@
-# 스프린트에 태스크 추가
-
-기존 스프린트에 새로운 개별 태스크를 추가합니다.
-
-## 사용법
-
-```
-/aiwf:add_task_to_sprint <스프린트ID> <태스크 제목>
-```
-
-예시:
-- `/aiwf:add_task_to_sprint S03 "API 성능 최적화"`
-- `/aiwf:add_task_to_sprint S03 "데이터베이스 인덱스 추가"`
-
-## 정확히 다음 12개 항목으로 TODO 생성
-
-1. 인수 분석 및 검증
-2. 대상 스프린트 존재 확인
-3. 스프린트 컨텍스트 및 목표 심층 분석
-4. 태스크 적합성 평가 및 사용자 확인
-5. 기존 태스크 목록 확인 및 중복 검사
-6. 다음 태스크 번호 결정
-7. 태스크 상세 내용 작성
-8. 태스크 파일 생성
-9. 스프린트 메타 파일 업데이트
-10. 프로젝트 매니페스트 업데이트
-11. Git 상태 확인
-12. 최종 보고 및 다음 단계 안내
-
-## 모든 TODO 항목에 대한 세부사항
-
-### 1. 인수 분석 및 검증
-
-입력 형식: `<스프린트ID> <태스크 제목>`
-
-**검증 항목:**
-- 스프린트 ID가 제공되었는지 확인 (예: S01, S02, S03)
-- 태스크 제목이 제공되었는지 확인
-- 태스크 제목이 따옴표로 묶여있다면 제거
-- 비어있는 경우 사용자에게 올바른 형식 요청
-
-### 2. 대상 스프린트 존재 확인
-
-**확인 단계:**
-- `.aiwf/03_SPRINTS/` 디렉토리에서 해당 스프린트 폴더 확인
-- 스프린트 메타 파일 존재 확인 (`S##_M##_sprint_meta.md`)
-- 스프린트 상태 확인 (completed가 아닌지)
-- 존재하지 않으면 오류 메시지와 함께 중단
-
-### 3. 스프린트 컨텍스트 및 목표 심층 분석
-
-**병렬 서브에이전트**를 사용하여 다음 내용을 상세히 분석:
-
-1. **스프린트 메타 파일 완전 분석**
-   - 스프린트 목표 및 범위 파악
-   - 예상 결과물(Deliverables) 확인
-   - 스프린트 성공 기준 이해
-   - 현재 진행 상황 및 남은 작업 파악
-
-2. **마일스톤 컨텍스트 확인**
-   - 관련 마일스톤 파일에서 상위 목표 확인
-   - 마일스톤 성공 기준과의 정렬성 검토
-   - 다른 스프린트와의 연관성 파악
-
-3. **기술적 제약사항 검토**
-   - `.aiwf/01_PROJECT_DOCS/ARCHITECTURE.md` 분석
-   - `.aiwf/05_ARCHITECTURAL_DECISIONS/` ADR 확인
-   - 기존 기술 스택 및 패턴 이해
-
-4. **분석 결과 정리**
-   - 스프린트의 핵심 목표 3-5개 도출
-   - 허용되는 작업 범위 명확화
-   - 제외되어야 할 작업 유형 식별
-
-### 4. 태스크 적합성 평가 및 사용자 확인
-
-**태스크 적합성 심층 평가:**
-
-1. **스프린트 목표와의 정렬성 검사**
-   - 제안된 태스크가 스프린트 목표에 직접적으로 기여하는가?
-   - 스프린트 범위를 벗어나지 않는가?
-   - 마일스톤 목표와 일치하는가?
-
-2. **기존 태스크와의 관계 분석**
-   - 중복되는 태스크가 있는가?
-   - 다른 태스크와 충돌하거나 상충되는가?
-   - 선행 태스크가 필요한가?
-
-3. **우선순위 및 복잡도 평가**
-   - 현재 스프린트 내에서 완료 가능한가?
-   - 다른 태스크보다 우선순위가 높은가?
-   - 예상 작업량이 적절한가?
-
-4. **사용자에게 분석 결과 제시**
-   ```
-   📊 태스크 적합성 분석 결과:
-   
-   🎯 스프린트 목표: [스프린트 핵심 목표]
-   📋 제안된 태스크: [태스크 제목]
-   
-   ✅ 적합성 평가:
-   - 목표 정렬성: [상/중/하] - [이유]
-   - 범위 적절성: [적합/경계/벗어남] - [설명]
-   - 우선순위: [높음/보통/낮음] - [근거]
-   - 예상 복잡도: [낮음/보통/높음]
-   
-   🔍 관련 태스크:
-   - [기존 태스크 목록 중 관련된 것들]
-   
-   💡 권장사항:
-   [태스크 추가를 권장하는지, 수정이 필요한지, 다른 스프린트가 적합한지 등]
-   
-   계속 진행하시겠습니까? (Y/N)
-   ```
-
-5. **사용자 확인 처리**
-   - Y: 태스크 추가 진행
-   - N: 취소하고 대안 제시
-   - 수정 제안 시: 새로운 태스크 제목으로 재평가
-
-### 5. 기존 태스크 목록 확인 및 중복 검사
-
-**상세한 중복 및 충돌 검사:**
-- 스프린트 디렉토리 내 모든 태스크 파일 스캔
-- 제목 및 내용 기반 유사도 검사
-- 기능적 중복 여부 확인
-- 관련 태스크 그룹핑 제안
-
-### 6. 다음 태스크 번호 결정
-
-**태스크 번호 할당:**
-- 기존 태스크 번호 파악
-- 순차적 번호 할당 (T01, T02...)
-- 파일명 형식: `T##_S##_<제목_언더스코어>.md`
-
-### 7. 태스크 상세 내용 작성
-
-**스프린트 분석 결과를 바탕으로 태스크 내용 구체화:**
-
-1. **태스크 개요 작성**
-   - 스프린트 목표와의 연관성 명시
-   - 구체적인 작업 범위 정의
-   - 예상 결과물 설명
-
-2. **요구사항 도출**
-   - 스프린트 목표에서 파생된 구체적 요구사항
-   - 기술적 제약사항 반영
-   - 측정 가능한 완료 조건
-
-3. **기술 가이드라인 구체화**
-   - 관련 ADR 참조
-   - 사용해야 할 기존 패턴/컴포넌트
-   - 준수해야 할 코딩 표준
-
-4. **구현 전략 수립**
-   - 단계별 구현 접근법
-   - 예상되는 기술적 도전과제
-   - 리스크 및 대응 방안
-
-### 8. 태스크 파일 생성
-
-**파일 위치:** `.aiwf/03_SPRINTS/S##_M##_<name>/T##_S##_<title>.md`
-
-**내용 포함:**
-```markdown
-# T##: [태스크 제목]
-
-**스프린트**: S## - [스프린트 이름]
-**생성일**: YYYY-MM-DD HH:MM
-**상태**: pending
-**우선순위**: medium
-**예상 시간**: TBD
-
-## 개요
-[태스크에 대한 간단한 설명]
-
-## 요구사항
-- [ ] [구체적인 요구사항 1]
-- [ ] [구체적인 요구사항 2]
-- [ ] [구체적인 요구사항 3]
-
-## 승인 기준
-- [ ] [완료 조건 1]
-- [ ] [완료 조건 2]
-- [ ] [완료 조건 3]
-
-## 기술 가이드라인
-- [관련 아키텍처 결정 참조]
-- [기존 코드베이스 패턴 참조]
-- [사용할 기술 스택]
-
-## 구현 노트
-- [구현 시 고려사항]
-- [잠재적 리스크]
-- [테스트 전략]
-
-## 참조
-- [관련 문서나 코드 링크]
-```
-
-### 9. 스프린트 메타 파일 업데이트
-
-스프린트 메타 파일의 태스크 섹션 업데이트:
-- 새로운 태스크를 목록에 추가
-- 전체 태스크 수 업데이트
-- 진행률은 그대로 유지 (새 태스크는 pending)
-
-### 10. 프로젝트 매니페스트 업데이트
-
-`.aiwf/00_PROJECT_MANIFEST.md` 업데이트:
-- "활성 태스크" 섹션에 새 태스크 추가
-- 태스크 통계 업데이트
-- 최종 업데이트 시간 변경
-
-### 11. Git 상태 확인
-
-**확인 사항:**
-- 작업 디렉토리가 깨끗한지 확인
-- 새로 생성된 파일 표시
-- 수정된 파일 목록 제공
-
-### 12. 최종 보고 및 다음 단계 안내
-
-**상세한 보고서 제공:**
-```
-✅ 태스크 추가 완료!
-
-📊 태스크 분석 요약:
-- 스프린트 정렬성: [평가 결과]
-- 우선순위: [설정된 우선순위]
-- 예상 복잡도: [복잡도]
-- 관련 태스크: [연관 태스크 목록]
-
-📄 생성된 파일: T##_S##_<title>.md
-🏃 스프린트: S## - [스프린트 이름]
-📋 태스크: T## - [태스크 제목]
-⏱️ 상태: pending
-
-📝 다음 단계:
-1. 태스크 파일을 열어 생성된 내용 검토
-2. 필요시 세부사항 추가 작성
-3. `/aiwf:do_task T##`로 작업 시작
-4. 완료 후 `/aiwf:update_task_status T## completed` 실행
-
-💡 팁: 
-- 태스크 목록 확인: `/aiwf:list_sprint_tasks S##`
-- 태스크 상세 보기: `/aiwf:view_task T##`
-- 관련 태스크 확인: [관련 태스크 번호들]
-```
-
-**출력 형식:**
-```
-✅ 태스크 추가 완료!
-
-📄 생성된 파일: T##_S##_<title>.md
-🏃 스프린트: S## - [스프린트 이름]
-📋 태스크: T## - [태스크 제목]
-⏱️ 상태: pending
-
-📝 다음 단계:
-1. 태스크 파일을 열어 세부사항 작성
-2. `/aiwf:do_task T##`로 작업 시작
-3. 완료 후 `/aiwf:update_task_status T## completed` 실행
-
-💡 팁: 태스크 목록 확인은 `/aiwf:list_sprint_tasks S##`
-```
-
-## 주의사항
-
-- **스프린트 적합성**: 태스크가 스프린트 목표에 부합하는지 반드시 검증
-- **중복 방지**: 기존 태스크와의 중복 또는 충돌 확인
-- **범위 관리**: 스프린트 범위를 벗어나는 태스크는 다른 스프린트로 안내
-- **완료 가능성**: 현재 스프린트 기간 내 완료 가능한 작업인지 평가
-- **의존성 확인**: 다른 태스크와의 의존 관계 파악 및 명시
-- **품질 기준**: 태스크 설명은 구체적이고 측정 가능해야 함
-
-## 분석 중심 접근법의 이점
-
-1. **목표 정렬**: 모든 태스크가 스프린트 목표에 직접 기여
-2. **중복 방지**: 유사하거나 중복된 작업 사전 차단
-3. **품질 향상**: 상세한 분석으로 태스크 품질 개선
-4. **시간 절약**: 부적절한 태스크로 인한 재작업 방지
-5. **투명성**: 태스크 추가 근거와 맥락 명확화

package/.claude/commands/aiwf/aiwf_changelog.md

@@ -1,82 +0,0 @@
-# Git 커밋 히스토리 기반 Changelog 자동 생성
-
-Git 커밋 히스토리를 분석하여 체계적인 changelog를 생성합니다.
-
-## 작업 단계
-
-### 1. Git 히스토리 분석
-- 최근 커밋들을 분석하여 변경사항 파악
-- 태그 정보 확인 (있는 경우)
-- 커밋 메시지에서 conventional commit 형식 파싱
-
-### 2. 변경사항 분류
-다음 카테고리로 커밋들을 분류:
-- ✨ Features (feat)
-- 🐛 Bug Fixes (fix)
-- 📝 Documentation (docs)
-- 🎨 Code Style (style)
-- ♻️ Refactoring (refactor)
-- ⚡ Performance (perf)
-- ✅ Tests (test)
-- 🔧 Build/Config (build, chore)
-
-### 3. Changelog 생성
-- CHANGELOG.md 파일 생성 또는 업데이트
-- 버전별로 섹션 구분 (태그 기반)
-- 각 카테고리별로 변경사항 정리
-- 커밋 SHA와 함께 표시
-
-### 4. 실행 방법
-```bash
-# 기본 실행 (전체 히스토리)
-/project:aiwf:changelog
-
-# 특정 커밋 범위 지정
-/project:aiwf:changelog v1.0.0..HEAD
-
-# 특정 개수의 최근 커밋
-/project:aiwf:changelog -n 50
-```
-
-### 5. 생성 예시
-```markdown
-# Changelog
-
-## [Unreleased]
-
-### ✨ Features
-- feat(auth): 소셜 로그인 기능 추가 (abc1234)
-- feat(api): RESTful API v2 구현 (def5678)
-
-### 🐛 Bug Fixes
-- fix(ui): 모바일 반응형 레이아웃 수정 (ghi9012)
-
-### 📝 Documentation
-- docs(readme): 설치 가이드 업데이트 (jkl3456)
-```
-
-## 구현 내용
-
-1. Git 로그 파싱:
-```bash
-git log --pretty=format:"%h|%s|%an|%ad" --date=short
-```
-
-2. Conventional Commit 패턴 매칭:
-```regex
-^(feat|fix|docs|style|refactor|perf|test|build|chore)(\(.+\))?:\s+(.+)$
-```
-
-3. 태그 정보 활용:
-```bash
-git describe --tags --abbrev=0
-```
-
-4. Changelog 템플릿 적용 및 파일 생성
-
-5. 기존 CHANGELOG.md가 있는 경우 적절히 병합
-
-## 주의사항
-- Conventional Commit 형식을 따르지 않는 커밋은 "기타 변경사항"으로 분류
-- 병합 커밋은 기본적으로 제외
-- 생성된 changelog는 검토 후 수동 편집 가능

package/.claude/commands/aiwf/aiwf_code_review.md

@@ -1,88 +0,0 @@
-# 코드 리뷰 - 위에서 아래로 실행
-
-코드 리뷰를 실행하기 위해 다음 지침을 위에서 아래로 사용하세요.
-
-## 정확히 다음 6개 항목으로 할 일 목록을 만드세요
-
-1. 주어진 범위 분석
-2. 범위 내에서 코드 변경사항 찾기
-3. 관련 사양 및 문서 찾기
-4. 문서 및 요구사항과 코드 변경사항 비교
-5. 가능한 차이점 분석
-6. 세부사항과 함께 통과/실패 판정 제공
-
-각 단계를 단계별로 따르고 다음 지침을 엄격히 준수하세요.
-
-## 모든 할 일 목록 항목에 대한 세부사항
-
-### 1. 주어진 범위 분석
-
-확인: <$ARGUMENTS>
-
-비어있으면 기본값을 사용하고, 그렇지 않으면 <$ARGUMENTS>를 해석하여 리뷰 범위를 식별합니다. 리뷰할 의미 있는 변경사항을 찾을 수 있는 경우에만 계속합니다.
-
-**맥락:** 코드 변경사항을 리뷰하기 전에:
-
-- `.aiwf/00_PROJECT_MANIFEST.md`를 읽어 현재 스프린트와 마일스톤 맥락을 이해합니다
-- 매니페스트를 사용하여 어떤 스프린트가 활성이고 어떤 작업이 범위에 있는지 식별합니다
-- 현재 스프린트의 납품에 적절한 요구사항에만 평가합니다
-
-### 2. 범위 내에서 코드 변경사항 찾기
-
-식별된 범위를 사용하여 `git diff` (기본값: `git diff HEAD~1`)로 코드 변경사항을 찾습니다.
-
-### 3. 관련 사양 및 문서 찾기
-
-- 수행된 작업에 관련된 태스크, 스프린트, 마일스톤을 찾고 발견사항을 출력합니다
-- `.aiwf/03_SPRINTS/`로 이동하여 현재 스프린트 디렉토리를 찾습니다
-- 스프린트 매타 파일을 읽어 스프린트 목표와 납품을 이해합니다
-- 특정 태스크가 범위에 있는 경우, 스프린트 디렉토리에서 태스크 파일을 찾아 읽습니다
-- 현재 마일스톤에 대한 `.aiwf/02_REQUIREMENTS/`에서 관련 요구사항을 식별합니다
-- 관련 문서, 특히 `.aiwf/01_PROJECT_DOCS/`와 `.aiwf/02_REQUIREMENTS/`에서 문서를 읽습니다
-- **중요:** 미래 마일스톤 기능이 아닌 현재 스프린트 납품에만 집중합니다
-
-### 4. 문서 및 요구사항과 코드 변경사항 비교
-
-- 발견된 요구사항과 사양에 대해 변경사항을 비교하기 위해 심층 사고를 사용합니다
-- 특히 다음 사항들을 비교합니다:
-  - **데이터 모델 / 스키마** — 필드, 타입, 제약사항, 관계
-  - **API / 인터페이스** — 엔드포인트, 매개변수, 반환 형태, 상태 코드, 오류
-  - **설정 / 환경** — 키, 기본값, 필수/선택사항
-  - **동작** — 비즈니스 규칙, 부작용, 오류 처리
-  - **품질** — 이름, 형식, 테스트, 린터 상태
-
-**중요:**
-
-- 사양에서 벗어나는 것은 허용되지 않습니다. 작은 것도 안 됩니다. 여기서는 매우 까다롭게 마세요!
-- 의심스러우면 **실패**를 선언하고 사용자에게 문의하세요
-- 사양과 문서를 따르지 않는 것에 대해 무관용입니다
-
-### 5. 차이점 분석
-
-- 발견된 모든 차이점을 분석합니다
-- 모든 문제에 심각도 점수를 부여합니다
-- 심각도는 1(낮음)에서 10(높음)까지입니다
-- 출력을 위해 문제 목록과 점수를 기억합니다
-
-### 6. 세부사항과 함께 통과/실패 판정 제공
-
-- 발견된 모든 차이점에 대해 **실패**를 선언합니다
-  - 무관용 - 선의의 추가사항에도 적용됩니다
-  - 작은 변경사항이 허용되는지 여부는 사용자가 결정하도록 합니다
-- 불일치가 나타나지 않은 경우에만 **통과**입니다
-
-#### 중요: 출력 형식
-
-- 리뷰 결과를 태스크 파일의 **## 출력 로그** 섹션에 출력합니다
-- 범위에 따라 `.aiwf/03_SPRINTS/` 또는 `.aiwf/04_GENERAL_TASKS/`에서 태스크 파일을 찾습니다
-- 타임스탬프와 함께 기존 출력 로그에 리뷰 결과를 추가합니다
-- 출력 형식:
-  ```
-  [YYYY-MM-DD HH:MM]: 코드 리뷰 - 통과/실패
-  결과: **실패/통과** 통과인지 실패인지에 대한 최종 결정
-  **범위:** 리뷰 범위에 대해 사용자에게 알립니다
-  **발견사항:** 발견된 모든 문제와 심각도 점수의 상세 목록
-  **요약:** 문제점이나 문제가 없는 상태에 대한 간단한 요약
-  **권장사항:** 추가 단계에 대한 개인적인 권장사항
-  ```
-- 또한 즉시 피드백을 위해 콘솔에 간단한 결과 요약을 출력합니다

package/.claude/commands/aiwf/aiwf_commit.md

@@ -1,160 +0,0 @@
-# 변경사항 분석 및 사용자 확인을 통한 논리적 git 커밋 생성
-
-다음 지시사항을 위에서 아래로 순서대로 따르세요.
-
-## 정확히 다음 6개 항목으로 TODO 생성
-
-1. 인수 파싱 및 git 상태 분석
-2. 변경사항 검토 및 논리적 커밋별 그룹화
-3. 커밋 구조 및 메시지 제안
-4. 사용자 승인 필요 여부 확인
-5. 승인된 커밋 실행
-6. 커밋 결과 보고
-
----
-
-## 1 · git 상태 분석 및 인수 파싱
-
-- 최대 효율성을 위해 다음 명령어들을 병렬 실행: `git status`, `git diff --staged`, `git diff`
-- 범위를 이해하기 위해 폴더 구조와 함께 모든 변경된 파일 나열
-
-### 중요: 인수 해석 규칙
-
-**컨텍스트 제공됨** (<$ARGUMENTS>에 텍스트가 포함된 경우):
-
-- YOLO가 <$ARGUMENTS>의 일부라면 사용자 승인을 건너뛰는 것을 의미 (Todo의 4단계 참조)
-- <$ARGUMENTS>의 다른 텍스트는 사용자가 제공한 **태스크 ID**, **스프린트 ID**, 또는 기타 **컨텍스트 식별자**를 나타냄
-- 이것은 파일 경로가 아니라 변경사항을 필터링하기 위한 의미적 컨텍스트임
-- **주요 초점**: 이 컨텍스트와 직접 관련된 파일만 커밋
-- **부차적 고려사항**: 주요 컨텍스트 처리 후, 사용자가 관련 없는 다른 변경사항을 커밋하고 싶은지 묻기
-
-**태스크 ID 패턴** (예: T01_S02, TX03_S01, T003):
-
-- 스프린트 태스크: `T<NN>_S<NN>` 형식 (예: T01_S02, T03_S02)
-- 완료된 스프린트 태스크: `TX<NN>_S<NN>` 형식 (예: TX01_S02, TX03_S01)
-- 일반 태스크: `T<NNN>` 형식 (예: T001, T002)
-- 완료된 일반 태스크: `TX<NNN>` 형식 (예: TX001, TX002)
-- 다음 위치에서 이 태스크 ID를 검색:
-  - `.aiwf/03_SPRINTS/` 디렉토리 (스프린트 태스크용)
-  - `.aiwf/04_GENERAL_TASKS/` 디렉토리 (일반 태스크용)
-  - 파일의 태스크 메타데이터 (frontmatter에서 `task_id: T01_S02` 찾기)
-  - Git diff 내용 (코드 주석이나 커밋이 태스크를 참조하는지 확인)
-- 이 태스크 구현의 일부로 수정된 모든 파일 식별
-- 여기에는 다음이 포함: 소스 코드, 테스트, 구성, 그리고 태스크 문서 파일 자체
-
-**스프린트 ID 패턴** (예: S01, S02):
-
-- 스프린트 ID만 제공된 경우, 해당 스프린트 내의 모든 태스크와 관련된 변경사항을 커밋
-- 검색 패턴: 스프린트 디렉토리의 `T*_S<NN>`
-- 예시: "S02"는 T01_S02, T02_S02, T03_S02 등의 변경사항을 포함
-
-**컨텍스트 제공되지 않음** (<$ARGUMENTS>가 비어있는 경우):
-
-- 모든 변경사항을 분석하고 논리적으로 그룹화
-- 서로 다른 논리적 작업 단위에 대해 별도 커밋 제안
-
-### 구현 단계
-
-1. 먼저 <$ARGUMENTS>에 텍스트가 포함되어 있는지 확인
-2. 포함되어 있다면 명시적으로 기술: "컨텍스트 제공됨: '$ARGUMENTS' - 이 컨텍스트와 관련된 변경사항에 집중하겠습니다"
-3. 태스크 ID 패턴인 경우, 태스크 파일을 찾아서 구현된 내용 이해
-4. 식별된 컨텍스트와 관련된 파일들로만 변경된 파일들을 필터링
-5. 컨텍스트와 일치하는 파일이 없으면 사용자에게 알림: "'$ARGUMENTS'와 관련된 변경사항을 찾을 수 없습니다"
-6. 관련 없는 변경사항이 존재하면 언급하되 초기 커밋 제안에는 포함하지 않음
-
-## 2 · 변경사항 검토 및 논리적 커밋별 그룹화
-
-### 우선순위: 컨텍스트 필터링
-
-**인수에 컨텍스트가 제공된 경우**:
-
-1. **먼저 필터링**: 변경사항을 두 그룹으로 분리:
-   - **컨텍스트와 관련**: 태스크/컨텍스트 구현의 일부인 파일들
-   - **컨텍스트와 무관**: 그 외 모든 것
-2. **집중**: 첫 번째 커밋에서는 "컨텍스트와 관련" 그룹만 분석
-3. **연기**: 잠재적인 후속 커밋을 위해 "무관" 그룹 보관 (사용자가 요청하는 경우에만)
-
-**표준 그룹화 로직** (컨텍스트 없음 또는 컨텍스트 내 그룹화용):
-
-- **논리적으로 함께 속하는 변경사항 고민**:
-  - 태스크 완료 (해당되는 경우 태스크 ID별 그룹화)
-  - 기능 추가 (기능 범위별 그룹화)
-  - 구성 업데이트 (별도 그룹화)
-  - 문서 업데이트 (문서 유형별 그룹화)
-  - 버그 수정 (관련 기능별 그룹화)
-- **신중하게 고려**하여 각 커밋이 독립적으로 이해되고 잠재적으로 되돌릴 수 있는 하나의 논리적 변경을 나타내도록 보장
-- 관련 없는 변경사항을 같은 커밋에 혼합하지 않기
-- 커밋 순서를 정할 때 변경사항 간의 의존성 고려
-
-## 3 · 커밋 제안
-
-### 컨텍스트 인식 커밋 제안
-
-**컨텍스트가 제공된 경우** (예: 태스크 ID):
-
-- **첫 번째 커밋**: 제공된 컨텍스트와 관련된 파일만 포함해야 함
-- 명확히 기술: "이 커밋은 $ARGUMENTS에 대한 변경사항을 포함합니다"
-- 이 커밋이 완료된 후, 다음과 같이 묻기: "[파일 목록]에 관련 없는 변경사항도 있습니다. 이것들에 대해서도 추가 커밋을 생성하시겠습니까?"
-
-**컨텍스트가 제공되지 않은 경우**:
-
-- 모든 변경사항의 논리적 그룹화를 기반으로 커밋 제안
-
-생성할 다음 커밋에 대해:
-
-- **컨텍스트**: 해당되는 경우, 이 커밋이 다루는 태스크/컨텍스트
-- **파일**: 포함될 특정 파일 목록
-- **커밋 메시지**: 관례적인 커밋 형식 사용, 명확하고 간결하게
-  - **중요:** Claude, Anthropic, 또는 AI 지원에 대한 어떤 언급도 포함하지 않아야 함
-  - 태스크 관련인 경우, 메시지에 태스크 ID 포함 (예: "feat(agents): implement T01_S02 coordinator agent" 또는 "fix(api): resolve T003 authentication issue")
-  - **GitHub 이슈 연결**: 태스크에 GitHub 이슈가 있는 경우, 커밋 메시지에 `fixes #123` 또는 `relates to #456` 포함
-- **근거**: 이러한 변경사항들이 왜 함께 속하는지에 대한 간단한 설명
-
-## 4 · 사용자 승인 필요 여부 확인
-
-YOLO가 <$ARGUMENTS>의 **일부라면** 이 단계를 건너뛰고 다음 단계로 이동.
-
-그렇지 않으면 사용자 승인을 요청.
-
-- 파일과 메시지를 포함한 완전한 커밋 계획 표시
-- 진행하기 전에 명시적인 사용자 확인 대기
-- 사용자가 거부하면 무엇을 변경해야 하는지 묻기
-- 사용자가 커밋 메시지나 범위를 수정하고 싶어하면 조정
-
-## 5 · 승인된 커밋 실행 및 계속
-
-승인된 커밋에 대해:
-
-- `git add`로 지정된 파일들 스테이징
-- **중요:** pre-commit 훅을 사용하고 있어 부족한 점을 보고할 가능성이 높음. 이를 수정해야 함. 특히 이런 문제들을 다루는 열린 태스크가 없다면 검증을 건너뛰지 마세요.
-- 승인된 메시지로 **커밋 생성**
-- 커밋이 성공적으로 생성되었는지 확인
-- **GitHub 이슈 업데이트 (해당하는 경우):**
-  - 태스크에 연결된 GitHub 이슈가 있는 경우
-  - 이슈에 커밋 링크 댓글 추가:
-    ```bash
-    gh issue comment {issue_number} --body "🔗 Commit: {commit_sha} - {commit_message}"
-    ```
-- **중요:** 남은 커밋이 더 있다면 다음 커밋을 위해 3단계로 돌아가기
-- 모든 커밋이 완료된 경우에만 6단계로 진행
-
-## 6 · 커밋 결과 보고
-
-요약 제공:
-
-- **생성된 커밋**: SHA와 메시지와 함께 각 커밋 나열
-- **커밋된 파일**: 커밋된 파일의 총 개수
-- **남은 변경사항**: 아직 커밋되지 않은 대기 중인 변경사항
-- **저장소 상태**: 커밋 후 현재 git 상태
-
-## 7 · 변경 로그 생성 (선택사항)
-
-성공적인 커밋 후:
-
-- 사용자에게 묻기: "커밋이 완료되었습니다. Changelog를 업데이트하시겠습니까? (y/n)"
-- yes인 경우 실행: `/project:aiwf:changelog`
-- 이는 다음을 수행:
-  - 최근 커밋 히스토리 분석
-  - CHANGELOG.md 생성 또는 업데이트
-  - 유형별 변경사항 분류 (feat, fix, docs 등)
-  - 방금 생성된 커밋들 포함

package/.claude/commands/aiwf/aiwf_compress_aggressive_persona.md

@@ -1,53 +0,0 @@
-# aiwf compress-aggressive-persona
-
-활성화된 페르소나를 고려하여 공격적 모드로 컨텍스트를 압축합니다.
-
-## 실행
-
-```javascript
-const { spawn } = require('child_process');
-const path = require('path');
-
-// .aiwf 디렉토리로 이동하여 명령 실행
-const cwd = path.join(process.cwd(), '.aiwf');
-const proc = spawn('node', [
-  '../claude-code/aiwf/ko/commands/compress-context.js',
-  'aggressive',
-  '--persona'
-], { cwd, stdio: 'inherit' });
-
-proc.on('error', (err) => {
-  console.error('명령 실행 실패:', err.message);
-});
-```
-
-## 설명
-
-페르소나 특성을 고려하면서도 50-70%의 높은 압축률을 목표로 합니다. 페르소나 관련 핵심 정보는 보존하되, 나머지는 적극적으로 요약합니다.
-
-### 특징
-
-- 페르소나 중심 요약 생성
-- 핵심 패턴만 보존
-- 중요도가 낮은 섹션은 요약으로 대체
-- 페르소나별 summarization focus 적용
-
-## 압축 결과
-
-압축 후 페르소나별 요약이 문서 하단에 추가됩니다:
-
-```markdown
----
-### [페르소나명] 관점 요약
-
-주요 내용 ([페르소나의 focus]):
-- 핵심 포인트 1
-- 핵심 포인트 2
-- ...
----
-```
-
-## 주의사항
-
-- 매우 높은 압축률로 인해 일부 세부 정보가 손실될 수 있습니다
-- 중요한 문서는 백업 후 사용을 권장합니다