Kilo CLI Coding Agent
by @nathansebhastian
Run Kilo CLI via background process for programmatic control.
clawhub install kilocli-coding-agentπ About This Skill
name: kilocli-coding-agent description: Run Kilo CLI via background process for programmatic control. version: 0.0.9 metadata: openclaw: requires: env: - GITHUB_TOKEN bins: - kilo - git - gh - tmux primaryEnv: GITHUB_TOKEN
IMPORTANT: You need to have Kilo CLI installed and configured so OpenClaw can use it without any issue.
npm install -g @kilocode/cli
If you want to automate pull requests to Github, then you also need to authenticate Github CLI in your project: https://github.com/cli/cli#installation
Coding Agent (background-first)
Use bash background mode for non-interactive coding work. For interactive coding sessions, use the tmux skill (always, except very simple one-shot prompts).
The Pattern: workdir + background
# Create temp space for chats/scratch work
SCRATCH=$(mktemp -d)Start agent in target directory ("little box" - only sees relevant files)
bash workdir:$SCRATCH background:true command:""
Or for project work:
bash workdir:~/project/folder background:true command:""
Returns sessionId for tracking
Monitor progress
process action:log sessionId:XXXCheck if done
process action:poll sessionId:XXXSend input (if agent asks a question)
process action:write sessionId:XXX data:"y"Kill if needed
process action:kill sessionId:XXX
Why workdir matters: Agent wakes up in a focused directory, doesn't wander off reading unrelated files (like your soul.md π ).
Kilo CLI
Building/Creating (Use Autonomous mode)
bash workdir:~/project background:true command:"kilo run --auto \"Build a snake game with dark theme\""
Reviewing PRs (vanilla, no flags)
β οΈ CRITICAL: Never review PRs in OpenClaw's own project folder!
# Option 1: Review in the actual project (if NOT OpenClaw)
bash workdir:~/Projects/some-other-repo background:true command:"kilo run \"Review current branch against main branch\""Option 2: Clone to temp folder for safe review (REQUIRED for OpenClaw PRs!)
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 \"Review current branch against main branch\""
Clean up after: rm -rf $REVIEW_DIR
Option 3: Use git worktree (keeps main intact)
git worktree add /tmp/pr-130-review pr-130-branch
bash workdir:/tmp/pr-130-review background:true command:"kilo run \"Review current branch against main branch\""
Why? Checking out branches in the running OpenClaw repo can break the live instance!
Batch PR Reviews (parallel army!)
# Fetch all PR refs first
git fetch origin '+refs/pull/*/head:refs/remotes/origin/pr/*'Deploy the army - one Kilo CLI per PR!
bash workdir:~/project background:true command:"kilo run \"Review PR #86. git diff origin/main...origin/pr/86\""
bash workdir:~/project background:true command:"kilo run \"Review PR #87. git diff origin/main...origin/pr/87\""
bash workdir:~/project background:true command:"kilo run \"Review PR #95. git diff origin/main...origin/pr/95\""
... repeat for all PRs
Monitor all
process action:listGet results and post to GitHub
process action:log sessionId:XXX
gh pr comment --body ""
Tips for PR Reviews
git fetch origin '+refs/pull/*/head:refs/remotes/origin/pr/*'git diff origin/main...origin/pr/XXgh pr comment to post reviews to GitHubtmux (interactive sessions)
Use the tmux skill for interactive coding sessions (always, except very simple one-shot prompts). Prefer bash background mode for non-interactive runs.
Parallel Issue Fixing with git worktrees + tmux
For fixing multiple issues in parallel, use git worktrees (isolated branches) + tmux sessions:
# 1. Clone repo to temp location
cd /tmp && git clone git@github.com:user/repo.git repo-worktrees
cd repo-worktrees2. Create worktrees for each issue (isolated branches!)
git worktree add -b fix/issue-78 /tmp/issue-78 main
git worktree add -b fix/issue-99 /tmp/issue-99 main3. Set up tmux sessions
SOCKET="${TMPDIR:-/tmp}/kilo-fixes.sock"
tmux -S "$SOCKET" new-session -d -s fix-78
tmux -S "$SOCKET" new-session -d -s fix-994. Launch Kilo CLI in each (after npm install!)
tmux -S "$SOCKET" send-keys -t fix-78 "cd /tmp/issue-78 && npm install && kilo run 'Fix issue #78: . Commit and push.'" Enter
tmux -S "$SOCKET" send-keys -t fix-99 "cd /tmp/issue-99 && npm install && kilo run 'Fix issue #99: . Commit and push.'" Enter5. Monitor progress
tmux -S "$SOCKET" capture-pane -p -t fix-78 -S -30
tmux -S "$SOCKET" capture-pane -p -t fix-99 -S -306. Check if done (prompt returned)
tmux -S "$SOCKET" capture-pane -p -t fix-78 -S -3 | grep -q "β―" && echo "Done!"7. Create PRs after fixes
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. Cleanup
tmux -S "$SOCKET" kill-server
git worktree remove /tmp/issue-78
git worktree remove /tmp/issue-99
Why worktrees? Each Kilo CLI works in isolated branch, no conflicts. Can run 5+ parallel fixes!
Why tmux over bash background? Kilo CLI is interactive β needs TTY for proper output. tmux provides persistent sessions with full history capture.
β οΈ Rules
1. Respect tool choice β if user asks for Kilo CLI, use Kilo CLI. NEVER offer to build it yourself! 2. Be patient β don't kill sessions because they're "slow" 3. Monitor with process:log β check progress without interfering 4. --full-auto for building β auto-approves changes 5. vanilla for reviewing β no special flags needed 6. Parallel is OK β run many Kilo CLI processes at once for batch work 7. NEVER start Kilo CLI in ~/openclaw/ β it'll read your soul docs and get weird ideas about the org chart! Use the target project dir or /tmp for blank slate chats 8. NEVER checkout branches in ~/Projects/openclaw/ β that's the LIVE OpenClaw instance! Clone to /tmp or use git worktree for PR reviews
PR Template (The Razor Standard)
When submitting PRs to external repos, use this format for quality & maintainer-friendliness:
## Original Prompt
[Exact request/problem statement]
What this does
[High-level description]Features:
Example usage: bash
Example
command example[result]Feature intent (maintainer-friendly)
[Why useful, how it fits, workflows it enables]Prompt history (timestamped)
YYYY-MM-DD HH:MM UTC: [Step 1] YYYY-MM-DD HH:MM UTC: [Step 2] How I tested
Manual verification: 1. [Test step] - Output:2. [Test step] - Result: [result]path/file.tsFiles tested:
[Detail] [Edge cases] Session logs (implementation)
[What was researched] [What was discovered] [Time spent] Implementation details
New files:- [description]path/file.tsModified files:
- [change]Technical notes:
[Detail 1] [Detail 2]
Key principles: 1. Human-written description (no AI slop) 2. Feature intent for maintainers 3. Timestamped prompt history 4. Session logs if using Kilo CLI agent