cc-viewer 1.6.182 → 1.6.183

package/concepts/ko/Tool-Grep.md

@@ -1,57 +1,46 @@
 # Grep
 
-## 정의
-
-ripgrep 기반의 강력한 콘텐츠 검색 도구. 정규 표현식, 파일 타입 필터링, 다양한 출력 모드를 지원합니다.
-
-## 파라미터
-
-| 파라미터 | 타입 | 필수 | 설명 |
-|----------|------|------|------|
-| `pattern` | string | 예 | 정규 표현식 검색 패턴 |
-| `path` | string | 아니오 | 검색 경로 (파일 또는 디렉토리), 기본값은 현재 작업 디렉토리 |
-| `glob` | string | 아니오 | 파일명 필터 (예: `*.js`, `*.{ts,tsx}`) |
-| `type` | string | 아니오 | 파일 타입 필터 (예: `js`, `py`, `rust`), glob보다 효율적 |
-| `output_mode` | enum | 아니오 | 출력 모드: `files_with_matches` (기본값), `content`, `count` |
-| `-i` | boolean | 아니오 | 대소문자 구분 없는 검색 |
-| `-n` | boolean | 아니오 | 행 번호 표시 (content 모드만), 기본값 true |
-| `-A` | number | 아니오 | 매치 후 표시할 행 수 |
-| `-B` | number | 아니오 | 매치 전 표시할 행 수 |
-| `-C` / `context` | number | 아니오 | 매치 전후 표시할 행 수 |
-| `head_limit` | number | 아니오 | 출력 항목 수 제한, 기본값 0 (무제한) |
-| `offset` | number | 아니오 | 처음 N개 결과 건너뛰기 |
-| `multiline` | boolean | 아니오 | 다중 행 매칭 모드 활성화, 기본값 false |
-
-## 사용 시나리오
-
-**적합한 경우:**
-- 코드베이스에서 특정 문자열이나 패턴 검색
-- 함수/변수의 사용 위치 검색
-- 파일 타입으로 검색 결과 필터링
-- 매치 수 집계
-
-**적합하지 않은 경우:**
-- 파일명으로 파일 검색 — Glob를 사용해야 함
-- 여러 라운드의 검색이 필요한 개방형 탐색 — Task (Explore 타입)를 사용해야 함
-
-## 주의사항
-
-- ripgrep 구문 사용 (grep이 아님), 중괄호 등 특수 문자는 이스케이프 필요
-- `files_with_matches` 모드는 파일 경로만 반환하며 가장 효율적
-- `content` 모드는 매칭 행 내용을 반환하며 컨텍스트 행 지원
-- 다중 행 매칭은 `multiline: true` 설정 필요
-- Bash 내의 `grep`이나 `rg` 명령보다 항상 Grep 도구를 우선 사용
-
-## 원문
-
-<textarea readonly>A powerful search tool built on ripgrep
-
-  Usage:
-  - ALWAYS use Grep for search tasks. NEVER invoke `grep` or `rg` as a Bash command. The Grep tool has been optimized for correct permissions and access.
-  - Supports full regex syntax (e.g., "log.*Error", "function\s+\w+")
-  - Filter files with glob parameter (e.g., "*.js", "**/*.tsx") or type parameter (e.g., "js", "py", "rust")
-  - Output modes: "content" shows matching lines, "files_with_matches" shows only file paths (default), "count" shows match counts
-  - Use Agent tool for open-ended searches requiring multiple rounds
-  - Pattern syntax: Uses ripgrep (not grep) - literal braces need escaping (use `interface\{\}` to find `interface{}` in Go code)
-  - Multiline matching: By default patterns match within single lines only. For cross-line patterns like `struct \{[\s\S]*?field`, use `multiline: true`
-</textarea>
+ripgrep 엔진을 사용하여 파일 내용을 검색합니다. 완전한 정규 표현식 지원, 파일 타입 필터링, 세 가지 출력 모드를 제공하여 정밀도와 간결성을 트레이드할 수 있습니다.
+
+## 사용 시점
+
+- 함수의 모든 호출 사이트나 식별자에 대한 모든 참조 찾기
+- 문자열이나 오류 메시지가 코드베이스 어디에든 나타나는지 확인
+- 리팩터링 전에 영향을 측정하기 위해 패턴의 발생 횟수 계산
+- 파일 타입 (`type: "ts"`) 또는 글로브 (`glob: "**/*.tsx"`)로 검색 좁히기
+- `multiline: true`로 여러 줄의 구조체 정의나 JSX 블록과 같은 교차 줄 매치 가져오기
+
+## 매개변수
+
+- `pattern` (string, 필수): 검색할 정규 표현식. ripgrep 문법을 사용하므로 리터럴 중괄호는 이스케이프가 필요합니다 (예: `interface{}`를 찾으려면 `interface\{\}`).
+- `path` (string, 선택): 검색할 파일 또는 디렉토리. 기본값은 현재 작업 디렉토리입니다.
+- `glob` (string, 선택): `*.js` 또는 `*.{ts,tsx}`와 같은 파일 이름 필터.
+- `type` (string, 선택): `js`, `py`, `rust`, `go`와 같은 파일 타입 단축키. 표준 언어의 경우 `glob`보다 효율적입니다.
+- `output_mode` (enum, 선택): `files_with_matches` (기본값, 경로만 반환), `content` (매칭 줄 반환), 또는 `count` (매치 횟수 반환).
+- `-i` (boolean, 선택): 대소문자 구분 없는 매칭.
+- `-n` (boolean, 선택): `content` 모드에서 줄 번호 포함. 기본값은 `true`입니다.
+- `-A` (number, 선택): 각 매치 뒤에 표시할 컨텍스트 줄 수 (`content` 모드 필요).
+- `-B` (number, 선택): 각 매치 앞의 컨텍스트 줄 수 (`content` 모드 필요).
+- `-C` / `context` (number, 선택): 각 매치 양쪽의 컨텍스트 줄 수.
+- `multiline` (boolean, 선택): 패턴이 줄바꿈을 걸칠 수 있도록 허용합니다 (`.`이 `\n`과 매치). 기본값은 `false`입니다.
+- `head_limit` (number, 선택): 반환되는 줄, 파일 경로, 또는 카운트 항목을 제한합니다. 기본값은 250. 무제한은 `0`을 전달하십시오 (신중하게 사용).
+- `offset` (number, 선택): `head_limit`을 적용하기 전에 처음 N개 결과를 건너뜁니다. 기본값은 `0`입니다.
+
+## 예시
+
+### 예시 1: 함수의 모든 호출 사이트 찾기
+각 호출의 주변 줄을 보려면 `pattern: "registerHandler\\("`, `output_mode: "content"`, `-C: 2`를 설정합니다.
+
+### 예시 2: 타입 전체의 매치 수 계산
+Python 소스에서 파일별 TODO 합계를 보려면 `pattern: "TODO"`, `type: "py"`, `output_mode: "count"`를 설정합니다.
+
+### 예시 3: 다중 라인 구조체 매치
+Go 구조체의 여러 줄에 선언된 필드를 캡처하려면 `pattern: "struct Config \\{[\\s\\S]*?version"`과 `multiline: true`를 사용합니다.
+
+## 참고사항
+
+- `Bash`를 통해 `grep`이나 `rg`를 실행하는 것보다 항상 `Grep`을 선호하십시오. 이 도구는 올바른 권한과 구조화된 출력에 최적화되어 있습니다.
+- 기본 출력 모드는 `files_with_matches`로 가장 저렴합니다. 라인 자체를 봐야 할 때만 `content`로 전환하십시오.
+- 컨텍스트 플래그 (`-A`, `-B`, `-C`)는 `output_mode`가 `content`가 아니면 무시됩니다.
+- 큰 결과 세트는 컨텍스트 토큰을 소모합니다. 초점을 유지하려면 `head_limit`, `offset`, 또는 더 엄격한 `glob`/`type` 필터를 사용하십시오.
+- 파일 이름 발견의 경우 대신 `Glob`을 사용하십시오. 여러 라운드에 걸친 개방형 조사의 경우 Explore 에이전트로 `Agent`를 디스패치하십시오.

package/concepts/ko/Tool-Monitor.md

@@ -0,0 +1,50 @@
+# Monitor
+
+장시간 실행되는 스크립트에서 이벤트를 스트리밍하는 백그라운드 모니터를 시작합니다. 표준 출력의 각 줄이 알림이 됩니다 — 작업을 계속하면서 이벤트가 채팅에 도착합니다.
+
+## 사용 시점
+
+- 배포가 실행되는 동안 로그 파일의 오류, 경고 또는 충돌 특징을 지속적으로 추적할 때
+- 원격 API, PR 또는 CI 파이프라인을 30초마다 폴링하여 새로운 상태 이벤트를 확인할 때
+- 파일시스템 디렉토리나 빌드 출력의 변화를 실시간으로 감시할 때
+- 많은 반복에 걸쳐 특정 조건을 기다릴 때 (예: 학습 단계 마일스톤 또는 큐 소진)
+- 단순한 "완료까지 대기"에는 **사용하지 않는다** — 그 경우 `run_in_background`가 있는 `Bash`를 사용하면 프로세스 종료 시 완료 알림이 한 번 전송된다
+
+## 매개변수
+
+- `command` (문자열, 필수): 실행할 셸 명령 또는 스크립트. 표준 출력에 쓰인 각 줄이 독립적인 알림 이벤트가 된다. 프로세스가 종료되면 모니터가 끝난다.
+- `description` (문자열, 필수): 모든 알림에 표시되는 짧고 읽기 쉬운 레이블. 구체적으로 작성할 것 — "deploy.log의 오류"가 "로그 감시 중"보다 낫다. 이 레이블로 어떤 모니터가 발동했는지 식별한다.
+- `timeout_ms` (숫자, 기본값 `300000`, 최대 `3600000`): 강제 종료 기한 (밀리초). 이 시간이 지나면 프로세스가 종료된다. `persistent: true`일 때는 무시된다.
+- `persistent` (불리언, 기본값 `false`): `true`로 설정하면 모니터가 타임아웃 없이 세션 전체 동안 실행된다. `TaskStop`으로 명시적으로 중지한다.
+
+## 예시
+
+### 예시 1: 로그 파일의 오류와 충돌 추적
+
+이 예시는 모든 종료 상태를 커버한다: 성공 마커, 트레이스백, 일반적인 오류 키워드, OOM 강제 종료, 예기치 않은 프로세스 종료.
+
+```bash
+tail -F /var/log/deploy.log | grep -E --line-buffered \
+  "deployed|Traceback|Error|FAILED|assert|Killed|OOM"
+```
+
+모든 파이프에서 `grep --line-buffered`를 사용할 것. 사용하지 않으면 OS가 4 KB 블록 단위로 출력을 버퍼링하여 이벤트가 수 분 지연된다. 교대 패턴은 성공 경로(`deployed`)와 실패 경로(`Traceback`, `Error`, `FAILED`, `Killed`, `OOM`) 모두를 커버한다. 성공 마커만 감시하는 모니터는 충돌 시 침묵한다 — 침묵은 "아직 실행 중"과 구별할 수 없다.
+
+### 예시 2: 원격 API를 30초마다 폴링
+
+```bash
+while true; do
+  curl -sf "https://api.example.com/status" || true
+  sleep 30
+done | grep --line-buffered -E "completed|failed|error"
+```
+
+`|| true`는 일시적인 네트워크 장애로 루프가 종료되는 것을 방지한다. 속도 제한을 피하려면 원격 API에 30초 이상의 폴링 간격이 적절하다. grep 패턴을 조정하여 성공과 실패 응답을 모두 캡처하고 API 측 오류가 침묵으로 가려지지 않도록 한다.
+
+## 참고사항
+
+- **파이프에서 항상 `grep --line-buffered`를 사용할 것.** 사용하지 않으면 OS가 4 KB 블록이 채워질 때까지 출력을 축적하기 때문에 파이프 버퍼링으로 인해 이벤트가 수 분 지연된다. `--line-buffered`는 각 줄 후에 강제로 플러시한다.
+- **필터는 성공과 실패 시그니처를 모두 커버해야 한다.** 성공 마커만 감시하는 모니터는 충돌, 행, 예기치 않은 종료 시 침묵한다. 교대 패턴을 넓힌다: 성공 키워드 외에도 `Error`, `Traceback`, `FAILED`, `Killed`, `OOM` 등 종료 상태 마커를 포함한다.
+- **원격 API의 폴링 간격은 30초 이상으로 할 것.** 외부 서비스에 대한 고빈도 폴링은 속도 제한 오류나 차단 위험이 있다. 로컬 파일시스템이나 프로세스 확인에는 0.5~1초가 적절하다.
+- **세션 전체 모니터링에는 `persistent: true`를 사용할 것.** 기본 `timeout_ms`는 300,000ms(5분)으로 프로세스가 종료된다. 명시적으로 중지할 때까지 계속 실행하려면 `persistent: true`를 설정하고 완료 후 `TaskStop`을 호출한다.
+- **이벤트 과다 시 자동 중지.** 표준 출력의 각 줄이 대화 메시지가 된다. 필터가 너무 넓어 너무 많은 이벤트가 발생하면 모니터가 자동으로 중지된다. 더 좁은 `grep` 패턴으로 재시작할 것. 200ms 이내에 도착하는 줄들은 하나의 알림으로 묶인다.

package/concepts/ko/Tool-NotebookEdit.md

@@ -1,33 +1,39 @@
 # NotebookEdit
 
-## 정의
+Jupyter 노트북 (`.ipynb`) 내의 단일 셀을 수정합니다. 노트북 구조의 나머지를 보존하면서 셀의 소스 교체, 새 셀 삽입, 기존 셀 삭제를 지원합니다.
 
-Jupyter notebook (.ipynb 파일) 내의 특정 셀을 치환, 삽입 또는 삭제합니다.
+## 사용 시점
 
-## 파라미터
+- 전체 파일을 다시 작성하지 않고 분석 노트북의 코드 셀 수정 또는 업데이트
+- 서술을 개선하거나 문서를 추가하기 위해 마크다운 셀 교체
+- 기존 노트북의 알려진 위치에 새 코드 또는 마크다운 셀 삽입
+- 다운스트림 셀이 더 이상 의존하지 않도록 오래되거나 손상된 셀 제거
+- 셀을 하나씩 반복하여 재현 가능한 노트북 준비
 
-| 파라미터 | 타입 | 필수 | 설명 |
-|----------|------|------|------|
-| `notebook_path` | string | 예 | notebook 파일의 절대 경로 |
-| `new_source` | string | 예 | 셀의 새 내용 |
-| `cell_id` | string | 아니오 | 편집할 셀 ID. 삽입 모드에서는 새 셀이 이 ID 뒤에 삽입됨 |
-| `cell_type` | enum | 아니오 | 셀 타입: `code` 또는 `markdown`. 삽입 모드에서 필수 |
-| `edit_mode` | enum | 아니오 | 편집 모드: `replace` (기본값), `insert`, `delete` |
+## 매개변수
 
-## 사용 시나리오
+- `notebook_path` (string, 필수): `.ipynb` 파일의 절대 경로. 상대 경로는 거부됩니다.
+- `new_source` (string, 필수): 새 셀 소스. `replace`와 `insert`의 경우 셀 본문이 됩니다. `delete`의 경우 무시되지만 스키마에 의해 여전히 필요합니다.
+- `cell_id` (string, 선택): 대상 셀의 ID. `replace`와 `delete` 모드에서 도구는 이 셀에 작동합니다. `insert` 모드에서 새 셀은 이 ID를 가진 셀 바로 뒤에 삽입됩니다. 노트북 맨 위에 삽입하려면 생략하십시오.
+- `cell_type` (enum, 선택): `code` 또는 `markdown`. `edit_mode`가 `insert`일 때 필수입니다. `replace` 중에 생략되면 기존 셀의 타입이 유지됩니다.
+- `edit_mode` (enum, 선택): `replace` (기본값), `insert`, 또는 `delete`.
 
-**적합한 경우:**
-- Jupyter notebook 내의 코드 또는 markdown 셀 수정
-- notebook에 새 셀 추가
-- notebook 내의 셀 삭제
+## 예시
 
-## 주의사항
+### 예시 1: 버그가 있는 코드 셀 교체
+절대 경로로 설정된 `notebook_path`, 대상 셀의 ID로 설정된 `cell_id`, 수정된 Python 코드를 포함하는 `new_source`로 `NotebookEdit`를 호출합니다. `edit_mode`는 기본값 `replace`로 둡니다.
 
-- `cell_number`는 0 인덱스
-- `insert` 모드는 지정 위치에 새 셀을 삽입
-- `delete` 모드는 지정 위치의 셀을 삭제
-- 경로는 절대 경로여야 함
+### 예시 2: 마크다운 설명 삽입
+기존 `setup` 셀 바로 뒤에 마크다운 셀을 추가하려면 `edit_mode: "insert"`, `cell_type: "markdown"`, `cell_id`를 설정 셀의 ID로, `new_source`에 서술을 넣습니다.
 
-## 원문
+### 예시 3: 오래된 셀 삭제
+`edit_mode: "delete"`로 설정하고 제거할 셀의 `cell_id`를 제공합니다. `new_source`에는 임의의 문자열을 제공하십시오. 적용되지 않습니다.
 
-<textarea readonly>Completely replaces the contents of a specific cell in a Jupyter notebook (.ipynb file) with new source. Jupyter notebooks are interactive documents that combine code, text, and visualizations, commonly used for data analysis and scientific computing. The notebook_path parameter must be an absolute path, not a relative path. The cell_number is 0-indexed. Use edit_mode=insert to add a new cell at the index specified by cell_number. Use edit_mode=delete to delete the cell at the index specified by cell_number.</textarea>
+## 참고사항
+
+- 항상 절대 경로를 전달하십시오. `NotebookEdit`는 작업 디렉토리에 대해 상대 경로를 해결하지 않습니다.
+- 도구는 대상 셀만 다시 씁니다. 관련 없는 셀의 실행 횟수, 출력, 메타데이터는 그대로 유지됩니다.
+- `cell_id` 없이 삽입하면 새 셀이 노트북 맨 처음에 배치됩니다.
+- `cell_type`은 삽입에 필수입니다. 교체의 경우 코드 셀을 마크다운으로 또는 그 반대로 명시적으로 변환하려는 경우가 아니면 생략하십시오.
+- 셀을 검사하고 ID를 가져오려면 먼저 노트북에서 `Read` 도구를 사용하십시오. 콘텐츠와 출력이 포함된 셀을 반환합니다.
+- 일반 소스 파일에는 일반 `Edit`를 사용하십시오. `NotebookEdit`는 `.ipynb` JSON에 특화되어 있으며 셀 구조를 이해합니다.

package/concepts/ko/Tool-PushNotification.md

@@ -0,0 +1,48 @@
+# PushNotification
+
+현재 Claude Code 세션에서 데스크톱 알림을 전송합니다. 원격 제어가 연결된 경우 사용자의 휴대폰으로도 푸시되어, 어디에 있든 세션으로 주의를 끌어옵니다.
+
+## 사용 시점
+
+- 사용자가 터미널을 떠나 있을 가능성이 높은 상황에서 오래 걸리는 작업이 완료된 경우
+- 빌드, 테스트 또는 배포가 완료되어 결과를 검토할 수 있는 경우
+- 작업을 계속하기 위해 사용자의 입력이 필요한 결정 지점에 도달한 경우
+- 자율적으로 해결할 수 없는 오류나 차단 요소가 발생한 경우
+- 사용자가 특정 작업 또는 조건이 충족되었을 때 알림을 보내달라고 명시적으로 요청한 경우
+
+## 사용하지 말아야 할 경우
+
+작업 중 일상적인 진행 상황 업데이트에는 알림을 보내지 마십시오. 사용자가 방금 질문하고 명백히 기다리고 있는 경우에도 마찬가지입니다. 짧은 작업이 완료되었을 때도 알림은 불필요합니다. 사용자가 제출 직후 기다리고 있다면 알림은 아무 가치가 없고, 이후 알림에 대한 신뢰만 떨어뜨립니다. 기본적으로 보내지 않는 방향으로 강하게 권장합니다.
+
+## 매개변수
+
+- `message` (문자열, 필수): 알림 본문. 200자 이내로 유지하십시오. 모바일 운영체제는 긴 문자열을 잘라냅니다. 사용자가 행동을 취할 수 있는 내용으로 시작하십시오: "build failed: 2 auth tests"는 "task complete"보다 훨씬 유용합니다.
+- `status` (문자열, 필수): 항상 `"proactive"`로 설정합니다. 이것은 고정 마커로 변경할 수 없습니다.
+
+## 예시
+
+### 예시 1: 오래 걸리는 분석이 완료되었을 때 알림 보내기
+
+저장소 전체 의존성 감사가 요청되어 실행에 몇 분이 걸렸습니다. 사용자는 자리를 비웠습니다. 보고서가 준비되면:
+
+```
+message: "의존성 감사 완료: lodash, axios, jsonwebtoken에서 고위험 CVE 3건 발견. 보고서: audit-report.txt"
+status: "proactive"
+```
+
+### 예시 2: 자율 작업 중 결정 지점 표시
+
+다단계 리팩토링 도중 두 모듈의 인터페이스가 충돌하여 설계 결정 없이는 병합할 수 없음을 발견한 경우:
+
+```
+message: "리팩토링 중단: AuthService와 UserService의 토큰 인터페이스 충돌. 계속하려면 결정이 필요합니다."
+status: "proactive"
+```
+
+## 참고사항
+
+- 기본적으로 **보내지 않는** 방향으로 판단하십시오. 사용자가 무엇을 하고 있든 알림은 방해가 됩니다. 정보 가치로 정당화되어야 하는 비용으로 취급하십시오.
+- 행동 가능한 내용으로 시작하십시오. 처음 몇 단어에서 무슨 일이 있었는지, 사용자가 무엇을 해야 하는지 알려주십시오. 일반적인 상태 레이블이 아니라요.
+- `message`는 200자 이내로 유지하십시오. 모바일 운영체제는 초과하는 문자열을 잘라내어 끝부분의 중요한 내용이 손실될 수 있습니다.
+- 원격 제어가 연결되지 않아 푸시가 전송되지 않았다고 결과에 표시되면, 이는 예상된 동작입니다. 재시도나 후속 조치는 필요 없습니다. 로컬 데스크톱 알림은 정상적으로 실행됩니다.
+- 알림 남발을 피하십시오. 사소한 일에 자주 알림을 보내면 사용자가 무시하기 시작합니다. 사용자가 자리를 비웠을 가능성이 높고, 지금 바로 결과를 알 가치가 있는 경우에만 이 도구를 사용하십시오.

package/concepts/ko/Tool-Read.md

@@ -1,56 +1,41 @@
 # Read
 
-## 정의
-
-로컬 파일 시스템에서 파일 내용을 읽습니다. 텍스트 파일, 이미지, PDF, Jupyter notebook을 지원합니다.
-
-## 파라미터
-
-| 파라미터 | 타입 | 필수 | 설명 |
-|----------|------|------|------|
-| `file_path` | string | 예 | 파일의 절대 경로 |
-| `offset` | number | 아니오 | 시작 행 번호 (대용량 파일 분할 읽기용) |
-| `limit` | number | 아니오 | 읽기 행 수 (대용량 파일 분할 읽기용) |
-| `pages` | string | 아니오 | PDF 페이지 범위 (예: "1-5", "3", "10-20"), PDF에만 적용 |
-
-## 사용 시나리오
-
-**적합한 경우:**
-- 코드 파일, 설정 파일 등 텍스트 파일 읽기
-- 이미지 파일 보기 (Claude는 멀티모달 모델)
-- PDF 문서 읽기
-- Jupyter notebook 읽기 (모든 셀과 출력을 반환)
-- 여러 파일을 병렬로 읽어 컨텍스트 획득
-
-**적합하지 않은 경우:**
-- 디렉토리 읽기 — Bash의 `ls` 명령을 사용해야 함
-- 개방형 코드베이스 탐색 — Task (Explore 타입)를 사용해야 함
-
-## 주의사항
-
-- 경로는 절대 경로여야 하며 상대 경로 불가
-- 기본적으로 파일의 처음 2000행을 읽음
-- 2000자를 초과하는 행은 잘림
-- 출력은 `cat -n` 형식이며 행 번호는 1부터 시작
-- 대용량 PDF (10페이지 초과)는 `pages` 파라미터 지정 필수, 1회 최대 20페이지
-- 존재하지 않는 파일 읽기는 오류를 반환 (크래시하지 않음)
-- 단일 메시지 내에서 여러 Read를 병렬 호출 가능
-
-## 원문
-
-<textarea readonly>Reads a file from the local filesystem. You can access any file directly by using this tool.
-Assume this tool is able to read all files on the machine. If the User provides a path to a file assume that path is valid. It is okay to read a file that does not exist; an error will be returned.
-
-Usage:
-- The file_path parameter must be an absolute path, not a relative path
-- By default, it reads up to 2000 lines starting from the beginning of the file
-- You can optionally specify a line offset and limit (especially handy for long files), but it's recommended to read the whole file by not providing these parameters
-- Any lines longer than 2000 characters will be truncated
-- Results are returned using cat -n format, with line numbers starting at 1
-- This tool allows Claude Code to read images (eg PNG, JPG, etc). When reading an image file the contents are presented visually as Claude Code is a multimodal LLM.
-- This tool can read PDF files (.pdf). For large PDFs (more than 10 pages), you MUST provide the pages parameter to read specific page ranges (e.g., pages: "1-5"). Reading a large PDF without the pages parameter will fail. Maximum 20 pages per request.
-- This tool can read Jupyter notebooks (.ipynb files) and returns all cells with their outputs, combining code, text, and visualizations.
-- This tool can only read files, not directories. To read a directory, use an ls command via the Bash tool.
-- You can call multiple tools in a single response. It is always better to speculatively read multiple potentially useful files in parallel.
-- You will regularly be asked to read screenshots. If the user provides a path to a screenshot, ALWAYS use this tool to view the file at the path. This tool will work with all temporary file paths.
-- If you read a file that exists but has empty contents you will receive a system reminder warning in place of file contents.</textarea>
+로컬 파일시스템에서 단일 파일의 내용을 로드합니다. 일반 텍스트, 소스 코드, 이미지, PDF, Jupyter 노트북을 지원하며, `cat -n` 스타일의 1 기반 줄 번호로 결과를 반환합니다.
+
+## 사용 시점
+
+- 편집 또는 분석 전에 알려진 경로의 소스 파일 읽기
+- 구성 파일, 잠금 파일, 로그, 또는 생성된 아티팩트 검사
+- 사용자가 대화에 붙여 넣은 스크린샷 또는 다이어그램 보기
+- 긴 PDF 매뉴얼에서 특정 페이지 범위 추출
+- 코드 셀, 마크다운, 셀 출력을 함께 검토하기 위해 `.ipynb` 노트북 열기
+
+## 매개변수
+
+- `file_path` (string, 필수): 대상 파일의 절대 경로. 상대 경로는 거부됩니다.
+- `offset` (integer, 선택): 읽기를 시작할 1 기반 줄 번호. `limit`와 함께 사용하면 큰 파일에 유용합니다.
+- `limit` (integer, 선택): `offset`에서 시작하여 반환할 최대 줄 수. 생략 시 기본값은 파일 맨 위에서 2000줄입니다.
+- `pages` (string, 선택): PDF 파일의 페이지 범위, 예를 들어 `"1-5"`, `"3"`, 또는 `"10-20"`. 10페이지를 초과하는 PDF에 필요합니다. 요청당 최대 20페이지입니다.
+
+## 예시
+
+### 예시 1: 전체 작은 파일 읽기
+`file_path`만 `/Users/me/project/src/index.ts`로 설정하여 `Read`를 호출합니다. 줄 번호와 함께 최대 2000줄이 반환되며, 이는 일반적으로 편집 컨텍스트에 충분합니다.
+
+### 예시 2: 긴 로그 페이지 넘기기
+컨텍스트 토큰을 낭비하지 않고 좁은 창을 검색하려면 수천 줄의 로그 파일에서 `offset: 5001`과 `limit: 500`을 사용합니다.
+
+### 예시 3: 특정 PDF 페이지 추출
+`/tmp/spec.pdf`의 120페이지 PDF의 경우, 필요한 챕터만 가져오려면 `pages: "8-15"`를 설정합니다. 큰 PDF에서 `pages`를 생략하면 오류가 발생합니다.
+
+### 예시 4: 이미지 보기
+PNG나 JPG 스크린샷의 절대 경로를 전달합니다. 이미지가 시각적으로 렌더링되어 Claude Code가 직접 추론할 수 있습니다.
+
+## 참고사항
+
+- 항상 절대 경로를 선호하십시오. 사용자가 제공하면 그대로 신뢰하십시오.
+- 2000자보다 긴 줄은 잘립니다. 매우 넓은 데이터의 경우 반환된 내용이 잘릴 수 있다고 처리하십시오.
+- 여러 독립 파일을 읽고 있나요? 병렬로 실행되도록 같은 응답에서 여러 `Read` 호출을 실행하십시오.
+- `Read`는 디렉토리를 나열할 수 없습니다. 대신 `Bash` `ls` 호출이나 `Glob` 도구를 사용하십시오.
+- 존재하지만 비어 있는 파일을 읽으면 파일 바이트 대신 시스템 알림이 반환되므로 해당 신호를 명시적으로 처리하십시오.
+- 현재 세션에서 같은 파일에 `Edit`를 사용하려면 성공적인 `Read`가 필요합니다.

package/concepts/ko/Tool-RemoteTrigger.md

@@ -0,0 +1,73 @@
+# RemoteTrigger
+
+claude.ai 원격 트리거 API를 호출하여 예약된 작업과 온디맨드 트리거 실행을 관리합니다. OAuth 토큰은 내부적으로 처리되며 모델이나 셸에 노출되지 않습니다.
+
+## 사용 시점
+
+- claude.ai의 원격 에이전트(트리거) 관리 — 기존 트리거 목록 조회, 검사 및 업데이트 포함
+- cron 기반 자동화 작업 생성 — Claude 에이전트가 반복 일정에 따라 실행되도록 설정
+- 다음 예약 실행을 기다리지 않고 기존 트리거를 즉시 실행
+- 모든 현재 트리거를 나열하거나 감사하여 구성 및 상태 검토
+- 트리거를 재생성하지 않고 일정, 페이로드 또는 설명과 같은 트리거 설정 업데이트
+
+## 매개변수
+
+- `action` (string, 필수): 수행할 작업 — `list`, `get`, `create`, `update`, `run` 중 하나
+- `trigger_id` (string, `get`, `update`, `run` 시 필수): 작업할 트리거의 식별자; 패턴 `^[\w-]+$`(단어 문자 및 대시만 허용)와 일치해야 함
+- `body` (object, `create` 및 `update` 시 필수; `run` 시 선택): API에 전송되는 요청 페이로드
+
+## 예시
+
+### 예시 1: 모든 트리거 목록 조회
+
+```json
+{
+  "action": "list"
+}
+```
+
+`GET /v1/code/triggers`를 호출하여 인증된 계정과 연결된 모든 트리거의 JSON 배열을 반환합니다.
+
+### 예시 2: 매주 평일 아침에 실행되는 새 트리거 생성
+
+```json
+{
+  "action": "create",
+  "body": {
+    "name": "weekday-morning-report",
+    "schedule": "0 8 * * 1-5",
+    "description": "매주 평일 UTC 08:00에 일일 요약 생성"
+  }
+}
+```
+
+제공된 본문으로 `POST /v1/code/triggers`를 호출하고, 할당된 `trigger_id`를 포함한 새로 생성된 트리거 객체를 반환합니다.
+
+### 예시 3: 온디맨드 트리거 실행
+
+```json
+{
+  "action": "run",
+  "trigger_id": "my-report-trigger"
+}
+```
+
+예약된 시간을 건너뛰고 즉시 `POST /v1/code/triggers/my-report-trigger/run`을 호출합니다.
+
+### 예시 4: 단일 트리거 조회
+
+```json
+{
+  "action": "get",
+  "trigger_id": "my-report-trigger"
+}
+```
+
+`GET /v1/code/triggers/my-report-trigger`를 호출하여 전체 트리거 구성을 반환합니다.
+
+## 참고사항
+
+- OAuth 토큰은 도구에 의해 프로세스 내부에서 주입됩니다 — 토큰을 수동으로 복사, 붙여넣기 또는 기록하지 마십시오. 이는 보안 위험을 초래하며 이 도구를 사용할 때는 불필요합니다.
+- 모든 트리거 API 호출에는 원시 `curl`이나 다른 HTTP 클라이언트 대신 이 도구를 사용하십시오. 직접 HTTP를 사용하면 보안 토큰 주입을 우회하여 자격 증명이 노출될 수 있습니다.
+- 도구는 API의 원시 JSON 응답을 반환합니다. 호출자는 응답을 파싱하고 오류 상태 코드를 처리할 책임이 있습니다.
+- `trigger_id` 값은 패턴 `^[\w-]+$`와 일치해야 합니다 — 영숫자 문자, 밑줄, 대시만 허용됩니다. 공백이나 특수 문자가 포함되면 요청이 실패합니다.

package/concepts/ko/Tool-ScheduleWakeup.md

@@ -0,0 +1,56 @@
+# ScheduleWakeup
+
+`/loop` 동적 모드에서 작업을 재개할 시점을 예약합니다. 이 도구를 사용하면 Claude가 지정된 시간 동안 슬립한 후 동일한 루프 프롬프트로 다시 트리거하여 작업 반복의 페이스를 자율적으로 제어할 수 있습니다.
+
+## 사용 시점
+
+- 반복 간격이 고정된 클록이 아닌 작업 상태에 따라 달라지는 `/loop` 동적 작업에서 자율적으로 페이스를 조절할 때
+- 긴 빌드, 배포 또는 테스트 실행이 완료될 때까지 기다렸다가 결과를 확인할 때
+- 현재 감시할 특정 신호가 없을 때 반복 사이에 유휴 대기를 삽입할 때
+- 사용자 프롬프트 없이 자율 루프를 실행할 때 — 리터럴 센티널 `<<autonomous-loop-dynamic>>`을 `prompt`로 전달
+- 곧 상태가 변경될 프로세스를 폴링할 때 (짧은 지연으로 캐시를 워밍 상태로 유지)
+
+## 매개변수
+
+- `delaySeconds` (숫자, 필수): 재개까지의 초 단위 시간. 런타임이 값을 자동으로 `[60, 3600]` 범위로 클램프하므로 직접 클램프할 필요가 없습니다.
+- `reason` (문자열, 필수): 선택한 지연 시간의 이유를 설명하는 짧은 문장. 사용자에게 표시되고 텔레메트리에 기록됩니다. 구체적으로 작성하세요 — "bun 빌드 완료 확인 중"이 "대기 중"보다 유용합니다.
+- `prompt` (문자열, 필수): 웨이크업 시 트리거될 `/loop` 입력. 다음 트리거가 작업을 반복할 수 있도록 매 턴 동일한 문자열을 전달합니다. 사용자 프롬프트 없는 자율 루프의 경우 리터럴 센티널 `<<autonomous-loop-dynamic>>`을 전달합니다.
+
+## 예시
+
+### 예시 1: 빠르게 변화하는 신호를 재확인하기 위한 짧은 지연 (캐시 워밍 유지)
+
+빌드가 막 시작되었고 일반적으로 2~3분 내에 완료됩니다.
+
+```json
+{
+  "delaySeconds": 120,
+  "reason": "약 2분 후 완료 예정인 bun 빌드 확인 중",
+  "prompt": "빌드 상태를 확인하고 오류 보고"
+}
+```
+
+120초의 지연으로 대화 컨텍스트가 Anthropic 프롬프트 캐시에 유지됩니다(TTL 5분). 따라서 다음 웨이크업이 더 빠르고 저렴합니다.
+
+### 예시 2: 긴 유휴 대기 (캐시 미스 허용, 더 긴 대기 시간에 분산)
+
+데이터베이스 마이그레이션이 실행 중이며 일반적으로 20~40분이 소요됩니다.
+
+```json
+{
+  "delaySeconds": 1200,
+  "reason": "마이그레이션은 보통 20~40분 소요; 20분 후 확인",
+  "prompt": "마이그레이션 상태 확인 후 완료 시 계속"
+}
+```
+
+웨이크업 시 캐시는 콜드 상태가 되지만, 20분의 대기는 단일 캐시 미스 비용을 충분히 분산시킵니다. 5분마다 폴링하면 동일한 캐시 미스 비용을 4번 지불하게 되어 아무런 이점이 없습니다.
+
+## 참고사항
+
+- **5분 캐시 TTL**: Anthropic 프롬프트 캐시는 300초 후에 만료됩니다. 300초 미만의 지연은 컨텍스트를 워밍 상태로 유지합니다. 300초를 초과하면 다음 웨이크업에서 캐시 미스가 발생합니다.
+- **정확히 300초는 피하세요**: 이는 최악의 선택입니다 — 캐시 미스 비용을 지불하면서 실질적으로 더 긴 대기 시간을 얻지 못합니다. 270초로 낮추거나(캐시 워밍 유지) 1200초 이상으로 커밋하세요(한 번의 캐시 미스로 훨씬 긴 대기 확보).
+- **유휴 대기의 기본값**: 감시할 특정 신호가 없을 때는 **1200~1800초** (20~30분)를 사용하세요. 이렇게 하면 루프가 주기적으로 확인하면서 시간당 12번의 의미 없는 캐시 미스를 발생시키지 않습니다.
+- **자동 클램프**: 런타임은 `delaySeconds`를 `[60, 3600]` 범위로 클램프합니다. 60 미만의 값은 60이 되고, 3600을 초과하는 값은 3600이 됩니다. 이 경계를 직접 처리할 필요가 없습니다.
+- **루프를 종료하려면 호출을 생략하세요**: 반복을 중단하려면 ScheduleWakeup을 호출하지 마세요. 호출을 생략하기만 하면 루프가 종료됩니다.
+- **매 턴 동일한 `prompt` 전달**: `prompt` 필드는 매 호출마다 원래의 `/loop` 지시를 포함해야 합니다. 그래야 다음 웨이크업이 어떤 작업을 재개해야 하는지 알 수 있습니다.

package/concepts/ko/Tool-SendMessage.md

@@ -1,41 +1,68 @@
 # SendMessage
 
-## 정의
+활성화된 팀 내에서 한 팀 멤버에서 다른 팀 멤버로 메시지를 전달하거나, 모든 팀원에게 한 번에 브로드캐스트합니다. 이것은 팀원이 들을 수 있는 유일한 채널입니다 — 일반 텍스트 출력에 쓴 것은 그들에게 보이지 않습니다.
 
-팀 내 agent 간에 메시지를 전송합니다. 직접 통신, 브로드캐스트, 프로토콜 메시지(종료 요청/응답, 계획 승인)에 사용됩니다.
+## 사용 시점
 
-## 파라미터
+- 팀 협업 중에 명명된 팀원에게 작업을 할당하거나 하위 문제를 넘겨줍니다.
+- 다른 에이전트로부터 상태, 중간 결과, 또는 코드 리뷰를 요청합니다.
+- `*`를 통해 전체 팀에게 결정, 공유 제약 조건, 또는 종료 공지를 브로드캐스트합니다.
+- 팀 리더의 종료 요청이나 계획 승인 요청과 같은 프로토콜 프롬프트에 답장합니다.
+- 위임된 작업의 끝에서 루프를 닫아 리더가 항목을 완료로 표시할 수 있도록 합니다.
 
-| 파라미터 | 타입 | 필수 | 설명 |
-|----------|------|------|------|
-| `to` | string | 예 | 수신자: 팀원 이름, 또는 `"*"`로 전체 브로드캐스트 |
-| `message` | string / object | 예 | 일반 텍스트 메시지 또는 구조화된 프로토콜 객체 |
-| `summary` | string | 아니오 | UI에 표시되는 5-10 단어 미리보기 |
+## 매개변수
 
-## 메시지 유형
+- `to` (string, 필수): 팀에 등록된 대상 팀원의 `name`, 또는 모든 팀원에게 한 번에 브로드캐스트하려면 `*`.
+- `message` (string 또는 object, 필수): 일반 통신용 일반 텍스트, 또는 `shutdown_response` 및 `plan_approval_response`와 같은 프로토콜 응답용 구조화된 객체.
+- `summary` (string, 선택): 일반 텍스트 메시지에 대한 팀 활동 로그에 표시되는 5-10단어의 미리보기. 긴 문자열 메시지에 필수. `message`가 프로토콜 객체일 때는 무시됩니다.
 
-### 일반 텍스트
-팀원 간의 직접 메시지. 조율, 상태 업데이트, 태스크 논의에 사용합니다.
+## 예시
 
-### 종료 요청
-팀원에게 정상 종료를 요청: `{ type: "shutdown_request", reason: "..." }`
+### 예시 1: 직접 작업 핸드오프
 
-### 종료 응답
-팀원이 종료를 승인 또는 거부: `{ type: "shutdown_response", approve: true/false }`
+```
+SendMessage(
+  to="db-lead",
+  message="Please audit prisma/schema.prisma and list any model missing createdAt/updatedAt timestamps. Reply when done.",
+  summary="Audit schema for missing timestamps"
+)
+```
 
-### 계획 승인 응답
-팀원의 계획을 승인 또는 거부: `{ type: "plan_approval_response", approve: true/false }`
+### 예시 2: 공유 제약 조건 브로드캐스트
 
-## 브로드캐스트 vs 직접 전송
+```
+SendMessage(
+  to="*",
+  message="Reminder: do not touch files under legacy/ — that subtree is frozen until the migration PR lands.",
+  summary="Freeze legacy/ during migration"
+)
+```
 
-- **직접 전송** (`to: "팀원-이름"`): 특정 팀원에게 전송 — 대부분의 통신에서 권장
-- **브로드캐스트** (`to: "*"`): 모든 팀원에게 전송 — 팀 전체 긴급 공지에만 사용
+### 예시 3: 프로토콜 응답
 
-## 관련 도구
+구조화된 메시지를 사용하여 리더의 종료 요청에 응답합니다:
 
-| 도구 | 용도 |
-|------|------|
-| `TeamCreate` | 새 팀 생성 |
-| `TeamDelete` | 완료 후 팀 제거 |
-| `Agent` | 팀에 합류하는 팀원 생성 |
-| `TaskCreate` / `TaskUpdate` / `TaskList` | 공유 태스크 목록 관리 |
+```
+SendMessage(
+  to="leader",
+  message={ "type": "shutdown_response", "ready": true, "final_report": "All assigned diff chunks committed on branch refactor-crew/db-lead." }
+)
+```
+
+### 예시 4: 계획 승인 응답
+
+```
+SendMessage(
+  to="leader",
+  message={ "type": "plan_approval_response", "approved": true, "notes": "LGTM, but please split step 4 into migration + backfill." }
+)
+```
+
+## 참고사항
+
+- 일반 어시스턴트 텍스트 출력은 팀원에게 전송되지 않습니다. 다른 에이전트가 무언가를 보기를 원한다면 반드시 `SendMessage`를 통해야 합니다. 이것이 팀 워크플로에서 가장 흔한 실수입니다.
+- 브로드캐스트 (`to: "*"`)는 비용이 많이 듭니다 — 모든 팀원을 깨우고 컨텍스트를 소비합니다. 진정으로 모두에게 영향을 미치는 공지에만 예약하십시오. 대상 전송을 선호하십시오.
+- 메시지를 간결하고 행동 지향적으로 유지하십시오. 수신자가 필요한 파일 경로, 제약 조건, 예상 응답 형식을 포함하십시오. 그들은 당신과 공유 메모리가 없다는 것을 기억하십시오.
+- 프로토콜 메시지 객체 (`shutdown_response`, `plan_approval_response`)는 고정된 형태를 가집니다. 프로토콜 필드를 일반 텍스트 메시지에 혼합하거나 그 반대로 하지 마십시오.
+- 메시지는 비동기입니다. 수신자는 다음 턴에 당신의 메시지를 받습니다. 그들이 답장할 때까지 읽거나 행동했다고 가정하지 마십시오.
+- 잘 작성된 `summary`는 리더를 위해 팀 활동 로그를 스캔 가능하게 만듭니다 — 커밋 제목처럼 다루십시오.