@yeongjaeyou/claude-code-config 0.4.0 → 0.5.1

package/.claude/commands/gh/decompose-issue.md

@@ -1,65 +1,66 @@
-## 작업 세분화하기
-
-큰 작업을 관리 가능한 독립적인 이슈들로 분해합니다. `@CLAUDE.md`의 프로젝트 지침을 준수할 것.
-
-## 작업 순서
-1. 이슈 번호 확인: `gh issue list`로 현재 이슈 번호 확인하기.
-2. 작업 분석: 작업의 핵심 요구사항과 목표를 이해하기.
-3. 작업 분해: 주요 작업을 더 작고 관리하기 쉬운 하위 작업 또는 이슈로 나누기. **너무 많은 이슈보다 최적의 개수로 분해 (관리 가능한 수준)**할 것.
-4. 의존성 분석: 다른 작업이 선행돼야 하는 의존성 파악하기
-5. 마일스톤 이름 제안: 분해된 작업들을 묶을 마일스톤명 제안하기
-6. 관련 PR 확인 (선택): `gh pr list --state closed --limit 20`로 참고할 만한 유사 작업 찾기 (없으면 생략)
-7. 분해된 이슈 출력: 분해된 이슈들을 마일스톤명과 함께 출력하기.
-8. 깃허브에 마일스톤과 이슈를 생성할지 묻기: AskUserQuestion 도구로 사용자가 결정하도록 요청하기.
-   - 마일스톤 생성: `gh api repos/:owner/:repo/milestones -f title="마일스톤명" -f description="설명"`
-   - 이슈 생성 시 `--milestone` 옵션으로 할당
-9. **GitHub Project에 이슈 추가 (선택)**
-   - `gh project list --owner <owner> --format json`으로 프로젝트 존재 여부 확인
-   - 프로젝트가 없으면: "프로젝트가 없습니다. `/gh:init-project`로 생성할 수 있습니다." 안내 후 스킵
-   - 프로젝트가 있으면: AskUserQuestion으로 추가 여부 질문
-   - 추가 원하면: 각 이슈에 대해 `gh project item-add <project-number> --owner <owner> --url <issue-url>`
-
-## 마일스톤 description 작성 가이드
-
-마일스톤 description에 반드시 포함할 내용:
-- 전체 작업의 목표와 범위
-- 이슈 처리 순서 (의존성 그래프)
-- 예: "이슈 순서: #1 -> #2 -> #3 -> #4"
-
-## 이슈 템플릿
-
-### 제목
-`[타입] 간결한 작업 설명`
-
-### 라벨 (실제 저장소 라벨 사용)
-**주의**: 라벨을 지정하기 전에 `gh label list` 명령어로 저장소의 실제 라벨을 확인하세요.
-
-예시 (프로젝트에 따라 다름, 참고용으로만 이해하고 사용하지 말 것):
-- **타입**: `type: feature`, `type: documentation`, `type: enhancement`, `type: bug`
-- **영역**: `area: model/inference`, `area: model/training`, `area: dataset`, `area: detection`
-- **난이도**: `complexity: easy`, `complexity: medium`, `complexity: hard`
-- **우선순위**: `priority: high`, `priority: medium`, `priority: low`
-
-### 설명
-**목적**: [왜 필요한지]
-
-**작업 내용**:
-- [ ] 구체적 요구사항 1
-- [ ] 구체적 요구사항 2
-
-**수정할 파일**:
-- `경로/파일명` - 변경 내용
-
-**완료 조건**:
-- [ ] 기능 구현 완료
-- [ ] 데모 페이지에 추가 (UI 컴포넌트인 경우)
-
-**의존성**:
-- [ ] 없음 또는 선행 이슈 #번호
-
-**권장 에이전트** (해당되는 경우):
-- 아규먼트에 에이전트 사용이 명시된 경우 여기에 포함
-
-**참고 자료** (선택사항):
-- 관련 PR이 있으면 추가 (예: PR #36 - 간단한 설명)
-- 없으면 이 섹션 생략 가능
+## Decompose Work
+
+Break down large work items into manageable, independent issues. Follow project guidelines in `@CLAUDE.md`.
+
+## Workflow
+
+1. Check issue numbers: Run `gh issue list` to view current issue numbers
+2. Analyze work: Understand core requirements and objectives
+3. Decompose work: Split major tasks into smaller, manageable sub-tasks or issues. **Aim for optimal count over excessive issues (keep it manageable)**
+4. Analyze dependencies: Identify prerequisite tasks
+5. Suggest milestone name: Propose a milestone to group decomposed tasks
+6. Check related PRs (optional): Run `gh pr list --state closed --limit 20` for similar work references (skip if none)
+7. Output decomposed issues: Display issues with proposed milestone name
+8. Ask about GitHub creation: Use AskUserQuestion to let user decide on milestone and issue creation
+   - Create milestone: `gh api repos/:owner/:repo/milestones -f title="Milestone Name" -f description="Description"`
+   - Assign issues with `--milestone` option
+9. **Add issues to GitHub Project (optional)**
+   - Check for existing projects: `gh project list --owner <owner> --format json`
+   - If no project exists: Display "No project found. You can create one with `/gh:init-project`" and skip
+   - If project exists: Ask user via AskUserQuestion whether to add issues
+   - If yes: Run `gh project item-add <project-number> --owner <owner> --url <issue-url>` for each issue
+
+## Milestone Description Guidelines
+
+Milestone description must include:
+- Overall objectives and scope
+- Issue processing order (dependency graph)
+- Example: "Issue order: #1 -> #2 -> #3 -> #4"
+
+## Issue Template
+
+### Title
+`[Type] Concise task description`
+
+### Labels (Use actual repository labels)
+**Note**: Before assigning labels, verify repository labels with `gh label list`.
+
+Examples (vary by project, for reference only):
+- **Type**: `type: feature`, `type: documentation`, `type: enhancement`, `type: bug`
+- **Area**: `area: model/inference`, `area: model/training`, `area: dataset`, `area: detection`
+- **Complexity**: `complexity: easy`, `complexity: medium`, `complexity: hard`
+- **Priority**: `priority: high`, `priority: medium`, `priority: low`
+
+### Description
+**Purpose**: [Why this is needed]
+
+**Tasks**:
+- [ ] Specific requirement 1
+- [ ] Specific requirement 2
+
+**Files to modify**:
+- `path/filename` - Change description
+
+**Completion criteria**:
+- [ ] Feature implementation complete
+- [ ] Added to demo page (for UI components)
+
+**Dependencies**:
+- [ ] None or prerequisite issue #number
+
+**Recommended agent** (if applicable):
+- Include here if agent usage is specified in arguments
+
+**References** (optional):
+- Add related PRs if available (e.g., PR #36 - brief description)
+- Omit this section if none

package/.claude/commands/gh/init-project.md

@@ -1,48 +1,48 @@
 ---
-description: GitHub Project 보드 초기화 및 설정
+description: Initialize and configure GitHub Project board
 ---
 
-# GitHub Project 초기화
+# Initialize GitHub Project
 
-GitHub Project 보드를 생성하고 기본 필드를 설정합니다. `@CLAUDE.md`의 프로젝트 지침을 준수할 것.
+Create a GitHub Project board and configure default fields. Follow project guidelines in `@CLAUDE.md`.
 
-## 사전 요구사항
+## Prerequisites
 
-`gh` CLI에 project 스코프가 필요합니다. 없으면 다음 명령어로 추가:
+The `gh` CLI requires project scope. Add it with:
 ```bash
 gh auth refresh -s project --hostname github.com
 ```
 
-## 아규먼트
+## Arguments
 
-- 프로젝트 이름 (선택): 없으면 저장소 이름을 기본값으로 사용
+- Project name (optional): Uses repository name as default if not provided
 
-## 작업 순서
+## Workflow
 
-1. **사전 확인**
-   - `gh auth status`로 project 스코프 확인
-   - 없으면 사용자에게 `gh auth refresh -s project --hostname github.com` 실행 안내
-   - `gh repo view --json nameWithOwner,owner -q ".owner.login"`로 owner 확인
+1. **Pre-check**
+   - Verify project scope with `gh auth status`
+   - If missing, instruct user to run `gh auth refresh -s project --hostname github.com`
+   - Get owner with `gh repo view --json nameWithOwner,owner -q ".owner.login"`
 
-2. **기존 프로젝트 확인**
-   - `gh project list --owner <owner> --format json`으로 기존 프로젝트 목록 확인
-   - 동일한 이름의 프로젝트가 있으면 AskUserQuestion으로 처리 방법 질문:
-     - 기존 프로젝트 사용
-     - 새 프로젝트 생성 (다른 이름으로)
-     - 작업 취소
+2. **Check existing projects**
+   - List existing projects with `gh project list --owner <owner> --format json`
+   - If a project with the same name exists, use AskUserQuestion to determine action:
+     - Use existing project
+     - Create new project (with different name)
+     - Cancel operation
 
-3. **프로젝트 생성**
-   - `gh project create --owner <owner> --title "<프로젝트명>" --format json`
-   - 생성된 프로젝트 번호(number) 저장
+3. **Create project**
+   - Run `gh project create --owner <owner> --title "<project-name>" --format json`
+   - Save the generated project number
 
-4. **Status 필드 확인**
-   - `gh project field-list <project-number> --owner <owner> --format json`으로 필드 확인
-   - GitHub Project는 기본적으로 Status 필드 제공 (Todo, In Progress, Done)
-   - 기본 필드가 있으면 그대로 사용
+4. **Verify Status field**
+   - Check fields with `gh project field-list <project-number> --owner <owner> --format json`
+   - GitHub Project provides default Status field (Todo, In Progress, Done)
+   - Use default fields if available
 
-5. **Priority 필드 생성 (선택)**
-   - AskUserQuestion으로 Priority 필드 생성 여부 질문
-   - 원하면 생성:
+5. **Create Priority field (optional)**
+   - Ask user via AskUserQuestion whether to create Priority field
+   - If yes, create:
      ```bash
      gh project field-create <project-number> --owner <owner> \
        --name "Priority" \
@@ -50,39 +50,33 @@ gh auth refresh -s project --hostname github.com
        --single-select-options "High,Medium,Low"
      ```
 
-6. **저장소에 프로젝트 링크**
-   - `gh repo view --json name -q .name`로 현재 저장소 이름 확인
-   - `gh project link <project-number> --owner <owner> --repo <repo>`로 연결
-   - 주의: `--repo`에는 저장소 이름만 지정 (owner/repo 형식 아님)
+6. **Link repository to project**
+   - Get current repository name with `gh repo view --json name -q .name`
+   - Link with `gh project link <project-number> --owner <owner> --repo <repo>`
+   - Note: `--repo` takes only the repository name (not owner/repo format)
 
-7. **결과 출력**
-   - 생성된 프로젝트 정보 요약
-   - 웹에서 확인할 수 있는 URL 제공: `gh project view <project-number> --owner <owner> --web`
+7. **Output results**
+   - Summarize created project information
+   - Provide web URL: `gh project view <project-number> --owner <owner> --web`
 
-## 출력 예시
+## Output Example
 
 ```
-GitHub Project 초기화 완료!
+GitHub Project initialization complete!
 
-프로젝트: my-project
-번호: 5
+Project: my-project
+Number: 5
 URL: https://github.com/users/<username>/projects/5
 
-기본 필드:
+Default fields:
 - Status: Todo, In Progress, Done
-- Priority: High, Medium, Low (선택적으로 추가됨)
+- Priority: High, Medium, Low (optionally added)
 
-연결된 저장소: owner/repo
+Linked repository: owner/repo
 
-다음 단계:
-- 이슈 추가: gh project item-add 5 --owner <owner> --url <issue-url>
-- 보드 확인: gh project view 5 --owner <owner> --web
+Next steps:
+- Add issue: gh project item-add 5 --owner <owner> --url <issue-url>
+- View board: gh project view 5 --owner <owner> --web
 ```
 
-## 작업 지침
-
-- 한글로 답변
-- 코드나 문서 작성 시 이모지 사용 금지
-- 오류 발생 시 명확한 해결 방법 제시
-- 프로젝트 번호는 이후 명령어에서 사용되므로 사용자에게 안내
-- `@me`는 일부 명령어에서 동작하지 않으므로 실제 owner를 사용
+> See [Work Guidelines](../guidelines/work-guidelines.md)

package/.claude/commands/gh/post-merge.md

@@ -1,93 +1,88 @@
 ---
-description: PR 머지 후 브랜치 정리 및 CLAUDE.md 업데이트
+description: Clean up branch and update CLAUDE.md after PR merge
 ---
 
-# PR 머지 후 정리
+# Post-Merge Cleanup
 
-PR이 머지된 후 브랜치 정리와 CLAUDE.md 업데이트를 수행합니다. `@CLAUDE.md`의 프로젝트 지침을 준수할 것.
+Perform branch cleanup and CLAUDE.md updates after a PR has been merged. Follow project guidelines in `@CLAUDE.md`.
 
-## 아규먼트
+## Arguments
 
-- PR 번호 (선택): 없으면 대화 맥락에서 파악하거나 최근 머지된 PR 목록에서 선택 요청
+- PR number (optional): If not provided, infer from conversation context or prompt user to select from recent merged PRs
 
-## 작업 순서
+## Workflow
 
-1. **PR 정보 확인**
-   - 아규먼트로 PR 번호가 주어지면 해당 PR 사용
-   - 없으면 대화 맥락에서 관련 PR/이슈 번호 파악 시도
-   - 파악 불가하면 `gh pr list --state merged --limit 5`로 최근 머지 PR 목록 보여주고 AskUserQuestion으로 선택 요청
-   - `gh pr view <PR번호> --json number,title,baseRefName,headRefName,body,state`로 PR 정보 확인
-   - `state`가 MERGED인지 확인
+1. **Identify PR**
+   - Use PR number if provided as argument
+   - Otherwise, attempt to infer related PR/issue number from conversation context
+   - If unable to determine, run `gh pr list --state merged --limit 5` to show recent merged PRs and prompt user to select
 
-2. **로컬 변경사항 확인**
-   - `git status --porcelain`으로 uncommitted 변경사항 확인
-   - **Untracked 파일 (`??`)**: 브랜치 이동에 영향 없으므로 무시하고 진행
-   - **Modified/Staged 파일 (`M`, `A`, `D` 등)**: AskUserQuestion으로 처리 방법 질문:
-     - **stash 후 진행**: `git stash push -m "post-merge: 임시 저장"`
-     - **변경사항 버리기**: `git checkout -- . && git clean -fd`
-     - **작업 중단**: 사용자가 직접 처리하도록 중단
-   - **stash 선택 시**: 작업 완료 후 AskUserQuestion으로 stash 복원 여부 질문:
-     - **pop**: `git stash pop` (stash 제거하면서 복원)
-     - **apply**: `git stash apply` (stash 유지하면서 복원)
-     - **나중에**: 사용자가 직접 처리
+   - Run `gh pr view <PR_NUMBER> --json number,title,baseRefName,headRefName,body,state` to get PR details
+   - Verify `state` is MERGED
 
-3. **베이스 브랜치로 이동**
+2. **Check Local Changes**
+   - Run `git status --porcelain` to check for uncommitted changes
+   - **Untracked files (`??`)**: Ignore and proceed (do not affect branch switching)
+   - **Modified/Staged files (`M`, `A`, `D`, etc.)**: Prompt user for action:
+     - **Stash and proceed**: `git stash push -m "post-merge: temp save"`
+     - **Discard changes**: `git checkout -- . && git clean -fd`
+     - **Abort**: Let user handle manually
+   - **If stash selected**: After workflow completion, prompt user for stash restoration:
+     - **pop**: `git stash pop` (restore and remove stash)
+     - **apply**: `git stash apply` (restore and keep stash)
+     - **later**: Let user handle manually
+
+3. **Switch to Base Branch**
    - `git fetch origin`
    - `git checkout <baseRefName>`
    - `git pull origin <baseRefName>`
 
-4. **이슈 브랜치 정리 (선택)**
-   - AskUserQuestion으로 로컬 브랜치 삭제 여부 질문
-   - 삭제 원하면: `git branch -d <headRefName>`
-
-5. **GitHub Project 상태 업데이트 (선택)**
-   - PR body에서 관련 이슈 번호 파악: `Closes #N`, `Fixes #N`, `Resolves #N` 패턴 검색
-   - `gh project list --owner <owner> --format json`으로 프로젝트 확인
-   - 프로젝트가 없으면 스킵 (경고 없이 진행)
-   - 프로젝트가 있으면:
-     - `gh project item-list`로 해당 이슈의 item-id 확인
-     - `gh project field-list`로 Status 필드 ID와 "Done" 옵션 ID 획득
-     - `gh project item-edit`로 Status를 "Done"으로 변경
-     - 이슈가 프로젝트에 없거나 Status 필드가 없으면 스킵
-
-6. **CLAUDE.md 분석 및 업데이트**
-   - CLAUDE.md 존재 여부 확인
-     - 없으면: AskUserQuestion으로 생성 여부 또는 스킵 여부 질문
-   - 기존 내용 분석:
-     - 해결된 이슈 관련 임시 지침 찾기 (예: `#<이슈번호>`, `issue-<번호>` 언급)
-     - 오래되거나 부정확한 정보 식별
-     - 중복되거나 불필요한 내용 식별
-   - 업데이트 제안 작성:
-     - **삭제 대상**: 해결된 이슈 관련 임시 메모/지침
-     - **추가 대상**: 이슈 해결 과정에서 발견한 새로운 패턴/컨벤션
-     - **수정 대상**: 오래되거나 부정확한 정보
-   - AskUserQuestion으로 제안 내용 확인 후 적용
-
-7. **변경사항 커밋 (선택)**
-   - CLAUDE.md가 변경되었으면 AskUserQuestion으로 커밋 여부 질문
-   - 커밋 원하면: Conventional Commits 형식으로 커밋
-
-## 작업 지침
-
-- 한글로 답변
-- 코드나 문서 작성 시 이모지 사용 금지
-- 불명확한 사항은 추측하지 말고 AskUserQuestion 도구로 질문
-- CLAUDE.md 변경은 반드시 사용자 확인 후 진행
-- 브랜치 삭제, 커밋 등 되돌리기 어려운 작업은 항상 사용자 확인 필요
-
-## CLAUDE.md 업데이트 가이드
-
-### 삭제 대상 예시
-- `TODO: #123 해결 후 제거` 형태의 임시 메모
-- 특정 이슈 해결을 위한 임시 워크어라운드 설명
-- 이미 해결된 알려진 이슈 목록
-
-### 추가 대상 예시
-- 이슈 해결 중 발견한 코드 컨벤션
-- 자주 발생하는 실수 방지 가이드
-- 새로 도입된 패턴이나 아키텍처 결정
-
-### 수정 대상 예시
-- 변경된 디렉토리 구조 설명
-- 업데이트된 의존성 정보
-- 더 이상 유효하지 않은 명령어나 설정
+4. **Clean Up Issue Branch (Optional)**
+   - Prompt user to confirm local branch deletion
+   - If confirmed: `git branch -d <headRefName>`
+
+5. **Update GitHub Project Status (Optional)**
+   - Extract related issue numbers from PR body: search for `Closes #N`, `Fixes #N`, `Resolves #N` patterns
+   - Run `gh project list --owner <owner> --format json` to check for projects
+   - If no projects exist, skip silently
+   - If projects exist:
+     - Run `gh project item-list` to get the issue's item-id
+     - Run `gh project field-list` to get Status field ID and "Done" option ID
+     - Run `gh project item-edit` to set Status to "Done"
+     - Skip if issue is not in project or Status field does not exist
+
+6. **Analyze and Update CLAUDE.md**
+   - Check if CLAUDE.md exists
+     - If not: Prompt user to create or skip
+   - Analyze existing content:
+     - Find temporary instructions related to resolved issue (e.g., mentions of `#<issue_number>`, `issue-<number>`)
+     - Identify outdated or inaccurate information
+     - Identify redundant or unnecessary content
+   - Prepare update proposal:
+     - **To remove**: Temporary notes/instructions related to resolved issue
+     - **To add**: New patterns/conventions discovered during issue resolution
+     - **To modify**: Outdated or inaccurate information
+   - Present proposal to user for confirmation before applying
+
+7. **Commit Changes (Optional)**
+   - If CLAUDE.md was modified, prompt user to confirm commit
+   - If confirmed: Commit using Conventional Commits format
+
+> See [Work Guidelines](../guidelines/work-guidelines.md)
+
+## CLAUDE.md Update Guide
+
+### Examples of Content to Remove
+- Temporary notes like `TODO: remove after #123 is resolved`
+- Temporary workaround descriptions for specific issues
+- Known issues lists that have been resolved
+
+### Examples of Content to Add
+- Code conventions discovered during issue resolution
+- Guidelines to prevent common mistakes
+- Newly introduced patterns or architecture decisions
+
+### Examples of Content to Modify
+- Changed directory structure descriptions
+- Updated dependency information
+- Commands or configurations that are no longer valid

package/.claude/commands/gh/resolve-issue.md

@@ -1,67 +1,59 @@
 
-# 깃허브 이슈 해결하기
+# Resolve GitHub Issue
 
-깃허브 이슈를 체계적으로 분석하고 해결하는 전문 개발자 역할을 수행합니다. 아규먼트로 깃허브 이슈 번호를 받아 해당 이슈를 해결합니다. `@CLAUDE.md`의 프로젝트 지침을 준수할 것.
+Act as an expert developer who systematically analyzes and resolves GitHub issues. Receive a GitHub issue number as argument and resolve the issue. Follow project guidelines in `@CLAUDE.md`.
 
-## 작업 순서
+## Workflow
 
-1. **이슈 분석**: 
-   - `gh issue view $ISSUE_NUMBER --json title,body,comments,milestone`로 이슈의 제목, 본문, 레이블, 마일스톤을 확인
-   - 마일스톤이 있다면 `gh issue list --milestone "<milestone-name>" --json number,title,state`로 관련 이슈들을 확인하여 전체 맥락 파악
-   - 요구사항을 정확히 파악
+1. **Analyze Issue**:
+   - Run `gh issue view $ISSUE_NUMBER --json title,body,comments,milestone` to get issue title, body, labels, and milestone
+   - If milestone exists, run `gh issue list --milestone "<milestone-name>" --json number,title,state` to view related issues and understand overall context
+   - Identify requirements precisely
 
-2. **브랜치 생성**: `main` 또는 `master` 브랜치에서 `issue-$ISSUE_NUMBER` 형태로 새 브랜치를 생성하고 체크아웃합니다.
-   - **서브모듈 초기화**: Worktree 사용 시 `git submodule update --init --recursive` 실행 필요
+2. **Create Branch**: Create and checkout a new branch named `issue-$ISSUE_NUMBER` from `main` or `master` branch.
+   - **Initialize submodules**: When using worktree, run `git submodule update --init --recursive`
 
-3. **GitHub Project 상태 업데이트 (선택)**
-   - `gh project list --owner <owner> --format json`으로 프로젝트 확인
-   - 프로젝트가 없으면 스킵 (경고 없이 진행)
-   - 프로젝트가 있으면:
-     - `gh project item-list <project-number> --owner <owner> --format json`으로 이슈가 프로젝트에 있는지 확인
-     - 없으면 `gh project item-add`로 추가
-     - `gh project field-list <project-number> --owner <owner> --format json`으로 Status 필드 ID와 "In Progress" 옵션 ID 획득
-     - Status 필드를 "In Progress"로 변경:
+3. **Update GitHub Project Status (Optional)**
+   - Run `gh project list --owner <owner> --format json` to check for projects
+   - If no projects exist, skip silently
+   - If projects exist:
+     - Run `gh project item-list <project-number> --owner <owner> --format json` to check if issue is in project
+     - If not, add with `gh project item-add`
+     - Run `gh project field-list <project-number> --owner <owner> --format json` to get Status field ID and "In Progress" option ID
+     - Update Status field to "In Progress":
        ```bash
        gh project item-edit --project-id <project-id> --id <item-id> --field-id <status-field-id> --single-select-option-id <in-progress-option-id>
        ```
-     - Status 필드가 없으면 스킵
+     - Skip if Status field does not exist
 
-4. **코드베이스 분석**: 이슈 해결에 필요한 관련 파일과 구조를 파악하기 위해 서브에이전트를 활용하여 코드베이스를 병렬로 분석합니다.
+4. **Analyze Codebase**: Use sub-agents to analyze the codebase in parallel, identifying relevant files and structure needed to resolve the issue.
 
-5. **해결 계획 수립**: 분석 결과를 바탕으로 구체적인 해결 방안을 계획하고 작업 단계를 정의합니다.
+5. **Plan Resolution**: Based on analysis results, develop a concrete resolution plan and define work steps.
 
-6. **이슈 해결**: 서브에이전트를 생성하여 계획에 따라 코드를 수정하고 기능을 구현합니다.
-   - **실행 검증 필수**: Python 스크립트, 실행 파일, 또는 동작 가능한 코드의 경우 반드시 실제 실행하여 정상 동작을 확인합니다. 단순히 파일 존재나 이전 결과만으로 판단하지 않습니다.
+6. **Resolve Issue**: Spawn sub-agents to modify code and implement features according to the plan.
+   - **Execution verification required**: For Python scripts, executables, or any runnable code, always execute to verify correct behavior. Do not rely solely on file existence or previous results.
 
-7. **테스트 작성**: 파일별로 독립적인 서브에이전트를 생성하여 병렬로 단위 테스트를 작성하고 80% 이상의 커버리지를 확보합니다.
+7. **Write Tests**: Spawn independent sub-agents per file to write unit tests in parallel, achieving at least 80% coverage.
 
-8. **검증**: 테스트 실행, 린트 검사, 빌드 확인을 각각 독립적인 서브에이전트로 병렬 실행하여 코드 품질을 검증합니다.
+8. **Validate**: Run tests, lint checks, and build verification in parallel using independent sub-agents to validate code quality.
 
-9. **PR 생성**: 해결된 이슈에 대한 풀 리퀘스트를 생성합니다.
+9. **Create PR**: Create a pull request for the resolved issue.
 
-10. **이슈 체크박스 업데이트**: 해당 이슈의 체크박스 항목들을 완료된 것으로 체크하여 업데이트합니다.
+10. **Update Issue Checkboxes**: Mark completed checkbox items in the issue as done.
 
-## 작업 지침
-- 불명확한 요구사항이나 구현 방향이 여러 가지일 경우 AskUserQuestion 도구로 사용자에게 확인
-- 마일스톤이 있다면 마일스톤 description을 읽어 전체 맥락과 이슈 순서를 파악
-- 한글로 답할 것, 주석 및 마크다운도 한글로 작성할 것
-- 코드나 문서 작성 시 이모지 사용 금지
-- PR 설명은 한글로 작성
-- 컴포넌트가 데모 페이지에 추가되는 경우, Playwright MCP를 사용해 해당 컴포넌트를 E2E 테스트로 검증합니다.
-- 일회성 테스트 스크립트나 임시 헬퍼 파일은 작업 완료 후 반드시 삭제합니다.
-- 커밋, PR, 이슈에 'Generated with Claude', 'Co-Authored-By: Claude' 등 Claude attribution 금지
+> See [Work Guidelines](../guidelines/work-guidelines.md)
 
-## 검증 및 완료 기준
+## Verification and Completion Criteria
 
-**중요**: 체크박스를 완료로 표시하기 전에 반드시 실제 동작을 확인해야 합니다.
+**Important**: Always verify actual behavior before marking checkboxes as complete.
 
-### 검증 원칙
-1. **실제 실행 필수**: 코드/설정이 실제로 동작하는지 직접 실행하여 확인
-2. **증거 제시**: 완료를 증명할 수 있는 실제 출력이나 결과를 보여줄 것
-3. **추측 금지**: 확인하지 않은 것은 "미확인" 또는 "추정됨"으로 명시
-4. **부분 완료 구분**: 코드는 작성했지만 테스트하지 않은 경우 명확히 구분
+### Verification Principles
+1. **Execution required**: Directly run code/configuration to confirm it actually works
+2. **Provide evidence**: Show actual output or results that prove completion
+3. **No guessing**: Explicitly mark unverified items as "unverified" or "assumed"
+4. **Distinguish partial completion**: Clearly separate code written but not tested
 
-### 금지 사항
-- 실행하지 않고 "동작할 것으로 예상됩니다"라고 보고
-- 로그를 보지 않고 "로그에 나타날 것입니다"라고 단언
-- 추측을 사실처럼 보고
+### Prohibited Actions
+- Reporting "expected to work" without execution
+- Stating "will appear in logs" without checking logs
+- Presenting assumptions as facts

package/.claude/commands/plan.md

@@ -1,25 +1,26 @@
 ---
-description: 요구사항 분석 후 구현 계획만 수립
+description: Analyze requirements and create implementation plan only
 ---
 
-# 구현 계획 수립
+# Implementation Planning
 
-아규먼트로 받은 요구사항을 신중히 분석하고, 코드베이스를 이해한 후, **실제 구현 없이** 실행 계획만 제시합니다.
+Carefully analyze the requirements provided as arguments, understand the codebase, and present an execution plan **without actual implementation**.
 
 ## IMPORTANT
 - When you need clarification or there are multiple options, please ask me interactive questions (USE interactive question tool `AskUserQuestion`) before proceeding.
 
-## 수행 작업
+## Tasks
 
-1. 요구사항의 의도 파악 (불명확하면 질문)
-2. 관련 코드베이스 조사 및 이해
-3. 단계별 실행 계획 작성
-4. 주의사항 및 결정 필요 사항 제시
+1. Understand the intent of requirements (ask questions if unclear)
+2. Investigate and understand the relevant codebase
+3. Create a step-by-step execution plan
+4. Present considerations and items requiring decisions
 
-## 처리 원칙
+## Guidelines
+
+- **No implementation**: Do not write code immediately; only create the plan
+- **Thorough investigation**: Understand the codebase first, then plan
+- **Ask first**: Do not guess; always ask about uncertainties or ambiguities
+- **Follow CLAUDE.md**: Adhere to project guidelines in `@CLAUDE.md`
+- **Transparent communication**: Clearly state unclear areas, risks, and alternatives
 
-- **구현 금지**: 바로 코드 작성하지 말고 계획만 수립
-- **충분한 조사**: 코드베이스를 먼저 이해한 후 계획
-- **질문 우선**: 모르는 것이나 헷갈리는 것은 추측하지 말고 반드시 질문
-- **CLAUDE.md 준수**: `@CLAUDE.md`의 프로젝트 지침을 준수할 것
-- **투명한 소통**: 불명확한 부분, 위험 요소, 대안 등 명시