Claude Code Pro

Token-efficient Claude Code workflow. Other skills burn tokens polling tmux every 30s — this one uses completion callbacks and only checks when notified. Obs...

Security Scan

The skill is largely coherent with its stated purpose (tmux-based Claude Code orchestration) but defaults to an unsafe 'auto' mode that instructs the Claude CLI to skip permission prompts, which increases the risk of unreviewed actions and data exposure; review before installing or run in a constrained environment.

Purpose & Capability

Name/description match the implementation: scripts create isolated tmux sessions (tmux -L cc), start a local Claude CLI process, and provide monitoring/send/list/stop helpers. Required binaries (tmux, bash, optional claude) are appropriate for the stated workflow.

Instruction Scope

Runtime instructions and scripts operate only on local tmux sessions and files, which fits the purpose, but the workflow encourages using a completion callback (openclaw system event) and—critically—defaults to auto mode that runs 'claude' with '--dangerously-skip-permissions'. That setting allows the started Claude process to run tools without confirmation and may cause arbitrary actions in the target workdir. The SKILL.md/README explicitly promotes skipping permission prompts, which expands the agent's effective scope beyond passive monitoring.

Install Mechanism

This is instruction- and script-based with no external downloads or installers. No install spec is provided; the files are plain bash scripts that will be written when the skill is installed. No network-based install URLs or archive extraction were observed.

Credentials

The skill declares no required environment variables or secrets and the scripts don't request credentials. However, it relies on an external 'claude' CLI which may itself use credentials or network access configured outside the skill; that is expected but worth being aware of.

Persistence & Privilege

The skill does not set always:true and does not modify other skills. However, its default behavior (start.sh default MODE='auto') instructs the Claude CLI to skip permission prompts ('--dangerously-skip-permissions'), effectively granting the spawned Claude session high autonomy over the working directory and tools. This is a design/privilege decision that significantly increases risk if used in untrusted or non-version-controlled repos.

What to consider before installing

This skill is functionally what it claims: it manages isolated tmux sessions and runs the local 'claude' CLI to save supervision tokens. Key things to consider before installing or running it: - Default auto mode is risky: start.sh defaults to --mode auto and the code sends '--dangerously-skip-permissions' to the claude CLI. That allows the spawned Claude process to run tools and make changes without interactive permission prompts. Use --mode plan or change the default to require permission for any environment where you care about unreviewed actions. - Run only in trusted, version-controlled project directories (or in an isolated container) because the agent will be given autonomy to operate on files in the workdir. - The skill expects the 'claude' CLI to be present and configured; verify how your Claude CLI stores credentials and ensure those credentials are scoped appropriately. - The skill relies on you appending an 'openclaw system event' callback in the task so the agent is notified on completion; if tasks don’t run that, the fallback behavior is a poll after 15 minutes. The callback is not enforced by the scripts. - If you want lower risk, edit start.sh to default to plan mode (remove or change the --dangerously-skip-permissions flag) and audit the scripts before use. Consider running the skill in a disposable container or VM for initial tests. Overall: coherent with purpose but the default 'skip permissions' behavior elevates risk — treat it as potentially dangerous unless you intentionally accept that autonomy.

Production-grade Claude Code workflow that doesn't waste your tokens.

The Problem with Other Skills

Most Claude Code tmux skills work like this:

Start task → Poll every 30s → Poll → Poll → Poll → Done
                 🔥 tokens      🔥       🔥       🔥

Each poll reads 100-200 lines of terminal output, feeds it to your agent, and burns tokens deciding "is it done yet?" A 20-minute task = 40 polls = thousands of wasted tokens.

How This Skill Works

Start task (with callback) → Wait → 📩 Notification → Read result (50 lines)
                               😴 zero tokens          ⚡ one read

The task itself tells you when it's done. Your agent sleeps until notified. One lightweight check confirms the result. That's it.

Token Savings Breakdown

Approach	20-min task	Tokens burned
Poll every 30s	40 reads × ~500 tokens	~20,000
Poll every 60s	20 reads × ~500 tokens	~10,000
This skill	1 notification + 1 read	~500

80-97% token savings on supervision alone.

Smart Dispatch: Know When NOT to Start

Before spawning Claude Code, ask:

Situation	Action
< 3 files involved	Don't start CC. Just read + edit directly.
Single bug fix	Don't start CC. Faster to fix inline.
Need extensive context exploration	✅ Start CC
Multi-file refactor	✅ Start CC
New feature (5+ files)	✅ Start CC

The fastest token savings come from not spawning a session at all.

Quick Start

# Start a task — note the callback at the end
bash {baseDir}/scripts/start.sh --label auth-refactor --workdir ~/project --task "Refactor auth module to use JWT.

When completely finished, run: openclaw system event --text \"Done: JWT auth refactor complete\" --mode now"

That's the key line: openclaw system event --text "Done: ..." --mode now. The task notifies your agent on completion. No polling needed.

Task from file (complex requirements)

bash {baseDir}/scripts/start.sh --label my-feature --workdir ~/project \
  --task-file /path/to/requirements.md --mode auto

Write detailed requirements once upfront → fewer mid-task corrections → fewer tokens.

Monitor (Only When Needed)

# Lightweight check — 50 lines, minimal tokens
bash {baseDir}/scripts/monitor.sh --session my-task --lines 50

# JSON mode — structured, even fewer tokens for agent parsing
bash {baseDir}/scripts/monitor.sh --session my-task --json

# Send follow-up (use sparingly — write requirements upfront instead)
bash {baseDir}/scripts/send.sh --session my-task --text "Also add unit tests"

# Compact context when running long
bash {baseDir}/scripts/send.sh --session my-task --compact

Manage Sessions

# List all active sessions
bash {baseDir}/scripts/list.sh          # human-readable
bash {baseDir}/scripts/list.sh --json   # structured

# Stop sessions
bash {baseDir}/scripts/stop.sh --session my-task
bash {baseDir}/scripts/stop.sh --all

Attach (Human SSH Access)

tmux -L cc attach -t cc-<label>

Agent Workflow

1. DECIDE — Is this a 3+ file task? No → just edit. Yes → continue.
2. START — start.sh with detailed task + completion callback
3. WAIT — Do other work. Zero tokens spent watching.
4. NOTIFIED — Receive "Done: ..." event
5. CHECK — monitor.sh --lines 50 to confirm result
6. CLEANUP — stop.sh to end session

Fallback: If no notification after 15 minutes, one lightweight poll with --json.

Completion Callback Template

Always append to your task prompt:

When completely finished, run this command to notify:
openclaw system event --text "Done: [brief description]" --mode now

This is what makes the whole approach work. The task signals completion; your agent doesn't need to guess.

Modes

Mode	Flag	Behavior
auto	--mode auto	Full permissions, runs freely (default)

Design Choices

• Isolated tmux socket (-L cc) — doesn't interfere with your tmux sessions
• cc- prefix on all sessions — easy to list/filter
• Bracketed paste for multi-line prompts — no escaping issues
• JSON output from list/monitor — agent-friendly, fewer tokens to parse

Files

Script	Purpose
scripts/start.sh	Launch CC in tmux with task
scripts/monitor.sh	Lightweight output capture
scripts/send.sh	Send prompts / compact / approve
scripts/list.sh	List active sessions
scripts/stop.sh	Kill sessions