@yeongjaeyou/claude-code-config 0.4.0 → 0.5.0

package/.claude/commands/code-review.md

@@ -1,75 +1,76 @@
 ---
-description: 사전 코드 리뷰 검토 및 자동 수정
+description: Pre-commit code review analysis and auto-fix
 ---
 
-# 코드 리뷰 검토
+# Code Review Analysis
 
-## 목적
+## Purpose
 
-CodeRabbit 등의 도구에서 이미 진행된 코드 리뷰 내용을 검토하고 처리합니다.
+Review and process code review feedback from external tools like CodeRabbit.
 
-**핵심:** 외부 도구의 리뷰 결과를 받아서 분석 → 자동 수정 가능한 것은 즉시 적용 → 판단이 필요한 것은 사용자에게 확인
+**Core workflow:** Receive external tool review results -> Analyze -> Auto-fix safe changes immediately -> Request user confirmation for items requiring judgment
 
-## 처리 프로세스
+## Processing Workflow
 
-1. **리뷰 내용 분석**: 제안된 변경사항의 타당성과 영향 범위 평가
-2. **자동 수정 적용**: 명확하고 안전한 수정사항 즉시 반영
-3. **체크리스트 제공**: 판단이 필요한 항목은 사용자 확인 요청
+1. **Analyze review content**: Evaluate validity and impact scope of suggested changes
+2. **Apply auto-fixes**: Immediately apply clear and safe fixes
+3. **Provide checklist**: Request user confirmation for items requiring judgment
 
-## 자동 수정 vs 체크리스트 기준
+## Auto-fix vs Checklist Criteria
 
-### 자동 수정 대상
-- 명백한 버그 수정 (null check, 조건문 오류 등)
-- 코딩 컨벤션 위반 (포맷팅, 네이밍 등)
-- 단순 오타 및 불필요한 코드 제거
-- race condition, memory leak 등 명확한 결함
+### Auto-fix Targets
+- Obvious bug fixes (null checks, conditional errors, etc.)
+- Coding convention violations (formatting, naming, etc.)
+- Simple typos and unnecessary code removal
+- Clear defects like race conditions, memory leaks
 
-### 체크리스트 반환 대상
-- 아키텍처 또는 설계 변경
-- 비즈니스 로직 수정 (기능 동작 변경)
-- 성능 최적화 (트레이드오프 있는 경우)
-- 리뷰 내용이 불명확하거나 논쟁의 여지가 있는 경우
+### Checklist Targets
+- Architecture or design changes
+- Business logic modifications (functional behavior changes)
+- Performance optimizations (with trade-offs)
+- Unclear or controversial review suggestions
 
-## 입력 형식
+## Input Format
 
-아규먼트로 CodeRabbit 리뷰 결과를 제공합니다:
+Provide CodeRabbit review results as arguments:
 
 ```
-⚠️ Potential issue | 🟠 Major
+Warning: Potential issue | Major
 
-[문제 설명]
-[상세 내용]
-[제안 변경사항: diff 형식]
+[Problem description]
+[Details]
+[Suggested changes: diff format]
 
-📝 Committable suggestion
-🤖 Prompt for AI Agents
-[파일명, 줄 번호, 수정 내용 요약]
+Committable suggestion
+Prompt for AI Agents
+[Filename, line number, fix summary]
 ```
 
-### 예시 (간단)
+### Examples
 
 ```
-⚠️ Style | 🟡 Minor
+Warning: Style | Minor
 
-변수명이 camelCase를 따르지 않습니다.
+Variable name does not follow camelCase.
 
 - const user_name = "John";
 + const userName = "John";
 ```
 
 ```
-⚠️ Logic | 🔴 Critical
+Warning: Logic | Critical
 
-useEffect의 의존성 배열에 state가 누락되었습니다.
+State is missing from useEffect dependency array.
 
 - useEffect(() => { fetch(url); }, []);
 + useEffect(() => { fetch(url); }, [url]);
 ```
 
-## 처리 가이드라인
+## Guidelines
+
+- **Critical review**: Validate review suggestions rather than accepting blindly
+- **Project guidelines first**: Follow `@CLAUDE.md` conventions and architecture principles
+- **Safety first**: Use `AskUserQuestion` tool to confirm with user when uncertain
+- **Interactive confirmation**: Use `AskUserQuestion` tool to provide options for items requiring judgment
+- **Commit after completion**: Commit with appropriate message and push after all fixes are complete
 
-- **비판적 검토**: 리뷰 내용을 무조건 수용하지 말고 타당성 검증
-- **프로젝트 지침 우선**: `@CLAUDE.md`의 컨벤션 및 아키텍처 원칙 준수
-- **안전 우선**: 확신이 없으면 `AskUserQuestion` 도구로 사용자에게 확인
-- **인터랙티브 확인**: 판단이 필요한 항목은 `AskUserQuestion` 도구를 사용하여 선택지 제공
-- **완료 후 커밋**: 모든 수정이 완료되면 적절한 커밋 메시지로 커밋 후 push

package/.claude/commands/commit-and-push.md

@@ -1,25 +1,25 @@
 ---
-description: Git 변경사항 분석 후 적절한 커밋 메시지로 커밋 및 푸시
+description: Analyze Git changes and commit with appropriate message, then push
 ---
 
-# 커밋 & 푸시
+# Commit & Push
 
-아규먼트로 받은 파일들만을 분석하여 적절한 커밋 메시지를 작성하고 커밋 후 푸시합니다.
+Analyze only the files provided as arguments, create an appropriate commit message, commit, and push.
 
-## 작업 순서
+## Workflow
 
-1. **변경 분석**: 아규먼트로 받은 파일들만의 변경 내용이 어떤 목적인지 분석
-   - 새로운 기능 추가
-   - 버그 수정
-   - 리팩토링
-   - 문서 업데이트
-   - 스타일/포맷팅
-2. **커밋 메시지 작성**: Conventional Commits 형식으로 명확하게 작성
-4. **커밋 & 푸시**: `git add` → `git commit` → `git push`
+1. **Analyze changes**: Determine the purpose of changes in the provided files only
+   - New feature addition
+   - Bug fix
+   - Refactoring
+   - Documentation update
+   - Style/formatting
+2. **Write commit message**: Write clearly in Conventional Commits format
+3. **Commit & Push**: `git add` -> `git commit` -> `git push`
 
-## 커밋 메시지 형식
+## Commit Message Format
 
-Conventional Commits 규칙 준수:
+Follow Conventional Commits rules:
 
 ```
 <type>: <subject>
@@ -27,26 +27,25 @@ Conventional Commits 규칙 준수:
 [optional body]
 ```
 
-### Type 종류
-- `feat`: 새로운 기능 추가
-- `fix`: 버그 수정
-- `refactor`: 코드 리팩토링
-- `docs`: 문서 변경
-- `style`: 코드 포맷팅, 세미콜론 누락 등
-- `test`: 테스트 코드 추가/수정
-- `chore`: 빌드, 설정 파일 변경
-
-### Subject 작성 원칙
-- 명령형, 현재 시제 사용
-- 첫 글자 소문자
-- 마침표 없음
-- 50자 이내로 간결하게
-
-## 작성 원칙
-- **한글로 작성 및 답변**
-- **아규먼트로 전달된 파일 외의 파일은 분석하지 않음**
-- **명확성**: 무엇을, 왜 변경했는지 명확히 전달
-- **CLAUDE.md 준수**: `@CLAUDE.md`의 프로젝트 지침 확인
-- **단일 목적**: 하나의 커밋은 하나의 논리적 변경만 포함
-
+### Types
+- `feat`: New feature addition
+- `fix`: Bug fix
+- `refactor`: Code refactoring
+- `docs`: Documentation changes
+- `style`: Code formatting, missing semicolons, etc.
+- `test`: Test code addition/modification
+- `chore`: Build, configuration file changes
+
+### Subject Guidelines
+- Use imperative, present tense
+- Start with lowercase
+- No period at the end
+- Keep it concise (under 50 characters)
+
+## Guidelines
+
+- **Do not analyze files other than those provided as arguments**
+- **Clarity**: Clearly communicate what was changed and why
+- **Follow CLAUDE.md**: Check project guidelines in `@CLAUDE.md`
+- **Single purpose**: One commit should contain only one logical change
 

package/.claude/commands/council.md

@@ -0,0 +1,318 @@
+---
+description: Consult multiple AI models and synthesize collective wisdom (LLM Council)
+---
+
+# LLM Council
+
+Inspired by Andrej Karpathy's LLM Council: query multiple AI models with the same question, anonymize their responses, and synthesize collective wisdom.
+
+**Core Philosophy:**
+- Collective intelligence > single expert opinion
+- Anonymization prevents model favoritism
+- Diverse perspectives lead to better answers
+
+---
+
+## Arguments
+
+`$ARGUMENTS` parsing:
+
+1. **No arguments**: `/council` - Prompt user for question
+2. **Question only**: `/council How should I structure this API?`
+3. **With evaluate flag**: `/council --evaluate What's the best approach?`
+4. **With deep reasoning**: `/council --deep What's the best architecture?`
+5. **Combined**: `/council --deep --evaluate Complex design decision?`
+
+**Flags:**
+- `--evaluate`: Enable Stage 3 peer evaluation where each model ranks the others
+- `--deep`: Enable maximum reasoning depth (Codex: xhigh + gpt-5.1-codex-max)
+
+---
+
+## Context Gathering (Before Stage 1)
+
+Before querying models, collect relevant context:
+
+**Auto-collect:**
+```
+- git status / git diff (current changes)
+- Directory structure (tree -L 2)
+- Files mentioned in conversation (Read/Edit history)
+
+Model-specific guidelines (project root):
+- ./CLAUDE.md (Claude Opus/Sonnet)
+- ./AGENTS.md (Codex)
+- ./gemini.md (Gemini)
+```
+
+**File Path Inclusion:**
+When the question involves specific files or images, provide **exact absolute paths** so each model can read them directly:
+
+```
+Prompt addition:
+"Relevant files for this question:
+- /absolute/path/to/file.py (source code)
+- /absolute/path/to/screenshot.png (UI reference)
+- /absolute/path/to/diagram.jpg (architecture)
+
+You can use Read tool to examine these files if needed."
+```
+
+**Model-specific file access:**
+| Model | File Access Method |
+|-------|-------------------|
+| Claude Opus/Sonnet | Read tool (images supported) |
+| Codex | sandbox read-only file access |
+| Gemini | Include file content in prompt, or instruct to read |
+
+**Sensitive Data Filtering (exclude from prompts):**
+```
+Files: .env*, secrets*, *credentials*, *.pem, *.key
+Patterns: sk-[a-zA-Z0-9]+, Bearer tokens, passwords
+Directories: node_modules/, __pycache__/, .git/
+```
+
+**Prompt Size Management:**
+```
+- Large files (>500 lines): include only relevant sections or diff
+- Max 5 files per prompt
+- Prefer git diff over full file content
+- If timeout occurs: reduce context, retry
+```
+
+---
+
+## Execution
+
+### Stage 1: Collect Responses
+
+Query all 4 models **in parallel** with identical prompt:
+
+```
+Models:
+- Claude Opus    → Task(model="opus", subagent_type="general-purpose")
+- Claude Sonnet  → Task(model="sonnet", subagent_type="general-purpose")
+- Codex          → mcp__codex__codex(sandbox="read-only", reasoningEffort="high")
+- Gemini         → Bash: cat <<'EOF' | gemini -p -
+```
+
+**Reasoning Control:**
+| Model | Default | --deep |
+|-------|---------|--------|
+| Claude Opus | standard | same |
+| Claude Sonnet | standard | same |
+| Codex | `reasoningEffort="high"` | `xhigh` + `gpt-5.1-codex-max` |
+| Gemini | CLI control N/A | CLI control N/A |
+
+Note:
+- Codex `xhigh` only works with `gpt-5.1-codex-max` or `gpt-5.2`
+- Gemini CLI doesn't support thinking level control yet (Issue #6693)
+
+**Prompt template for each model:**
+```
+You are participating in an LLM Council deliberation.
+
+## Guidelines
+Read and follow your project guidelines before answering:
+- Claude models: Read ./CLAUDE.md
+- Codex: Read ./AGENTS.md
+- Gemini: Read ./gemini.md
+
+## Question
+[USER_QUESTION]
+
+## Context
+Working Directory: [ABSOLUTE_PATH]
+
+## Relevant Files (READ these directly for accurate context)
+- [/absolute/path/to/file1.ext] - [brief description]
+- [/absolute/path/to/image.png] - [screenshot/diagram description]
+- [/absolute/path/to/file2.ext] - [brief description]
+
+Do NOT ask for file contents. Use your file access tools to READ them directly.
+
+## Current Changes (if applicable)
+[git diff summary or key changes]
+
+## Instructions
+Provide your best answer. Be concise but thorough.
+Focus on accuracy, practicality, and actionable insights.
+```
+
+**Important:**
+- Use `run_in_background: true` for Task calls to enable true parallelism
+- Set timeout: 120000ms for each call
+- Continue with successful responses if some models fail
+
+### Stage 2: Anonymize
+
+After collecting responses:
+
+1. **Shuffle** the response order randomly
+2. **Assign labels**: Response A, Response B, Response C, Response D
+3. **Create mapping** (keep internal, reveal later):
+   ```
+   label_to_model = {
+     "Response A": "gemini",
+     "Response B": "opus",
+     "Response C": "sonnet",
+     "Response D": "codex"
+   }
+   ```
+
+4. **Display** anonymized responses to user in a structured format
+
+### Stage 3: Peer Evaluation (if --evaluate)
+
+If `--evaluate` flag is present, query each model again with all anonymized responses:
+
+**Evaluation prompt:**
+```
+You are evaluating responses from an LLM Council.
+
+Original Question: [USER_QUESTION]
+
+[ANONYMIZED_RESPONSES]
+
+Instructions:
+1. Evaluate each response for accuracy, completeness, and usefulness
+2. Identify strengths and weaknesses of each
+3. End with "FINAL RANKING:" section
+
+FINAL RANKING:
+1. Response [X] - [brief reason]
+2. Response [Y] - [brief reason]
+3. Response [Z] - [brief reason]
+4. Response [W] - [brief reason]
+```
+
+**Calculate aggregate rankings:**
+- Parse each model's ranking
+- Sum rank positions for each response
+- Lower total = higher collective approval
+
+### Stage 4: Synthesize
+
+As the main agent (moderator), synthesize the final answer:
+
+1. **Reveal** the label-to-model mapping
+2. **Analyze** all responses:
+   - Consensus points (where models agree)
+   - Disagreements (where they differ)
+   - Unique insights (valuable points from individual models)
+3. **If --evaluate**: Include aggregate rankings and "street cred" scores
+4. **Produce** final verdict combining best elements
+
+---
+
+## Output Format
+
+```markdown
+## LLM Council Deliberation
+
+### Question
+[Original user question]
+
+### Individual Responses (Anonymized)
+
+#### Response A
+[Content]
+
+#### Response B
+[Content]
+
+#### Response C
+[Content]
+
+#### Response D
+[Content]
+
+### Model Reveal
+| Label | Model |
+|-------|-------|
+| Response A | [model name] |
+| Response B | [model name] |
+| Response C | [model name] |
+| Response D | [model name] |
+
+### Aggregate Rankings (if --evaluate)
+| Rank | Model | Avg Position | Votes |
+|------|-------|--------------|-------|
+
+### Council Synthesis
+
+#### Consensus
+[Points where all/most models agree]
+
+#### Disagreements
+[Points of divergence with analysis]
+
+#### Unique Insights
+[Valuable contributions from specific models]
+
+### Final Verdict
+[Synthesized answer combining collective wisdom]
+```
+
+---
+
+## Error Handling
+
+- **Model timeout**: Continue with successful responses, note failures
+- **All models fail**: Report error, suggest retry
+- **Parse failure in rankings**: Use fallback regex extraction
+- **Empty response**: Exclude from synthesis, note in output
+
+---
+
+## Examples
+
+```bash
+# Basic council consultation
+/council What's the best way to implement caching in this API?
+
+# With peer evaluation for important decisions
+/council --evaluate Should we use microservices or monolith for this project?
+
+# Architecture review
+/council --evaluate Review the current authentication flow and suggest improvements
+```
+
+---
+
+## User Interaction
+
+Use `AskUserQuestion` tool when clarification is needed:
+
+**Before Stage 1:**
+- Question is ambiguous or too broad
+- Missing critical context (e.g., "review this code" but no file specified)
+- Multiple interpretations possible
+
+**During Execution:**
+- Conflicting requirements detected
+- Need to confirm scope (e.g., "Should I include performance considerations?")
+
+**After Synthesis:**
+- Models strongly disagree and user input would help decide
+- Actionable next steps require user confirmation
+
+**Example questions:**
+```
+- "Your question mentions 'the API' - which specific endpoint or service?"
+- "Should the council focus on: (1) Code quality, (2) Architecture, (3) Performance, or (4) All aspects?"
+- "Models disagree on X vs Y approach. Which aligns better with your constraints?"
+```
+
+**Important:** Never assume or guess when context is unclear. Ask first, then proceed.
+
+---
+
+## Guidelines
+
+- Respond in the same language as the user's question
+- No emojis in code or documentation
+- If context is needed, gather it before querying models
+- For code-related questions, include relevant file snippets in the prompt
+- Respect `@CLAUDE.md` project conventions
+- **Never assume unclear context - use AskUserQuestion to clarify**

package/.claude/commands/edit-notebook.md

@@ -1,42 +1,43 @@
 ---
-description: Jupyter Notebook(.ipynb) 파일 안전 편집
+description: Safely edit Jupyter Notebook (.ipynb) files
 ---
 
-# Notebook 편집
+# Notebook Editing
 
-Jupyter Notebook 파일을 올바른 도구로 안전하게 편집합니다.
+Safely edit Jupyter Notebook files using the correct tools.
 
-## 필수 규칙
+## Required Rules
 
-1. **도구 사용**: `NotebookEdit` 도구만 사용
-   - `Edit`, `Write`, `search_replace` 등 텍스트 편집 도구 사용 금지
-   - .ipynb는 JSON 구조이므로 전용 도구 필수
+1. **Tool usage**: Use only the `NotebookEdit` tool
+   - Do not use text editing tools like `Edit`, `Write`, `search_replace`
+   - .ipynb files are JSON structures and require dedicated tools
 
-2. **셀 삽입 순서**: 새 노트북 작성 시 순서 보장 필수
-   - **중요**: `cell_id` 미지정 시 항상 맨 앞에 삽입됨
-   - **방법 1 (권장)**: 이전 셀의 cell_id를 추적하여 순차 삽입
+2. **Cell insertion order**: Ensure correct order when creating new notebooks
+   - **Important**: Cells are inserted at the beginning if `cell_id` is not specified
+   - **Method 1 (recommended)**: Track previous cell's cell_id for sequential insertion
      ```
-     첫 셀 삽입 → cell_id='abc123' 반환
-     두 번째 셀 삽입 시 cell_id='abc123' 지정 → 첫 셀 다음에 삽입
-     세 번째 셀 삽입 시 cell_id='def456' 지정 → 두 번째 셀 다음에 삽입
+     Insert first cell -> Returns cell_id='abc123'
+     Insert second cell with cell_id='abc123' -> Inserted after first cell
+     Insert third cell with cell_id='def456' -> Inserted after second cell
      ```
-   - **방법 2**: 역순 삽입 (마지막 셀부터 첫 셀까지)
-   - **절대 금지**: cell_id 없이 순차 삽입 (역순 결과 발생)
-
-3. **source 형식**: NotebookEdit 사용 시 source가 string으로 저장될 수 있음
-   - **문제**: `"line1\\nline2"` (string) → Jupyter에서 `\n`이 그대로 표시됨
-   - **정상**: `["line1\n", "line2\n"]` (list of strings)
-   - **해결**: 새 노트북 생성 시 Python으로 직접 JSON 작성 권장
-
-4. **편집 후 검증**: 수정 후 반드시 확인
-   - JSON 구문 유효성 검증
-   - 셀 실행 순서 보존 확인 (Read로 첫 30줄 확인)
-   - 함수/임포트/의존성 누락 확인
-   - 명시적 지시가 없으면 셀 출력 보존
-
-## 처리 원칙
-
-- **전용 도구만 사용**: NotebookEdit 외 다른 편집 도구 절대 금지
-- **구조 보존**: 기존 셀 순서 및 출력 유지
-- **검증 필수**: 편집 후 즉시 변경사항 확인
-- **CLAUDE.md 준수**: 프로젝트 지침 엄수
+   - **Method 2**: Insert in reverse order (from last cell to first)
+   - **Never**: Insert sequentially without cell_id (causes reverse order)
+
+3. **Source format**: Source may be saved as string when using NotebookEdit
+   - **Problem**: `"line1\\nline2"` (string) -> `\n` displayed literally in Jupyter
+   - **Correct**: `["line1\n", "line2\n"]` (list of strings)
+   - **Solution**: When creating new notebooks, directly write JSON using Python
+
+4. **Post-edit verification**: Always verify after modifications
+   - Validate JSON syntax
+   - Confirm cell execution order is preserved (check first 30 lines with Read)
+   - Check for missing functions/imports/dependencies
+   - Preserve cell outputs unless explicitly instructed otherwise
+
+## Guidelines
+
+- **Use dedicated tool only**: Never use editing tools other than NotebookEdit
+- **Preserve structure**: Maintain existing cell order and outputs
+- **Verification required**: Immediately verify changes after editing
+- **Follow CLAUDE.md**: Adhere strictly to project guidelines
+

package/.claude/commands/gh/create-issue-label.md

@@ -1,29 +1,31 @@
-## 이슈 라벨 생성하기
+## Create Issue Labels
 
-프로젝트 구조를 분석하여 적절한 GitHub 이슈 라벨을 생성합니다. `@CLAUDE.md`의 프로젝트 지침을 준수할 것.
+Analyze project structure and create appropriate GitHub issue labels. Follow project guidelines in `@CLAUDE.md`.
 
-## 작업 순서
-1. 프로젝트 분석: `package.json`, `README.md`, 코드 구조 파악
-2. 기술 스택 확인: 사용된 프레임워크, 라이브러리, 도구 식별
-3. 프로젝트 영역 분류: 프론트엔드, 백엔드, API, 인프라 등
-4. 라벨 생성: 타입, 영역, 난이도 기반으로 핵심 라벨만 생성
+## Workflow
 
-## 라벨 생성 기준
+1. Analyze project: Examine `package.json`, `README.md`, and code structure
+2. Identify tech stack: Detect frameworks, libraries, and tools in use
+3. Classify project areas: Frontend, backend, API, infrastructure, etc.
+4. Create labels: Generate essential labels based on type, area, and complexity
 
-**아래는 예시이며, 프로젝트에 맞게 조정해서 생성해주세요.**
+## Label Guidelines
 
-### 타입 (Type)
+**The following are examples; adjust based on your project needs.**
+
+### Type
 - `type: feature`, `type: bug`, `type: enhancement`, `type: documentation`, `type: refactor`
 
-### 영역 (Area)
+### Area
 - `frontend` `backend` `api` `devops`, `crawling` `ai` `database` `infrastructure`
 
-### 난이도 (Complexity)
+### Complexity
 - `complexity: easy` `complexity: medium` `complexity: hard`
 
-## 생성 명령어 예시
+## Example Commands
+
 ```bash
-gh label create "type: feature" --color "0e8a16" --description "새로운 기능 추가"
-gh label create "frontend" --color "1d76db" --description "프론트엔드 관련 작업"
-gh label create "complexity: easy" --color "7057ff" --description "간단한 작업"
-```
+gh label create "type: feature" --color "0e8a16" --description "New feature addition"
+gh label create "frontend" --color "1d76db" --description "Frontend-related work"
+gh label create "complexity: easy" --color "7057ff" --description "Simple task"
+```