a watcher needs a baseline, and the deploy procedure needs to be findable

Two gaps found by testing the actual goal — "I say watch master for a new tag, and it works without me
listing the caveats" — rather than by rereading what was written.

THE BASELINE. The commander skill had "what must never happen twice", which is a CLAIM: do not act twice on
the same item. The owner's constraint is different and was missing entirely: do not act on items that already
existed when you were armed. "Watch for a new tag" is not a condition — a watcher armed today sees every
historical tag and, unless something says otherwise, treats all of them as news and acts on each in turn.
Nobody says "ignore the ones already there" because to a person it is obviously implied. It is not implied to
a shell loop.

So the skill now names the two honest kinds of baseline — a record of what has been handled, which survives a
restart, or a snapshot taken at arming, which does not — and requires the loop to say which it is using. On
this machine the lock files made the omission harmless. On a fresh one, a new commander would have deployed
every tag in the history, one at a time.

FINDABILITY. The deploy procedure was reachable only through a sentence at the end of the commander skill, so
an agent asked to deploy would have to open one skill and read to its last line to learn the other existed.
It has a description of its own now, which is the entire interface: the agent sees only that before deciding
to open anything.

The new skill does NOT copy the procedure. It names `scripts/deploy-claim.sh`, `docs/servers.md` and the plan
format, which live with the code and change with it — a second copy would be right the day it was written and
wrong the day somebody edits the first, and the copy an agent happened to read would be the stale one. One
hop costs a Read; a wrong procedure costs a fleet.

What it does carry is the fleet-specific part that would not belong in a procedure: poll a local remote and
why (a tag pushed at 21:47 noticed at 23:07 through the public one, twenty seconds through the local),
pm_cwd rather than a hard-coded path, the per-host login, plugins:update restarting sidecars on its own, and
that a skipped host is either behind or current — different things, and only one of them asks the owner for
anything.

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

skills/commander/SKILL.md

@@ -53,6 +53,22 @@ if it is money, or a duplicate message, or a half-applied change, the action mus
 starting and refuse a second attempt. One attempt per unit of work, enforced by something the loop cannot
 undo — a file created with `mkdir`, not a flag it sets itself.
 
+**What does "new" mean — and this one you must supply, not ask for.** "Watch for a new tag" is not a
+condition. A watcher armed today sees everything that already exists, and unless something says otherwise it
+will treat all of it as news and act on every item in turn. Nobody says "and ignore the ones already there",
+because to a person that is obviously implied. It is not implied to a shell loop.
+
+So a watcher needs a **baseline**, and there are only two honest kinds:
+
+- **A record of what has been handled.** Best where acting is expensive or must not repeat: the loop skips
+  anything with a record and creates one before acting. This also survives a restart, which a remembered
+  baseline does not.
+- **A snapshot taken at arming.** Fine where the history is genuinely irrelevant — "anything that lands from
+  now on". Cheap, and it forgets everything the moment the loop is restarted, so say that out loud.
+
+Choose one and say which, in the condition itself. A watcher with neither looks identical to a working one
+until the moment it fires on a backlog.
+
 **What does "done" look like to you?** A report is worth more than a success flag, and the parts worth
 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.