名称： kilocli-coding-agent
描述： 通过后台进程运行 Kilo CLI，实现程序化控制。
版本： 0.0.9
元数据：
openclaw:
requires:
env:
- GITHUB_TOKEN
bins:
- kilo
- git
- gh
- tmux
primaryEnv: GITHUB_TOKEN

重要提示：你需要安装并配置好 Kilo CLI，以便 OpenClaw 可以无障碍地使用它。

npm install -g @kilocode/cli

如果你想自动化向 Github 提交拉取请求，还需要在你的项目中认证 Github CLI：https://github.com/cli/cli#installation

编码代理（后台优先模式）

对于非交互式的编码工作，使用 bash 后台模式。对于交互式编码会话，请使用 tmux 技能（始终如此，除非是非常简单的一次性提示）。

模式：工作目录 + 后台

# 为聊天/临时工作创建临时空间
SCRATCH=$(mktemp -d)

# 在目标目录中启动代理（"小盒子" - 只看到相关文件）
bash workdir:$SCRATCH background:true command:"<代理命令>"
# 或者用于项目工作：
bash workdir:~/project/folder background:true command:"<代理命令>"
# 返回用于跟踪的 sessionId

# 监控进度
process action:log sessionId:XXX

# 检查是否完成
process action:poll sessionId:XXX

# 发送输入（如果代理提问）
process action:write sessionId:XXX data:"y"

# 必要时终止
process action:kill sessionId:XXX

为什么工作目录很重要：代理在指定的目录中启动，不会漫游读取无关文件（比如你的 soul.md 😅）。

Kilo CLI

构建/创建（使用自主模式）

bash workdir:~/project background:true command:"kilo run --auto \"构建一个暗黑主题的贪吃蛇游戏\""

审查 PR（普通模式，无需额外标志）

⚠️ 关键：切勿在 OpenClaw 自己的项目文件夹中审查 PR！
- 要么在提交 PR 的项目中进行审查（如果它不是 ~/Projects/openclaw）
- 要么先克隆到一个临时文件夹

# 选项 1：在实际项目中审查（如果不是 OpenClaw）
bash workdir:~/Projects/some-other-repo background:true command:"kilo run \"审查当前分支与主分支的差异\""

# 选项 2：克隆到临时文件夹进行安全审查（对于 OpenClaw PR 是必需的！）
REVIEW_DIR=$(mktemp -d)
git clone https://github.com/openclaw/openclaw.git $REVIEW_DIR
cd $REVIEW_DIR && gh pr checkout 130
bash workdir:$REVIEW_DIR background:true command:"kilo run \"审查当前分支与主分支的差异\""
# 完成后清理：rm -rf $REVIEW_DIR

# 选项 3：使用 git worktree（保持主分支完好）
git worktree add /tmp/pr-130-review pr-130-branch
bash workdir:/tmp/pr-130-review background:true command:"kilo run \"审查当前分支与主分支的差异\""

为什么？ 在正在运行的 OpenClaw 仓库中检出分支可能会破坏实时实例！

批量 PR 审查（并行大军！）

# 首先获取所有 PR 引用
git fetch origin '+refs/pull/*/head:refs/remotes/origin/pr/*'

# 部署大军 - 每个 PR 一个 Kilo CLI！
bash workdir:~/project background:true command:"kilo run \"审查 PR #86。git diff origin/main...origin/pr/86\""
bash workdir:~/project background:true command:"kilo run \"审查 PR #87。git diff origin/main...origin/pr/87\""
bash workdir:~/project background:true command:"kilo run \"审查 PR #95。git diff origin/main...origin/pr/95\""
# ... 对所有 PR 重复此操作

# 监控所有进程
process action:list

# 获取结果并发布到 GitHub
process action:log sessionId:XXX
gh pr comment <PR#> --body "<审查内容>"

PR 审查技巧

• 先获取引用：git fetch origin '+refs/pull/*/head:refs/remotes/origin/pr/*'
• 使用 git diff：告诉 Kilo CLI 使用 git diff origin/main...origin/pr/XX
• 不要检出分支：多个并行审查 = 不要让它们切换分支
• 发布结果：使用 gh pr comment 将审查发布到 GitHub

tmux（交互式会话）

对于交互式编码会话，请使用 tmux 技能（始终如此，除非是非常简单的一次性提示）。对于非交互式运行，优先使用 bash 后台模式。

使用 git worktrees + tmux 并行修复问题

要并行修复多个问题，请使用 git worktrees（隔离分支）+ tmux 会话：

# 1. 将仓库克隆到临时位置
cd /tmp && git clone git@github.com:user/repo.git repo-worktrees
cd repo-worktrees

# 2. 为每个问题创建工作树（隔离分支！）
git worktree add -b fix/issue-78 /tmp/issue-78 main
git worktree add -b fix/issue-99 /tmp/issue-99 main

# 3. 设置 tmux 会话
SOCKET="${TMPDIR:-/tmp}/kilo-fixes.sock"
tmux -S "$SOCKET" new-session -d -s fix-78
tmux -S "$SOCKET" new-session -d -s fix-99

# 4. 在每个会话中启动 Kilo CLI（在 npm install 之后！）
tmux -S "$SOCKET" send-keys -t fix-78 "cd /tmp/issue-78 && npm install && kilo run '修复问题 #78：<描述>。提交并推送。'" Enter
tmux -S "$SOCKET" send-keys -t fix-99 "cd /tmp/issue-99 && npm install && kilo run '修复问题 #99：<描述>。提交并推送。'" Enter

# 5. 监控进度
tmux -S "$SOCKET" capture-pane -p -t fix-78 -S -30
tmux -S "$SOCKET" capture-pane -p -t fix-99 -S -30

# 6. 检查是否完成（提示符已返回）
tmux -S "$SOCKET" capture-pane -p -t fix-78 -S -3 | grep -q "❯" && echo "完成！"

# 7. 修复后创建 PR
cd /tmp/issue-78 && git push -u origin fix/issue-78
gh pr create --repo user/repo --head fix/issue-78 --title "fix: ..." --body "..."

# 8. 清理
tmux -S "$SOCKET" kill-server
git worktree remove /tmp/issue-78
git worktree remove /tmp/issue-99

为什么使用 worktrees？ 每个 Kilo CLI 在隔离的分支中工作，没有冲突。可以并行运行 5 个以上的修复任务！

为什么用 tmux 而不是 bash 后台？ Kilo CLI 是交互式的——需要 TTY 来正确输出。tmux 提供了带有完整历史记录的持久会话。

⚠️ 规则

1. 尊重工具选择 — 如果用户要求使用 Kilo CLI，就使用 Kilo CLI。切勿主动提出自己构建它！
2. 保持耐心 — 不要因为会话“慢”而终止它们
3. 使用 process:log 监控 — 在不干扰的情况下检查进度
4. 构建时使用 --full-auto — 自动批准更改
5. 审查时使用普通模式 — 无需特殊标志
6. 允许并行 — 对于批量工作，可以同时运行多个 Kilo CLI 进程
7. 切勿在 ~/openclaw/ 中启动 Kilo CLI — 它会读取你的灵魂文档并对组织架构产生奇怪的想法！使用目标项目目录或 /tmp 进行空白对话
8. 切勿在 ~/Projects/openclaw/ 中检出分支 — 那是正在运行的 OpenClaw 实例！克隆到 /tmp 或使用 git worktree 进行 PR 审查

PR 模板（The Razor 标准）

当向外部仓库提交 PR 时，请使用此格式以确保质量和维护者友好性：

## 原始提示
[确切的请求/问题描述]

## 此 PR 的作用
[高层描述]

**功能：**
- [关键功能 1]
- [关键功能 2]

**使用示例：**
```bash
# 示例
命令示例
```

## 功能意图（维护者友好）
[为什么有用，如何契合，它启用了哪些工作流]

## 提示历史（带时间戳）
- YYYY-MM-DD HH:MM UTC：[步骤 1]
- YYYY-MM-DD HH:MM UTC：[步骤 2]

## 测试方式
**手动验证：**
1. [测试步骤] - 输出：`[结果]`
2. [测试步骤] - 结果：[结果]

**测试的文件：**
- [详情]
- [边界情况]

## 会话日志（实现过程）
- [研究了什么]
- [发现了什么]
- [花费的时间]

## 实现细节
**新文件：**
- `路径/文件.ts` - [描述]

**修改的文件：**
- `路径/文件.ts` - [变更]

**技术说明：**
- [细节 1]
- [细节 2]

---

关键原则：
1. 人工编写的描述（无 AI 痕迹）
2. 为维护者说明功能意图
3. 带时间戳的提示历史
4. 如果使用 Kilo CLI 代理，附上会话日志