Multi Harness

---
name: multi-harness
description: Universal Harness Adapter — Delegate bounded coding-agent work across local agent harnesses (Pi, OpenCode, Codex CLI, Claude Code CLI, DHS). Use for explicit cross-harness requests, model comparisons, external-only runtimes, or named models requiring a CLI fallback. Do not use for generic requests to spawn subagents already exposed by the current session.
---

# Multi Harness (Universal Harness Adapter)

Coordinate local agent harnesses without losing control of scope, safety, or verification.

Use this skill as the primary agent. You remain the orchestrator: decide what to delegate, run the external harness, inspect its output and any file changes, then synthesize the result for the user.

## Routing Gate

Apply this gate before diagnostics, profile selection, or running `delegate.py`:

1. Default to the current harness's native subagents when they expose the requested model. Requests for generic subagents, workers, parallelism, or orchestration are not external-harness requests.
2. Use this skill only with an explicit external signal: Pi, OpenCode, Codex CLI, Claude Code CLI, DHS, another/external/cross harness, multiple distinct harnesses, harness comparison, or an external-only runtime the user has asked to use.
3. When the user explicitly requests an external runtime or specific CLI model, use the Universal Harness Adapter (`delegate.py`).
4. If this skill was auto-triggered without an explicit external signal, do not run diagnostics or delegation scripts. Continue using the current harness's native subagent tools.
5. If the requested harness or model is not available locally, report the limitation and ask for confirmation before switching to an alternative model, harness, or native subagents. Never silently substitute.

Examples:
- "Spawn three Codex subagents" -> use native Codex subagents when exposed; if unavailable, report the limitation and confirm before using the Codex CLI profile.
- "Parallelize the review with subagents" -> native subagents; do not use `multi-harness`.
- "Delegate this review to Pi with GLM or DeepSeek" -> use `multi-harness`.
- "Run this implementation via DeepSeek Harness (DHS/DSH) or OpenCode" -> use `multi-harness`.

## Universal CLI Harness Execution

The adapter supports running bounded tasks across:
- **Codex CLI**: `codex exec --ephemeral [-m <model>] [-C <dir>] [--yolo]`
- **Claude Code CLI**: `claude -p "<prompt>" [--dangerously-skip-permissions]`
- **DeepSeek Harness (DHS / DSH)**: `dsh exec --dir <dir> [--model <model>] [--yolo]` *(Headless execution engine; no terminal TUI)*
- **Pi**: `pi --print --mode text [--model <model>] --tools <tools>`
- **OpenCode**: `opencode run --dir <dir> [--model <model>] [--auto]`

For dynamic model resolution:
Profiles with `model: auto` dynamically discover and select the highest active frontier model in your local runtime configuration (e.g. resolving `GLM-5.3+`, latest `DeepSeek-V4+`, or `GPT-5.x`), or accept explicit user overrides via `--model <name>`.

For permission bypass across any harness:
Pass `--yolo` or `--dangerously-skip-permissions` to `delegate.py`. It will map the flag to each harness's native permission bypass mechanism (`--yolo` for Codex/DHS, `--dangerously-skip-permissions` for Claude Code, `--auto` for OpenCode, full tool allowlist for Pi).

For delegated implementation with worktree auto-isolation:
Pass `--worktree <slug>` to `delegate.py`. It will:
1. Validate `<slug>` (alphanumeric characters, dashes, and underscores only; rejecting `.`, `..`, traversal segments, and absolute paths) and resolve inside `.worktrees/<slug>` on branch `task/<slug>`.
2. Verify the worktree path is registered with Git if it already exists, preventing escapes or hijacking of existing directories.
3. Execute the delegated task inside the isolated worktree, requesting structured YAML output via prompt conventions.
4. Capture raw output, exit code, and run metadata cleanly without touching the main checkout.

## Quick Start

Run diagnostics to check installed harnesses and local models:

```bash
python3 <skill_dir>/scripts/delegate.py --diagnose
python3 <skill_dir>/scripts/delegate.py --list-profiles
```

Delegate a read-only review to Pi with the latest GLM frontier model:

```bash
python3 <skill_dir>/scripts/delegate.py \
  --profile pi-glm-review \
  --cwd "$PWD" \
  --task "Review the changed files for correctness bugs. Return only actionable findings."
```

Delegate a write-capable implementation only when the user explicitly wants another harness to edit files:

```bash
python3 <skill_dir>/scripts/delegate.py \
  --profile pi-glm-implement \
  --allow-write \
  --cwd "$PWD" \
  --task "Implement the scoped change described in PLAN.md task 2. Keep edits minimal and run tests."
```

Use `--dry-run` before any unfamiliar profile.

## Routing

Read `references/profiles.md` when choosing a profile or adding a new one.

Default choices:
- Research, planning, deep review, debugging: `pi-glm-*` or `pi-deepseek-*` profiles.
- Isolated Pi profiles: `pi-lean` (minimal/clean), `pi-gsd` (GSD prompts), `pi-search` (research), or any local profile via `--pi-profile <name>`.
- Large context sweeps: `pi-minimax-large`.
- Headless execution: `dhs-*` profiles via DeepSeek Harness.
- Fast mechanical scan or OpenCode-specific command behavior: `opencode-fast`.
- Implementation by another harness: only a `*-implement` profile with `--allow-write` or `--yolo`.

GLM, DeepSeek, and OpenAI profiles automatically resolve to the highest version available in your local runtime configuration (e.g. `glm-5.3` when configured) unless an explicit `--model` is supplied.

## Delegation Workflow

1. Define the task boundary in one paragraph: objective, files/dirs, non-goals, and expected output.
2. Choose the lowest-risk profile that can do the job.
3. For read-only delegation, use profiles that enforce read-only tools where possible. Pi can enforce this with `--tools read,grep,find,ls`; OpenCode read-only depends on prompt contract or a configured read-only agent.
4. Run `delegate.py`. The script writes prompt/output metadata under `~/.cache/multi-harness/runs/`.
5. Read the returned output. Do not paste it blindly into the final answer.
6. If the harness was allowed to write, inspect `git status` and relevant diffs before accepting any change.
7. Verify with local tests/checks in the primary harness.
8. Report what was delegated, what came back, what you accepted, and what you rejected.

## Prompt Contract

Read `references/prompt-contracts.md` before delegating anything that can write files, touch secrets, call external services, or operate on production systems.

Every delegated prompt must include:

- The exact working directory.
- The task type and profile.
- Permission mode: read-only or write-allowed.
- Explicit forbidden actions.
- Expected output sections.
- A reminder that the external harness has no reliable access to this conversation unless you include the context.

## Guardrails

- Do not delegate secrets, credentials, private keys, raw `.env` values, or production tokens.
- Do not let another harness perform destructive operations, cloud changes, Kubernetes changes, database writes, payments, email sending, or git pushes without a separate explicit user request.
- Do not run write-capable profiles on a dirty worktree unless you have inspected the existing changes and can distinguish user changes from delegated changes.
- Do not accept a delegated result without checking evidence. External harnesses are advisors/executors, not authorities.
- Do not use shell string interpolation for untrusted task text. Use `delegate.py` so prompts are passed as subprocess arguments.
- Stop and ask the user before delegating to a paid/quota-sensitive model for a large or open-ended job unless the user already requested it.

## Output Contract

Structured output requested from delegated workers (e.g. YAML status/findings blocks) is a prompt-level convention rather than a machine-enforced schema in `delegate.py`. The runner captures raw stdout and stderr; as the orchestrator, you must inspect and validate returned content yourself.

When reporting back to the user, include:

- Harness/profile used.
- Whether it was read-only or write-capable.
- Key findings or changes accepted.
- Verification you ran locally.
- Any residual risk or rejected delegate suggestion.

Keep raw delegate logs in the run directory; summarize instead of dumping them.