verify-witness
Verify the Ed25519 witness manifest of a scaffolded harness. Fast yes/no signature check that proves the publisher signed this exact file set — separate from the full release-readiness umbrella in validate-harness.
git clone --depth 1 https://github.com/ruvnet/metaharness /tmp/verify-witness && cp -r /tmp/verify-witness/.claude-plugin/skills/verify-witness ~/.claude/skills/verify-witnessSKILL.md
# verify-witness > Codex skill: Ed25519 witness manifest verification for a scaffolded harness. ## What it does Reads `.harness/witness.json`, validates the Ed25519 signature against the embedded public key, and reports `VALID` / `INVALID` with a one-line reason. Distinct from [`validate-harness`](../validate-harness/): - `validate-harness` is the **umbrella** — doctor + verify + path-guard + mcp + secrets - `verify-witness` is **only** the signature check — fast yes/no for CI / federation handshakes / multi-signer workflows ## Usage from Codex ``` /verify-witness /verify-witness path=./my-harness /verify-witness path=./my-harness strict=false ``` ## Equivalent CLI ```bash harness verify ./my-harness ``` ## Why it's separate from validate-harness When two harnesses federate (iter 9), they need to confirm each other's witness signatures BEFORE doing the full release-readiness check. Splitting this surface lets federation peers run a fast signature handshake without paying for the full validate sweep. Also: CI workflows that only care about signature integrity (e.g. mirroring a published harness to a private registry) can call this skill instead of the heavier umbrella. ## What's checked | Check | Detail | |-------|--------| | File present | `.harness/witness.json` exists | | Manifest shape | All required fields (harness, version, entries, public_key, signature) | | Signature | Ed25519 verify against the embedded public key | | Strict mode | If `strict=true` and no witness, exit non-zero. If `false`, soft-skip with PASS | Exit 0 = signature VALID. Exit 1 = INVALID / missing (strict mode).
Diff two scaffolded harnesses (ADR-031). Reports manifest meta drift + host list + per-file fingerprint changes (added/removed/changed). Exits 0 IDENTICAL, 1 DRIFT, 2 missing manifest. Use --bundle for the ADR-031 schema-1 JSON envelope.
Scaffold your own focused AI agent harness — pick host (Claude Code, Codex, pi.dev, Hermes), template, agents, skills, and ship a npm-publishable harness with its own npx CLI. Use when a user asks to "create my own agent harness", "scaffold a harness", "make a custom Claude Code plugin like ruflo", or "build a vertical AI assistant for X".
Kernel-version skew check (ADR-027). Reports manifest surface + manifest kernel + installed kernel + verdict (match/patch-diff/minor-diff/major-diff). Exits 1 on minor/major skew with a copy-pasteable `npm install @metaharness/kernel@X.Y.Z` next step. Exits 2 if no .harness/manifest.json at path.
Health-check the harness: kernel load, MCP wiring, memory backend, host adapter.
Evolve this harness with Darwin Mode — frozen model, evolving harness (real, sandboxed, safety-gated).
Scaffold a ready-made AI agent harness in one command from the 19 published @metaharness/* example packages — 9 host integrations (Claude Code, Codex, Hermes, pi.dev, OpenClaw, RVM, Copilot, OpenCode, GitHub Actions) + 10 vertical pods (devops, research, trading, support, legal, coding, education, sales, gaming, repo-maintainer).
GCP Secret Manager integration: validate setup, fetch values, or confirm an NPM_TOKEN is non-revoked via `npm whoami`. Used for publish-time token rotation without long-lived keys in CI.
List the available harness templates and what each one ships with. Use when the user asks "what templates are available", "what verticals does the harness generator support", or "show me what I can scaffold".