acp-router_skill

This skill routes OpenClaw requests to the appropriate ACP harness path, enabling seamless one-shot or threaded sessions for Pi, Claude Code, Codex, OpenCode,
  • TypeScript

234.5k

GitHub Stars

1

Bundled Files

4 months ago

Catalog Refreshed

5 months ago

First Indexed

Readme & install

Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.

Installation

Preview and clipboard use veilstrat where the catalogue uses aiagentskills.

npx veilstrat add skill openclaw/openclaw --skill acp-router

  • SKILL.md6.9 KB

Overview

This skill routes plain-language requests to Pi, Claude Code, Codex, OpenCode, Gemini CLI, or ACP harness work into either the OpenClaw ACP runtime or direct acpx-driven sessions. It detects intent to run or continue harness work and chooses the appropriate path while enforcing installation, session, and failure-recovery policies. The goal is reliable, predictable harness control without using subagent runtimes or PTY scraping.

How this skill works

The router inspects user intent for harness-related requests and maps named harnesses to default agentIds (pi, claude, codex, opencode, gemini). It prefers the OpenClaw ACP runtime path via sessions_spawn (runtime: "acp", thread: true, mode: "session") and embeds the task so the session receives it immediately. If the runtime is unavailable or the user requests direct control, it drives the harness using a pinned plugin-local acpx binary and deterministic session names.

When to use it

  • User asks to run or continue work in Pi/Claude Code/Codex/OpenCode/Gemini harnesses
  • Start a threaded harness session where follow-up prompts must stay in context
  • Relay prompts directly to an external coding harness without subagent lifecycle needs
  • When ACP runtime is unhealthy or unavailable and a deterministic fallback is required

Best practices

  • Always set agentId explicitly unless a different ACP default is known
  • Prefer OpenClaw ACP runtime (sessions_spawn) for end-to-end lifecycle and thread behavior
  • Use plugin-local pinned acpx binary at ./extensions/acpx/node_modules/.bin/acpx for direct calls
  • Name direct sessions deterministically (oc-<harness>-<conversationId>) so follow-ups reuse context
  • Verify and repair acpx installation automatically before offering fallback; avoid global installs unless requested

Example use cases

  • User: "spawn a test codex session in thread and tell it to say hi" — use sessions_spawn with task:"Say hi." and agentId:"codex"
  • User: "Keep a Claude thread going to iterate on this function" — create an ACP session thread so the harness retains conversation history
  • User: "Just relay these prompts to pi via CLI" — use acpx with a stable session name and --format quiet, creating the session if missing
  • User: "Start a one-shot OpenCode run in my repo" — run acpx <agent> exec with --cwd set to workspace path

FAQ

Automatically attempt local repair (ensure plugin-local acpx, verify version, reinstall if needed), restart gateway and retry spawn once; only then offer fallback options.

When should you use direct acpx instead of the ACP runtime?

Use direct acpx when the user explicitly requests it, when the ACP runtime is unavailable/unhealthy, or when the task is pure prompt relay and lifecycle features are unnecessary.

Built by
VeilStrat
AI signals for GTM teams
© 2026 VeilStrat. All rights reserved.All systems operational