aiwf 0.3.8 → 0.3.13

package/claude-code/aiwf/ko/.claude/CLAUDE_BE.md

@@ -1,276 +0,0 @@
-# CLAUDE.md
-
-IMPORTANT: These are my development preferences and guidelines. YOU MUST follow them when working on my projects.
-site: https://github.com/wcygan/dotfiles
-
-## Code Style & Workflow
-
-### Testing
-
-- **ALWAYS** write clear, descriptive test names for better readability
-- **ALWAYS** prefer running single tests over the whole test suite for performance
-- Use `deno test --filter="test name"` or framework-specific single test runners
-
-### Language & Framework Preferences
-
-#### Backend Programming
-
-IMPORTANT: I am primarily a backend developer and prefer these languages and frameworks:
-
-- **Go**: Use [ConnectRPC](https://github.com/connectrpc/connect-go) for RPC services
-- **Rust**: Use [axum](https://github.com/tokio-rs/axum) for web services
-- **Java**: Use [Spring Boot](https://spring.io/projects/spring-boot) with [Quarkus](https://quarkus.io/)
-
-#### Scripting & Automation
-
-**YOU MUST** use Deno for all scripting tasks instead of Bash or Python:
-
-- Create `deno.json` in project root with tasks for common operations
-- Use JSR imports: `import { walk } from "@std/fs";` NOT `https://deno.land/...`
-- Use [Dax](https://github.com/dsherret/dax) for cross-platform shell operations
-- Example deno.json imports: `"@std/fs": "jsr:@std/fs@^1.0.17"`
-
-#### Web Development
-
-Use [Deno Fresh](https://fresh.deno.dev/) with these practices:
-
-- Built-in test runner: `Deno.test()`
-- Organize tests: `/tests/unit/`, `/tests/component/`, `/tests/e2e/`
-- Mock external dependencies for fast, reliable tests
-- Use fresh-testing-library for component/handler testing
-
-## Infrastructure Choices
-
-IMPORTANT: I run a Talos Linux Kubernetes Cluster. Use these modern alternatives:
-
-- **Database**: Postgres (NOT MySQL)
-- **Cache**: DragonflyDB (NOT Redis)
-- **Streaming**: RedPanda (NOT Kafka)
-- **NoSQL**: ScyllaDB (NOT Cassandra)
-
-## Modern Development Tools
-
-### Preferred Command-Line Tools
-
-**ALWAYS** prefer these modern, fast alternatives:
-
-- **ripgrep (rg)**: Use instead of grep for searching code
-- **fd**: Use instead of find for finding files
-- **fzf**: Use for interactive fuzzy finding
-- **bat**: Use instead of cat for syntax-highlighted file viewing
-- **exa/eza**: Use instead of ls for better file listings
-- **delta**: Use for better git diffs
-- **zoxide**: Use instead of cd for smarter directory navigation
-- **duf**: Use instead of df for disk usage
-- **htop/btop**: Use instead of top for process monitoring
-- **jq**: Use for JSON processing and manipulation
-- **yq**: Use for YAML processing and manipulation
-- **hexyl**: Use for hex viewing of binary files
-
-### Output Format Preferences
-
-**ALWAYS** prefer JSON output for parsing when available:
-
-- Use `-o json` or `--json` flags when available (e.g., `kubectl get nodes -o json`)
-- Parse structured JSON output instead of text formats for reliability
-- Use `jq` for JSON processing in scripts
-- Examples:
-  - `kubectl get pods -o json | jq '.items[].metadata.name'`
-  - `docker inspect container-name | jq '.[0].State.Status'`
-  - `aws ec2 describe-instances --output json | jq '.Reservations[].Instances[]'`
-
-### Common Commands
-
-```bash
-# Modern tool usage
-rg "pattern" --type rust        # Search Rust files
-fd ".rs$" src/                   # Find all Rust files
-bat src/main.rs                  # View file with syntax highlighting
-eza -la --git                    # List files with git status
-delta                            # Better git diff viewer
-
-# Deno development
-deno task dev          # Start development server
-deno task test         # Run all tests
-deno test --filter="specific test"  # Run single test
-deno task build        # Build project
-deno check            # Type check
-deno fmt              # Format code
-deno lint             # Lint code
-
-# Project setup
-deno task init        # Initialize / configure the project for a new environment
-deno task deps        # Update dependencies
-
-# Git worktree (for multi-agent workflows)
-git worktree add ../project-feature feature-branch
-git worktree list
-git worktree remove ../project-feature
-```
-
-## Development Workflow
-
-1. **ALWAYS** run type checking/linting after code changes (e.g., `deno check`, `go vet`, `cargo check`)
-2. **ALWAYS** format code before committing using project's formatter
-3. **ALWAYS** run relevant tests before pushing changes
-4. **NEVER** commit without running pre-commit checks
-5. **ALWAYS** use semantic commit messages (feat:, fix:, docs:, refactor:, test:, chore:)
-
-### AI-Assisted Development Pattern
-
-1. **WRITE** failing tests first (test-driven development)
-2. **GENERATE** implementation with AI assistance
-3. **VERIFY** code meets requirements and security standards
-4. **REFACTOR** at appropriate checkpoints, not continuously
-5. **LOG** extensively for debugging AI-generated code
-
-### Context Management
-
-- **PROVIDE** clear, specific requirements to minimize context gaps
-- **INCLUDE** relevant project context in prompts
-- **DOCUMENT** assumptions and decisions in code comments
-
-## Security & Code Verification
-
-### AI-Generated Code Review
-
-- **ALWAYS** review and understand AI-generated code before accepting
-- **NEVER** commit code you don't fully understand
-- **RUN** security scanning on all generated code
-- **VERIFY** all third-party dependencies suggested by AI
-- **TEST** edge cases and error handling thoroughly
-
-### Sensitive Data Protection
-
-- **NEVER** share API keys, credentials, or proprietary code with AI
-- **USE** environment variables or secret management tools
-- **SANITIZE** logs and debug output before sharing
-
-## Project Planning & Coordination
-
-### PLAN.md Adherence
-
-When a `PLAN.md` file exists in the project root, **YOU MUST**:
-
-1. **READ** the PLAN.md file at the start of each session to understand current tasks and priorities
-2. **FOLLOW** the task breakdown and execution strategy defined in the plan
-3. **RESPECT** task dependencies and join points for multi-agent coordination
-4. **UPDATE** task status in the plan as work progresses
-5. **COORDINATE** with other agents at defined synchronization points
-6. **USE** the TodoWrite tool to track individual tasks from the plan
-
-### Multi-Agent Workflow
-
-When working as part of a multi-agent team:
-
-- **CHECK** `/tmp/{project-name}/project-status.md` or coordination files for shared state
-- **WORK** only on assigned tasks to avoid conflicts
-- **COMMUNICATE** progress through PR comments or status files
-- **WAIT** at join points until all parallel work is complete
-- **MERGE** work carefully following the plan's integration strategy
-- **USE** git worktrees to work on separate branches without conflicts
-- **CREATE** status files in `/tmp/{project-name}/claude-scratch/` for inter-agent communication
-- **COORDINATE** using shared JSON status files for structured updates in project-specific directories
-
-## Performance & Optimization
-
-### Token Efficiency
-
-- **OPTIMIZE** prompts for clarity and brevity
-- **BATCH** related operations in single requests
-- **USE** structured outputs (JSON) for parsing efficiency
-- **CACHE** common patterns and solutions locally
-
-### Parallel Development
-
-- **USE** Docker containers for isolated AI agent environments
-- **IMPLEMENT** clear synchronization points for multi-agent work
-- **MAINTAIN** shared state files in `/tmp/{project-name}/`
-
-## Task Management
-
-Use the task management system for tracking work items:
-
-- **Location**: Tasks are stored in `/tasks/` directory with `status.json` index
-- **Commands**: Use `/task-create`, `/task-update`, `/task-list`, `/task-show`, `/task-log`, `/task-search`, `/task-archive`
-- **Format**: Tasks are markdown files with structured metadata
-- **Integration**: Active tasks sync with TodoWrite for session tracking
-
-## File Organization
-
-- `/src/` - Source code
-- `/tests/` - Test files organized by type
-- `/scripts/` - Deno automation scripts
-- `/tasks/` - Task management files (markdown + status.json)
-- `deno.json` - Project configuration and tasks
-- `import_map.json` - Import mappings (if needed)
-
-## Documentation Style
-
-### README Files
-
-**KEEP README FILES CONCISE AND SCANNABLE:**
-
-- **Maximum 50 lines** for most projects
-- **No excessive emojis** or decorative elements
-- **Essential sections only**: Purpose, Quick Start, Key Commands
-- **No verbose explanations** - let code and comments speak
-- **Single quick start command** when possible
-- **Brief feature lists** without detailed descriptions
-- **Minimal project structure** - only if complex
-- **Essential links only** - avoid resource dumps
-
-**Example concise README:**
-
-````markdown
-# Project Name
-
-Brief one-line description of what it does.
-
-## Quick Start
-
-```bash
-deno task init && deno task dev
-```
-````
-
-## Key Commands
-
-- `deno task test` - Run tests
-- `deno task build` - Build project
-
-## Features
-
-- Core feature 1
-- Core feature 2
-- Core feature 3
-
-```
-**Avoid:**
-- Long feature descriptions
-- Extensive project structure diagrams
-- Multiple installation methods
-- Verbose technical explanations
-- Marketing-style language
-- Detailed configuration options in main README
-
-## Claude Code Features
-
-### Thinking Modes
-- `think` - Standard mode (4,000 tokens)
-- `think hard` - Enhanced analysis
-- `think harder` - Deep computation
-- `ultrathink` - Maximum analysis (31,999 tokens)
-
-### Effective Usage
-- **USE** thinking modes for complex architectural decisions
-- **AVOID** over-thinking simple tasks
-- **BALANCE** computation time with task complexity
-
-## IMPORTANT Notes
-
-- **YOU MUST** follow these guidelines exactly as written
-- **ALWAYS** ask for clarification if requirements conflict
-- **NEVER** use deprecated patterns or old import styles
-- **ALWAYS** prioritize performance and type safety
-```

package/claude-code/aiwf/ko/.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-code/aiwf/ko/.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-code/aiwf/ko/.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-code/aiwf/ko/.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('aiwf', [
-  'compress',
-  'aggressive',
-  '--persona'
-], { cwd, stdio: 'inherit' });
-
-proc.on('error', (err) => {
-  console.error('명령 실행 실패:', err.message);
-});
-```
-
-## 설명
-
-페르소나 특성을 고려하면서도 50-70%의 높은 압축률을 목표로 합니다. 페르소나 관련 핵심 정보는 보존하되, 나머지는 적극적으로 요약합니다.
-
-### 특징
-
-- 페르소나 중심 요약 생성
-- 핵심 패턴만 보존
-- 중요도가 낮은 섹션은 요약으로 대체
-- 페르소나별 summarization focus 적용
-
-## 압축 결과
-
-압축 후 페르소나별 요약이 문서 하단에 추가됩니다:
-
-```markdown
----
-### [페르소나명] 관점 요약
-
-주요 내용 ([페르소나의 focus]):
-- 핵심 포인트 1
-- 핵심 포인트 2
-- ...
----
-```
-
-## 주의사항
-
-- 매우 높은 압축률로 인해 일부 세부 정보가 손실될 수 있습니다
-- 중요한 문서는 백업 후 사용을 권장합니다