Giga Coding Agent

Run Codex CLI, Claude Code, OpenCode, or Pi Coding Agent via background process for programmatic control.

Security Scan

The skill's declared purpose (running coding agents in background) matches the instructions, but the SKILL.md asks you to run powerful CLI workflows (git/gh/push, agent flags that bypass sandboxes) without declaring required tools or credential usage — proceed cautiously.

Purpose & Capability

The name/description match the instructions: the skill is an instruction cookbook for running Codex, Claude, OpenCode, or Pi as background processes. However the SKILL.md assumes additional tools (git, gh, pnpm/pnpm install, tmux, mktemp, a 'bash' skill dispatch mechanism) and access to GitHub/git credentials that are not listed in the registry requirements. Those omissions make the declared requirements incomplete, though not necessarily malicious.

Instruction Scope

The instructions include cloning repos, running agents with flags that auto-approve or bypass sandboxes (e.g. --yolo / --dangerously-bypass-approvals-and-sandbox), committing and pushing changes, and using gh pr comment — all of which can modify remote repositories and require credentials. The SKILL.md also references reading ~/.codex/config.toml for defaults. While this is within the broad purpose (automated coding), it grants the running agent potentially wide filesystem and network effects; the doc does not limit or explicitly require confirmation steps before destructive actions.

Install Mechanism

This is instruction-only (no install spec) which is lower risk in that nothing is written by default. The SKILL.md does include an example that installs the Pi agent via 'npm install -g', but does not provide an install spec or verify sources. Relying on local package managers (npm/pnpm) and global installs is expected but not fully specified.

Credentials

The registry lists no required environment variables, but the instructions implicitly rely on credentials and environment state: git or gh authentication (SSH keys or GITHUB_TOKEN), npm authentication for package installs, and optional API keys for Pi (it mentions env var defaults for API key). The skill does not declare or warn about requiring these secrets, so users might unintentionally expose or use credentials when running the recommended commands.

Persistence & Privilege

The skill does not request always:true, has no install step that persists code, and is instruction-only. It does instruct running background agents and using other skills (bash, tmux) but does not claim persistent elevated privileges over the system or other skills.

What to consider before installing

This skill is basically a cookbook for running third‑party coding CLIs in background mode — that is coherent with its description, but it presumes you have and are willing to use git/gh/ssh or token credentials, pnpm/npm, and the agent CLIs. Before installing or using it: (1) Confirm you trust the CLIs (codex/claude/opencode/pi) you will run; (2) Never use flags like --yolo (they bypass safety sandboxes); (3) Be explicit about which credentials (GitHub token, SSH key, API keys) are present in your environment and avoid running in your live project folder; (4) Prefer cloning to a temporary directory and inspect commands before letting any agent auto-commit/push; (5) Ask the publisher to list all required binaries and credentials (git, gh, pnpm, tmux, and any API keys) and to remove or clearly warn about unsafe flags. If you cannot confirm those, treat the skill as risky and run its commands manually under supervision rather than allowing autonomous invocation.

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 😅).

---

Codex CLI

Model: gpt-5.2-codex is the default (set in ~/.codex/config.toml)

Building/Creating (use --full-auto or --yolo)

# --full-auto: sandboxed but auto-approves in workspace
bash workdir:~/project background:true command:"codex exec --full-auto \"Build a snake game with dark theme\""

# --yolo: NO sandbox, NO approvals (fastest, most dangerous)
bash workdir:~/project background:true command:"codex --yolo \"Build a snake game with dark theme\""

# Note: --yolo is a shortcut for --dangerously-bypass-approvals-and-sandbox

Reviewing PRs (vanilla, no flags)

⚠️ CRITICAL: Never review PRs in Clawdbot's own project folder!

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

# Option 1: Review in the actual project (if NOT clawdbot)
bash workdir:~/Projects/some-other-repo background:true command:"codex review --base main"

# Option 2: Clone to temp folder for safe review (REQUIRED for clawdbot PRs!)
REVIEW_DIR=$(mktemp -d)
git clone https://github.com/clawdbot/clawdbot.git $REVIEW_DIR
cd $REVIEW_DIR && gh pr checkout 130
bash workdir:$REVIEW_DIR background:true command:"codex review --base origin/main"
# 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:"codex review --base main"

Why? Checking out branches in the running Clawdbot 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 Codex per PR!
bash workdir:~/project background:true command:"codex exec \"Review PR #86. git diff origin/main...origin/pr/86\""
bash workdir:~/project background:true command:"codex exec \"Review PR #87. git diff origin/main...origin/pr/87\""
bash workdir:~/project background:true command:"codex exec \"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 Codex 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

---

Claude Code

bash workdir:~/project background:true command:"claude \"Your task\""

---

OpenCode

bash workdir:~/project background:true command:"opencode run \"Your task\""

---

Pi Coding Agent

# Install: npm install -g @mariozechner/pi-coding-agent
bash workdir:~/project background:true command:"pi \"Your task\""

---

Pi flags (common)

• --print / -p: non-interactive; runs prompt and exits.
• --provider <name>: pick provider (default: google).
• --model <id>: pick model (default: gemini-2.5-flash).
• --api-key <key>: override API key (defaults to env vars).

Examples:

# Set provider + model, non-interactive
bash workdir:~/project background:true command:"pi --provider openai --model gpt-4o-mini -p \"Summarize src/\""

---

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}/codex-fixes.sock"
tmux -S "$SOCKET" new-session -d -s fix-78
tmux -S "$SOCKET" new-session -d -s fix-99

# 4. Launch Codex in each (after pnpm install!)
tmux -S "$SOCKET" send-keys -t fix-78 "cd /tmp/issue-78 && pnpm install && codex --yolo 'Fix issue #78: <description>. Commit and push.'" Enter
tmux -S "$SOCKET" send-keys -t fix-99 "cd /tmp/issue-99 && pnpm install && codex --yolo '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 Codex works in isolated branch, no conflicts. Can run 5+ parallel fixes!

Why tmux over bash background? Codex is interactive — needs TTY for proper output. tmux provides persistent sessions with full history capture.

---

⚠️ Rules

1. Respect tool choice — if user asks for Codex, use Codex. 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 Codex processes at once for batch work
7. NEVER start Codex in ~/clawd/ — 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/clawdbot/ — that's the LIVE Clawdbot 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]

---
*Submitted by Razor 🥷 - Mariano's AI agent*

Key principles:

1. Human-written description (no AI slop)
2. Feature intent for maintainers
3. Timestamped prompt history
4. Session logs if using Codex/agent

Example: https://github.com/steipete/bird/pull/22