aiwf 0.3.0 → 0.3.1

package/claude-code/aiwf/ko/.claude/commands/aiwf/aiwf_code_review.md

@@ -1,88 +1,88 @@
-# 코드 리뷰 - 탑 다운 실행
+# 코드 리뷰 - 위에서 아래로 실행
 
-Use the following instructions from top to bottom to execute a Code Review.
+코드 리뷰를 실행하기 위해 다음 지침을 위에서 아래로 사용하세요.
 
-## Create a TODO with EXACTLY these 6 Items
+## 정확히 다음 6개 항목으로 할 일 목록을 만드세요
 
-1. Analyze the Scope given
-2. Find code changes within Scope
-3. Find relevant Specification and Documentation
-4. Compare code changes against Documentation and Requirements
-5. Analyze possible differences
-6. Provide PASS/FAIL verdict with details
+1. 주어진 범위 분석
+2. 범위 내에서 코드 변경사항 찾기
+3. 관련 사양 및 문서 찾기
+4. 문서 및 요구사항과 코드 변경사항 비교
+5. 가능한 차이점 분석
+6. 세부사항과 함께 통과/실패 판정 제공
 
-Follow step by step and adhere closely to the following instructions for each step.
+각 단계를 단계별로 따르고 다음 지침을 엄격히 준수하세요.
 
-## DETAILS on every TODO item
+## 모든 할 일 목록 항목에 대한 세부사항
 
-### 1. Analyze the Scope given
+### 1. 주어진 범위 분석
 
-check: <$ARGUMENTS>
+확인: <$ARGUMENTS>
 
-If empty, use default, otherwise interpret <$ARGUMENTS> to identify the scope of the Review. Only continue if you can find meaningful changes to review.
+비어있으면 기본값을 사용하고, 그렇지 않으면 <$ARGUMENTS>를 해석하여 리뷰 범위를 식별합니다. 리뷰할 의미 있는 변경사항을 찾을 수 있는 경우에만 계속합니다.
 
-**CONTEXT:** Before reviewing code changes:
+**맥락:** 코드 변경사항을 리뷰하기 전에:
 
-- Read `.aiwf/00_PROJECT_MANIFEST.md` to understand current sprint and milestone context
-- Use the manifest to identify which sprint is active and what work is in scope
-- Only evaluate against requirements appropriate for the current sprint's deliverables
+- `.aiwf/00_PROJECT_MANIFEST.md`를 읽어 현재 스프린트와 마일스톤 맥락을 이해합니다
+- 매니페스트를 사용하여 어떤 스프린트가 활성이고 어떤 작업이 범위에 있는지 식별합니다
+- 현재 스프린트의 납품에 적절한 요구사항에만 평가합니다
 
-### 2. Find code changes within Scope
+### 2. 범위 내에서 코드 변경사항 찾기
 
-With the identified Scope use `git diff` (on default: `git diff HEAD~1`) to find code changes.
+식별된 범위를 사용하여 `git diff` (기본값: `git diff HEAD~1`)로 코드 변경사항을 찾습니다.
 
-### 3. Find relevant Specifications and Documentation
+### 3. 관련 사양 및 문서 찾기
 
-- FIND the Task, Sprint and Milestone involved in the work that was done and output your findings
-- Navigate to `.aiwf/03_SPRINTS/` to find the current sprint directory
-- READ the sprint meta file to understand sprint objectives and deliverables
-- If a specific task is in scope, find and READ the task file in the sprint directory
-- IDENTIFY related requirements in `.aiwf/02_REQUIREMENTS/` for the current milestone
-- READ involved Documents especially in `.aiwf/01_PROJECT_DOCS/` and `.aiwf/02_REQUIREMENTS/`
-- **IMPORTANT:** Focus on current sprint deliverables, not future milestone features
+- 수행된 작업에 관련된 태스크, 스프린트, 마일스톤을 찾고 발견사항을 출력합니다
+- `.aiwf/03_SPRINTS/`로 이동하여 현재 스프린트 디렉토리를 찾습니다
+- 스프린트 매타 파일을 읽어 스프린트 목표와 납품을 이해합니다
+- 특정 태스크가 범위에 있는 경우, 스프린트 디렉토리에서 태스크 파일을 찾아 읽습니다
+- 현재 마일스톤에 대한 `.aiwf/02_REQUIREMENTS/`에서 관련 요구사항을 식별합니다
+- 관련 문서, 특히 `.aiwf/01_PROJECT_DOCS/`와 `.aiwf/02_REQUIREMENTS/`에서 문서를 읽습니다
+- **중요:** 미래 마일스톤 기능이 아닌 현재 스프린트 납품에만 집중합니다
 
-### 4. Compare code changes against Documentation and Requirements
+### 4. 문서 및 요구사항과 코드 변경사항 비교
 
-- Use DEEP THINKING to compare changes against found Requirements and Specs.
-- Compare especially these things:
-  - **Data models / schemas** — fields, types, constraints, relationships.
-  - **APIs / interfaces** — endpoints, params, return shapes, status codes, errors.
-  - **Config / environment** — keys, defaults, required/optional.
-  - **Behaviour** — business rules, side-effects, error handling.
-  - **Quality** — naming, formatting, tests, linter status.
+- 발견된 요구사항과 사양에 대해 변경사항을 비교하기 위해 심층 사고를 사용합니다
+- 특히 다음 사항들을 비교합니다:
+  - **데이터 모델 / 스키마** — 필드, 타입, 제약사항, 관계
+  - **API / 인터페이스** — 엔드포인트, 매개변수, 반환 형태, 상태 코드, 오류
+  - **설정 / 환경** — 키, 기본값, 필수/선택사항
+  - **동작** — 비즈니스 규칙, 부작용, 오류 처리
+  - **품질** — 이름, 형식, 테스트, 린터 상태
 
-**IMPORTANT**:
+**중요:**
 
-- Deviations from the Specs is not allowed. Not even small ones. Be very picky here!
-- If in doubt call a **FAIL** and ask the User.
-- Zero tolerance on not following the Specs and Documentation.
+- 사양에서 벗어나는 것은 허용되지 않습니다. 작은 것도 안 됩니다. 여기서는 매우 까다롭게 마세요!
+- 의심스러우면 **실패**를 선언하고 사용자에게 문의하세요
+- 사양과 문서를 따르지 않는 것에 대해 무관용입니다
 
-### 5. Analyze the differences
+### 5. 차이점 분석
 
-- Analyze any difference found
-- Give every issue a Severity Score
-- Severity ranges from 1 (low) to 10 (high)
-- Remember List of issues and Scores for output
+- 발견된 모든 차이점을 분석합니다
+- 모든 문제에 심각도 점수를 부여합니다
+- 심각도는 1(낮음)에서 10(높음)까지입니다
+- 출력을 위해 문제 목록과 점수를 기억합니다
 
-### 6. Provide PASS/FAIL verdict with details
+### 6. 세부사항과 함께 통과/실패 판정 제공
 
-- Call a **FAIL** on any differences found.
-  - Zero Tolerance - even on well meant additions.
-  - Leave it on the user to decide if small changes are allowed.
-- Only **PASS** if no discrepancy appeared.
+- 발견된 모든 차이점에 대해 **실패**를 선언합니다
+  - 무관용 - 선의의 추가사항에도 적용됩니다
+  - 작은 변경사항이 허용되는지 여부는 사용자가 결정하도록 합니다
+- 불일치가 나타나지 않은 경우에만 **통과**입니다
 
-#### IMPORTANT: Output Format
+#### 중요: 출력 형식
 
-- Output the results of your review to the task's **## Output Log** section in the task file
-- Find the task file in `.aiwf/03_SPRINTS/` or `.aiwf/04_GENERAL_TASKS/` based on the scope
-- Append the review results to the existing Output Log with timestamp
-- Output Format:
+- 리뷰 결과를 태스크 파일의 **## 출력 로그** 섹션에 출력합니다
+- 범위에 따라 `.aiwf/03_SPRINTS/` 또는 `.aiwf/04_GENERAL_TASKS/`에서 태스크 파일을 찾습니다
+- 타임스탬프와 함께 기존 출력 로그에 리뷰 결과를 추가합니다
+- 출력 형식:
   ```
-  [YYYY-MM-DD HH:MM]: Code Review - PASS/FAIL
-  Result: **FAIL/PASS** Your final decision on if it's a PASS or a FAIL.
-  **Scope:** Inform the user about the review scope.
-  **Findings:** Detailed list with all Issues found and Severity Score.
-  **Summary:** Short summary on what is wrong or not.
-  **Recommendation:** Your personal recommendation on further steps.
+  [YYYY-MM-DD HH:MM]: 코드 리뷰 - 통과/실패
+  결과: **실패/통과** 통과인지 실패인지에 대한 최종 결정
+  **범위:** 리뷰 범위에 대해 사용자에게 알립니다
+  **발견사항:** 발견된 모든 문제와 심각도 점수의 상세 목록
+  **요약:** 문제점이나 문제가 없는 상태에 대한 간단한 요약
+  **권장사항:** 추가 단계에 대한 개인적인 권장사항
   ```
-- Also output a brief result summary to the console for immediate feedback
+- 또한 즉시 피드백을 위해 콘솔에 간단한 결과 요약을 출력합니다

package/claude-code/aiwf/ko/.claude/commands/aiwf/aiwf_commit.md

@@ -1,160 +1,160 @@
 # 변경사항 분석 및 사용자 확인을 통한 논리적 git 커밋 생성
 
-Follow these instructions from top to bottom.
+다음 지시사항을 위에서 아래로 순서대로 따르세요.
 
-## Create a TODO with EXACTLY these 6 items
+## 정확히 다음 6개 항목으로 TODO 생성
 
-1. Parse arguments and analyze git status
-2. Review changes and group by logical commits
-3. Propose commit structure and messages
-4. Check if user approval is necessary
-5. Execute approved commits
-6. Report commit results
+1. 인수 파싱 및 git 상태 분석
+2. 변경사항 검토 및 논리적 커밋별 그룹화
+3. 커밋 구조 및 메시지 제안
+4. 사용자 승인 필요 여부 확인
+5. 승인된 커밋 실행
+6. 커밋 결과 보고
 
 ---
 
-## 1 · Analyze git status and parse arguments
+## 1 · git 상태 분석 및 인수 파싱
 
-- Run these commands in parallel for maximum efficiency: `git status`, `git diff --staged`, `git diff`
-- List all changed files with their folder structure to understand the scope
+- 최대 효율성을 위해 다음 명령어들을 병렬 실행: `git status`, `git diff --staged`, `git diff`
+- 범위를 이해하기 위해 폴더 구조와 함께 모든 변경된 파일 나열
 
-### CRITICAL: Argument Interpretation Rules
+### 중요: 인수 해석 규칙
 
-**Context Provided** (when <$ARGUMENTS> contains text):
+**컨텍스트 제공됨** (<$ARGUMENTS>에 텍스트가 포함된 경우):
 
-- If YOLO is part of the <$ARGUMENTS> it is meant to skip user Approval (see Step 4 on your Todo)
-- The other text in <$ARGUMENTS> represents a **task ID**, **sprint ID**, or other **contextual identifier** provided by the user
-- This is NOT a file path - it's a semantic context for filtering changes
-- **PRIMARY FOCUS**: Only commit files directly related to this context
-- **SECONDARY CONSIDERATION**: After handling the primary context, ask if user wants to commit other unrelated changes
+- YOLO가 <$ARGUMENTS>의 일부라면 사용자 승인을 건너뛰는 것을 의미 (Todo의 4단계 참조)
+- <$ARGUMENTS>의 다른 텍스트는 사용자가 제공한 **태스크 ID**, **스프린트 ID**, 또는 기타 **컨텍스트 식별자**를 나타냄
+- 이것은 파일 경로가 아니라 변경사항을 필터링하기 위한 의미적 컨텍스트임
+- **주요 초점**: 이 컨텍스트와 직접 관련된 파일만 커밋
+- **부차적 고려사항**: 주요 컨텍스트 처리 후, 사용자가 관련 없는 다른 변경사항을 커밋하고 싶은지 묻기
 
-**Task ID Pattern** (e.g., T01_S02, TX03_S01, T003):
+**태스크 ID 패턴** (예: T01_S02, TX03_S01, T003):
 
-- Sprint Tasks: `T<NN>_S<NN>` format (e.g., T01_S02, T03_S02)
-- Completed Sprint Tasks: `TX<NN>_S<NN>` format (e.g., TX01_S02, TX03_S01)
-- General Tasks: `T<NNN>` format (e.g., T001, T002)
-- Completed General Tasks: `TX<NNN>` format (e.g., TX001, TX002)
-- Search for this task ID in:
-  - `.aiwf/03_SPRINTS/` directory (for sprint tasks)
-  - `.aiwf/04_GENERAL_TASKS/` directory (for general tasks)
-  - Task metadata in files (look for `task_id: T01_S02` in frontmatter)
-  - Git diff content (to see if code comments or commits reference the task)
-- Identify ALL files that were modified as part of this task's implementation
-- This includes: source code, tests, configuration, and the task documentation file itself
+- 스프린트 태스크: `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 내용 (코드 주석이나 커밋이 태스크를 참조하는지 확인)
+- 이 태스크 구현의 일부로 수정된 모든 파일 식별
+- 여기에는 다음이 포함: 소스 코드, 테스트, 구성, 그리고 태스크 문서 파일 자체
 
-**Sprint ID Pattern** (e.g., S01, S02):
+**스프린트 ID 패턴** (예: S01, S02):
 
-- When only sprint ID is provided, commit all changes related to ANY task within that sprint
-- Search pattern: `T*_S<NN>` in the sprint directory
-- Example: "S02" would include changes for T01_S02, T02_S02, T03_S02, etc.
+- 스프린트 ID만 제공된 경우, 해당 스프린트 내의 모든 태스크와 관련된 변경사항을 커밋
+- 검색 패턴: 스프린트 디렉토리의 `T*_S<NN>`
+- 예시: "S02"는 T01_S02, T02_S02, T03_S02 등의 변경사항을 포함
 
-**No Context Provided** (when <$ARGUMENTS> is empty):
+**컨텍스트 제공되지 않음** (<$ARGUMENTS>가 비어있는 경우):
 
-- Analyze all changes and group them logically
-- Propose separate commits for different logical units of work
+- 모든 변경사항을 분석하고 논리적으로 그룹화
+- 서로 다른 논리적 작업 단위에 대해 별도 커밋 제안
 
-### Implementation Steps
+### 구현 단계
 
-1. First, determine if <$ARGUMENTS> contains any text
-2. If yes, explicitly state: "Context provided: '$ARGUMENTS' - I will focus on changes related to this context"
-3. If it's a task ID pattern, find the task file and understand what was implemented
-4. Filter the changed files to only those related to the identified context
-5. If no files match the context, inform the user: "No changes found related to '$ARGUMENTS'"
-6. If unrelated changes exist, mention them but DO NOT include in initial commit proposal
+1. 먼저 <$ARGUMENTS>에 텍스트가 포함되어 있는지 확인
+2. 포함되어 있다면 명시적으로 기술: "컨텍스트 제공됨: '$ARGUMENTS' - 이 컨텍스트와 관련된 변경사항에 집중하겠습니다"
+3. 태스크 ID 패턴인 경우, 태스크 파일을 찾아서 구현된 내용 이해
+4. 식별된 컨텍스트와 관련된 파일들로만 변경된 파일들을 필터링
+5. 컨텍스트와 일치하는 파일이 없으면 사용자에게 알림: "'$ARGUMENTS'와 관련된 변경사항을 찾을 수 없습니다"
+6. 관련 없는 변경사항이 존재하면 언급하되 초기 커밋 제안에는 포함하지 않음
 
-## 2 · Review changes and group by logical commits
+## 2 · 변경사항 검토 및 논리적 커밋별 그룹화
 
-### PRIORITY: Context Filtering
+### 우선순위: 컨텍스트 필터링
 
-**If context provided in arguments**:
+**인수에 컨텍스트가 제공된 경우**:
 
-1. **FILTER FIRST**: Separate changes into two groups:
-   - **Related to context**: Files that are part of the task/context implementation
-   - **Unrelated to context**: Everything else
-2. **FOCUS**: Only analyze the "related to context" group for the first commit
-3. **DEFER**: Keep the "unrelated" group for potential later commits (only if user requests)
+1. **먼저 필터링**: 변경사항을 두 그룹으로 분리:
+   - **컨텍스트와 관련**: 태스크/컨텍스트 구현의 일부인 파일들
+   - **컨텍스트와 무관**: 그 외 모든 것
+2. **집중**: 첫 번째 커밋에서는 "컨텍스트와 관련" 그룹만 분석
+3. **연기**: 잠재적인 후속 커밋을 위해 "무관" 그룹 보관 (사용자가 요청하는 경우에만)
 
-**Standard grouping logic** (for no-context or within-context grouping):
+**표준 그룹화 로직** (컨텍스트 없음 또는 컨텍스트 내 그룹화용):
 
-- **Think about** which changes belong together logically:
-  - Task completion (group by task ID when applicable)
-  - Feature additions (group by feature scope)
-  - Configuration updates (group separately)
-  - Documentation updates (group by documentation type)
-  - Bug fixes (group by related functionality)
-- **Think carefully** to ensure each commit represents one logical change that can be understood and potentially reverted independently
-- Avoid mixing unrelated changes in the same commit
-- Consider dependencies between changes when ordering commits
+- **논리적으로 함께 속하는 변경사항 고민**:
+  - 태스크 완료 (해당되는 경우 태스크 ID별 그룹화)
+  - 기능 추가 (기능 범위별 그룹화)
+  - 구성 업데이트 (별도 그룹화)
+  - 문서 업데이트 (문서 유형별 그룹화)
+  - 버그 수정 (관련 기능별 그룹화)
+- **신중하게 고려**하여 각 커밋이 독립적으로 이해되고 잠재적으로 되돌릴 수 있는 하나의 논리적 변경을 나타내도록 보장
+- 관련 없는 변경사항을 같은 커밋에 혼합하지 않기
+- 커밋 순서를 정할 때 변경사항 간의 의존성 고려
 
-## 3 · Propose commit
+## 3 · 커밋 제안
 
-### Context-Aware Commit Proposal
+### 컨텍스트 인식 커밋 제안
 
-**When context was provided** (e.g., task ID):
+**컨텍스트가 제공된 경우** (예: 태스크 ID):
 
-- **FIRST COMMIT**: Must contain ONLY files related to the provided context
-- State clearly: "This commit includes changes for $ARGUMENTS"
-- After this commit is done, then ask: "There are also unrelated changes in [list files]. Would you like me to create additional commits for these?"
+- **첫 번째 커밋**: 제공된 컨텍스트와 관련된 파일만 포함해야 함
+- 명확히 기술: "이 커밋은 $ARGUMENTS에 대한 변경사항을 포함합니다"
+- 이 커밋이 완료된 후, 다음과 같이 묻기: "[파일 목록]에 관련 없는 변경사항도 있습니다. 이것들에 대해서도 추가 커밋을 생성하시겠습니까?"
 
-**When no context provided**:
+**컨텍스트가 제공되지 않은 경우**:
 
-- Propose commits based on logical grouping of all changes
+- 모든 변경사항의 논리적 그룹화를 기반으로 커밋 제안
 
-For the next commit to create:
+생성할 다음 커밋에 대해:
 
-- **Context**: If applicable, which task/context this commit addresses
-- **Files**: List the specific files to be included
-- **Commit message**: Use conventional commit format, be clear and concise
-  - **CRITICAL:** Must not contain any attribution to Claude, Anthropic, or AI assistance
-  - If task-related, include task ID in message (e.g., "feat(agents): implement T01_S02 coordinator agent" or "fix(api): resolve T003 authentication issue")
-  - **GitHub Issue Linking**: If task has a GitHub issue, include `fixes #123` or `relates to #456` in commit message
-- **Reasoning**: Brief explanation of why these changes belong together
+- **컨텍스트**: 해당되는 경우, 이 커밋이 다루는 태스크/컨텍스트
+- **파일**: 포함될 특정 파일 목록
+- **커밋 메시지**: 관례적인 커밋 형식 사용, 명확하고 간결하게
+  - **중요:** 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 · Check if user approval is necessary
+## 4 · 사용자 승인 필요 여부 확인
 
-If YOLO **IS** part of the <$ARGUMENTS> skip this and jump to next step.
+YOLO가 <$ARGUMENTS>의 **일부라면** 이 단계를 건너뛰고 다음 단계로 이동.
 
-Otherwise ask the User for approval.
+그렇지 않으면 사용자 승인을 요청.
 
-- Show the complete commit plan including files and message
-- Wait for explicit user confirmation before proceeding
-- If user says no, ask what should be changed
-- If user wants to modify the commit message or scope, make adjustments
+- 파일과 메시지를 포함한 완전한 커밋 계획 표시
+- 진행하기 전에 명시적인 사용자 확인 대기
+- 사용자가 거부하면 무엇을 변경해야 하는지 묻기
+- 사용자가 커밋 메시지나 범위를 수정하고 싶어하면 조정
 
-## 5 · Execute approved commit and continue
+## 5 · 승인된 커밋 실행 및 계속
 
-For the approved commit:
+승인된 커밋에 대해:
 
-- Stage the specified files with `git add`
-- **IMPORTANT:** We are using pre-commit hooks that will likely report shortcomings. You need to fix them. Don't skip validation unless there are open tasks adressing especially these problems.
-- **Create the commit** with the approved message
-- Verify commit was created successfully
-- **GitHub Issue Update (if applicable):**
-  - If task has a linked GitHub issue
-  - Add commit link comment to issue:
+- `git add`로 지정된 파일들 스테이징
+- **중요:** pre-commit 훅을 사용하고 있어 부족한 점을 보고할 가능성이 높음. 이를 수정해야 함. 특히 이런 문제들을 다루는 열린 태스크가 없다면 검증을 건너뛰지 마세요.
+- 승인된 메시지로 **커밋 생성**
+- 커밋이 성공적으로 생성되었는지 확인
+- **GitHub 이슈 업데이트 (해당하는 경우):**
+  - 태스크에 연결된 GitHub 이슈가 있는 경우
+  - 이슈에 커밋 링크 댓글 추가:
     ```bash
     gh issue comment {issue_number} --body "🔗 Commit: {commit_sha} - {commit_message}"
     ```
-- **IMPORTANT:** If there are more commits remaining, return to step 3 for the next commit
-- Only proceed to step 6 when all commits are completed
+- **중요:** 남은 커밋이 더 있다면 다음 커밋을 위해 3단계로 돌아가기
+- 모든 커밋이 완료된 경우에만 6단계로 진행
 
-## 6 · Report commit results
+## 6 · 커밋 결과 보고
 
-Provide summary:
+요약 제공:
 
-- **Commits Created**: List each commit with SHA and message
-- **Files Committed**: Total count of files committed
-- **Remaining Changes**: Any uncommitted changes still pending
-- **Repository Status**: Current git status after commits
+- **생성된 커밋**: SHA와 메시지와 함께 각 커밋 나열
+- **커밋된 파일**: 커밋된 파일의 총 개수
+- **남은 변경사항**: 아직 커밋되지 않은 대기 중인 변경사항
+- **저장소 상태**: 커밋 후 현재 git 상태
 
-## 7 · Generate Changelog (Optional)
+## 7 · 변경 로그 생성 (선택사항)
 
-After successful commits:
+성공적인 커밋 후:
 
-- Ask user: "커밋이 완료되었습니다. Changelog를 업데이트하시겠습니까? (y/n)"
-- If yes, execute: `/project:aiwf:changelog`
-- This will:
-  - Analyze recent commit history
-  - Generate or update CHANGELOG.md
-  - Categorize changes by type (feat, fix, docs, etc.)
-  - Include the commits just created
+- 사용자에게 묻기: "커밋이 완료되었습니다. Changelog를 업데이트하시겠습니까? (y/n)"
+- yes인 경우 실행: `/project:aiwf:changelog`
+- 이는 다음을 수행:
+  - 최근 커밋 히스토리 분석
+  - CHANGELOG.md 생성 또는 업데이트
+  - 유형별 변경사항 분류 (feat, fix, docs 등)
+  - 방금 생성된 커밋들 포함