cc-viewer 1.6.182 → 1.6.183

package/concepts/ko/Tool-Agent.md

@@ -1,125 +1,60 @@
 # Agent
 
-## 정의
+자체 컨텍스트 창을 갖춘 자율적인 Claude Code 서브에이전트를 생성하여 특정 작업을 처리하고 하나의 통합된 결과를 반환합니다. 이는 개방형 조사, 병렬 작업, 또는 팀 협업을 위임하는 표준적인 메커니즘입니다.
 
-서브 agent (SubAgent)를 시작하여 복잡한 다단계 태스크를 자율적으로 처리합니다. 서브 agent는 독립된 서브프로세스로, 각각 전용 도구 세트와 컨텍스트를 가집니다. Agent는 최신 Claude Code 버전에서 Task 도구의 이름이 변경된 버전입니다.
+## 사용 시점
 
-## 파라미터
+- 어떤 파일이 관련 있는지 아직 모르고 `Glob`, `Grep`, `Read`의 여러 라운드가 예상되는 개방형 검색.
+- 병렬 독립 작업 — 하나의 메시지에서 여러 에이전트를 실행하여 서로 다른 영역을 동시에 조사합니다.
+- 부모 컨텍스트를 간결하게 유지하기 위해 주요 대화로부터 노이즈가 많은 탐색을 분리합니다.
+- `Explore`, `Plan`, `claude-code-guide`, `statusline-setup`과 같은 전문화된 서브에이전트 타입에 위임합니다.
+- 조율된 다중 에이전트 작업을 위해 활성화된 팀에 명명된 팀원을 생성합니다.
 
-| 파라미터 | 타입 | 필수 | 설명 |
-|----------|------|------|------|
-| `prompt` | string | 예 | 서브 agent가 실행할 태스크 설명 |
-| `description` | string | 예 | 3~5단어의 짧은 요약 |
-| `subagent_type` | string | 예 | 서브 agent 타입, 사용 가능한 도구 세트를 결정 |
-| `model` | enum | 아니오 | 모델 지정 (sonnet / opus / haiku), 기본값은 부모로부터 상속 |
-| `max_turns` | integer | 아니오 | 최대 agentic 턴 수 |
-| `run_in_background` | boolean | 아니오 | 백그라운드 실행 여부. 백그라운드 태스크는 output_file 경로를 반환 |
-| `resume` | string | 아니오 | 재개할 agent ID, 이전 실행에서 계속. 컨텍스트를 잃지 않고 이전 서브 agent를 이어받는 데 유용 |
-| `isolation` | enum | 아니오 | 격리 모드, `worktree`로 임시 git worktree 생성 |
+대상 파일이나 심볼을 이미 알고 있는 경우에는 사용하지 마십시오 — `Read`, `Grep`, 또는 `Glob`을 직접 사용하십시오. `Agent`를 통한 한 단계 조회는 전체 컨텍스트 창을 낭비하고 지연 시간을 추가합니다.
 
-## 서브 agent 타입
+## 매개변수
 
-| 타입 | 용도 | 사용 가능한 도구 |
-|------|------|------------------|
-| `Bash` | 명령 실행, git 작업 | Bash |
-| `general-purpose` | 범용 다단계 태스크 | 전체 도구 |
-| `Explore` | 코드베이스 빠른 탐색 | Agent/Edit/Write/NotebookEdit/ExitPlanMode 외 모든 도구 |
-| `Plan` | 구현 방안 설계 | Agent/Edit/Write/NotebookEdit/ExitPlanMode 외 모든 도구 |
-| `claude-code-guide` | Claude Code 사용 가이드 Q&A | Glob, Grep, Read, WebFetch, WebSearch |
-| `statusline-setup` | 상태 표시줄 설정 | Read, Edit |
+- `description` (string, 필수): 작업을 설명하는 3-5 단어의 짧은 레이블로, UI와 로그에 표시됩니다.
+- `prompt` (string, 필수): 에이전트가 실행할 완전하고 자체 포함된 지시사항. 필요한 모든 컨텍스트, 제약 조건, 기대하는 반환 형식을 포함해야 합니다.
+- `subagent_type` (string, 선택): `general-purpose`, `Explore`, `Plan`, `claude-code-guide`, `statusline-setup`과 같은 사전 설정 페르소나. 기본값은 `general-purpose`입니다.
+- `run_in_background` (boolean, 선택): true인 경우 에이전트가 비동기로 실행되며 부모는 작업을 계속할 수 있습니다. 결과는 나중에 검색됩니다.
+- `model` (string, 선택): 이 에이전트에 대한 모델을 재정의합니다 — `opus`, `sonnet`, 또는 `haiku`. 기본값은 부모 세션의 모델입니다.
+- `isolation` (string, 선택): 에이전트의 파일시스템 쓰기가 부모와 충돌하지 않도록 격리된 git 워크트리 안에서 에이전트를 실행하려면 `worktree`로 설정합니다.
+- `team_name` (string, 선택): 기존 팀에 생성할 때 에이전트가 합류할 팀 식별자.
+- `name` (string, 선택): 팀 내에서 주소 지정 가능한 팀원 이름으로, `SendMessage`의 `to` 대상으로 사용됩니다.
 
-## 사용 시나리오
+## 예시
 
-**적합한 경우:**
-- 다단계로 자율 완료해야 하는 복잡한 태스크
-- 코드베이스 탐색 및 심층 조사 (Explore 타입 사용)
-- 격리 환경이 필요한 병렬 작업
-- 백그라운드 실행이 필요한 장시간 태스크
+### 예시 1: 개방형 코드 검색
 
-**적합하지 않은 경우:**
-- 특정 파일 경로 읽기 — 직접 Read 또는 Glob 사용
-- 2~3개 알려진 파일 내 검색 — 직접 Read 사용
-- 특정 클래스 정의 검색 — 직접 Glob 사용
+```
+Agent(
+  description="Find auth middleware",
+  subagent_type="Explore",
+  prompt="Locate every place in this repo where JWT verification is performed. Return a bulleted list of absolute file paths with a one-line note about each site's role. Do not modify any files."
+)
+```
 
-## 주의사항
+### 예시 2: 병렬 독립 조사
 
-- 서브 agent는 완료 후 단일 메시지를 반환하며, 그 결과는 사용자에게 보이지 않으므로 메인 agent가 전달해야 함
-- 단일 메시지 내에서 여러 병렬 Agent 호출을 발행하여 효율 향상 가능
-- 백그라운드 태스크는 TaskOutput 도구로 진행 상황 확인
-- Explore 타입은 직접 Glob/Grep 호출보다 느리므로, 단순 검색으로 충분하지 않을 때만 사용
-- 장시간 실행되며 즉시 결과가 필요 없는 태스크에는 `run_in_background: true` 권장; 결과가 필요한 경우 포그라운드(기본값) 사용
-- `resume` 파라미터를 통해 이전에 시작한 서브 agent 세션을 계속할 수 있으며, 축적된 컨텍스트를 유지
+같은 메시지에서 두 개의 에이전트를 실행합니다 — 하나는 빌드 파이프라인을 검사하고, 다른 하나는 테스트 하니스를 검토합니다. 각 에이전트는 자체 컨텍스트 창을 받고 요약을 반환합니다. 단일 도구 호출 블록에서 일괄 실행하면 동시에 실행됩니다.
 
-## 원문
+### 예시 3: 실행 중인 팀에 팀원 생성
 
-<textarea readonly>Launch a new agent to handle complex, multi-step tasks autonomously.
+```
+Agent(
+  description="Data layer specialist",
+  team_name="refactor-crew",
+  name="db-lead",
+  prompt="You are db-lead on team refactor-crew. Audit all Prisma schema files and propose a migration plan. Use SendMessage to report findings to the team leader."
+)
+```
 
-The Agent tool launches specialized agents (subprocesses) that autonomously handle complex tasks. Each agent type has specific capabilities and tools available to it.
+## 참고사항
 
-Available agent types and the tools they have access to:
-- general-purpose: General-purpose agent for researching complex questions, searching for code, and executing multi-step tasks. When you are searching for a keyword or file and are not confident that you will find the right match in the first few tries use this agent to perform the search for you. (Tools: *)
-- statusline-setup: Use this agent to configure the user's Claude Code status line setting. (Tools: Read, Edit)
-- Explore: Fast agent specialized for exploring codebases. Use this when you need to quickly find files by patterns (eg. "src/components/**/*.tsx"), search code for keywords (eg. "API endpoints"), or answer questions about the codebase (eg. "how do API endpoints work?"). When calling this agent, specify the desired thoroughness level: "quick" for basic searches, "medium" for moderate exploration, or "very thorough" for comprehensive analysis across multiple locations and naming conventions. (Tools: All tools except Agent, ExitPlanMode, Edit, Write, NotebookEdit)
-- Plan: Software architect agent for designing implementation plans. Use this when you need to plan the implementation strategy for a task. Returns step-by-step plans, identifies critical files, and considers architectural trade-offs. (Tools: All tools except Agent, ExitPlanMode, Edit, Write, NotebookEdit)
-- claude-code-guide: Use this agent when the user asks questions ("Can Claude...", "Does Claude...", "How do I...") about: (1) Claude Code (the CLI tool) - features, hooks, slash commands, MCP servers, settings, IDE integrations, keyboard shortcuts; (2) Claude Agent SDK - building custom agents; (3) Claude API (formerly Anthropic API) - API usage, tool use, Anthropic SDK usage. **IMPORTANT:** Before spawning a new agent, check if there is already a running or recently completed claude-code-guide agent that you can resume using the "resume" parameter. (Tools: Glob, Grep, Read, WebFetch, WebSearch)
-
-When using the Agent tool, you must specify a subagent_type parameter to select which agent type to use.
-
-When NOT to use the Agent tool:
-- If you want to read a specific file path, use the Read or Glob tool instead of the Agent tool, to find the match more quickly
-- If you are searching for a specific class definition like "class Foo", use the Glob tool instead, to find the match more quickly
-- If you are searching for code within a specific file or set of 2-3 files, use the Read tool instead of the Agent tool, to find the match more quickly
-- Other tasks that are not related to the agent descriptions above
-
-Usage notes:
-- Always include a short description (3-5 words) summarizing what the agent will do
-- Launch multiple agents concurrently whenever possible, to maximize performance; to do that, use a single message with multiple tool uses
-- When the agent is done, it will return a single message back to you. The result returned by the agent is not visible to the user. To show the user the result, you should send a text message back to the user with a concise summary of the result.
-- You can optionally run agents in the background using the run_in_background parameter. When an agent runs in the background, you will be automatically notified when it completes — do NOT sleep, poll, or proactively check on its progress. Continue with other work or respond to the user instead.
-- **Foreground vs background**: Use foreground (default) when you need the agent's results before you can proceed — e.g., research agents whose findings inform your next steps. Use background when you have genuinely independent work to do in parallel.
-- Agents can be resumed using the `resume` parameter by passing the agent ID from a previous invocation. When resumed, the agent continues with its full previous context preserved. When NOT resuming, each invocation starts fresh and you should provide a detailed task description with all necessary context.
-- When the agent is done, it will return a single message back to you along with its agent ID. You can use this ID to resume the agent later if needed for follow-up work.
-- Provide clear, detailed prompts so the agent can work autonomously and return exactly the information you need.
-- Agents with "access to current context" can see the full conversation history before the tool call. When using these agents, you can write concise prompts that reference earlier context (e.g., "investigate the error discussed above") instead of repeating information. The agent will receive all prior messages and understand the context.
-- The agent's outputs should generally be trusted
-- Clearly tell the agent whether you expect it to write code or just to do research (search, file reads, web fetches, etc.), since it is not aware of the user's intent
-- If the agent description mentions that it should be used proactively, then you should try your best to use it without the user having to ask for it first. Use your judgement.
-- If the user specifies that they want you to run agents "in parallel", you MUST send a single message with multiple Agent tool use content blocks. For example, if you need to launch both a build-validator agent and a test-runner agent in parallel, send a single message with both tool calls.
-- You can optionally set `isolation: "worktree"` to run the agent in a temporary git worktree, giving it an isolated copy of the repository. The worktree is automatically cleaned up if the agent makes no changes; if changes are made, the worktree path and branch are returned in the result.
-
-Example usage:
-
-<example_agent_descriptions>
-"test-runner": use this agent after you are done writing code to run tests
-"greeting-responder": use this agent to respond to user greetings with a friendly joke
-</example_agent_descriptions>
-
-<example>
-user: "Please write a function that checks if a number is prime"
-assistant: Sure let me write a function that checks if a number is prime
-assistant: First let me use the Write tool to write a function that checks if a number is prime
-assistant: I'm going to use the Write tool to write the following code:
-<code>
-function isPrime(n) {
-  if (n <= 1) return false
-  for (let i = 2; i * i <= n; i++) {
-    if (n % i === 0) return false
-  }
-  return true
-}
-</code>
-<commentary>
-Since a significant piece of code was written and the task was completed, now use the test-runner agent to run the tests
-</commentary>
-assistant: Now let me use the test-runner agent to run the tests
-assistant: Uses the Agent tool to launch the test-runner agent
-</example>
-
-<example>
-user: "Hello"
-<commentary>
-Since the user is greeting, use the greeting-responder agent to respond with a friendly joke
-</commentary>
-assistant: "I'm going to use the Agent tool to launch the greeting-responder agent"
-</example>
-</textarea>
+- 에이전트는 이전 실행의 메모리가 없습니다. 모든 호출은 제로에서 시작하므로 `prompt`는 완전히 자체 포함되어야 합니다 — 파일 경로, 규칙, 질문, 원하는 답변의 정확한 형태를 포함해야 합니다.
+- 에이전트는 정확히 하나의 최종 메시지를 반환합니다. 실행 중에 명확한 질문을 할 수 없으므로 프롬프트의 모호함은 결과에서 추측이 됩니다.
+- 병렬로 여러 에이전트를 실행하는 것은 서브태스크가 독립적인 경우 순차 호출보다 훨씬 빠릅니다. 단일 도구 호출 블록에서 일괄 처리하십시오.
+- 에이전트가 파일을 작성할 것이고 메인 작업 트리에 병합하기 전에 변경 사항을 검토하려면 언제든 `isolation: "worktree"`를 사용하십시오.
+- 읽기 전용 정찰에는 `subagent_type: "Explore"`를, 설계 작업에는 `Plan`을 선호하십시오. `general-purpose`는 혼합 읽기/쓰기 작업의 기본값입니다.
+- 백그라운드 에이전트 (`run_in_background: true`)는 장시간 실행되는 작업에 적합합니다. sleep 루프로 폴링하지 마십시오 — 완료 시 부모에게 알림이 갑니다.

package/concepts/ko/Tool-AskUserQuestion.md

@@ -1,75 +1,60 @@
 # AskUserQuestion
 
-## 정의
-
-실행 중 사용자에게 질문하여 확인 획득, 가설 검증 또는 결정 요청에 사용합니다.
-
-## 파라미터
-
-| 파라미터 | 타입 | 필수 | 설명 |
-|----------|------|------|------|
-| `questions` | array | 예 | 질문 목록 (1~4개 질문) |
-| `answers` | object | 아니오 | 사용자로부터 수집한 답변 |
-| `annotations` | object | 아니오 | 각 질문의 주석 (프리뷰 선택 비고 등) |
-| `metadata` | object | 아니오 | 추적 및 분석용 메타데이터 |
-
-각 `question` 객체:
-
-| 필드 | 타입 | 필수 | 설명 |
-|------|------|------|------|
-| `question` | string | 예 | 완전한 질문 텍스트. 물음표로 끝나야 함 |
-| `header` | string | 예 | 짧은 라벨 (최대 12자), 라벨 칩으로 표시 |
-| `options` | array | 예 | 2~4개 선택지 |
-| `multiSelect` | boolean | 예 | 다중 선택 허용 여부 |
-
-각 `option` 객체:
-
-| 필드 | 타입 | 필수 | 설명 |
-|------|------|------|------|
-| `label` | string | 예 | 선택지 표시 텍스트 (1~5단어) |
-| `description` | string | 예 | 선택지 설명 |
-| `markdown` | string | 아니오 | 프리뷰 콘텐츠 (ASCII 레이아웃, 코드 스니펫 등의 시각적 비교용) |
-
-## 사용 시나리오
-
-**적합한 경우:**
-- 사용자 선호도나 요구사항 수집
-- 모호한 지시 명확화
-- 구현 중 결정 획득
-- 사용자에게 방향 선택 제공
-
-**적합하지 않은 경우:**
-- "방안이 괜찮으신가요?"라고 묻는 경우 — ExitPlanMode를 사용해야 함
-
-## 주의사항
-
-- 사용자는 항상 "Other"를 선택하여 커스텀 입력을 제공할 수 있음
-- 추천 선택지는 첫 번째에 배치하고 label 끝에 "(Recommended)" 추가
-- `markdown` 프리뷰는 단일 선택 질문에만 지원
-- `markdown`이 있는 선택지는 좌우 병렬 레이아웃으로 전환
-- 계획 모드에서는 방안 확정 전 요구사항 명확화에 사용
-
-## 원문
-
-<textarea readonly>Use this tool when you need to ask the user questions during execution. This allows you to:
-1. Gather user preferences or requirements
-2. Clarify ambiguous instructions
-3. Get decisions on implementation choices as you work
-4. Offer choices to the user about what direction to take.
-
-Usage notes:
-- Users will always be able to select "Other" to provide custom text input
-- Use multiSelect: true to allow multiple answers to be selected for a question
-- If you recommend a specific option, make that the first option in the list and add "(Recommended)" at the end of the label
-
-Plan mode note: In plan mode, use this tool to clarify requirements or choose between approaches BEFORE finalizing your plan. Do NOT use this tool to ask "Is my plan ready?" or "Should I proceed?" - use ExitPlanMode for plan approval. IMPORTANT: Do not reference "the plan" in your questions (e.g., "Do you have feedback about the plan?", "Does the plan look good?") because the user cannot see the plan in the UI until you call ExitPlanMode. If you need plan approval, use ExitPlanMode instead.
-
-Preview feature:
-Use the optional `markdown` field on options when presenting concrete artifacts that users need to visually compare:
-- ASCII mockups of UI layouts or components
-- Code snippets showing different implementations
-- Diagram variations
-- Configuration examples
-
-When any option has a markdown, the UI switches to a side-by-side layout with a vertical option list on the left and preview on the right. Do not use previews for simple preference questions where labels and descriptions suffice. Note: previews are only supported for single-select questions (not multiSelect).
-</textarea>
+채팅 UI 내에서 사용자에게 하나 이상의 구조화된 객관식 질문을 제시하고, 선택 항목을 수집하여 어시스턴트에게 반환합니다 — 자유 형식의 왕복 대화 없이 의도를 명확히 하는 데 유용합니다.
+
+## 사용 시점
+
+- 요청에 여러 합리적인 해석이 있으며 진행하기 전에 사용자가 하나를 선택해야 합니다.
+- 사용자가 자유 텍스트 답변이 오류가 나기 쉬운 구체적인 옵션 (프레임워크, 라이브러리, 파일 경로, 전략) 중에서 선택해야 합니다.
+- 미리보기 창을 사용하여 대안을 나란히 비교하고 싶습니다.
+- 여러 관련 결정을 하나의 프롬프트로 일괄 처리하여 왕복을 줄일 수 있습니다.
+- 계획이나 도구 호출이 사용자가 아직 지정하지 않은 구성에 의존합니다.
+
+## 매개변수
+
+- `questions` (array, 필수): 단일 프롬프트에서 함께 표시되는 1개에서 4개의 질문. 각 질문 객체에는 다음이 포함됩니다:
+  - `question` (string, 필수): 물음표로 끝나는 전체 질문 텍스트.
+  - `header` (string, 필수): 질문 위에 칩으로 렌더링되는 짧은 레이블 (최대 12자).
+  - `options` (array, 필수): 2개에서 4개의 옵션 객체. 각 옵션에는 `label` (1-5단어), `description`, 선택적인 `markdown` 미리보기가 있습니다.
+  - `multiSelect` (boolean, 필수): `true`인 경우 사용자가 하나 이상을 선택할 수 있습니다.
+
+## 예시
+
+### 예시 1: 단일 프레임워크 선택
+
+```
+AskUserQuestion(questions=[{
+  "header": "Test runner",
+  "question": "Which test runner should I configure?",
+  "multiSelect": false,
+  "options": [
+    {"label": "Vitest (Recommended)", "description": "Fast, Vite-native, Jest-compatible API"},
+    {"label": "Jest",                  "description": "Mature, broadest plugin ecosystem"},
+    {"label": "Node --test",           "description": "Zero dependencies, built in"}
+  ]
+}])
+```
+
+### 예시 2: 두 레이아웃의 나란히 미리보기
+
+```
+AskUserQuestion(questions=[{
+  "header": "Layout",
+  "question": "Which dashboard layout do you prefer?",
+  "multiSelect": false,
+  "options": [
+    {"label": "Sidebar",  "description": "Nav on the left", "markdown": "```\n+------+---------+\n| NAV  | CONTENT |\n+------+---------+\n```"},
+    {"label": "Top bar",  "description": "Nav across top",  "markdown": "```\n+-----------------+\n|       NAV       |\n+-----------------+\n|     CONTENT     |\n+-----------------+\n```"}
+  ]
+}])
+```
+
+## 참고사항
+
+- UI는 모든 질문에 "Other" 자유 텍스트 옵션을 자동으로 추가합니다. 자체 "Other", "None", "Custom" 항목을 추가하지 마십시오 — 내장된 이스케이프 해치와 중복됩니다.
+- 각 호출을 1개에서 4개의 질문으로, 각 질문을 2개에서 4개의 옵션으로 제한하십시오. 이 범위를 초과하면 하니스에 의해 거부됩니다.
+- 특정 옵션을 추천하는 경우 먼저 배치하고 레이블에 "(Recommended)"를 추가하여 UI가 선호되는 경로를 강조 표시하도록 하십시오.
+- `markdown` 필드를 통한 미리보기는 단일 선택 질문에서만 지원됩니다. ASCII 레이아웃, 코드 스니펫, 구성 차이와 같은 시각적 아티팩트에 사용하십시오 — 레이블과 설명으로 충분한 간단한 선호도 질문에는 사용하지 마십시오.
+- 질문의 옵션에 `markdown` 값이 있으면 UI는 왼쪽에 옵션 목록, 오른쪽에 미리보기가 있는 나란히 배치된 레이아웃으로 전환됩니다.
+- "이 계획이 괜찮아 보이나요?"를 묻기 위해 `AskUserQuestion`을 사용하지 마십시오 — 계획 승인을 위해 존재하는 `ExitPlanMode`를 호출하십시오. 계획 모드에서는 질문 텍스트에 "계획"을 언급하는 것도 피하십시오. `ExitPlanMode`가 실행될 때까지 계획이 사용자에게 보이지 않기 때문입니다.
+- API 키나 비밀번호와 같은 민감한 정보나 자유 형식 입력을 요청하는 데 이 도구를 사용하지 마십시오. 대신 채팅에서 질문하십시오.

package/concepts/ko/Tool-Bash.md

@@ -1,167 +1,39 @@
 # Bash
 
-## 정의
+영속적인 작업 디렉토리 안에서 셸 명령을 실행하고 stdout/stderr를 반환합니다. git, npm, docker, 빌드 스크립트 실행과 같이 전용 Claude Code 도구로 표현할 수 없는 작업에 예약되어 있습니다.
 
-셸 명령을 실행하며, 선택적 타임아웃 설정을 지원합니다. 작업 디렉토리는 명령 간에 유지되지만, 셸 상태 (환경 변수 등)는 유지되지 않습니다.
+## 사용 시점
 
-## 파라미터
+- git 작업 실행 (`git status`, `git diff`, `git commit`, `gh pr create`)
+- 패키지 매니저 및 빌드 도구 실행 (`npm install`, `npm run build`, `pytest`, `cargo build`)
+- `run_in_background`를 사용하여 백그라운드에서 장시간 실행되는 프로세스 (개발 서버, watcher) 시작
+- 내장된 동등한 것이 없는 도메인별 CLI (`docker`, `terraform`, `kubectl`, `gh`) 호출
+- 순서가 중요한 경우 `&&`로 의존적인 단계를 함께 연결
 
-| 파라미터 | 타입 | 필수 | 설명 |
-|----------|------|------|------|
-| `command` | string | 예 | 실행할 bash 명령 |
-| `description` | string | 아니오 | 명령의 간단한 설명 |
-| `timeout` | number | 아니오 | 타임아웃 (밀리초), 최대 600000, 기본값 120000 |
-| `run_in_background` | boolean | 아니오 | 백그라운드에서 실행 여부 |
+## 매개변수
 
-## 사용 시나리오
+- `command` (string, 필수): 실행할 정확한 셸 명령.
+- `description` (string, 필수): 짧고 능동적인 어조의 요약 (간단한 명령의 경우 5-10단어; 파이프되거나 모호한 명령의 경우 더 많은 컨텍스트).
+- `timeout` (number, 선택): 밀리초 단위의 타임아웃, 최대 `600000` (10분). 기본값은 `120000` (2분)입니다.
+- `run_in_background` (boolean, 선택): `true`인 경우 명령이 분리되어 실행되며 완료 시 알림을 받습니다. `&`를 직접 추가하지 마십시오.
 
-**적합한 경우:**
-- git 작업 (commit, push, branch 등)
-- npm/yarn 등 패키지 관리 명령
-- docker 작업
-- 컴파일, 빌드 명령
-- 디렉토리 내용 목록 표시 (`ls`)
-- 기타 셸 실행이 필요한 시스템 명령
+## 예시
 
-**적합하지 않은 경우:**
-- 파일 읽기 — Read를 사용해야 함
-- 파일명 검색 — Glob를 사용해야 함
-- 파일 내용 검색 — Grep를 사용해야 함
-- 파일 편집 — Edit를 사용해야 함
-- 파일 쓰기 — Write를 사용해야 함
-- 사용자에게 정보 출력 — 응답 텍스트에 직접 출력
-- 장시간 실행 프로세스 (dev server, watch 모드) — 사용자에게 수동 실행 권장
+### 예시 1: 커밋 전 저장소 상태 검사
+같은 메시지에서 두 개의 병렬 `Bash` 호출로 `git status`와 `git diff --stat`을 실행하여 컨텍스트를 빠르게 수집한 다음, 후속 호출에서 커밋을 구성합니다.
 
-## 주의사항
+### 예시 2: 의존적인 빌드 단계 연결
+각 단계가 이전 단계가 성공한 후에만 실행되도록 `npm ci && npm run build && npm test`와 같은 단일 호출을 사용합니다. 실패 후에도 나중의 단계가 의도적으로 실행되기를 원할 때만 `;`를 사용하십시오.
 
-- 공백이 포함된 경로는 큰따옴표로 감싸야 함
-- 출력이 30000자를 초과하면 잘림
-- 백그라운드 실행 명령은 TaskOutput으로 결과 획득
-- 가능한 절대 경로를 사용하고 `cd`를 피할 것
-- 독립적인 명령은 여러 Bash를 병렬 호출 가능
-- 의존 관계가 있는 명령은 `&&`로 연결
-- 셸 환경은 사용자의 profile (bash 또는 zsh)에서 초기화
+### 예시 3: 장시간 실행되는 개발 서버
+`run_in_background: true`로 `npm run dev`를 호출합니다. 종료 시 알림을 받습니다. `sleep` 루프로 폴링하지 마십시오. 맹목적으로 재시도하는 대신 실패를 진단하십시오.
 
-## 원문
+## 참고사항
 
-<textarea readonly>Executes a given bash command and returns its output.
-
-The working directory persists between commands, but shell state does not. The shell environment is initialized from the user's profile (bash or zsh).
-
-IMPORTANT: Avoid using this tool to run `find`, `grep`, `cat`, `head`, `tail`, `sed`, `awk`, or `echo` commands, unless explicitly instructed or after you have verified that a dedicated tool cannot accomplish your task. Instead, use the appropriate dedicated tool as this will provide a much better experience for the user:
-
- - File search: Use Glob (NOT find or ls)
- - Content search: Use Grep (NOT grep or rg)
- - Read files: Use Read (NOT cat/head/tail)
- - Edit files: Use Edit (NOT sed/awk)
- - Write files: Use Write (NOT echo >/cat <<EOF)
- - Communication: Output text directly (NOT echo/printf)
-While the Bash tool can do similar things, it’s better to use the built-in tools as they provide a better user experience and make it easier to review tool calls and give permission.
-
-# Instructions
- - If your command will create new directories or files, first use this tool to run `ls` to verify the parent directory exists and is the correct location.
- - Always quote file paths that contain spaces with double quotes in your command (e.g., cd "path with spaces/file.txt")
- - Try to maintain your current working directory throughout the session by using absolute paths and avoiding usage of `cd`. You may use `cd` if the User explicitly requests it.
- - You may specify an optional timeout in milliseconds (up to 600000ms / 10 minutes). By default, your command will timeout after 120000ms (2 minutes).
- - You can use the `run_in_background` parameter to run the command in the background. Only use this if you don't need the result immediately and are OK being notified when the command completes later. You do not need to check the output right away - you'll be notified when it finishes. You do not need to use '&' at the end of the command when using this parameter.
- - Write a clear, concise description of what your command does. For simple commands, keep it brief (5-10 words). For complex commands (piped commands, obscure flags, or anything hard to understand at a glance), include enough context so that the user can understand what your command will do.
- - When issuing multiple commands:
-  - If the commands are independent and can run in parallel, make multiple Bash tool calls in a single message. Example: if you need to run "git status" and "git diff", send a single message with two Bash tool calls in parallel.
-  - If the commands depend on each other and must run sequentially, use a single Bash call with '&&' to chain them together.
-  - Use ';' only when you need to run commands sequentially but don't care if earlier commands fail.
-  - DO NOT use newlines to separate commands (newlines are ok in quoted strings).
- - For git commands:
-  - Prefer to create a new commit rather than amending an existing commit.
-  - Before running destructive operations (e.g., git reset --hard, git push --force, git checkout --), consider whether there is a safer alternative that achieves the same goal. Only use destructive operations when they are truly the best approach.
-  - Never skip hooks (--no-verify) or bypass signing (--no-gpg-sign, -c commit.gpgsign=false) unless the user has explicitly asked for it. If a hook fails, investigate and fix the underlying issue.
- - Avoid unnecessary `sleep` commands:
-  - Do not sleep between commands that can run immediately — just run them.
-  - If your command is long running and you would like to be notified when it finishes – simply run your command using `run_in_background`. There is no need to sleep in this case.
-  - Do not retry failing commands in a sleep loop — diagnose the root cause or consider an alternative approach.
-  - If waiting for a background task you started with `run_in_background`, you will be notified when it completes — do not poll.
-  - If you must poll an external process, use a check command (e.g. `gh run view`) rather than sleeping first.
-  - If you must sleep, keep the duration short (1-5 seconds) to avoid blocking the user.
-
-# Committing changes with git
-
-Only create commits when requested by the user. If unclear, ask first. When the user asks you to create a new git commit, follow these steps carefully:
-
-Git Safety Protocol:
-- NEVER update the git config
-- NEVER run destructive git commands (push --force, reset --hard, checkout ., restore ., clean -f, branch -D) unless the user explicitly requests these actions. Taking unauthorized destructive actions is unhelpful and can result in lost work, so it's best to ONLY run these commands when given direct instructions 
-- NEVER skip hooks (--no-verify, --no-gpg-sign, etc) unless the user explicitly requests it
-- NEVER run force push to main/master, warn the user if they request it
-- CRITICAL: Always create NEW commits rather than amending, unless the user explicitly requests a git amend. When a pre-commit hook fails, the commit did NOT happen — so --amend would modify the PREVIOUS commit, which may result in destroying work or losing previous changes. Instead, after hook failure, fix the issue, re-stage, and create a NEW commit
-- When staging files, prefer adding specific files by name rather than using "git add -A" or "git add .", which can accidentally include sensitive files (.env, credentials) or large binaries
-- NEVER commit changes unless the user explicitly asks you to. It is VERY IMPORTANT to only commit when explicitly asked, otherwise the user will feel that you are being too proactive
-
-1. You can call multiple tools in a single response. When multiple independent pieces of information are requested and all commands are likely to succeed, run multiple tool calls in parallel for optimal performance. run the following bash commands in parallel, each using the Bash tool:
-  - Run a git status command to see all untracked files. IMPORTANT: Never use the -uall flag as it can cause memory issues on large repos.
-  - Run a git diff command to see both staged and unstaged changes that will be committed.
-  - Run a git log command to see recent commit messages, so that you can follow this repository's commit message style.
-2. Analyze all staged changes (both previously staged and newly added) and draft a commit message:
-  - Summarize the nature of the changes (eg. new feature, enhancement to an existing feature, bug fix, refactoring, test, docs, etc.). Ensure the message accurately reflects the changes and their purpose (i.e. "add" means a wholly new feature, "update" means an enhancement to an existing feature, "fix" means a bug fix, etc.).
-  - Do not commit files that likely contain secrets (.env, credentials.json, etc). Warn the user if they specifically request to commit those files
-  - Draft a concise (1-2 sentences) commit message that focuses on the "why" rather than the "what"
-  - Ensure it accurately reflects the changes and their purpose
-3. You can call multiple tools in a single response. When multiple independent pieces of information are requested and all commands are likely to succeed, run multiple tool calls in parallel for optimal performance. run the following commands:
-   - Add relevant untracked files to the staging area.
-   - Create the commit with a message ending with:
-   Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
-   - Run git status after the commit completes to verify success.
-   Note: git status depends on the commit completing, so run it sequentially after the commit.
-4. If the commit fails due to pre-commit hook: fix the issue and create a NEW commit
-
-Important notes:
-- NEVER run additional commands to read or explore code, besides git bash commands
-- NEVER use the TodoWrite or Agent tools
-- DO NOT push to the remote repository unless the user explicitly asks you to do so
-- IMPORTANT: Never use git commands with the -i flag (like git rebase -i or git add -i) since they require interactive input which is not supported.
-- IMPORTANT: Do not use --no-edit with git rebase commands, as the --no-edit flag is not a valid option for git rebase.
-- If there are no changes to commit (i.e., no untracked files and no modifications), do not create an empty commit
-- In order to ensure good formatting, ALWAYS pass the commit message via a HEREDOC, a la this example:
-<example>
-git commit -m "$(cat <<'EOF'
-   Commit message here.
-
-   Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
-   EOF
-   )"
-</example>
-
-# Creating pull requests
-Use the gh command via the Bash tool for ALL GitHub-related tasks including working with issues, pull requests, checks, and releases. If given a Github URL use the gh command to get the information needed.
-
-IMPORTANT: When the user asks you to create a pull request, follow these steps carefully:
-
-1. You can call multiple tools in a single response. When multiple independent pieces of information are requested and all commands are likely to succeed, run multiple tool calls in parallel for optimal performance. run the following bash commands in parallel using the Bash tool, in order to understand the current state of the branch since it diverged from the main branch:
-   - Run a git status command to see all untracked files (never use -uall flag)
-   - Run a git diff command to see both staged and unstaged changes that will be committed
-   - Check if the current branch tracks a remote branch and is up to date with the remote, so you know if you need to push to the remote
-   - Run a git log command and `git diff [base-branch]...HEAD` to understand the full commit history for the current branch (from the time it diverged from the base branch)
-2. Analyze all changes that will be included in the pull request, making sure to look at all relevant commits (NOT just the latest commit, but ALL commits that will be included in the pull request!!!), and draft a pull request title and summary:
-   - Keep the PR title short (under 70 characters)
-   - Use the description/body for details, not the title
-3. You can call multiple tools in a single response. When multiple independent pieces of information are requested and all commands are likely to succeed, run multiple tool calls in parallel for optimal performance. run the following commands in parallel:
-   - Create new branch if needed
-   - Push to remote with -u flag if needed
-   - Create PR using gh pr create with the format below. Use a HEREDOC to pass the body to ensure correct formatting.
-<example>
-gh pr create --title "the pr title" --body "$(cat <<'EOF'
-## Summary
-<1-3 bullet points>
-
-## Test plan
-[Bulleted markdown checklist of TODOs for testing the pull request...]
-
-🤖 Generated with [Claude Code](https://claude.com/claude-code)
-EOF
-)"
-</example>
-
-Important:
-- DO NOT use the TodoWrite or Agent tools
-- Return the PR URL when you're done, so the user can see it
-
-# Other common operations
-- View comments on a Github PR: gh api repos/foo/bar/pulls/123/comments</textarea>
+- 작업 디렉토리는 호출 간에 유지되지만 셸 상태 (내보낸 변수, 셸 함수, 별칭)는 유지되지 않습니다. 절대 경로를 선호하고 사용자가 요청하지 않는 한 `cd`를 피하십시오.
+- 파이프된 셸 동등물보다 전용 도구를 선호하십시오: `find`/`ls` 대신 `Glob`, `grep`/`rg` 대신 `Grep`, `cat`/`head`/`tail` 대신 `Read`, `sed`/`awk` 대신 `Edit`, `echo >` 또는 히어독 대신 `Write`, 사용자에게 표시되는 출력의 경우 `echo`/`printf` 대신 일반 어시스턴트 텍스트.
+- 공백이 포함된 경로는 큰따옴표로 묶으십시오 (예: `"/Users/me/My Project/file.txt"`).
+- 독립 명령의 경우 단일 메시지 내에서 여러 `Bash` 도구 호출을 병렬로 수행하십시오. 한 명령이 다른 명령에 의존하는 경우에만 `&&`로 연결하십시오.
+- 30000자 이상의 출력은 잘립니다. 큰 로그를 캡처할 때는 파일로 리다이렉트한 다음 `Read` 도구로 읽으십시오.
+- `git rebase -i`나 `git add -i`와 같은 대화형 플래그를 사용하지 마십시오. 이 도구를 통해 입력을 받을 수 없습니다.
+- 사용자가 명시적으로 요청하지 않는 한 git 후크를 건너뛰거나 (`--no-verify`, `--no-gpg-sign`) 파괴적인 작업 (`reset --hard`, `push --force`, `clean -f`)을 수행하지 마십시오.

package/concepts/ko/Tool-CronCreate.md

@@ -0,0 +1,57 @@
+# CronCreate
+
+프롬프트를 미래의 특정 시간에 실행되도록 대기열에 등록합니다. 일회성 실행과 반복 실행 모두 지원합니다. 사용자의 로컬 시간대를 기준으로 표준 5필드 cron 표현식을 사용하므로 시간대 변환이 필요하지 않습니다.
+
+## 사용 시점
+
+- **일회성 알림**: 사용자가 특정 시간에 알림을 원할 때 ("내일 오후 3시에 알려줘"). `recurring: false`로 설정하면 한 번 실행된 후 자동으로 삭제됩니다.
+- **반복 일정**: 사용자가 주기적으로 실행되길 원할 때 ("매 평일 오전 9시", "30분마다"). 기본값인 `recurring: true`를 사용합니다.
+- **자율 에이전트 루프**: 일일 요약이나 주기적 상태 확인처럼 스스로 재실행되는 워크플로를 구성할 때.
+- **지속성 작업**: 세션 재시작 후에도 일정을 유지해야 할 때. `durable: true`를 전달하면 `.claude/scheduled_tasks.json`에 저장됩니다.
+- **대략적인 시간 요청**: 사용자가 "오전 9시쯤" 또는 "매시간"이라고 말할 때, `:00`이나 `:30`을 피하고 비정각 분 값(예: `57 8 * * *` 또는 `7 * * * *`)을 선택하여 서버 부하를 분산시킵니다.
+
+## 매개변수
+
+- `cron` (string, 필수): 사용자의 로컬 시간대 기준 5필드 cron 표현식. 형식은 `분 시 일 월 요일`입니다. 예: `"0 9 * * 1-5"`는 월요일~금요일 오전 9:00을 의미합니다.
+- `prompt` (string, 필수): cron이 실행될 때 대기열에 추가될 프롬프트 텍스트. 예약된 시간에 REPL에 제출되는 정확한 메시지입니다.
+- `recurring` (boolean, 선택, 기본값 `true`): `true`이면 매 cron 주기마다 실행되며 7일 후 자동 만료됩니다. `false`이면 한 번만 실행된 후 자동 삭제됩니다 — 일회성 알림에 사용합니다.
+- `durable` (boolean, 선택, 기본값 `false`): `false`이면 메모리에만 저장되며 세션 종료 시 사라집니다. `true`이면 `.claude/scheduled_tasks.json`에 저장되어 재시작 후에도 유지됩니다.
+
+## 예시
+
+### 예시 1: 일회성 알림
+
+사용자 말: "내일 오후 2시 30분에 주간 보고서 보내라고 알려줘." 내일이 4월 21일이라고 가정:
+
+```json
+{
+  "cron": "30 14 21 4 *",
+  "prompt": "알림: 지금 주간 보고서를 보내세요.",
+  "recurring": false,
+  "durable": true
+}
+```
+
+`recurring: false`로 실행 후 자동 삭제됩니다. `durable: true`로 재시작 전에도 유지됩니다.
+
+### 예시 2: 반복 평일 오전 작업
+
+사용자 말: "매 평일 오전마다 내 GitHub 미해결 이슈를 요약해줘."
+
+```json
+{
+  "cron": "3 9 * * 1-5",
+  "prompt": "나에게 할당된 모든 미해결 GitHub 이슈를 요약하세요.",
+  "recurring": true,
+  "durable": true
+}
+```
+
+분 값으로 `0` 대신 `3`을 사용하여 정각 부하 집중을 피합니다. 작업은 7일 후 자동 만료됩니다.
+
+## 참고사항
+
+- **7일 자동 만료**: 반복 작업은 최대 7일 동안 실행된 후 자동으로 삭제됩니다. 더 긴 일정이 필요하면 만료 전에 다시 만드세요.
+- **유휴 상태일 때만 실행**: `CronCreate`는 REPL이 다른 쿼리를 처리하지 않을 때만 프롬프트를 대기열에 추가합니다. 실행 시점에 REPL이 바쁘면 현재 쿼리가 완료될 때까지 대기합니다.
+- **:00과 :30 분 값 회피**: 대략적인 시간 요청에는 의도적으로 비정각 분 값을 선택하여 시스템 부하를 분산시키세요. 사용자가 정확한 분을 지정할 때만 :00이나 :30을 사용합니다.
+- **시간대 변환 불필요**: cron 표현식은 사용자의 로컬 시간대로 직접 해석됩니다. UTC나 다른 시간대로 변환할 필요가 없습니다.