harnesslisted

# harness — flag-routed skill The first token of `$ARGUMENTS` selects the mode: `--onboard | --init | --add | --run | --status | --stop | --resume`. Everything after it is the mode's input. Engine scripts live at `${CLAUDE_PLUGIN_ROOT}/bin/` (also on PATH as `harness-*.sh`). Always call them with absolute paths: `bash "${CLAUDE_PLUGIN_ROOT}/bin/harness-run.sh" status`. **Every side effect goes through an engine verb.** You never run osascript/tmux yourself, never write registry/state files by hand, never label GitHub issues except via `harness-tickets.sh`. Config resolution (engine-enforced, know it to explain it): **project `.harness/config.json` > user `~/.claude/harness/config.json` > built-in defaults**, per key. --- ## --onboard (user-level setup; safe to re-run, preserves unknown keys) Goal: write `~/.claude/harness/config.json`. Use AskUserQuestion for each decision — never assume. Steps: 1. **Terminal**: detect the default deterministically — run `echo "$TERM_PROGRAM"` (`iTerm.app` → iterm2, `Apple_Terminal` → terminal; empty → check `ls /Applications/iTerm.app`). Present the detection: "You're running in iTerm2 — use it for harness sessions?" Options: detected app (recommended) / other installed terminal / tmux. Then ask fullscreen yes/no and explain the two-window layout (control window: orchestrator + watch; work window: workers) — it's the default; power users can edit `terminal.windows` later. 2. **Accounts**: explain plainly: "By default t