cc-viewer 1.6.182 → 1.6.183

package/concepts/ja/Tool-Bash.md

@@ -1,167 +1,39 @@
 # Bash
 
-## 定義
+永続的な作業ディレクトリ内でシェルコマンドを実行し、その stdout/stderr を返します。git、npm、docker、ビルドスクリプトの実行など、専用の Claude Code ツールでは表現できない操作に限定するのが最適です。
 
-シェルコマンドを実行します。オプションのタイムアウト設定に対応。作業ディレクトリはコマンド間で永続化されますが、シェル状態（環境変数など）は永続化されません。
+## 使用タイミング
 
-## パラメータ
-
-| パラメータ | 型 | 必須 | 説明 |
-|------------|------|------|------|
-| `command` | string | はい | 実行する bash コマンド |
-| `description` | string | いいえ | コマンドの簡単な説明 |
-| `timeout` | number | いいえ | タイムアウト（ミリ秒）、最大 600000、デフォルト 120000 |
-| `run_in_background` | boolean | いいえ | バックグラウンドで実行するかどうか |
-
-## 使用シナリオ
-
-**適している場合：**
-- git 操作（commit、push、branch など）
-- npm/yarn などのパッケージ管理コマンド
-- docker 操作
-- コンパイル、ビルドコマンド
-- ディレクトリ内容の一覧表示（`ls`）
-- その他シェル実行が必要なシステムコマンド
-
-**適していない場合：**
-- ファイルの読み取り——Read を使用すべき
-- ファイル名の検索——Glob を使用すべき
-- ファイル内容の検索——Grep を使用すべき
-- ファイルの編集——Edit を使用すべき
-- ファイルの書き込み——Write を使用すべき
-- ユーザーへの情報出力——レスポンステキストに直接出力
-- 長時間実行プロセス（dev server、watch モード）——ユーザーに手動実行を推奨
-
-## 注意事項
-
-- スペースを含むパスはダブルクォートで囲む必要がある
-- 出力が 30000 文字を超えると切り詰められる
-- バックグラウンド実行のコマンドは TaskOutput で結果を取得
-- できるだけ絶対パスを使用し、`cd` を避ける
-- 独立したコマンドは複数の Bash を並列呼び出し可能
-- 依存関係のあるコマンドは `&&` で連結
-- シェル環境はユーザーの profile（bash または zsh）から初期化
-
-## 原文
-
-<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).
+- git 操作の実行 (`git status`、`git diff`、`git commit`、`gh pr create`)
+- パッケージマネージャーやビルドツールの実行 (`npm install`、`npm run build`、`pytest`、`cargo build`)
+- `run_in_background` を使った長時間実行プロセス (開発サーバー、ウォッチャー) のバックグラウンド起動
+- 組み込みに相当するものがないドメイン固有 CLI (`docker`、`terraform`、`kubectl`、`gh`) の呼び出し
+- 順序が重要な場合に `&&` で依存ステップを連結
 
-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.
+- `command` (string, required): 実行する正確なシェルコマンド。
+- `description` (string, required): 短くアクティブボイスの要約 (単純なコマンドは 5〜10 語、パイプ化されたものや分かりにくいものはさらに文脈を補足)。
+- `timeout` (number, optional): タイムアウト (ミリ秒)。最大 `600000` (10 分)。デフォルトは `120000` (2 分)。
+- `run_in_background` (boolean, optional): `true` の場合、コマンドはデタッチして実行され、完了時に通知されます。自分で `&` を付けないでください。
 
-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>
+### 例 1: コミット前にリポジトリの状態を確認
+同じメッセージ内で `git status` と `git diff --stat` を 2 つの並列 `Bash` 呼び出しとして発行し、コンテキストを素早く収集してから、後続の呼び出しでコミットを組み立てます。
 
-## Test plan
-[Bulleted markdown checklist of TODOs for testing the pull request...]
+### 例 2: 依存するビルドステップの連結
+`npm ci && npm run build && npm test` のような単一呼び出しを使用し、各ステップが前のステップの成功後にのみ実行されるようにします。失敗後も後続のステップを実行させたい場合のみ `;` を使用してください。
 
-🤖 Generated with [Claude Code](https://claude.com/claude-code)
-EOF
-)"
-</example>
+### 例 3: 長時間実行の開発サーバー
+`npm run dev` を `run_in_background: true` で呼び出します。終了時に通知されます。`sleep` ループでポーリングしないでください。盲目的に再試行するのではなく、失敗を診断してください。
 
-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` ツール呼び出しを並列に行ってください。1 つのコマンドが別のコマンドに依存する場合のみ `&&` で連結してください。
+- 30000 文字を超える出力は切り詰められます。大きなログをキャプチャする場合は、ファイルにリダイレクトしてから `Read` ツールで読み込んでください。
+- `git rebase -i` や `git add -i` などの対話フラグは絶対に使用しないでください。このツールから入力を受け取れません。
+- ユーザーが明示的に要求しない限り、git フック (`--no-verify`、`--no-gpg-sign`) をスキップしたり、破壊的操作 (`reset --hard`、`push --force`、`clean -f`) を実行しないでください。

package/concepts/ja/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 未解決 Issue を要約して。」
+
+```json
+{
+  "cron": "3 9 * * 1-5",
+  "prompt": "自分にアサインされたすべての GitHub 未解決 Issue を要約してください。",
+  "recurring": true,
+  "durable": true
+}
+```
+
+分に `0` ではなく `3` を使い、正時の負荷集中を回避します。このタスクは 7 日後に自動期限切れになります。
+
+## 注意事項
+
+- **7 日間の自動期限切れ**: 繰り返しタスクは最大 7 日間実行された後、自動削除されます。より長い期間が必要な場合は、期限切れ前に再作成してください。
+- **アイドル時のみ発火**: `CronCreate` は REPL が他のクエリを処理していないときのみプロンプトをキューに追加します。発火時に REPL が処理中の場合、現在のクエリが完了するまで待機します。
+- **:00 と :30 の回避**: おおよその時刻リクエストに対しては、意図的にオフミニット値を選択してシステム負荷を分散させてください。ユーザーが正確な分を指定した場合のみ :00 や :30 を使用します。
+- **タイムゾーン変換不要**: cron 式はユーザーのローカルタイムゾーンで直接解釈されます。UTC や他のタイムゾーンへの変換は不要です。

package/concepts/ja/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` を呼び出してもノーオペレーションとなり、エラーは発生しません。
+- `CronDelete` は現在のインメモリセッションにのみ影響します。ランタイムが再起動をまたいでクロン状態を永続化しない場合、`CronDelete` が呼び出されたかどうかに関わらず、再起動後にスケジュールされたジョブは失われます。
+- 一括削除操作はありません。各ジョブをそれぞれの `id` を使って個別にキャンセルしてください。

package/concepts/ja/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 を特定する
+
+複数の定期実行ジョブを作成しており、そのうちの 1 つを削除する必要がある場合は、まず `CronList` を呼び出してください。返された一覧から、`prompt` の概要と cron 式が削除対象タスクに一致するジョブを探し、その `id` をコピーして `CronDelete` に渡します。
+
+## 注意事項
+
+- `durable: true` を指定して作成されたジョブを除き、現在のセッションで作成されたジョブのみが一覧に表示されます。`durable: true` を指定したジョブはセッション再起動後も持続します。
+- 概要の `prompt` フィールドは省略されており、完全なプロンプトテキストの冒頭部分のみが表示されます。
+- すでに実行された一回限りのジョブ（`recurring` が `false`）は自動的に削除され、一覧には表示されなくなります。

package/concepts/ja/Tool-Edit.md

@@ -1,46 +1,38 @@
 # Edit
 
-## 定義
+既存ファイル内で完全一致の文字列置換を実行します。差分のみが送信されるため、正確で監査可能な編集ができる、ファイル変更の推奨方法です。
 
-精確な文字列置換によるファイル編集。ファイル内の `old_string` を `new_string` に置換します。
+## 使用タイミング
 
-## パラメータ
+- 周囲のファイルを書き直さずに単一関数のバグを修正
+- 設定値、バージョン文字列、インポートパスを更新
+- `replace_all` を使ってファイル全体でシンボルをリネーム
+- アンカー付近にブロックを挿入 (`old_string` を拡張して近隣の文脈を含め、置換を提供)
+- マルチステップのリファクタリングの一部として、小さく範囲を限定した編集を適用
 
-| パラメータ | 型 | 必須 | 説明 |
-|------------|------|------|------|
-| `file_path` | string | はい | 変更するファイルの絶対パス |
-| `old_string` | string | はい | 置換する元のテキスト |
-| `new_string` | string | はい | 置換後の新しいテキスト（old_string と異なる必要がある） |
-| `replace_all` | boolean | いいえ | すべてのマッチを置換するかどうか、デフォルト `false` |
+## パラメータ
 
-## 使用シナリオ
+- `file_path` (string, required): 変更するファイルの絶対パス。
+- `old_string` (string, required): 検索する正確なテキスト。空白とインデントを含め、文字単位で一致する必要があります。
+- `new_string` (string, required): 置換テキスト。`old_string` と異なる必要があります。
+- `replace_all` (boolean, optional): `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` を少なくとも 1 回呼び出す必要があります。`Read` 出力の行番号プレフィックスはファイル内容の一部ではありません。`old_string` や `new_string` に含めないでください。
+- 空白は正確に一致する必要があります。特に YAML、Makefile、Python ではタブとスペース、末尾スペースに注意してください。
+- `old_string` が一意でなく、`replace_all` が `false` の場合、編集は失敗します。コンテキストを拡張するか `replace_all` を有効にしてください。
+- 既存ファイルには `Write` よりも `Edit` を優先してください。`Write` はファイル全体を上書きし、注意しないと無関係な内容を失います。
+- 同じファイル内の複数の無関係な編集には、1 つの大きく壊れやすい置換ではなく、複数の `Edit` 呼び出しを順次発行してください。
+- ソースファイルの編集時に、絵文字、マーケティング文、要求されていないドキュメントブロックを追加しないでください。

package/concepts/ja/Tool-EnterPlanMode.md

@@ -1,128 +1,35 @@
 # EnterPlanMode
 
-## 定義
+セッションをプランモードに切り替えます。これは読み取り専用の探索フェーズで、アシスタントはコードベースを調査し、ファイルを変更する前にユーザーの承認を得るための具体的な実装プランを作成します。
 
-Claude Code を計画モードに切り替え、実装前にコードベースを探索し方針を設計するために使用します。
+## 使用タイミング
+
+- ユーザーが複数のファイルやサブシステムにまたがる重要な変更を依頼した場合。
+- 要件が曖昧で、アプローチを決める前にアシスタントがコードを読む必要がある場合。
+- リファクタリング、マイグレーション、依存関係のアップグレードが提案され、影響範囲が不明な場合。
+- ユーザーが明示的に「プランを立てて」、「まずプランを立てよう」と言ったり、設計レビューを要求した場合。
+- リスクが十分に高く、直接編集に移ると作業が無駄になったり状態を損なう可能性がある場合。
 
 ## パラメータ
 
-パラメータなし。
+なし。`EnterPlanMode` は引数を取りません — 空のパラメータオブジェクトで呼び出してください。
 
-## 使用シナリオ
+## 例
 
-**適している場合：**
-- 新機能の実装——アーキテクチャの判断が必要
-- 複数の実行可能な方針がある——ユーザーの選択が必要
-- コード変更が既存の動作や構造に影響する
-- 複数ファイルの変更——2〜3ファイル以上に及ぶ可能性
-- 要件が不明確——まず探索して範囲を理解する必要がある
-- ユーザーの好みが重要——実装に複数の合理的な方向性がある
+### 例 1: 大きな機能リクエスト
 
-**適していない場合：**
-- 1行または少数行の修正（タイプミス、明らかなバグ）
-- ユーザーが非常に具体的な指示を出している
-- 純粋な調査/探索タスク——Task（Explore タイプ）を使用すべき
+ユーザーが「管理パネルに Okta 経由の SSO を追加して」と依頼します。アシスタントは `EnterPlanMode` を呼び出し、数ターンかけて認証ミドルウェア、セッションストレージ、ルートガード、既存のログイン UI を読み込みます。必要な変更、マイグレーションステップ、テストカバレッジを説明するプランを作成し、`ExitPlanMode` を介して承認のために提出します。
 
-## 計画モードでの動作
+### 例 2: リスクの高いリファクタリング
 
-計画モードに入ると、Claude Code は：
-1. Glob、Grep、Read ツールを使用してコードベースを深く探索
-2. 既存のパターンとアーキテクチャを理解
-3. 実装方針を設計
-4. 方針をユーザー承認に提出
-5. 必要に応じて AskUserQuestion で確認
-6. 方針が準備できたら ExitPlanMode で終了
+ユーザーが「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` コマンドのみを使用してください。
+- 些細なワンライナーの編集、純粋な調査質問、ユーザーがすでに変更を詳細に指定したタスクにはプランモードに入らないでください。オーバーヘッドが役立つよりも害になります。
+- 自動モードの下では、ユーザーが明示的に要求しない限りプランモードは推奨されません — 自動モードは事前プランニングよりも行動を優先します。
+- 高コストな作業での方向修正を減らすためにプランモードを使用してください。5 分のプランがしばしば 1 時間の誤った方向の編集を節約します。
+- プランモードに入ったら、実際に変更される部分に調査の焦点を合わせてください。当面のタスクと無関係なリポジトリの網羅的なツアーは避けてください。
+- プラン自体は、`ExitPlanMode` が提出できるように、ハーネスが期待するパスにディスクへ書き込む必要があります。プランには、漠然とした意図ではなく、具体的なファイルパス、関数名、検証ステップを含めるべきです。
+- ユーザーはプランを拒否して修正を求めるかもしれません。プランが承認されるまでプランモード内で繰り返し、その後にのみ終了してください。