claude-delegate

Delegate a coding task to a separate Claude Code CLI process or another Claude session as an implementer, then review its diff and land it yourself. Use only when the user explicitly asks to delegate implementation to Claude Code, another Claude session, or the `claude` CLI — for example, "have another Claude implement this", "delegate this to Claude Code", or "run this queue through a separate Claude session." Do not trigger merely because the current orchestrator is Claude, and do not use when

1,195stars113forksUpdated 8/20/2026

Code Review Productivity & Workflow #claude-code #orchestration #cli #ai-agents #code-review #automation

Security Assessment

Low Risk(85/100)

Detected risks:

Shell and agent orchestration(The skill spawns a separate Claude Code CLI process that edits the working tree and runs shell commands via a Node relay script., It documents an opt-in flag that bypasses Claude Code's normal permission prompts, though the skill scopes it as mutually exclusive with the safer read-only mode and emphasizes sandbox-required profiles.)

Security Score85/100

About claude-delegate

claude-delegate turns one Claude session into an orchestrator that hands a single bounded coding task to a separate Claude Code CLI process, then reviews the resulting diff and lands the change itself. It solves the problem of keeping a clear review boundary when you want another agent to do the actual editing: the orchestrator writes the brief and owns the judgment, the separate implementer session edits the working tree, and the orchestrator verifies and commits. It is explicitly not a signal for the current Claude to implement directly — it triggers only when a human asks for delegation to another Claude process.

The core of the skill is a Node relay script (scripts/relay.mjs) that wraps Claude Code's non-interactive `claude -p` mode, sends the brief on stdin (never argv), captures a structured JSON stream, and writes result artifacts under the system temp directory. It exposes dials for model, effort, turn caps, spend caps, a watchdog timeout, session resume/continue, and a read-only plan mode limited to Read/Glob/Grep with a change tripwire. Reference docs cover writing the brief, dispatch-and-poll mechanics, review-and-land, and running sequential multi-task queues with a durable progress file. The relay deliberately avoids background and bare modes, strips only the inherited CLAUDECODE variable, denies MCP tools, and disables slash commands to prevent recursion.

It targets developers and agent-orchestration engineers who run Claude Code and want a disciplined delegate-review-land loop rather than ad-hoc parallel agents. Prerequisites are the authenticated `claude` CLI, Node 18+, git, and a shell sandbox on macOS, Linux, or WSL2. Typical use cases include running a migration or refactor queue one reviewable commit at a time, or dispatching read-only diagnosis runs.

FAQ

When should this skill be used?

Only when a human explicitly asks to delegate implementation to a separate Claude Code process or session (for example, 'have another Claude implement this'). It should not trigger just because the current orchestrator is Claude, and not when the user wants the current session to implement directly.

What are the prerequisites?

The `claude` CLI installed and authenticated (verified via `claude --version` and `claude auth status`), Node 18+, git, and the ability to run shell commands. Claude's shell sandbox requires macOS, Linux, or WSL2; native Windows launch is noted as pending verification.

How is a task dispatched?

By running scripts/relay.mjs with a brief file and a target directory, e.g. `node relay.mjs --brief brief.txt --cd /path/to/repo`. Flags allow read-only mode, session resume, model/effort selection, turn and budget caps, and a relay timeout. The relay blocks until Claude exits and writes a result.json.

Does the implementer commit changes?

No. The brief instructs the implementer not to commit; the orchestrator reviews the diff, runs the project's gate commands, and lands the commit itself. One reviewed commit per task keeps history and rollback clear.

What are the safety boundaries?

The normal profile fails when the sandbox is unavailable rather than running shell commands unsandboxed, denies MCP tools, disables slash commands, and never uses bare mode. A `--dangerously-skip-permissions` opt-in exists but is mutually exclusive with read-only mode and should be used only when the human approves the reduced boundary.