cc-viewer 1.6.182 → 1.6.183

package/concepts/ko/Tool-CronDelete.md

@@ -0,0 +1,43 @@
+# CronDelete
+
+`CronCreate`로 이전에 예약된 크론 작업을 취소합니다. 인메모리 세션 저장소에서 즉시 제거하며, 작업이 이미 자동 삭제된 경우(단발성 작업은 실행 후 자동 제거, 반복 작업은 7일 후 자동 만료)에는 아무런 효과가 없습니다.
+
+## 사용 시점
+
+- 사용자가 7일 자동 만료 전에 반복 예약 작업을 중지하도록 요청할 때.
+- 단발성 작업이 더 이상 필요하지 않아 실행 전에 취소해야 할 때.
+- 기존 작업의 일정을 변경해야 할 때 — `CronDelete`로 삭제한 후 새 표현식으로 `CronCreate`를 사용해 재생성합니다.
+- 여러 오래된 작업을 정리하여 세션 저장소를 깔끔하게 유지할 때.
+
+## 매개변수
+
+- `id` (string, 필수): 작업이 처음 생성될 때 `CronCreate`가 반환한 작업 ID입니다. 이 값은 정확히 일치해야 하며, 퍼지 검색이나 이름 기반 조회는 지원하지 않습니다.
+
+## 예시
+
+### 예시 1: 실행 중인 반복 작업 취소
+
+ID가 `"cron_abc123"`인 반복 작업이 이전에 생성되었고, 사용자가 중지를 요청합니다.
+
+```
+CronDelete({ id: "cron_abc123" })
+```
+
+해당 작업이 세션 저장소에서 제거되어 다시 실행되지 않습니다.
+
+### 예시 2: 실행 전 오래된 단발성 작업 제거
+
+ID가 `"cron_xyz789"`인 단발성 작업이 30분 후에 실행되도록 예약되었지만, 사용자가 더 이상 필요하지 않다고 결정했습니다.
+
+```
+CronDelete({ id: "cron_xyz789" })
+```
+
+작업이 취소됩니다. 원래 예약된 시간이 되어도 아무 작업도 수행되지 않습니다.
+
+## 참고사항
+
+- `id`는 반드시 `CronCreate`의 반환값에서 가져와야 합니다. 설명이나 콜백으로 작업을 조회할 방법은 없으므로, 나중에 취소할 가능성이 있다면 ID를 저장해두세요.
+- 작업이 이미 자동 삭제된 경우(단발성으로 실행되거나 7일 반복 만료에 도달한 경우), 해당 ID로 `CronDelete`를 호출해도 무효 작업(no-op)이 되며 오류는 발생하지 않습니다.
+- `CronDelete`는 현재 인메모리 세션에만 영향을 미칩니다. 런타임이 재시작 간 크론 상태를 유지하지 않는다면, `CronDelete` 호출 여부와 관계없이 재시작 후 예약 작업은 모두 사라집니다.
+- 일괄 삭제 기능은 없으므로, 각 작업의 `id`를 사용하여 개별적으로 취소해야 합니다.

package/concepts/ko/Tool-CronList.md

@@ -0,0 +1,30 @@
+# CronList
+
+현재 세션에서 `CronCreate`를 통해 예약된 모든 크론 작업을 나열합니다. 각 활성 크론의 `id`, cron 표현식, 축약된 `prompt`, `recurring` 플래그, `durable` 플래그, 다음 실행 시간을 포함한 요약을 반환합니다.
+
+## 사용 시점
+
+- 변경을 가하거나 세션을 종료하기 전에 현재 예약된 작업을 감사합니다.
+- `CronDelete`를 호출하여 작업을 삭제하기 전에 올바른 `id`를 찾습니다.
+- 작업의 존재 여부와 다음 실행 시간을 확인하여 예상된 작업이 실행되지 않은 원인을 디버그합니다.
+- 일회성(비반복) 작업이 아직 실행되지 않고 대기 중인지 확인합니다.
+
+## 매개변수
+
+없음.
+
+## 예시
+
+### 예시 1: 예약된 모든 작업 감사
+
+인수 없이 `CronList`를 호출하면 모든 활성 크론 작업의 전체 목록을 가져올 수 있습니다. 응답에는 각 작업의 `id`, cron 표현식, `prompt`의 축약 버전, `recurring`(반복) 여부, `durable`(영속화) 여부, 다음 예약 실행 시간이 포함됩니다.
+
+### 예시 2: 특정 반복 작업의 id 찾기
+
+여러 크론 작업을 생성했고 그 중 하나를 삭제해야 한다면, 먼저 `CronList`를 호출하세요. 반환된 목록에서 `prompt` 요약과 cron 표현식이 삭제하려는 작업과 일치하는 항목을 찾아 해당 `id`를 복사하여 `CronDelete`에 전달합니다.
+
+## 참고사항
+
+- `durable: true`로 생성된 작업을 제외하고, 현재 세션에서 생성된 작업만 나열됩니다. `durable: true` 작업은 세션 재시작 후에도 유지됩니다.
+- 요약의 `prompt` 필드는 잘려 있으며, 전체 프롬프트 텍스트의 앞부분만 표시됩니다.
+- 이미 실행된 일회성 작업(`recurring`이 `false`)은 자동으로 삭제되어 목록에 더 이상 표시되지 않습니다.

package/concepts/ko/Tool-Edit.md

@@ -1,46 +1,38 @@
 # Edit
 
-## 정의
+기존 파일 내에서 정확한 문자열 교체를 수행합니다. 차이점만 전송되므로 편집이 정밀하고 감사 가능하게 유지되어 파일을 수정하는 선호되는 방법입니다.
 
-정확한 문자열 치환을 통한 파일 편집. 파일 내의 `old_string`을 `new_string`으로 치환합니다.
+## 사용 시점
 
-## 파라미터
+- 주변 파일을 다시 작성하지 않고 단일 함수의 버그 수정
+- 구성 값, 버전 문자열, 또는 import 경로 업데이트
+- `replace_all`로 파일 전체에서 심볼 이름 변경
+- 앵커 근처에 블록 삽입 (`old_string`을 확장하여 주변 컨텍스트 포함 후 교체 제공)
+- 다단계 리팩터링의 일환으로 작고 범위가 잘 지정된 편집 적용
 
-| 파라미터 | 타입 | 필수 | 설명 |
-|----------|------|------|------|
-| `file_path` | string | 예 | 수정할 파일의 절대 경로 |
-| `old_string` | string | 예 | 치환할 원본 텍스트 |
-| `new_string` | string | 예 | 치환 후 새 텍스트 (old_string과 달라야 함) |
-| `replace_all` | boolean | 아니오 | 모든 매치를 치환할지 여부, 기본값 `false` |
+## 매개변수
 
-## 사용 시나리오
+- `file_path` (string, 필수): 수정할 파일의 절대 경로.
+- `old_string` (string, 필수): 검색할 정확한 텍스트. 공백과 들여쓰기를 포함하여 문자 단위로 일치해야 합니다.
+- `new_string` (string, 필수): 교체 텍스트. `old_string`과 달라야 합니다.
+- `replace_all` (boolean, 선택): `true`인 경우 `old_string`의 모든 발생을 교체합니다. 기본값은 `false`이며, 일치 항목이 고유해야 합니다.
 
-**적합한 경우:**
-- 기존 파일 내 특정 코드 섹션 수정
-- 버그 수정, 로직 업데이트
-- 변수 이름 변경 (`replace_all: true`와 함께 사용)
-- 파일 내용을 정확하게 수정해야 하는 모든 시나리오
+## 예시
 
-**적합하지 않은 경우:**
-- 새 파일 생성 — Write를 사용해야 함
-- 대규모 재작성 — Write로 전체 파일을 덮어써야 할 수 있음
+### 예시 1: 단일 호출 사이트 수정
+`old_string`을 정확한 라인 `const port = 3000;`으로, `new_string`을 `const port = process.env.PORT ?? 3000;`으로 설정합니다. 일치가 고유하므로 `replace_all`은 기본값을 유지할 수 있습니다.
 
-## 주의사항
+### 예시 2: 파일 전체에서 심볼 이름 변경
+`api.ts`에서 모든 `getUser`를 `fetchUser`로 이름을 바꾸려면 `old_string: "getUser"`, `new_string: "fetchUser"`, `replace_all: true`로 설정합니다.
 
-- 사용 전 반드시 Read로 해당 파일을 읽어야 하며, 그렇지 않으면 오류 발생
-- `old_string`은 파일 내에서 유일해야 함. 유일하지 않으면 더 많은 컨텍스트를 포함하여 유일하게 만들거나 `replace_all`을 사용
-- 텍스트 편집 시 원본 들여쓰기 (tab/공백)를 유지해야 함. Read 출력의 행 번호 접두사를 포함하지 말 것
-- 새 파일 생성보다 기존 파일 편집을 우선
-- `new_string`은 `old_string`과 달라야 함
+### 예시 3: 반복되는 스니펫의 모호성 제거
+`return null;`이 여러 분기에서 나타나는 경우, `old_string`을 확장하여 주변 컨텍스트 (예: 앞의 `if` 라인)를 포함시켜 일치가 고유하도록 하십시오. 그렇지 않으면 도구가 추측하지 않고 오류를 반환합니다.
 
-## 원문
+## 참고사항
 
-<textarea readonly>Performs exact string replacements in files.
-
-Usage:
-- You must use your `Read` tool at least once in the conversation before editing. This tool will error if you attempt an edit without reading the file. 
-- When editing text from Read tool output, ensure you preserve the exact indentation (tabs/spaces) as it appears AFTER the line number prefix. The line number prefix format is: spaces + line number + tab. Everything after that tab is the actual file content to match. Never include any part of the line number prefix in the old_string or new_string.
-- ALWAYS prefer editing existing files in the codebase. NEVER write new files unless explicitly required.
-- Only use emojis if the user explicitly requests it. Avoid adding emojis to files unless asked.
-- The edit will FAIL if `old_string` is not unique in the file. Either provide a larger string with more surrounding context to make it unique or use `replace_all` to change every instance of `old_string`.
-- Use `replace_all` for replacing and renaming strings across the file. This parameter is useful if you want to rename a variable for instance.</textarea>
+- `Edit`가 변경을 수락하기 전에 현재 세션에서 파일에 대해 적어도 한 번 `Read`를 호출해야 합니다. `Read` 출력의 라인 번호 접두사는 파일 내용의 일부가 아닙니다. `old_string`이나 `new_string`에 포함하지 마십시오.
+- 공백이 정확히 일치해야 합니다. 특히 YAML, Makefile, Python에서 탭 대 공백, 뒤쪽 공백에 주의하십시오.
+- `old_string`이 고유하지 않고 `replace_all`이 `false`이면 편집이 실패합니다. 컨텍스트를 확장하거나 `replace_all`을 활성화하십시오.
+- 파일이 이미 존재하는 경우 언제든 `Write`보다 `Edit`를 선호하십시오. `Write`는 전체 파일을 덮어쓰고 주의하지 않으면 관련 없는 내용을 잃습니다.
+- 동일한 파일에서 여러 관련 없는 편집의 경우 하나의 큰 취약한 교체 대신 여러 `Edit` 호출을 순차적으로 실행하십시오.
+- 소스 파일을 편집할 때 이모지, 마케팅 카피, 요청되지 않은 문서 블록 도입을 피하십시오.

package/concepts/ko/Tool-EnterPlanMode.md

@@ -1,128 +1,35 @@
 # EnterPlanMode
 
-## 정의
+세션을 계획 모드로 전환합니다. 계획 모드는 읽기 전용 탐색 단계로, 어시스턴트가 코드베이스를 조사하고 구체적인 구현 계획을 작성하여 파일이 수정되기 전에 사용자의 승인을 받는 단계입니다.
 
-Claude Code를 계획 모드로 전환하여, 구현 전에 코드베이스를 탐색하고 방안을 설계하는 데 사용합니다.
+## 사용 시점
 
-## 파라미터
+- 사용자가 여러 파일이나 하위 시스템에 걸쳐 있는 사소하지 않은 변경을 요청합니다.
+- 요구사항이 모호하며 어시스턴트가 접근 방식을 확정하기 전에 코드를 읽어야 합니다.
+- 리팩터링, 마이그레이션, 또는 의존성 업그레이드가 제안되고 영향 범위가 불분명합니다.
+- 사용자가 명시적으로 "이것을 계획해 달라", "먼저 계획하자"라고 말하거나 설계 검토를 요청합니다.
+- 위험이 충분히 높아서 바로 편집으로 이동하면 작업을 낭비하거나 상태를 손상시킬 수 있습니다.
 
-파라미터 없음.
+## 매개변수
 
-## 사용 시나리오
+없음. `EnterPlanMode`는 인수를 받지 않습니다 — 빈 매개변수 객체로 호출하십시오.
 
-**적합한 경우:**
-- 새 기능 구현 — 아키텍처 결정이 필요
-- 여러 실행 가능한 방안이 존재 — 사용자 선택이 필요
-- 코드 변경이 기존 동작이나 구조에 영향
-- 다중 파일 변경 — 2~3개 이상의 파일에 걸칠 가능성
-- 요구사항이 불명확 — 먼저 탐색하여 범위를 이해해야 함
-- 사용자 선호가 중요 — 구현에 여러 합리적인 방향이 있음
+## 예시
 
-**적합하지 않은 경우:**
-- 1줄 또는 소수 줄의 수정 (오타, 명백한 버그)
-- 사용자가 매우 구체적인 지시를 제공한 경우
-- 순수 조사/탐색 태스크 — Task (Explore 타입)를 사용해야 함
+### 예시 1: 큰 기능 요청
 
-## 계획 모드에서의 동작
+사용자가 다음과 같이 묻습니다: "관리자 패널에 Okta를 통한 SSO를 추가해 주세요." 어시스턴트는 `EnterPlanMode`를 호출한 다음, 여러 턴에 걸쳐 인증 미들웨어, 세션 저장소, 라우트 가드, 기존 로그인 UI를 읽는 데 시간을 소비합니다. 필요한 변경, 마이그레이션 단계, 테스트 범위를 설명하는 계획을 작성한 다음 승인을 위해 `ExitPlanMode`를 통해 제출합니다.
 
-계획 모드에 진입하면 Claude Code는:
-1. Glob, Grep, Read 도구를 사용하여 코드베이스를 깊이 탐색
-2. 기존 패턴과 아키텍처를 이해
-3. 구현 방안을 설계
-4. 방안을 사용자 승인에 제출
-5. 필요 시 AskUserQuestion으로 확인
-6. 방안이 준비되면 ExitPlanMode로 종료
+### 예시 2: 위험한 리팩터링
 
-## 주의사항
+사용자가 다음과 같이 말합니다: "REST 컨트롤러를 tRPC로 변환해 주세요." 어시스턴트는 계획 모드에 들어가, 각 컨트롤러를 조사하고, 공개 계약을 카탈로그화하고, 롤아웃 단계 (shim, dual-read, cutover)를 나열하며, 어떤 파일도 건드리기 전에 순서 계획을 제안합니다.
 
-- 이 도구는 계획 모드 진입을 위해 사용자 동의가 필요
-- 계획이 필요한지 확실하지 않으면 계획하는 쪽으로 기울일 것 — 사전 조율이 재작업보다 나음
+## 참고사항
 
-## 원문
-
-<textarea readonly>Use this tool proactively when you're about to start a non-trivial implementation task. Getting user sign-off on your approach before writing code prevents wasted effort and ensures alignment. This tool transitions you into plan mode where you can explore the codebase and design an implementation approach for user approval.
-
-## When to Use This Tool
-
-**Prefer using EnterPlanMode** for implementation tasks unless they're simple. Use it when ANY of these conditions apply:
-
-1. **New Feature Implementation**: Adding meaningful new functionality
-   - Example: "Add a logout button" - where should it go? What should happen on click?
-   - Example: "Add form validation" - what rules? What error messages?
-
-2. **Multiple Valid Approaches**: The task can be solved in several different ways
-   - Example: "Add caching to the API" - could use Redis, in-memory, file-based, etc.
-   - Example: "Improve performance" - many optimization strategies possible
-
-3. **Code Modifications**: Changes that affect existing behavior or structure
-   - Example: "Update the login flow" - what exactly should change?
-   - Example: "Refactor this component" - what's the target architecture?
-
-4. **Architectural Decisions**: The task requires choosing between patterns or technologies
-   - Example: "Add real-time updates" - WebSockets vs SSE vs polling
-   - Example: "Implement state management" - Redux vs Context vs custom solution
-
-5. **Multi-File Changes**: The task will likely touch more than 2-3 files
-   - Example: "Refactor the authentication system"
-   - Example: "Add a new API endpoint with tests"
-
-6. **Unclear Requirements**: You need to explore before understanding the full scope
-   - Example: "Make the app faster" - need to profile and identify bottlenecks
-   - Example: "Fix the bug in checkout" - need to investigate root cause
-
-7. **User Preferences Matter**: The implementation could reasonably go multiple ways
-   - If you would use AskUserQuestion to clarify the approach, use EnterPlanMode instead
-   - Plan mode lets you explore first, then present options with context
-
-## When NOT to Use This Tool
-
-Only skip EnterPlanMode for simple tasks:
-- Single-line or few-line fixes (typos, obvious bugs, small tweaks)
-- Adding a single function with clear requirements
-- Tasks where the user has given very specific, detailed instructions
-- Pure research/exploration tasks (use the Agent tool with explore agent instead)
-
-## What Happens in Plan Mode
-
-In plan mode, you'll:
-1. Thoroughly explore the codebase using Glob, Grep, and Read tools
-2. Understand existing patterns and architecture
-3. Design an implementation approach
-4. Present your plan to the user for approval
-5. Use AskUserQuestion if you need to clarify approaches
-6. Exit plan mode with ExitPlanMode when ready to implement
-
-## Examples
-
-### GOOD - Use EnterPlanMode:
-User: "Add user authentication to the app"
-- Requires architectural decisions (session vs JWT, where to store tokens, middleware structure)
-
-User: "Optimize the database queries"
-- Multiple approaches possible, need to profile first, significant impact
-
-User: "Implement dark mode"
-- Architectural decision on theme system, affects many components
-
-User: "Add a delete button to the user profile"
-- Seems simple but involves: where to place it, confirmation dialog, API call, error handling, state updates
-
-User: "Update the error handling in the API"
-- Affects multiple files, user should approve the approach
-
-### BAD - Don't use EnterPlanMode:
-User: "Fix the typo in the README"
-- Straightforward, no planning needed
-
-User: "Add a console.log to debug this function"
-- Simple, obvious implementation
-
-User: "What files handle routing?"
-- Research task, not implementation planning
-
-## Important Notes
-
-- This tool REQUIRES user approval - they must consent to entering plan mode
-- If unsure whether to use it, err on the side of planning - it's better to get alignment upfront than to redo work
-- Users appreciate being consulted before significant changes are made to their codebase
-</textarea>
+- 계획 모드는 계약상 읽기 전용입니다. 그 안에 있는 동안 어시스턴트는 `Edit`, `Write`, `NotebookEdit`, 또는 변이를 일으키는 셸 명령을 실행해서는 안 됩니다. `Read`, `Grep`, `Glob`, 그리고 비파괴적인 `Bash` 명령만 사용하십시오.
+- 사소한 한 줄짜리 편집, 순수 연구 질문, 또는 사용자가 이미 변경을 전체 세부 사항으로 지정한 작업에는 계획 모드에 들어가지 마십시오. 오버헤드가 도움보다 더 해를 끼칩니다.
+- Auto 모드에서는 사용자가 명시적으로 요청하지 않는 한 계획 모드를 권장하지 않습니다 — Auto 모드는 사전 계획보다 행동을 선호합니다.
+- 비싼 작업에서 경로 수정을 줄이기 위해 계획 모드를 사용하십시오. 5분간의 계획은 종종 한 시간의 잘못된 편집을 절약합니다.
+- 계획 모드에 들어가면 실제로 변경될 시스템의 부분에 조사를 집중하십시오. 당면한 작업과 관련 없는 저장소의 철저한 둘러보기를 피하십시오.
+- 계획 자체는 하니스가 기대하는 경로의 디스크에 작성되어야 `ExitPlanMode`가 제출할 수 있습니다. 계획에는 모호한 의도가 아니라 구체적인 파일 경로, 함수 이름, 검증 단계가 포함되어야 합니다.
+- 사용자는 계획을 거부하고 수정을 요청할 수 있습니다. 계획이 수락될 때까지 계획 모드 내에서 반복하십시오. 그때만 종료하십시오.

package/concepts/ko/Tool-EnterWorktree.md

@@ -1,56 +1,44 @@
 # EnterWorktree
 
-## 정의
+새 브랜치에 격리된 Git 워크트리를 생성하거나, 현재 저장소의 기존 워크트리로 세션을 전환합니다. 이를 통해 기본 체크아웃을 건드리지 않고 병렬 또는 실험적 작업을 진행할 수 있습니다.
 
-격리된 git worktree를 생성하고 현재 세션을 해당 worktree로 전환합니다. 사용자가 명시적으로 worktree 작업을 요청할 때만 사용합니다.
+## 사용 시점
 
-## 매개변수
-
-| 매개변수명 | 타입 | 필수 | 설명 |
-|---|---|---|---|
-| name | string | 아니오 | worktree 이름. 제공하지 않으면 임의의 이름이 생성됩니다. |
-
-## 사용 사례
+- 사용자가 명시적으로 "worktree"라고 말합니다 — 예를 들어 "start a worktree", "create a worktree", 또는 "work in a worktree".
+- `CLAUDE.md` 또는 영속 메모리의 프로젝트 지시사항이 현재 작업에 워크트리를 사용하도록 지시합니다.
+- 이전에 워크트리로 설정된 작업을 계속하고 싶습니다 (다시 들어가려면 `path`를 전달합니다).
+- 여러 실험적 브랜치가 지속적인 체크아웃 변경 없이 디스크에 공존해야 합니다.
+- 장시간 실행되는 작업이 메인 작업 트리의 관련 없는 편집으로부터 격리되어야 합니다.
 
-**적합한 경우:**
-- 사용자가 명시적으로 "worktree"라고 말한 경우 (예: "worktree 생성", "worktree에서 작업")
-
-**적합하지 않은 경우:**
-- 사용자가 브랜치 생성/전환을 요청 — git 명령어 사용
-- 사용자가 버그 수정이나 기능 개발을 요청 — worktree를 명시하지 않는 한 일반 git 워크플로우 사용
-
-## 참고사항
-
-- git 저장소 내에 있거나 WorktreeCreate/WorktreeRemove hooks가 구성되어 있어야 함
-- 이미 worktree 내에 있으면 안 됨
-
-## 원문
-
-<textarea readonly>Use this tool ONLY when the user explicitly asks to work in a worktree. This tool creates an isolated git worktree and switches the current session into it.
+## 매개변수
 
-## When to Use
+- `name` (string, 선택): 새 워크트리 디렉토리의 이름. 각 `/`로 구분된 세그먼트는 문자, 숫자, 점, 밑줄, 대시만 포함할 수 있으며, 전체 문자열은 최대 64자로 제한됩니다. 생략되고 `path`도 생략되면 임의의 이름이 생성됩니다. `path`와 상호 배타적입니다.
+- `path` (string, 선택): 전환할 현재 저장소의 기존 워크트리의 파일시스템 경로. 이 저장소에 대한 `git worktree list`에 나타나야 하며, 현재 저장소의 등록된 워크트리가 아닌 경로는 거부됩니다. `name`과 상호 배타적입니다.
 
-- The user explicitly says "worktree" (e.g., "start a worktree", "work in a worktree", "create a worktree", "use a worktree")
+## 예시
 
-## When NOT to Use
+### 예시 1: 설명적인 이름으로 새 워크트리 생성
 
-- The user asks to create a branch, switch branches, or work on a different branch — use git commands instead
-- The user asks to fix a bug or work on a feature — use normal git workflow unless they specifically mention worktrees
-- Never use this tool unless the user explicitly mentions "worktree"
+```
+EnterWorktree(name="feat/okta-sso")
+```
 
-## Requirements
+`HEAD`를 기반으로 하는 새 브랜치에 `.claude/worktrees/feat/okta-sso`를 생성한 다음, 세션의 작업 디렉토리를 그 안으로 전환합니다. 종료할 때까지 이후의 모든 파일 편집과 셸 명령은 해당 워크트리 내에서 작동합니다.
 
-- Must be in a git repository, OR have WorktreeCreate/WorktreeRemove hooks configured in settings.json
-- Must not already be in a worktree
+### 예시 2: 기존 워크트리 다시 들어가기
 
-## Behavior
+```
+EnterWorktree(path="/Users/me/repo/.claude/worktrees/feat/okta-sso")
+```
 
-- In a git repository: creates a new git worktree inside `.claude/worktrees/` with a new branch based on HEAD
-- Outside a git repository: delegates to WorktreeCreate/WorktreeRemove hooks for VCS-agnostic isolation
-- Switches the session's working directory to the new worktree
-- On session exit, the user will be prompted to keep or remove the worktree
+이전에 생성된 워크트리에서 작업을 재개합니다. `path`를 통해 들어갔기 때문에 `ExitWorktree`는 자동으로 삭제하지 않습니다 — `action: "keep"`으로 나가면 원래 디렉토리로 돌아갑니다.
 
-## Parameters
+## 참고사항
 
-- `name` (optional): A name for the worktree. If not provided, a random name is generated.
-</textarea>
+- 사용자가 명시적으로 요청하거나 프로젝트 지시사항이 요구하지 않는 한 `EnterWorktree`를 호출하지 마십시오. 일반적인 브랜치 전환이나 버그 수정 요청은 워크트리가 아닌 일반 Git 명령을 사용해야 합니다.
+- Git 저장소 내에서 호출되면 도구는 `.claude/worktrees/` 아래에 워크트리를 생성하고 `HEAD`를 기반으로 새 브랜치를 등록합니다. Git 저장소 외부에서는 VCS에 구애받지 않는 격리를 위해 `settings.json`의 구성된 `WorktreeCreate` / `WorktreeRemove` 후크에 위임합니다.
+- 한 번에 하나의 워크트리 세션만 활성화됩니다. 이미 워크트리 세션 내에 있는 경우 도구가 실행을 거부합니다. 먼저 `ExitWorktree`로 종료하십시오.
+- 세션 중간에 나가려면 `ExitWorktree`를 사용하십시오. 새로 생성된 워크트리 안에 있는 동안 세션이 종료되면 사용자에게 유지할지 제거할지 묻는 프롬프트가 표시됩니다.
+- `path`로 들어간 워크트리는 외부로 간주됩니다 — `action: "remove"`와 함께 `ExitWorktree`는 이를 삭제하지 않습니다. 이는 사용자가 수동으로 관리하는 워크트리를 보호하기 위한 안전 장치입니다.
+- 새 워크트리는 현재 브랜치의 내용을 상속하지만 독립적인 작업 디렉토리와 인덱스를 갖습니다. 메인 체크아웃의 스테이징 및 비스테이징 변경 사항은 워크트리 내에서 보이지 않습니다.
+- 명명 팁: 작업 종류 (`feat/`, `fix/`, `spike/`)로 접두사를 붙여서 `git worktree list`에서 여러 동시 워크트리를 쉽게 구분할 수 있도록 하십시오.

package/concepts/ko/Tool-ExitPlanMode.md

@@ -1,62 +1,42 @@
 # ExitPlanMode
 
-## 정의
+계획 모드 동안 작성된 구현 계획을 사용자 승인을 위해 제출하고, 승인되면 세션을 계획 모드 밖으로 전환하여 편집을 시작할 수 있도록 합니다.
 
-계획 모드를 종료하고 방안을 사용자 승인에 제출합니다. 방안 내용은 이전에 작성된 계획 파일에서 읽어옵니다.
+## 사용 시점
 
-## 파라미터
+- `EnterPlanMode` 동안 작성된 계획이 완료되어 검토 준비가 되었습니다.
+- 작업이 순수 연구가 아닌 구현 중심 (코드 또는 구성 변경)이므로 명시적 계획이 적절합니다.
+- 모든 사전 독서 및 분석이 완료되었으며, 사용자가 결정하기 전에 추가 조사가 필요하지 않습니다.
+- 어시스턴트가 단순한 목표가 아닌 구체적인 파일 경로, 함수, 단계를 열거했습니다.
+- 사용자가 계획을 보여달라고 요청했거나 계획 모드 워크플로가 편집 도구로 넘어가려고 합니다.
 
-| 파라미터 | 타입 | 필수 | 설명 |
-|----------|------|------|------|
-| `allowedPrompts` | array | 아니오 | 구현 방안에 필요한 권한 설명 목록 |
+## 매개변수
 
-`allowedPrompts` 배열의 각 요소:
+- `allowedPrompts` (array, 선택): 승인 화면에서 사용자가 입력하여 계획을 자동 승인하거나 변경할 수 있는 프롬프트. 각 요소는 범위가 지정된 권한 (예: 작업 이름 및 적용할 도구)을 지정합니다. 기본 승인 흐름을 사용하려면 설정하지 마십시오.
 
-| 필드 | 타입 | 필수 | 설명 |
-|------|------|------|------|
-| `tool` | enum | 예 | 적용할 도구, 현재 `Bash`만 지원 |
-| `prompt` | string | 예 | 작업의 의미적 설명 (예: "run tests", "install dependencies") |
+## 예시
 
-## 사용 시나리오
+### 예시 1: 표준 제출
 
-**적합한 경우:**
-- 계획 모드에서 방안이 완성되어 사용자 승인에 제출할 준비가 됨
-- 코드를 작성해야 하는 구현 태스크에만 사용
+계획 모드 내에서 인증 리팩터링을 조사하고 계획 파일을 디스크에 작성한 후, 어시스턴트는 인수 없이 `ExitPlanMode`를 호출합니다. 하니스는 표준 위치에서 계획을 읽고, 사용자에게 표시하며, 승인 또는 거부를 기다립니다.
 
-**적합하지 않은 경우:**
-- 순수 조사/탐색 태스크 — 계획 모드를 종료할 필요 없음
-- 사용자에게 "방안이 괜찮으신가요?"라고 묻고 싶은 경우 — 이것이 바로 이 도구의 기능이므로 AskUserQuestion으로 묻지 말 것
+### 예시 2: 사전 승인된 빠른 작업
 
-## 주의사항
+```
+ExitPlanMode(allowedPrompts=[
+  {"tool": "Bash", "prompt": "run tests"},
+  {"tool": "Bash", "prompt": "install dependencies"}
+])
+```
 
-- 이 도구는 방안 내용을 파라미터로 받지 않음 — 이전에 작성된 계획 파일에서 읽어옴
-- 사용자는 계획 파일의 내용을 보고 승인함
-- 이 도구를 호출하기 전에 AskUserQuestion으로 "방안이 괜찮은지" 묻지 말 것. 중복됨
-- 질문에서 "계획"을 언급하지 말 것. 사용자는 ExitPlanMode 전에 계획 내용을 볼 수 없기 때문
+사용자가 일상적인 후속 명령에 대한 권한을 미리 부여하여, 어시스턴트가 구현 중에 각 권한 프롬프트에 대해 일시 중지할 필요가 없도록 합니다.
 
-## 원문
+## 참고사항
 
-<textarea readonly>Use this tool when you are in plan mode and have finished writing your plan to the plan file and are ready for user approval.
-
-## How This Tool Works
-- You should have already written your plan to the plan file specified in the plan mode system message
-- This tool does NOT take the plan content as a parameter - it will read the plan from the file you wrote
-- This tool simply signals that you're done planning and ready for the user to review and approve
-- The user will see the contents of your plan file when they review it
-
-## When to Use This Tool
-IMPORTANT: Only use this tool when the task requires planning the implementation steps of a task that requires writing code. For research tasks where you're gathering information, searching files, reading files or in general trying to understand the codebase - do NOT use this tool.
-
-## Before Using This Tool
-Ensure your plan is complete and unambiguous:
-- If you have unresolved questions about requirements or approach, use AskUserQuestion first (in earlier phases)
-- Once your plan is finalized, use THIS tool to request approval
-
-**Important:** Do NOT use AskUserQuestion to ask "Is this plan okay?" or "Should I proceed?" - that's exactly what THIS tool does. ExitPlanMode inherently requests user approval of your plan.
-
-## Examples
-
-1. Initial task: "Search for and understand the implementation of vim mode in the codebase" - Do not use the exit plan mode tool because you are not planning the implementation steps of a task.
-2. Initial task: "Help me implement yank mode for vim" - Use the exit plan mode tool after you have finished planning the implementation steps of the task.
-3. Initial task: "Add a new feature to handle user authentication" - If unsure about auth method (OAuth, JWT, etc.), use AskUserQuestion first, then use exit plan mode tool after clarifying the approach.
-</textarea>
+- `ExitPlanMode`는 구현 스타일의 작업에만 의미가 있습니다. 사용자의 요청이 파일 변경이 없는 연구 또는 설명 작업인 경우, 종료하기 위해 계획 모드를 거치지 말고 직접 답변하십시오.
+- 이 도구를 호출하기 전에 계획이 이미 디스크에 작성되어 있어야 합니다. `ExitPlanMode`는 계획 본문을 매개변수로 받지 않습니다. 하니스가 기대하는 경로에서 읽습니다.
+- 사용자가 계획을 거부하면 계획 모드로 돌아갑니다. 피드백에 따라 수정하고 다시 제출하십시오. 계획이 승인되지 않은 상태에서 파일 편집을 시작하지 마십시오.
+- 승인은 계획 모드를 떠나고 계획에 설명된 범위에 대해 변이를 일으키는 도구 (`Edit`, `Write`, `Bash` 등)를 사용할 권한을 부여합니다. 이후 범위를 확장하려면 새 계획 또는 명시적인 사용자 동의가 필요합니다.
+- 이 도구를 호출하기 전에 "이 계획이 괜찮아 보이나요?"를 묻기 위해 `AskUserQuestion`을 사용하지 마십시오 — 계획 승인을 요청하는 것이 바로 `ExitPlanMode`가 하는 일이며, 계획이 제출되기 전까지 사용자는 계획을 볼 수 없습니다.
+- 계획을 최소화하고 실행 가능하게 유지하십시오. 검토자는 1분 이내에 훑어보고 정확히 무엇이 변경될지 이해할 수 있어야 합니다.
+- 구현 중간에 계획이 잘못되었다는 것을 깨달으면 조용히 벗어나지 말고 멈추고 사용자에게 보고하십시오. 계획 모드에 다시 들어가는 것이 유효한 다음 단계입니다.

package/concepts/ko/Tool-ExitWorktree.md

@@ -0,0 +1,41 @@
+# ExitWorktree
+
+`EnterWorktree`로 생성된 worktree 세션을 종료하고 세션을 원래 작업 디렉터리로 되돌립니다. 이 도구는 현재 세션에서 `EnterWorktree`로 생성된 worktree에만 작동하며, 활성 세션이 없으면 아무 작업도 수행하지 않습니다.
+
+## 사용 시점
+
+- 격리된 worktree에서의 작업이 완료되어 메인 작업 디렉터리로 돌아가고 싶을 때.
+- 피처 브랜치 worktree에서 작업을 완료하고 병합한 후 브랜치와 디렉터리를 정리하고 싶을 때.
+- worktree를 나중에 다시 사용하기 위해 보존하면서, 아무것도 삭제하지 않고 원래 디렉터리로 돌아가고 싶을 때.
+- 실험적이거나 임시 브랜치를 버리고 디스크에 아무 결과물도 남기고 싶지 않을 때.
+- 새 `EnterWorktree` 세션을 시작하기 전에 현재 세션을 먼저 종료해야 할 때.
+
+## 매개변수
+
+- `action` (문자열, 필수): `"keep"`은 worktree 디렉터리와 브랜치를 디스크에 그대로 보존하여 나중에 돌아올 수 있게 하고, `"remove"`는 worktree 디렉터리와 브랜치를 모두 삭제하여 깔끔하게 종료합니다.
+- `discard_changes` (불리언, 선택, 기본값 `false`): `action`이 `"remove"`일 때만 의미가 있습니다. worktree에 커밋되지 않은 파일이나 원래 브랜치에 없는 커밋이 있으면, `discard_changes`를 `true`로 설정하지 않는 한 도구가 삭제를 거부합니다. 오류 응답에는 해당 변경 사항 목록이 포함되므로 재호출 전에 사용자에게 확인할 수 있습니다.
+
+## 예시
+
+### 예시 1: 변경 사항 병합 후 깔끔한 종료
+
+worktree에서 작업을 마치고 브랜치를 메인에 병합한 후, `action: "remove"`를 지정하여 `ExitWorktree`를 호출하면 worktree 디렉터리와 브랜치가 삭제되고 원래 작업 디렉터리로 돌아갑니다.
+
+```
+ExitWorktree(action: "remove")
+```
+
+### 예시 2: 커밋되지 않은 실험 코드가 있는 임시 worktree 버리기
+
+worktree에 완전히 버려야 할 실험적인 미커밋 변경 사항이 있는 경우, 먼저 `action: "remove"`를 시도합니다. 도구가 거부하고 미커밋 변경 사항을 나열합니다. 변경 사항을 버려도 된다는 것을 사용자에게 확인한 후, `discard_changes: true`를 지정하여 다시 호출합니다.
+
+```
+ExitWorktree(action: "remove", discard_changes: true)
+```
+
+## 참고사항
+
+- 이 도구는 현재 세션에서 `EnterWorktree`로 생성된 worktree에만 작동합니다. `git worktree add`로 생성한 worktree, 이전 세션의 worktree, 또는 `EnterWorktree`를 호출한 적이 없는 일반 작업 디렉터리에는 영향을 미치지 않으며, 이러한 경우에는 아무 작업도 수행하지 않습니다.
+- worktree에 커밋되지 않은 변경 사항이나 원래 브랜치에 없는 커밋이 있으면, `discard_changes: true`를 명시적으로 지정하지 않는 한 `action: "remove"`는 거부됩니다. 데이터는 복구할 수 없으므로 `discard_changes: true`를 설정하기 전에 반드시 사용자에게 확인하십시오.
+- worktree에 tmux 세션이 연결된 경우: `remove`에서는 해당 세션이 종료되고, `keep`에서는 세션이 계속 실행되며 나중에 사용자가 재연결할 수 있도록 세션 이름이 반환됩니다.
+- `ExitWorktree` 완료 후 `EnterWorktree`를 다시 호출하여 새 worktree 세션을 시작할 수 있습니다.

package/concepts/ko/Tool-Glob.md

@@ -1,39 +1,35 @@
 # Glob
 
-## 정의
+글로브 패턴에 대해 파일 이름을 매칭하고 가장 최근 수정 시간 순으로 정렬된 경로를 반환합니다. `find`로 셸을 실행하지 않고도 어떤 규모의 코드베이스에서든 파일을 빠르게 찾는 데 최적화되어 있습니다.
 
-빠른 파일명 패턴 매칭 도구로, 모든 규모의 코드베이스를 지원합니다. 수정 시간순으로 정렬된 매칭 파일 경로를 반환합니다.
+## 사용 시점
 
-## 파라미터
+- 특정 확장자의 모든 파일 열거 (예: `src` 아래의 모든 `*.ts` 파일)
+- 명명 규칙으로 구성 또는 픽스처 파일 발견 (`**/jest.config.*`, `**/*.test.tsx`)
+- 대상을 지정한 `Grep`을 실행하기 전에 검색 표면 좁히기
+- `Write`를 호출하기 전에 알려진 패턴에 파일이 이미 존재하는지 확인
+- 수정 시간 순서에 의존하여 최근에 수정된 파일 찾기
 
-| 파라미터 | 타입 | 필수 | 설명 |
-|----------|------|------|------|
-| `pattern` | string | 예 | glob 패턴 (예: `**/*.js`, `src/**/*.ts`) |
-| `path` | string | 아니오 | 검색 디렉토리, 기본값은 현재 작업 디렉토리. "undefined"나 "null"을 전달하지 말 것 |
+## 매개변수
 
-## 사용 시나리오
+- `pattern` (string, 필수): 매칭할 글로브 표현식. 단일 세그먼트 와일드카드의 경우 `*`, 재귀 매치의 경우 `**`, 대안의 경우 `{a,b}`를 지원합니다 (예: `src/**/*.{ts,tsx}`).
+- `path` (string, 선택): 검색을 실행할 디렉토리. 제공되는 경우 유효한 디렉토리 경로여야 합니다. 현재 작업 디렉토리를 검색하려면 필드를 완전히 생략하십시오. 문자열 `"undefined"`나 `"null"`을 전달하지 마십시오.
 
-**적합한 경우:**
-- 파일명 패턴으로 파일 검색
-- 특정 타입의 모든 파일 검색 (예: 모든 `.tsx` 파일)
-- 특정 클래스 정의 (예: `class Foo`)를 찾을 때 먼저 파일 위치 파악
-- 단일 메시지 내에서 여러 Glob 호출을 병렬 실행 가능
+## 예시
 
-**적합하지 않은 경우:**
-- 파일 내용 검색 — Grep를 사용해야 함
-- 여러 라운드의 검색이 필요한 개방형 탐색 — Task (Explore 타입)를 사용해야 함
+### 예시 1: 모든 TypeScript 소스 파일
+`pattern: "src/**/*.ts"`로 `Glob`을 호출합니다. 결과는 mtime 순으로 정렬된 목록이므로, 가장 최근에 편집된 파일이 먼저 나타나 핫스팟에 집중하는 데 유용합니다.
 
-## 주의사항
+### 예시 2: 클래스 정의 후보 찾기
+이름을 모르는 파일에 클래스가 있다고 의심될 때, `pattern: "**/*UserService*"`로 검색하여 후보를 좁힌 다음 `Read` 또는 `Grep`으로 후속 작업을 진행합니다.
 
-- 표준 glob 구문 지원: `*`는 단일 레벨, `**`는 다중 레벨, `{}`는 다중 선택 매칭
-- 결과는 수정 시간순으로 정렬
-- Bash의 `find` 명령보다 권장
+### 예시 3: 대규모 작업 전 병렬 발견
+단일 메시지에서 여러 `Glob` 호출을 실행합니다 (예: `**/*.test.ts`용 하나와 `**/fixtures/**`용 하나). 이를 통해 둘 다 병렬로 실행되고 결과를 상관 관계로 지을 수 있습니다.
 
-## 원문
+## 참고사항
 
-<textarea readonly>- Fast file pattern matching tool that works with any codebase size
-- Supports glob patterns like "**/*.js" or "src/**/*.ts"
-- Returns matching file paths sorted by modification time
-- Use this tool when you need to find files by name patterns
-- When you are doing an open ended search that may require multiple rounds of globbing and grepping, use the Agent tool instead
-- You can call multiple tools in a single response. It is always better to speculatively perform multiple searches in parallel if they are potentially useful.</textarea>
+- 결과는 알파벳순이 아닌 파일 수정 시간 (최신 우선)으로 정렬됩니다. 안정적인 순서가 필요하면 다운스트림에서 정렬하십시오.
+- 패턴은 셸이 아닌 도구에 의해 평가됩니다. 명령 줄에서처럼 따옴표로 묶거나 이스케이프할 필요가 없습니다.
+- 여러 라운드의 검색과 추론이 필요한 개방형 탐색의 경우, 많은 `Glob` 호출을 연결하는 대신 Explore 에이전트 타입으로 `Agent`에 위임하십시오.
+- 파일 이름 발견에는 `find`나 `ls`의 `Bash` 호출보다 `Glob`을 선호하십시오. 권한을 일관되게 처리하고 구조화된 출력을 반환합니다.
+- 파일 이름이 아닌 파일 내용을 찾을 때는 대신 `Grep`을 사용하십시오.