cc-viewer 1.6.182 → 1.6.183

package/concepts/ja/Tool-EnterWorktree.md

@@ -1,56 +1,44 @@
 # EnterWorktree
 
-## 定義
+新しいブランチで分離された Git worktree を作成するか、現在のリポジトリの既存の worktree にセッションを切り替えます。これにより、並列作業や実験的な作業を、プライマリのチェックアウトに触れずに進めることができます。
 
-隔離された git worktree を作成し、現在のセッションをその中に切り替えます。ユーザーが明示的に worktree での作業を要求した場合にのみ使用します。
+## 使用タイミング
 
-## パラメータ
-
-| パラメータ名 | 型 | 必須 | 説明 |
-|---|---|---|---|
-| name | string | 否 | `name`（任意）：worktree の名前。指定しない場合はランダムな名前が生成されます。 |
-
-## 使用場面
+- ユーザーが明示的に「worktree」と言った場合 — 例えば「worktree を開始して」、「worktree を作成して」、「worktree で作業して」。
+- `CLAUDE.md` やメモリの永続的なプロジェクト指示が、現在のタスクに worktree を使用するよう指示している場合。
+- 以前に worktree としてセットアップされたタスクを継続したい場合 (`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, optional): 新しい worktree ディレクトリの名前。`/` で区切られた各セグメントは文字、数字、ドット、アンダースコア、ダッシュのみを含むことができます。文字列全体は 64 文字が上限です。省略し、`path` も省略された場合、ランダムな名前が生成されます。`path` と相互に排他的です。
+- `path` (string, optional): セッションを切り替える、現在のリポジトリの既存 worktree のファイルシステムパス。このリポジトリの `git worktree list` に表示されている必要があります。現在のリポジトリの登録された worktree でないパスは拒否されます。`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: 説明的な名前で新しい worktree を作成
 
-- 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` を作成し、セッションの作業ディレクトリをその中に切り替えます。以降のすべてのファイル編集とシェルコマンドは、終了するまでその worktree 内で動作します。
 
-- Must be in a git repository, OR have WorktreeCreate/WorktreeRemove hooks configured in settings.json
-- Must not already be in a worktree
+### 例 2: 既存の worktree に再度入る
 
-## 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
+以前に作成した worktree で作業を再開します。`path` で入ったため、`ExitWorktree` は自動的に削除しません — `action: "keep"` で終了すると元のディレクトリに戻るだけです。
 
-## Parameters
+## 注意事項
 
-- `name` (optional): A name for the worktree. If not provided, a random name is generated.
-</textarea>
+- ユーザーが明示的に要求するか、プロジェクト指示が要求しない限り `EnterWorktree` を呼び出さないでください。通常のブランチ切り替えやバグ修正リクエストは worktree ではなく通常の Git コマンドを使用してください。
+- Git リポジトリ内で呼び出されると、ツールは `.claude/worktrees/` の下に worktree を作成し、`HEAD` に基づく新しいブランチを登録します。Git リポジトリの外では、VCS 非依存の分離のため、`settings.json` で設定された `WorktreeCreate` / `WorktreeRemove` フックに委譲します。
+- 一度にアクティブになる worktree セッションは 1 つだけです。すでに worktree セッション内にいる場合、ツールは実行を拒否します。まず `ExitWorktree` で終了してください。
+- セッション中に終了するには `ExitWorktree` を使用してください。新しく作成された worktree 内にいる状態でセッションが終了すると、ユーザーに保持するか削除するかのプロンプトが表示されます。
+- `path` で入った worktree は外部と見なされます — `ExitWorktree` の `action: "remove"` では削除されません。これはユーザーが手動で管理する worktree を保護する安全装置です。
+- 新しい worktree は現在のブランチの内容を継承しますが、独立した作業ディレクトリとインデックスを持ちます。メインチェックアウトのステージング済みおよびステージング前の変更は worktree 内では見えません。
+- 命名のヒント: 作業の種類 (`feat/`、`fix/`、`spike/`) をプレフィックスに付けると、複数の同時 worktree が `git worktree list` で区別しやすくなります。

package/concepts/ja/Tool-ExitPlanMode.md

@@ -1,62 +1,42 @@
 # ExitPlanMode
 
-## 定義
+プランモード中に作成された実装プランをユーザーの承認のために提出し、承認された場合はセッションをプランモードから遷移させて編集を開始できるようにします。
 
-計画モードを終了し、方針をユーザー承認に提出します。方針の内容は以前書き込まれた計画ファイルから読み取られます。
+## 使用タイミング
 
-## パラメータ
-
-| パラメータ | 型 | 必須 | 説明 |
-|------------|------|------|------|
-| `allowedPrompts` | array | いいえ | 実装方針に必要な権限の説明リスト |
-
-`allowedPrompts` 配列の各要素：
-
-| フィールド | 型 | 必須 | 説明 |
-|------------|------|------|------|
-| `tool` | enum | はい | 適用するツール、現在は `Bash` のみサポート |
-| `prompt` | string | はい | 操作のセマンティック説明（例："run tests"、"install dependencies"） |
-
-## 使用シナリオ
+- `EnterPlanMode` 中に書かれたプランが完成し、レビューの準備ができた。
+- タスクは実装中心 (コードや設定の変更) であり、純粋な調査ではないため、明示的なプランが適切である。
+- すべての前提となる読み込みと分析が完了し、ユーザーが決定する前にさらなる調査は不要である。
+- アシスタントが具体的なファイルパス、関数、ステップを列挙した — 単なる目標ではない。
+- ユーザーがプランを見せるよう依頼した、またはプランモードのワークフローが編集ツールに引き渡されようとしている。
 
-**適している場合：**
-- 計画モードで方針が完成し、ユーザー承認に提出する準備ができた
-- コードを書く必要がある実装タスクにのみ使用
-
-**適していない場合：**
-- 純粋な調査/探索タスク——計画モードを終了する必要はない
-- ユーザーに「方針でよろしいですか？」と聞きたい場合——これがまさにこのツールの機能であり、AskUserQuestion で聞かないこと
-
-## 注意事項
+## パラメータ
 
-- このツールは方針の内容をパラメータとして受け取らない——以前書き込まれた計画ファイルから読み取る
-- ユーザーは計画ファイルの内容を見て承認する
-- このツールを呼び出す前に AskUserQuestion で「方針は大丈夫ですか」と聞かないこと。重複になる
-- 質問の中で「計画」に言及しないこと。ユーザーは ExitPlanMode の前に計画の内容を見ることができないため
+- `allowedPrompts` (array, optional): ユーザーが承認画面で入力してプランを自動承認または変更できるプロンプト。各要素はスコープ付きの権限 (例えば操作名と、それが適用されるツール) を指定します。デフォルトの承認フローを使用する場合は未設定のままにします。
 
-## 原文
+## 例
 
-<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.
+### 例 1: 標準的な提出
 
-## 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
+プランモード内で認証リファクタリングを調査し、プランファイルをディスクに書き込んだ後、アシスタントは引数なしで `ExitPlanMode` を呼び出します。ハーネスはプランを正規の場所から読み込み、ユーザーに表示して承認または拒否を待ちます。
 
-## 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.
+### 例 2: 事前承認されたクイックアクション
 
-## 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
+```
+ExitPlanMode(allowedPrompts=[
+  {"tool": "Bash", "prompt": "run tests"},
+  {"tool": "Bash", "prompt": "install dependencies"}
+])
+```
 
-**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/ja/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/ja/Tool-Glob.md

@@ -1,39 +1,35 @@
 # Glob
 
-## 定義
+ファイル名を glob パターンに対してマッチさせ、最新の変更時刻が最初になるようにソートされたパスを返します。`find` にシェルアウトすることなく、任意のサイズのコードベースで素早くファイルを見つけるために最適化されています。
 
-高速なファイル名パターンマッチングツール。任意の規模のコードベースに対応。修正時間順にソートされたマッチするファイルパスを返します。
+## 使用タイミング
 
-## パラメータ
+- 特定の拡張子のすべてのファイルを列挙する (例えば `src` 以下のすべての `*.ts` ファイル)
+- 命名規則によって設定ファイルやフィクスチャファイルを発見する (`**/jest.config.*`、`**/*.test.tsx`)
+- ターゲットを絞った `Grep` を実行する前に検索対象を絞り込む
+- `Write` を呼ぶ前に、既知のパターンにファイルがすでに存在するかチェック
+- 変更時刻順に依存することで、最近触れたファイルを見つける
 
-| パラメータ | 型 | 必須 | 説明 |
-|------------|------|------|------|
-| `pattern` | string | はい | glob パターン（例：`**/*.js`、`src/**/*.ts`） |
-| `path` | string | いいえ | 検索ディレクトリ、デフォルトは現在の作業ディレクトリ。"undefined" や "null" を渡さないこと |
+## パラメータ
 
-## 使用シナリオ
+- `pattern` (string, required): マッチさせる glob 式。単一セグメントのワイルドカードには `*`、再帰的マッチには `**`、代替には `{a,b}` をサポートします。例 `src/**/*.{ts,tsx}`。
+- `path` (string, optional): 検索を実行するディレクトリ。提供する場合は有効なディレクトリパスである必要があります。現在の作業ディレクトリを検索するには、フィールドを完全に省略してください。`"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` に委譲してください。
+- ファイル名の発見には `Bash` での `find` や `ls` 呼び出しよりも `Glob` を優先してください。パーミッションを一貫して処理し、構造化された出力を返します。
+- ファイル名ではなくファイル内のコンテンツを探す場合は、代わりに `Grep` を使用してください。

package/concepts/ja/Tool-Grep.md

@@ -1,57 +1,46 @@
 # Grep
 
-## 定義
+ripgrep エンジンを使用してファイル内容を検索します。完全な正規表現サポート、ファイルタイプフィルタリング、3 つの出力モードを提供し、精度とコンパクトさをトレードオフできます。
 
-ripgrep ベースの強力なコンテンツ検索ツール。正規表現、ファイルタイプフィルタリング、複数の出力モードに対応。
+## 使用タイミング
+
+- 関数のすべての呼び出し箇所や識別子のすべての参照を特定
+- 文字列やエラーメッセージがコードベースのどこかに現れるか確認
+- リファクタリング前に影響を測るためにパターンの出現回数を数える
+- 検索をファイルタイプ (`type: "ts"`) や glob (`glob: "**/*.tsx"`) に絞り込む
+- `multiline: true` でマルチライン構造体定義や JSX ブロックなどの複数行マッチを取得
 
 ## パラメータ
 
-| パラメータ | 型 | 必須 | 説明 |
-|------------|------|------|------|
-| `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 タイプ）を使用すべき
+- `pattern` (string, required): 検索する正規表現。ripgrep 構文を使用するため、リテラルな中括弧はエスケープが必要です (例えば `interface{}` を見つけるには `interface\{\}`)。
+- `path` (string, optional): 検索するファイルまたはディレクトリ。デフォルトは現在の作業ディレクトリ。
+- `glob` (string, optional): `*.js` や `*.{ts,tsx}` などのファイル名フィルタ。
+- `type` (string, optional): `js`、`py`、`rust`、`go` などのファイルタイプショートカット。標準言語には `glob` より効率的です。
+- `output_mode` (enum, optional): `files_with_matches` (デフォルト、パスのみ返す)、`content` (マッチ行を返す)、`count` (マッチ集計を返す)。
+- `-i` (boolean, optional): 大文字小文字を区別しないマッチ。
+- `-n` (boolean, optional): `content` モードで行番号を含める。デフォルトは `true`。
+- `-A` (number, optional): 各マッチの後に表示するコンテキスト行数 (`content` モードが必要)。
+- `-B` (number, optional): 各マッチの前のコンテキスト行数 (`content` モードが必要)。
+- `-C` / `context` (number, optional): 各マッチの両側のコンテキスト行数。
+- `multiline` (boolean, optional): パターンが改行をまたぐことを許可する (`.` が `\n` にマッチ)。デフォルトは `false`。
+- `head_limit` (number, optional): 返される行、ファイルパス、カウントエントリを制限。デフォルトは 250。無制限には `0` を渡します (控えめに使用)。
+- `offset` (number, optional): `head_limit` を適用する前に最初の N 件の結果をスキップ。デフォルトは `0`。
+
+## 例
+
+### 例 1: 関数のすべての呼び出し箇所を検索
+`pattern: "registerHandler\\("`、`output_mode: "content"`、`-C: 2` を設定して、各呼び出しの周囲の行を表示します。
+
+### 例 2: 型全体のマッチを数える
+`pattern: "TODO"`、`type: "py"`、`output_mode: "count"` を設定し、Python ソース全体のファイル別 TODO 合計を表示します。
+
+### 例 3: マルチライン構造体マッチ
+`multiline: true` とともに `pattern: "struct Config \\{[\\s\\S]*?version"` を使用して、Go 構造体の数行内に宣言されたフィールドをキャプチャします。
 
 ## 注意事項
 
-- 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>
+- `Bash` で `grep` や `rg` を実行するよりも常に `Grep` を優先してください。ツールは正しい権限と構造化出力のために最適化されています。
+- デフォルトの出力モードは `files_with_matches` で、最も安価です。行自体を見る必要がある場合にのみ `content` に切り替えてください。
+- コンテキストフラグ (`-A`、`-B`、`-C`) は、`output_mode` が `content` でない限り無視されます。
+- 大きな結果セットはコンテキストトークンを消費します。焦点を保つには `head_limit`、`offset`、またはより厳密な `glob`/`type` フィルタを使用してください。
+- ファイル名の発見には代わりに `Glob` を使用してください。複数ラウンドにわたるオープンエンドな調査には、Explore エージェントで `Agent` を派遣してください。

package/concepts/ja/Tool-Monitor.md

@@ -0,0 +1,50 @@
+# Monitor
+
+長時間実行されるスクリプトからイベントをストリーミングするバックグラウンドモニターを起動します。標準出力の各行が通知になります——作業を続けながら、イベントがチャットに届きます。
+
+## 使用タイミング
+
+- デプロイ実行中にログファイルのエラー、警告、クラッシュシグネチャを継続的に追跡する
+- リモート API、PR、CI パイプラインを 30 秒ごとにポーリングして新しいステータスイベントを取得する
+- ファイルシステムのディレクトリやビルド出力の変化をリアルタイムで監視する
+- 多くの反復にわたって特定の条件を待機する（例：トレーニングステップのマイルストーンやキューの消化）
+- 単純な「完了まで待機」には**使用しない** — その場合は `run_in_background` 付きの `Bash` を使用する。プロセス終了時に完了通知が 1 回届く
+
+## パラメータ
+
+- `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 000 ミリ秒（5 分）でプロセスが終了される。明示的に停止するまで実行し続けるには `persistent: true` を設定し、完了したら `TaskStop` を呼び出す。
+- **イベント過多による自動停止。** 標準出力の各行が会話メッセージになる。フィルターが広すぎて大量のイベントが発生すると、モニターは自動停止される。より厳密な `grep` パターンで再起動すること。200 ミリ秒以内に届いた複数行は 1 つの通知にまとめられる。

package/concepts/ja/Tool-NotebookEdit.md

@@ -1,33 +1,39 @@
 # NotebookEdit
 
-## 定義
+Jupyter ノートブック (`.ipynb`) 内の単一セルを変更します。ノートブック構造の残りを保持したまま、セルのソースの置換、新しいセルの挿入、既存のセルの削除をサポートします。
 
-Jupyter notebook（.ipynb ファイル）内の特定のセルを置換、挿入、または削除します。
+## 使用タイミング
+
+- ファイル全体を書き直さずに分析ノートブックのコードセルを修正または更新
+- マークダウンセルを入れ替えてナレーティブを改善したりドキュメントを追加
+- 既存のノートブックの既知の位置に新しいコードセルやマークダウンセルを挿入
+- 下流のセルが依存しないよう、古いまたは壊れたセルを削除
+- セルを 1 つずつ反復処理して再現可能なノートブックを準備
 
 ## パラメータ
 
-| パラメータ | 型 | 必須 | 説明 |
-|------------|------|------|------|
-| `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, required): `.ipynb` ファイルの絶対パス。相対パスは拒否されます。
+- `new_source` (string, required): 新しいセルのソース。`replace` と `insert` ではセル本体になります。`delete` では無視されますが、スキーマによって依然として必須です。
+- `cell_id` (string, optional): 対象セルの ID。`replace` と `delete` モードでは、ツールはこのセルに作用します。`insert` モードでは、新しいセルはこの ID のセルの直後に挿入されます。ノートブックの先頭に挿入するには省略します。
+- `cell_type` (enum, optional): `code` または `markdown`。`edit_mode` が `insert` のときに必要です。`replace` で省略された場合、既存のセルのタイプが保持されます。
+- `edit_mode` (enum, optional): `replace` (デフォルト)、`insert`、または `delete`。
 
-## 使用シナリオ
+## 例
 
-**適している場合：**
-- Jupyter notebook 内のコードまたは markdown セルを変更
-- notebook に新しいセルを追加
-- notebook 内のセルを削除
+### 例 1: バグのあるコードセルを置換
+`notebook_path` を絶対パスに、`cell_id` を対象セルの ID に、`new_source` を修正された Python コードに設定して `NotebookEdit` を呼び出します。`edit_mode` はデフォルトの `replace` のままにします。
 
-## 注意事項
+### 例 2: マークダウン説明を挿入
+既存の `setup` セルの直後にマークダウンセルを追加するには、`edit_mode: "insert"`、`cell_type: "markdown"`、`cell_id` を setup セルの ID に設定し、`new_source` にナレーティブを入れます。
 
-- `cell_number` は 0 インデックス
-- `insert` モードは指定位置に新しいセルを挿入
-- `delete` モードは指定位置のセルを削除
-- パスは絶対パスでなければならない
+### 例 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/ja/Tool-PushNotification.md

@@ -0,0 +1,48 @@
+# PushNotification
+
+現在の Claude Code セッションからデスクトップ通知を送信します。リモートコントロールが接続されている場合は、ユーザーのスマートフォンにもプッシュ通知が届き、どこにいてもセッションへ注意を引き戻します。
+
+## 使用タイミング
+
+- ユーザーがおそらく端末を離れているときに、長時間かかるタスクが完了した場合
+- ビルド、テスト、またはデプロイが完了し、結果が確認できる状態になった場合
+- 作業が継続できない決断ポイントに到達し、ユーザーの判断が必要な場合
+- 自律的に解決できないエラーやブロッカーが発生した場合
+- ユーザーが特定のタスクや条件が満たされたときに通知するよう明示的に依頼した場合
+
+## 使用しない場合
+
+タスク中の通常の進捗更新には通知を送らないでください。ユーザーが直前に質問して明らかに待機中の場合も同様です。短いタスクが完了しても通知は不要です——ユーザーが送信してすぐ待っているなら、通知は無意味であり、今後の通知への信頼を損ないます。基本的には送らないことを強く推奨します。
+
+## パラメータ
+
+- `message`（文字列、必須）：通知の本文。200文字以内に収めてください。モバイルOSはそれ以上の文字列を切り捨てます。ユーザーが行動しやすい内容から始めてください："build failed: 2 auth tests" は "task complete" よりも有用です。
+- `status`（文字列、必須）：常に `"proactive"` を設定します。これは固定マーカーであり、変更できません。
+
+## 例
+
+### 例 1：長時間の解析が完了したときの通知
+
+リポジトリ全体の依存関係監査が要求され、実行に数分かかりました。ユーザーは席を外しています。レポートが準備できたとき：
+
+```
+message: "依存関係監査完了: lodash、axios、jsonwebtoken に高危険度 CVE が 3 件見つかりました。レポート: audit-report.txt"
+status: "proactive"
+```
+
+### 例 2：自律作業中の決断ポイントのフラグ
+
+複数ステップのリファクタリング中に、2 つのモジュールのインターフェイスが競合し、設計上の判断なしには統合できないことが判明した場合：
+
+```
+message: "リファクタリング停止: AuthService と UserService のトークンインターフェイスが競合。続行前にご判断が必要です。"
+status: "proactive"
+```
+
+## 注意事項
+
+- 基本的には**送らない**方向で判断してください。ユーザーが何をしていても、通知は割り込みになります。その情報価値によって正当化されるコストとして扱ってください。
+- 行動可能な内容から始めてください。最初の数語で何が起きたか、ユーザーが何をすべきかを伝えてください——汎用的なステータスラベルではなく。
+- `message` は 200 文字以内に収めてください。モバイル OS は超過した文字列を切り捨てるため、末尾の重要な情報が失われる可能性があります。
+- リモートコントロールが接続されていないためにプッシュが送信されなかったと結果に表示された場合、それは期待される動作です。再試行や後続の対応は不要です。ローカルのデスクトップ通知は引き続き発火します。
+- 通知の乱用を避けてください。些細な出来事で頻繁に通知を送ると、ユーザーは無視するようになります。ユーザーが席を外している可能性が高く、今すぐ結果を知る価値がある場合にのみ使用してください。