sc:deploy-remote

Deploy & manage the remote from the local workspace

This skill lets the agent develop locally and then deploy / manage a remote host over SSH without leaving the local workspace. The workspace is linked to its remote via a small config file; you push code and run remote commands through that link. No remote engine, no server switching.

1. Read (or create) the workspace ↔ remote link

The link lives at .squadcoder/remote.json in the workspace root:

{
  "host": "Relay",                      // an ~/.ssh/config alias (preferred) OR user@host
  "path": "/opt/squadcoder",            // the remote target directory
  "build": "npm run build",             // optional: local build to run before deploy (or null)
  "exclude": ["node_modules", ".git", ".env", ".env.*", "*.key", "*.pem", "id_*", "*.log", "dist/cache"],
  "postDeploy": "sudo systemctl restart squadcoder || true"  // optional: remote command after sync
}

• If the file exists, use it.
• If it does not exist, ASK the user for the host (offer the hosts in ~/.ssh/config) and the remote path, then WRITE the file (with the secret-safe exclude defaults above) so the link persists for next time. Confirm the values back before deploying.

2. Pre-flight (do these EVERY time, in order)

1. Confirm the target out loud: "Deploying <workspace> → <host>:<path>. Proceed?" Wait for go on the first deploy of a session.
2. Verify SSH reachability (non-destructive): ssh <host> 'echo ok && whoami && uname -a'. If it fails, stop and report — do not guess credentials.
3. Create the remote dir if missing (idempotent, never deletes): ssh <host> 'mkdir -p "<path>"'.
4. Local build if build is set: run it locally and stop on failure (never deploy a broken build).

3. Security gate (MANDATORY — this is the whole point of the exclude list)

Before any file leaves the machine:

• NEVER sync secrets. Always apply the exclude patterns (.env*, *.key, *.pem, id_*, credentials, .git). If you detect a secret-looking file that isn't excluded, STOP and warn.
• Scan the diff for hard-coded secrets (API keys, tokens, passwords) in the files about to ship; if found, refuse and tell the user to move them to env/secret storage on the remote.
• Least privilege: prefer a non-root SSH user + sudo only for the specific service restart. Never chmod 777, never deploy as root unless the user explicitly says so.
• Loopback/keys only: rely on the host's key auth from ~/.ssh/config; never put passwords in argv.