cc-viewer 1.6.182 → 1.6.183

package/concepts/zh/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
+- `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```"}
+  ]
+}])
+```
 
 ## 注意事项
 
-- 用户始终可以选择 "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 会自动为每个问题追加一个「Other」自由文本选项。不要自行添加「Other」「None」或「Custom」条目——否则会与内置的兜底入口重复。
+- 每次调用限制在 1 到 4 个问题，每个问题限制在 2 到 4 个选项。超出上限会被运行时拒绝。
+- 若你推荐某一选项，请将它放在首位，并在其 label 后追加「(Recommended)」，以便 UI 高亮推荐路径。
+- 通过 `markdown` 字段提供的预览仅支持单选题。用于 ASCII 布局、代码片段、配置差异等视觉工件，而不是只需 label 加 description 就够的简单偏好选择。
+- 当问题中任一选项带有 `markdown` 值时，UI 会切换为左侧选项列表、右侧预览的并排布局。
+- 不要用 `AskUserQuestion` 询问「这个计划看起来如何？」——请改用 `ExitPlanMode`，它正是用于计划审批。在计划模式下，也请避免在问题文本中提及「the plan」，因为在 `ExitPlanMode` 运行之前用户看不到计划。
+- 不要使用本工具请求 API 密钥、密码等敏感或自由格式的输入。请改为在聊天中直接询问。

package/concepts/zh/Tool-Bash.md

@@ -1,167 +1,39 @@
 # Bash
 
-## 定义
+在一个持久工作目录中运行 shell 命令，并返回其 stdout/stderr。最适合用于没有专用 Claude Code 工具可替代的操作，例如运行 git、npm、docker 或构建脚本。
 
-执行 shell 命令，支持可选的超时设置。工作目录在命令间持久化，但 shell 状态（环境变量等）不持久化。
+## 何时使用
 
-## 参数
-
-| 参数 | 类型 | 必填 | 说明 |
-|------|------|------|------|
-| `command` | string | 是 | 要执行的 bash 命令 |
-| `description` | string | 否 | 命令的简短描述 |
-| `timeout` | number | 否 | 超时时间（毫秒），最大 600000，默认 120000 |
-| `run_in_background` | boolean | 否 | 是否后台运行 |
-
-## 使用场景
-
-**适合使用：**
-- git 操作（commit、push、branch 等）
-- npm/yarn 等包管理命令
-- docker 操作
-- 编译、构建命令
-- 列出目录内容（`ls`）
-- 其他需要 shell 执行的系统命令
-
-**不适合使用：**
-- 读取文件——应使用 Read
-- 搜索文件名——应使用 Glob
-- 搜索文件内容——应使用 Grep
-- 编辑文件——应使用 Edit
-- 写入文件——应使用 Write
-- 向用户输出信息——直接在响应文本中输出
-- 长时间运行的进程（dev server、watch 模式）——建议用户手动运行
-
-## 注意事项
-
-- 包含空格的路径必须用双引号包裹
-- 输出超过 30000 字符会被截断
-- 后台运行的命令通过 TaskOutput 获取结果
-- 尽量使用绝对路径，避免 `cd`
-- 独立命令可以并行调用多个 Bash
-- 有依赖关系的命令用 `&&` 链接
-- Shell 环境从用户的 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` 在后台启动长时间运行的进程（开发服务器、watcher）
+- 调用无内置对应工具的领域专用 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, 必填)：要执行的 shell 命令原文。
+- `description` (string, 必填)：使用主动语态的简短摘要（简单命令 5-10 词；带管道或晦涩参数的命令需提供更多上下文）。
+- `timeout` (number, 可选)：毫秒级超时时间，最大 `600000`（10 分钟）。默认 `120000`（2 分钟）。
+- `run_in_background` (boolean, 可选)：为 `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` 两个 `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：长时间运行的开发服务器
+以 `run_in_background: true` 调用 `npm run dev`。它退出时你会收到通知。不要用 `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>
+- 工作目录在多次调用间保持不变，但 shell 状态（导出的变量、shell 函数、别名）不会。请优先使用绝对路径，除非用户要求，否则避免使用 `cd`。
+- 优先使用专用工具而非 shell 等价管道：用 `Glob` 代替 `find`/`ls`、`Grep` 代替 `grep`/`rg`、`Read` 代替 `cat`/`head`/`tail`、`Edit` 代替 `sed`/`awk`、`Write` 代替 `echo >` 或 heredoc，面向用户的输出使用普通助手文本而非 `echo`/`printf`。
+- 任何包含空格的路径都要用双引号包裹（例如 `"/Users/me/My Project/file.txt"`）。
+- 对于独立命令，请在同一条消息中并行发起多个 `Bash` 调用。仅在一个命令依赖另一个时才用 `&&` 串联。
+- 超过 30000 字符的输出会被截断。若需捕获大型日志，请重定向到文件后用 `Read` 工具读取。
+- 切勿使用交互式标志，如 `git rebase -i` 或 `git add -i`；它们无法通过本工具接收输入。
+- 除非用户明确要求，不要跳过 git hook（`--no-verify`、`--no-gpg-sign`）或执行破坏性操作（`reset --hard`、`push --force`、`clean -f`）。

package/concepts/zh/Tool-CronCreate.md

@@ -0,0 +1,57 @@
+# CronCreate
+
+将提示词排队到未来某个时刻执行，支持一次性触发和周期性重复两种模式。使用标准的 5 字段 cron 表达式，基于用户本地时区，无需进行时区转换。
+
+## 何时使用
+
+- **一次性提醒**：当用户希望在某个具体时间收到提醒时（如"明天下午 3 点提醒我"），将 `recurring` 设为 `false`，任务触发一次后自动删除。
+- **周期性计划**：当用户希望某件事反复发生时（如"每个工作日早上 9 点"、"每 30 分钟一次"），使用默认的 `recurring: true`。
+- **自主 Agent 循环**：当需要构建一个定期自我触发的工作流时，例如每日摘要或周期性状态检查。
+- **持久化任务**：当计划需要在会话重启后继续保留时，传入 `durable: true`，任务将写入 `.claude/scheduled_tasks.json`。
+- **大致时间请求**：当用户说"大约 9 点"或"每小时"时，应选择非整点分钟值（例如 `57 8 * * *` 或 `7 * * * *`），避免大量用户在 :00 或 :30 时刻同时触发。
+
+## 参数
+
+- `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
+}
+```
+
+使用分钟 `3` 而非 `0`，避免在整点造成服务器负载峰值。该任务 7 天后自动过期。
+
+## 注意事项
+
+- **7 天自动过期**：周期性任务最多运行 7 天后自动删除。如需更长时间的计划，请在过期前重新创建。
+- **仅在空闲时触发**：`CronCreate` 仅在 REPL 未处理其他查询时才将提示词排队。如果触发时 REPL 正在处理其他请求，提示词将等待当前查询完成后再执行。
+- **避免使用 :00 和 :30 分钟值**：对于大致时间的请求，应主动选择非整点分钟值，以分散系统负载。只有用户明确指定某个精确分钟时，才使用 :00 或 :30。
+- **无需时区转换**：cron 表达式直接按用户本地时区解析，无需转换为 UTC 或其他时区。

package/concepts/zh/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/zh/Tool-CronList.md

@@ -0,0 +1,30 @@
+# CronList
+
+列出当前会话中通过 `CronCreate` 创建的所有定时任务。返回每个活跃任务的摘要，包括 `id`、cron 表达式、缩略 `prompt`、`recurring` 标志、`durable` 标志及下次触发时间。
+
+## 何时使用
+
+- 在修改或结束会话前，审查当前已调度的所有任务。
+- 在调用 `CronDelete` 删除某个任务前，先找到正确的 `id`。
+- 通过确认任务是否存在及其下次触发时间，排查预期任务未执行的问题。
+- 确认某个一次性（非循环）任务是否尚未触发、仍处于待执行状态。
+
+## 参数
+
+无。
+
+## 示例
+
+### 示例 1：审查所有已调度任务
+
+不带任何参数调用 `CronList`，即可获取所有活跃定时任务的完整列表。返回结果包括每个任务的 `id`、cron 表达式、`prompt` 的截断版本、是否 `recurring`（循环）、是否 `durable`（持久化）以及下次触发时间。
+
+### 示例 2：找到特定循环任务的 id
+
+若您创建了多个定时任务并需要删除其中某一个，请先调用 `CronList`。在返回列表中查找 `prompt` 摘要和 cron 表达式与目标任务匹配的条目，复制其 `id` 并传递给 `CronDelete`。
+
+## 注意事项
+
+- 仅列出当前会话中创建的任务，除非创建时指定了 `durable: true`，该选项允许任务在会话重启后持续存在。
+- 摘要中的 `prompt` 字段会被截断，仅显示完整提示文本的开头部分，而非全部内容。
+- 已触发并执行完毕的一次性任务（`recurring` 为 `false`）会被自动删除，不再出现在列表中。

package/concepts/zh/Tool-Edit.md

@@ -1,46 +1,38 @@
 # Edit
 
-## 定义
+在已有文件中执行精确的字符串替换。它是修改文件的首选方式，因为只传输 diff，使编辑既精确又可审计。
 
-通过精确的字符串替换来编辑文件。将文件中的 `old_string` 替换为 `new_string`。
+## 何时使用
 
-## 参数
+- 修复单个函数中的 bug，而不重写其周围文件
+- 更新配置值、版本字符串或 import 路径
+- 通过 `replace_all` 在文件内重命名符号
+- 在某个锚点附近插入代码块（扩展 `old_string` 纳入附近上下文，再提供替换内容）
+- 作为多步重构的一部分，应用小范围、界限清晰的编辑
 
-| 参数 | 类型 | 必填 | 说明 |
-|------|------|------|------|
-| `file_path` | string | 是 | 要修改的文件的绝对路径 |
-| `old_string` | string | 是 | 要替换的原始文本 |
-| `new_string` | string | 是 | 替换后的新文本（必须与 old_string 不同） |
-| `replace_all` | boolean | 否 | 是否替换所有匹配项，默认 `false` |
+## 参数
 
-## 使用场景
+- `file_path` (string, 必填)：要修改文件的绝对路径。
+- `old_string` (string, 必填)：要搜索的精确文本。必须逐字符匹配，包括空白与缩进。
+- `new_string` (string, 必填)：替换文本。必须不同于 `old_string`。
+- `replace_all` (boolean, 可选)：为 `true` 时替换 `old_string` 的每一处匹配。默认为 `false`，此时要求匹配唯一。
 
-**适合使用：**
-- 修改现有文件中的特定代码段
-- 修复 bug、更新逻辑
-- 重命名变量（配合 `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>
+- 在当前会话中必须至少对文件调用过一次 `Read`，`Edit` 才会接受改动。`Read` 输出的行号前缀不是文件内容的一部分；不要把它们放进 `old_string` 或 `new_string`。
+- 空白必须完全一致。注意制表符与空格、以及行尾空格，尤其是在 YAML、Makefile 和 Python 中。
+- 如果 `old_string` 不唯一且 `replace_all` 为 `false`，编辑将失败。请扩大上下文或启用 `replace_all`。
+- 只要文件已存在，优先使用 `Edit` 而非 `Write`；`Write` 会覆盖整个文件，稍有不慎就会丢失无关内容。
+- 对同一文件的多处无关编辑，应按顺序发起多次 `Edit` 调用，而不是一次庞大且脆弱的替换。
+- 编辑源代码时避免引入表情符号、营销性文案或未请求的文档块。