# Conductor Remote Long Task > Coordinate recoverable remote SSH compute from any local project by using the central Conductor runtime at /.local/conductor, selecting a verified SSH route for either a workstation or a shared compute server, dispatching direct remote commands or scripts, and closing the job with local review. Use when Codex should run tests, builds, data processing, or other compute remotely over SSH instead of delegating to a second remote AI runtime, especially when the work may outlive the current thread and needs receipts, logs, and recoverable closeout. - Skill: `ocean326/conductor-remote-long-task` (Agent Skill, multi-file: 4 files) - Install (CLI): `npx skillmds@latest add ocean326/conductor-remote-long-task` - Raw SKILL.md: https://api.skillmd.com/api/skills/ocean326/conductor-remote-long-task/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Productivity - Author: ocean326 (https://skillmd.com/u/ocean326) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/ocean326/conductor-remote-long-task --- # Conductor Remote Long Task Use this skill as a thin Conductor wrapper around remote SSH compute. Keep durable control state local and keep remote execution ordinary shell compute. Read these bundled resources only when needed: - `scripts/select_ssh_route.py` to probe `workstation` or `shared-server` and return the best SSH alias plus remote shell command. - `references/command-patterns.md` to copy exact helper commands, dispatch patterns, and close-out shapes. ## Installed Defaults Use these fixed paths and values unless the user explicitly overrides them: - PersonalBrain root: `` - helper path: `/30_skills/personal/conductor_runtime/conductor_runtime_v1.py` - runtime root: `/.local/conductor` - supported target machines: - `workstation` - `shared-server` - preferred workstation Linux route order: - `workstation-linux-primary` - `workstation-linux-via-host` - `workstation-linux-campus` - preferred shared-server route order: - `shared-server-primary` - `shared-server-via-linux` - `shared-server-via-workstation` Always call the helper with: - `--runtime-root /.local/conductor` Never rely on a project-local relative `.local/conductor`. ## Public-Safe Environment Notes This public copy keeps route names, toolchain paths, and machine inventory generic on purpose. Keep the workflow shape here, then fill in the real aliases, paths, and package/runtime details only in your private install. Recommended pattern: - keep one primary Linux route for workstation compute - keep one fallback Linux bridge route through the workstation host shell - keep one Windows-native route for toolchains that must stay in the Windows shell - keep one primary shared-server route and one or two documented fallback routes - store CUDA, compiler, and virtual-environment specifics in private machine notes, not in the public skill body - if remote shells need extra environment setup, source one stable shell-init file instead of repeating many exports in every command - if Windows-native package builds are sensitive to proxies or codepage issues, clear those environment variables in a private wrapper before networked build steps ## Use This Skill For - remote tests, builds, data processing, or material-processing tasks on a workstation or shared compute server - tasks that need a receipt, recoverable checkpoints, and local close-out - tasks started from any local project directory but coordinated by the central Conductor runtime Do not use this skill for: - whole-machine administration - interactive long-lived remote sessions - remote LLM orchestration or a second remote AI runtime - broad multi-machine fanout where several targets should run in parallel - short local tasks that do not need remote orchestration ## Required Intent Fields Resolve these fields from the user's request before dispatch: - `target_machine` - `runtime_family` - `workspace_or_root` - `task_class` - `objective` - `success_criteria` Default rules: - infer `target_machine=workstation` when the request does not name a machine - allow only `workstation` or `shared-server` - default `runtime_family=linux` for workstation compute unless the task clearly needs the Windows shell - force `runtime_family=linux` for `shared-server` - infer `task_class=research` only when the request is clearly about collecting, organizing, or summarizing material - otherwise use `task_class=project` - ask a minimal follow-up only when `workspace_or_root` or `success_criteria` is too ambiguous to run safely ## Fixed I/O Contract Local input contract: - `target_machine` - `runtime_family` - `workspace_or_root` - `task_class` - `objective` - `success_criteria` Always resolve missing fields from natural language first. Ask the smallest possible follow-up only when a safe run still cannot be inferred. Remote evidence contract: - a remote exit status or detached-session marker - remote absolute paths for output files, logs, or result folders when those paths matter later - a local dispatch log under `.local/conductor/artifacts//` Local close-out contract: - `complete` - `gate` - `review` Use the local dispatch log as fallback evidence when the remote task itself does not emit a richer artifact set. ## Workflow ### 1. Create the central receipt Run: - `submit` Then keep the returned `job_id`. ### 2. Select the SSH route Run `python3 scripts/select_ssh_route.py --target-machine --runtime `. Carry forward these fields from the result: - `selected_alias` - `remote_shell_command` - `route_family` If no route succeeds: - treat it as a transport failure - write a local checkpoint with the failed aliases - stop before mutating remote state further ### 3. Reserve a job-local tool path when a script is clearer than one command Run: - `tool-path --job-id --tool-name run_remote_compute.sh` Write task-specific scripts only inside: - `/.local/conductor/artifacts//tools/` Prefer: - `dispatch` for a short one-shot command - `dispatch-script` for multi-line shell logic, environment setup, or result capture Do not place task-specific executors in the skill folder. ### 4. Execute direct remote compute Run: - `dispatch --job-id --ssh-target --command ""` - or `dispatch-script --job-id --local-script --ssh-target --remote-shell-command ""` Use these shell rules: - workstation Linux-path tasks: - prefer `workstation-linux-primary` with `bash -s` - otherwise bridge through `wsl -e bash -s` - workstation Windows-shell tasks: - use `powershell -NoProfile -NonInteractive -Command -` - shared-server tasks: - use `bash -s` For workstation Linux CUDA/Python tasks, prefer the primary direct route and a preconfigured shell init file so routine jobs do not need to repeat environment exports inline. For workstation Windows-native CUDA/Python builds, prefer a `cmd /c` wrapper that: - calls the local Visual Studio build-tools bootstrap first when native extensions require MSVC - clears stale proxy variables before networked package installs - sets `PYTHONUTF8=1` when source installs are sensitive to README or metadata encoding - exports `CUDA_PATH` from your private machine config before invoking GPU build tools - uses one documented GPU-capable Python environment from your private machine notes when the task matches a previously verified workflow Do not launch `codex exec`, supervisor wrappers, or a remote agent as part of this skill. If the task truly needs to outlive the current thread, use ordinary remote primitives such as `tmux`, `nohup`, or a job-local shell wrapper and then poll with short SSH probes. Keep that detached mode exceptional. ### 5. Close the job locally After the remote command or script finishes: 1. call `complete` 2. call `gate` 3. call `review` Decision rules: - if the remote command returns `0`, prefer `review --decision done` - if the remote command returns nonzero but the failure is informative and final, prefer `review --decision blocked` - if transport fails or the detached job disappears without usable evidence, prefer `review --decision needs_followup` Include in `evidence_pointers`: - the local dispatch log - any remote output path that the user may need next - any detached-session marker such as `tmux:` or `pid:` ## Guardrails - keep the runtime centralized under `/.local/conductor` - treat the skill as a protocol adapter, not a second execution engine - prefer direct SSH compute over remote agent orchestration - prefer `workstation-linux-primary` for workstation Linux-path work when available - if `workstation-linux-primary` is down, fall back to `workstation-linux-via-host` or `workstation-linux-campus` plus `wsl -e bash -s` - prefer direct `shared-server-primary` for shared compute, then `shared-server-via-linux`, then `shared-server-via-workstation` - treat host-key verification failures as route failures; choose another verified alias instead of mutating SSH trust mid-task - treat the shared server as compute only, not as a durable knowledge home - do not reopen a closed receipt - respect same-job locking; if a helper command returns `job_lock_conflict`, wait and retry the next polling cycle instead of forcing a write - if a helper command returns `protocol_conflict` for a closed receipt, stop mutating that job - if SSH transport is down, record the transport failure and retry only after a route probe succeeds again ## Example Triggers - `Use $conductor-remote-long-task to run this test suite on my workstation over SSH and close with evidence.` - `Use $conductor-remote-long-task to run shared compute on my server and choose the best reachable SSH path.` - `Use $conductor-remote-long-task from this project and keep the central Conductor runtime.`