Kilo CLI Coding Agent

Run Kilo CLI via background process for programmatic control.

Security Scan

The skill's requirements and instructions are consistent with its stated purpose of orchestrating Kilo CLI and GitHub workflows; it does request a powerful GitHub token (justified by its actions) but otherwise is proportionate and instruction-only.

Purpose & Capability

Name/description, required binaries (kilo, git, gh, tmux), and required env var (GITHUB_TOKEN) all align with a skill that runs Kilo CLI to review code, create PRs, and push changes. No unrelated credentials or binaries are requested.

Instruction Scope

SKILL.md instructs running Kilo CLI in background or tmux, cloning repositories into temp directories, using git worktrees, running npm install, and using gh to post PR comments—all within the claimed domain. It explicitly warns not to operate on the OpenClaw repo directly. The instructions do direct the agent to create/push commits and post comments, which matches the need for a GitHub token.

Install Mechanism

This is an instruction-only skill (no install spec). The document suggests installing @kilocode/cli via npm -g, which is a normal, explicit user action; nothing in the registry attempts to download or execute code automatically.

Credentials

Only GITHUB_TOKEN is required and it is the declared primary credential. That token will be used to create PRs, push commits, and post comments and therefore needs broad repo write privileges per the README/claw.json. This is proportionate to the skill's functionality but carries real risk if an over-privileged token is provided.

Persistence & Privilege

Skill is not always:true and does not request persistent system modifications. It relies on the agent's ability to run background processes and use existing binaries, which is expected for this kind of automation.

Assessment

This skill is coherent with its purpose, but review and take precautions before enabling it: only provide a GitHub token scoped to the minimum required permissions (prefer a machine/service account token rather than your personal token), avoid using it against sensitive or org-wide repos, test first in a disposable repo/clone, and review the Kilo CLI package and any global npm installs yourself. Remember the skill's instructions will run git/gh commands that can commit, push, and post comments — grant privileges accordingly and rotate/revoke tokens if you stop using the skill.

---

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:"<agent command>"
# Or for project work:
bash workdir:~/project/folder background:true command:"<agent command>"
# Returns sessionId for tracking

# Monitor progress
process action:log sessionId:XXX

# Check if done  
process action:poll sessionId:XXX

# Send 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!

• Either use the project where the PR is submitted (if it's NOT ~/Projects/openclaw)
• Or clone to a temp folder first

# 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:list

# Get results and post to GitHub
process action:log sessionId:XXX
gh pr comment <PR#> --body "<review content>"

Tips for PR Reviews

• Fetch refs first: git fetch origin '+refs/pull/*/head:refs/remotes/origin/pr/*'
• Use git diff: Tell Kilo CLI to use git diff origin/main...origin/pr/XX
• Don't checkout: Multiple parallel reviews = don't let them change branches
• Post results: Use gh pr comment to post reviews to GitHub

---

tmux (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 [e-mail]:user/repo.git repo-worktrees
cd repo-worktrees

# 2. 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 main

# 3. 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-99

# 4. 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: <description>. Commit and push.'" Enter
tmux -S "$SOCKET" send-keys -t fix-99 "cd /tmp/issue-99 && npm install && kilo run 'Fix issue #99: <description>. Commit and push.'" Enter

# 5. Monitor progress
tmux -S "$SOCKET" capture-pane -p -t fix-78 -S -30
tmux -S "$SOCKET" capture-pane -p -t fix-99 -S -30

# 6. 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:**
- [Key feature 1]
- [Key feature 2]

**Example usage:**
```bash
# Example
command example
```

## 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: `[result]`
2. [Test step] - Result: [result]

**Files tested:**
- [Detail]
- [Edge cases]

## Session logs (implementation)
- [What was researched]
- [What was discovered]
- [Time spent]

## Implementation details
**New files:**
- `path/file.ts` - [description]

**Modified files:**
- `path/file.ts` - [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