the commander skill was missing four mechanics, three of them expensive

Audited it against what the background-job dialog actually sends and against the deploy procedure, rather
than trusting that it was complete. It carried the concepts and five of the nine mechanics. Four were absent,
and three had cost real time to discover:

- OFFICER_ROOT is EMPTY in the sidecar's environment, so a path built from it resolves to /data/... — a lock
  lands where nothing reads it and every release looks permanently undeployed.
- stderr must be kept out of a --output-format=stream-json pipe. The CLI prints warnings there and one of
  them corrupts the first jq parse.
- jq --unbuffered, or the job panel shows nothing for the duration and reads as hung. A background job with
  no output is indistinguishable from a dead one.
- The claim goes before the SPAWN, not inside the action: an action that dies before claiming has claimed
  nothing and runs again.

Also added the one instruction the dialog sends that the skill had dropped, and it is the most important of
them: ASK before arming if the condition is not completely clear. A wrong condition fails silently — it
either never fires or fires constantly — and is found out days later. Arming late costs a minute.

The audit is the point. A skill that covers the concepts and misses the mechanics reads as complete and
produces a loop that does not work, which is the failure mode a reference is supposed to prevent.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

skills/commander/SKILL.md

@@ -57,6 +57,27 @@ undo — a file created with `mkdir`, not a flag it sets itself.
 reading are the ones that are hard to reconstruct: what it skipped, what it could not verify, what it left
 outstanding. Ask for those explicitly or you will get a summary of what went right.
 
+# Writing the loop, if you are the one writing it
+
+The background-job dialog already sends the load-bearing mechanics — use the harness's own background
+mechanism, keep the wait in the shell, put the test into the shell condition, and **ask first if the
+condition is not completely clear** rather than arming a guess. That last one matters more than it reads: a
+wrong condition fails silently, either never firing or firing constantly, and it is found out days later.
+Arming late costs a minute.
+
+Four details the mechanics do not carry, each of which was learned by getting it wrong:
+
+- **`OFFICER_ROOT` is empty in the sidecar's environment.** Any path built from it resolves to `/data/...`,
+  so a lock file lands somewhere nothing reads and every release looks permanently undeployed. Set it
+  explicitly in the loop.
+- **Keep stderr out of a `--output-format=stream-json` pipe.** The CLI prints warnings there — a
+  connectors notice, among others — and one of them landing in the stream corrupts the first `jq` parse.
+  Redirect it to its own reader.
+- **`jq --unbuffered`**, or the job panel shows nothing for as long as the work takes and reads as hung.
+  A background job that produces no output is indistinguishable from a dead one.
+- **The claim goes before the spawn, not inside the action.** If the action claims its own work, an action
+  that dies before claiming has claimed nothing and will run again.
+
 # Things that are true and surprising
 
 - **Its cost line understates.** The recorded cost counts the commander's OWN turns — one row per `result`