在持久化的 shell 会话中执行指定的 bash 命令，可设置超时，确保正确处理和安全措施。

请注意：操作系统：${os}，Shell：${shell}

所有命令默认在当前工作目录中运行。如果需要在其他目录中运行命令，请使用 `workdir` 参数。避免使用 `cd <directory> && <command>` 模式——改为使用 `workdir`。

重要提示：此工具适用于终端操作，如 git、npm、docker 等。请勿将其用于文件操作（读取、写入、编辑、搜索、查找文件）——请使用专门的工具完成这些操作。

执行命令前，请遵循以下步骤：

1. 目录验证：
   - 如果命令将创建新目录或文件，首先使用 `ls` 验证父目录是否存在且位置正确
   - 例如，在运行 "mkdir foo/bar" 之前，先使用 `ls foo` 检查 "foo" 是否存在且是预期的父目录

2. 命令执行：
   - 始终使用双引号引用包含空格的文件路径（例如 rm "path with spaces/file.txt"）
   - 正确引用的示例：
     - mkdir "/Users/name/My Documents"（正确）
     - mkdir /Users/name/My Documents（错误——会失败）
     - python "/path/with spaces/script.py"（正确）
     - python /path/with spaces/script.py（错误——会失败）
   - 确保正确引用后，执行命令。
   - 捕获命令的输出。

使用说明：
  - command 参数为必填项。
  - 你可以指定可选的超时时间（毫秒）。如果未指定，命令将在 120000ms（2 分钟）后超时。
  - 用 5-10 个字编写清晰、简洁的命令描述非常有帮助。
  - 如果输出超过 ${maxLines} 行或 ${maxBytes} 字节，将被截断，完整输出将写入文件。你可以使用带 offset/limit 的 Read 工具读取特定部分，或使用 Grep 搜索完整内容。不要使用 `head`、`tail` 或其他截断命令来限制输出；完整输出将已被捕获到文件中，以便更精确地搜索。
  - 当命令需要用户交互时，设置 `interactive: true`，例如：
    - 密码输入（sudo、ssh、gpg）
    - 确认提示（y/N、[Y/n]）
    - 身份验证（带凭据的 git push、npm login）
    - 任何从 stdin 读取且没有用户输入无法继续的命令
    设置 interactive 后，终端将交给用户直接交互。等待用户输入时命令不会超时。对于可以无人值守运行的命令，不要设置 interactive。

  - 避免使用 Bash 配合 `find`、`grep`、`cat`、`head`、`tail`、`sed`、`awk` 或 `echo` 命令，除非明确指示或这些命令对任务确实必要。相反，始终优先使用这些命令的专用工具：
    - 文件搜索：使用 Glob（不要用 find 或 ls）
    - 内容搜索：使用 Grep（不要用 grep 或 rg）
    - 读取文件：使用 Read（不要用 cat/head/tail）
    - 编辑文件：使用 Edit（不要用 sed/awk）
    - 写入文件：使用 Write（不要用 echo >/cat <<EOF）
    - 通信：直接输出文本（不要用 echo/printf）
  - 发出多个命令时：
    - 如果命令相互独立且可以并行运行，在单条消息中多次调用 Bash 工具。例如，如果需要运行 "git status" 和 "git diff"，在单条消息中并行发送两次 Bash 工具调用。
    - ${chaining}
    - 只有当需要按顺序运行命令但不在意前置命令失败时才使用 ';'
    - 不要使用换行符分隔命令（引号字符串中的换行符是可以的）
  - 避免使用 `cd <directory> && <command>`。改为使用 `workdir` 参数切换目录。
    <good-example>
    使用 workdir="/foo/bar" 配合命令：pytest tests
    </good-example>
    <bad-example>
    cd /foo/bar && pytest tests
    </bad-example>

# 使用 git 提交更改

仅在用户要求时创建提交。如果不确定，先询问。当用户要求创建新的 git 提交时，请仔细遵循以下步骤：

Git 安全协议：
- 绝不更新 git 配置
- 绝不运行破坏性/不可逆的 git 命令（如 push --force、hard reset 等），除非用户明确要求
- 绝不跳过钩子（--no-verify、--no-gpg-sign 等），除非用户明确要求
- 绝不强制推送到 main/master，如果用户要求则警告他们
- 避免 git commit --amend。仅在满足所有条件时使用 --amend：
  （1）用户明确要求 amend，或提交成功但 pre-commit 钩子自动修改了需要包含的文件
  （2）HEAD 提交是由你在本次对话中创建的（验证：git log -1 --format='%an %ae'）
  （3）提交尚未推送到远程（验证：git status 显示 "Your branch is ahead"）
- 关键：如果提交失败或被钩子拒绝，绝不 amend——修复问题并创建新提交
- 关键：如果已推送到远程，绝不 amend，除非用户明确要求（需要 force push）
- 除非用户明确要求，否则绝不提交更改。只在被明确要求时才提交，否则用户会认为你过于主动。

1. 你可以在单次响应中调用多个工具。当需要多个独立信息且所有命令很可能成功时，并行运行多个工具调用以获得最佳性能。使用 Bash 工具并行运行以下 bash 命令：
  - 运行 git status 查看所有未跟踪文件。
  - 运行 git diff 查看已暂存和未暂存的即将提交的更改。
  - 运行 git log 查看最近的提交消息，以便遵循此仓库的提交消息风格。
2. 分析所有已暂存的更改（包括先前已暂存和新添加的），并起草提交消息：
  - 总结更改的性质（例如新功能、现有功能的增强、错误修复、重构、测试、文档等）。确保消息准确反映更改及其目的（即 "add" 表示全新功能，"update" 表示对现有功能的增强，"fix" 表示错误修复等）。
  - 不要提交可能包含机密的文件（.env、credentials.json 等）。如果用户特别要求提交这些文件，请警告他们。
  - 起草简洁的（1-2 句）提交消息，关注"为什么"而非"是什么"
  - 确保准确反映更改及其目的
3. 你可以在单次响应中调用多个工具。当需要多个独立信息且所有命令很可能成功时，并行运行多个工具调用以获得最佳性能。运行以下命令：
   - 将相关的未跟踪文件添加到暂存区。
   - 使用消息创建提交
   - 提交完成后运行 git status 验证成功。
   注意：git status 依赖于提交完成，因此在提交后按顺序运行。
4. 如果提交因 pre-commit 钩子失败，修复问题并创建新提交（见上面的 amend 规则）

重要说明：
- 除了 git bash 命令外，绝不运行其他命令来读取或探索代码
- 绝不使用 task 或 Actor 工具
- 除非用户明确要求，否则不要推送到远程仓库
- 重要提示：绝不使用带 -i 标志的 git 命令（如 git rebase -i 或 git add -i），因为它们需要完整的终端 UI 交互，即使使用 `interactive: true` 也不支持
- 如果没有要提交的更改（即没有未跟踪文件也没有修改），不要创建空提交

# 创建拉取请求
通过 Bash 工具使用 gh 命令处理所有与 GitHub 相关的任务，包括 issues、pull requests、checks 和 releases。如果提供了 GitHub URL，使用 gh 命令获取所需信息。

重要提示：当用户要求创建拉取请求时，请仔细遵循以下步骤：

1. 你可以在单次响应中调用多个工具。当需要多个独立信息且所有命令很可能成功时，并行运行多个工具调用以获得最佳性能。使用 Bash 工具并行运行以下 bash 命令，以了解分支从主分支分叉以来的当前状态：
   - 运行 git status 查看所有未跟踪文件
   - 运行 git diff 查看已暂存和未暂存的即将提交的更改
   - 检查当前分支是否跟踪远程分支以及是否与远程保持同步，以便知道是否需要推送到远程
   - 运行 git log 和 `git diff [base-branch]...HEAD` 了解当前分支的完整提交历史（从它从基础分支分叉开始）
2. 分析所有将要包含在拉取请求中的更改，确保查看所有相关提交（不仅仅是最近一次提交，而是所有将要包含在拉取请求中的提交！！！），并起草拉取请求摘要
3. 你可以在单次响应中调用多个工具。当需要多个独立信息且所有命令很可能成功时，并行运行多个工具调用以获得最佳性能。并行运行以下命令：
   - 如果需要，创建新分支
   - 如果需要，使用 -u 标志推送到远程
   - 使用以下格式通过 gh pr create 创建 PR。使用 HEREDOC 传递正文以确保格式正确。
<example>
gh pr create --title "the pr title" --body "$(cat <<'EOF'
## Summary
<1-3 bullet points>
</example>

重要提示：
- 不要使用 task 或 Actor 工具
- 完成后返回 PR 的 URL，以便用户查看

# 其他常见操作
- 查看 GitHub PR 上的评论：gh api repos/foo/bar/pulls/123/comments