harness-subagent

Hand a bounded task to another coding-agent CLI, then judge what comes back.

Ever wanted to call Codex from Claude Code?
Ever wanted Grok Build to invoke Claude Code?
Ever wanted Claude Code to send a diff to GPT for a second opinion?

That is this skill. You stay in the agent you already use. It becomes the parent: it writes a short brief, starts another CLI in the background, reads that CLI's report, and tells you what it agrees with, what it does not, and what it will do next.

The child is not an oracle. A model that reviews its own work repeats its own blind spots. A model trained by a different vendor may not. That value is lost if the parent forwards the answer without judging it.

Supported child CLIs: Claude Code (claude), Codex (codex), Grok Build (grok), Antigravity (agy), the Cursor CLI (cursor-agent), and Meta's Muse Code (muse). Name the CLI, model, or effort and that wins. Leave any of them out and the parent fills the gap from a short task table that prefers a different vendor than itself. No personas.

This is a Claude skill in the Agent Skills format. Any agent that can run a shell command in the background can use it.

Do not use it to install those CLIs, for questions the parent can answer from its own context, or inside a child it launched. A child never delegates again.

Installation

npx skills add realspqrk/harness-subagent -g

That is the skills.sh installer. -g installs at user level, for example ~/.claude/skills/harness-subagent for Claude Code or ~/.cursor/skills/harness-subagent for Cursor (paths). Update later with npx skills update -g.

Without npx, clone it into your agent's skills folder:

git clone https://github.com/realspqrk/harness-subagent.git ~/.claude/skills/harness-subagent

Requirements

• At least one of claude, codex, grok, agy, cursor-agent, or muse on PATH and logged in.
• Python 3 (python or python3).
• Windows: Git Bash. The parent runs scripts/spawn.sh through Git Bash. SKILL.md has the exact invocation.

Health check

From the installed skill folder:

scripts/health.sh            # one row per CLI: name, version, login, update
scripts/health.sh --update   # same, and runs each CLI's own update command

Example output (tab-separated):

claude   2.1.280 (Claude Code)   logged-in       -
codex    codex-cli 0.155.1       logged-in       -
grok     missing                 -               -
agy      present                 login-unknown   -
cursor   2026.09.08-6caf4ff      logged-in       -
muse     Muse Code 1.4.6 (1.4.6-R6000.1)  login-unknown   -

The exit code is 0 only when every CLI is present, every CLI with a login check is logged in, and (with --update) every update succeeded. A CLI you never use shows up as missing and makes the exit code 1. Read the rows. agy and muse have no login status command, so they always report login-unknown. The per-CLI login and update commands are in the Health section of SKILL.md.

Use it

The protocol is SKILL.md. This is the short version.

1. You name the CLI and the model, or let the parent pick. Spoken names such as Opus 5.5, Fable, Sonnet 5.5, Astra, Sol, Terra, Luna, Grok 4.7, Muse Wonder, Wonder Full, Spark, and Ember resolve to exact ids in references/models.md, which also lists prices and effort levels. For Antigravity and Cursor, pass the id that CLI accepts. If you leave the CLI, model, or effort out, the parent fills each blank from the task table in SKILL.md, says what it picked, and spawns. It never picks max, ultra, Fable, Wonder Full, or Grok 4.7 Fast on its own.
2. The parent writes a brief. It creates brief.md in a new temp run directory: one task sentence, where to look, what was already tried, and when it is done. It names paths. It does not paste the repo.
3. The parent runs scripts/spawn.sh in the background and waits for it to exit.
4. The parent judges the report. It reads report.md (or last.md) and capture-status.txt, then says what it agrees with, what it does not, and what it will do. A pasted report is not an answer.

you ──> parent ──brief.md──> spawn.sh ──> child CLI
             ^                               │
             └──────── report.md ────────────┘
parent judges ──> you

Things you can say:

• Ask Codex with Astra, effort high, to review the diff on this branch.
• Have Claude Code with Opus 5.5 build the settings page layout in src/ui/settings/.
• Ask Grok 4.7 to try to refute the plan in docs/plan.md.
• Use harness-subagent: Sol, medium effort. Find out why tests/api flakes on CI. Report only, no edits.
• Get Fable 5.2 to review this migration before I merge it.
• Get a second opinion on this plan from another vendor. (The parent picks the model and effort.)

One job per spawn. "Implement and then review it" is two spawns, or one spawn plus the parent's own review.

If the child hits a usage limit that resets within 24 hours, spawn.sh waits and resumes that same session once. Any other usage-limit stop ends the run. The parent reports it and waits for you. It does not switch CLI or model because of a limit.

With Superpowers

Superpowers is a development methodology built from skills. Several of its skills dispatch subagents through the host's own subagent tool:

This is the beginning of the README. Read the rest at the original. Read the full README ↗