NinjaTech / SuperNinja

NinjaTech ships as two distinct agent surfaces, and they need different harnesses:

• Ninja Dev — a local IDE / VS Code-style agent. Runs on your machine. Treeship attaches via MCP or shell-wrap.
• SuperNinja — a remote VM agent. Treeship can't auto-discover it locally; it joins through the (forthcoming) treeship agent invite flow or via GitHub PR / Actions evidence.

This page covers both. If you're not sure which you're running, treeship add --discover will tell you.

Ninja Dev (local)

Detection

Treeship looks for these signals on treeship add --discover:

• ~/.ninja-dev/ directory
• ~/.config/ninjatech/ directory
• A VS Code extension whose dirname starts with ninjatech or ninja-dev
• ninja-dev or ninjatech on PATH

Any one is enough to surface a discovery hint. Two or more bumps confidence from low to medium.

Harness profile

treeship harness inspect ninjatech-ninja-dev

Attach

There's no automated installer for Ninja Dev today (install: None in the manifest) — the extension's MCP config path varies across versions. Register manually:

treeship agent register \
  --name ninja-dev \
  --tools read_file,write_file,bash \
  --description "Ninja Dev IDE local"

Then point your Ninja Dev MCP config at npx -y @treeship/mcp — see the Generic MCP guide for the shape.

SuperNinja (remote VM)

Why it's not auto-discoverable

SuperNinja by definition runs on a machine that isn't yours. Discovery shows it as an always-on hint with confidence: low, not as a detection — there's no filesystem signal we could honestly match on.

treeship harness inspect ninjatech-superninja

The harness inspect output is honest about this:

known gaps:
  - SuperNinja runs on a remote VM and is not auto-discoverable locally.
  - Coverage stays at basic until Treeship runs inside the VM or routes through MCP.
  - Use `treeship agent invite` to attach a remote host (deferred to v0.9.9).

What works today (v0.9.8)

Three honest paths, in order of fidelity:

1. Manual register + git-reconcile backstop

Best when SuperNinja's edits land in your local workspace via PR or rsync:

treeship agent register \
  --name superninja \
  --tools read_file,write_file,bash \
  --description "SuperNinja remote VM via PR"

Then run a normal session — git-reconcile at close picks up the diff. The receipt's files-written list will be tagged [git-reconcile] instead of [hook], which is the honest source attribution.

2. Manual register + GitHub Actions evidence

If SuperNinja opens PRs against this repo, you can verify those PRs separately and link the receipts. Coming as part of the GitHub verification surface — see GitHub verification (v0.9.9).

3. MCP if the remote routes through it

If your SuperNinja deployment exposes an MCP endpoint, you can point a local @treeship/mcp proxy at it and Treeship will see MCP-routed tool calls. This is the same shape as Generic MCP.

What lands in v0.9.9

# On your local machine
treeship agent invite \
  --name superninja \
  --kind ninjatech-superninja \
  --host remote-vm

# Output:
#   Run on the remote VM:
#     curl -fsSL treeship.dev/setup | sh
#     treeship join --invite trj_8xK2...

The invite encodes which Ship/workspace the remote should join, expires in 15 minutes, and produces a Host Card + Agent Instance Card on this side once the remote runs join. After join succeeds, the SuperNinja harness can run inside the VM, lifting coverage from basic to medium (or higher if MCP plumbing is wired).

This is intentionally not in v0.9.8. The principle is local-first: get a signed receipt from local agents before adding the remote-attach configuration burden.

See also

• Agent Harnesses — how harnesses work in general
• Coverage levels — what basic vs medium actually claim
• First run — local-first setup flow
• Generic MCP — shape of any custom MCP-backed harness