commanders: orient in whatever this place is, not in a repository

The intake section named a `deploy/` folder as what to look for, which is a
platform-shaped thought in a file that has to work for a mailbox, a drop folder,
a document library or a machine that runs one script. An example that specific
reads as an instruction.

So orientation says what it actually means — stop being a stranger to this
directory — and the domain knowledge arrives the way it was designed to: the
skills index lists what is available by description, and naming a system is the
cue to open its skill rather than to infer it from a directory listing. Officer
itself is just one entry in that index, not a special case worth writing down
here.

And if there is no skill for what they named, say so and ask. That is a real
answer; inventing a mechanism to fill the gap is not.

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

skills/commander/SKILL.md

@@ -54,12 +54,24 @@ name and a working directory — the person has not said what they want yet, and
 ask. That is the whole reason the button exists: writing a good opening prompt is the hard part, and asking
 somebody to do it before they have talked to you gets it done badly or not at all.
 
-**Turn one is orientation, not questions.** Read where you actually are before you ask anything. List the
-directory, read a README, look at what the repository already does — and check whether the job they are
-about to describe has been done here by hand before. Most of the time it has, and the shape of it is on
-disk: a `deploy/` folder with previous releases in it, a procedure somebody wrote, a script with the steps
-already ordered. Finding that is worth more than any question you could ask, because it turns "how should
-this work" into "is this still how you want it".
+**Turn one is orientation, not questions.** Read where you actually are before you ask anything. What that
+means depends entirely on what the directory turns out to be — a repository, a folder somebody drops files
+into, a mailbox, a library of documents, a machine that runs one script. List it, read whatever explains
+it, and form a view. You are not looking for anything in particular; you are trying to stop being a
+stranger before you ask somebody to explain their work to you.
+
+**Whatever the job is, look for whether it has been done here by hand already.** It usually has, and the
+shape of it is on disk — a folder of previous runs, a procedure somebody wrote down, a script with the
+steps already in order, a naming convention nobody documented. Finding that is worth more than any
+question you could ask, because it turns "how should this work" into "is this still how you want it", and
+the second question gets a much better answer.
+
+**When they name a system, read its skill before you reason about it.** Your skills index lists what is
+available here by description; the bodies load when you open one. So a system that Officer knows about —
+itself included — has its knowledge somewhere better than your guess, and reaching for it is one tool call.
+Do that instead of inferring how something works from its directory listing, and instead of asking them to
+explain something already written down. If there is no skill for what they named, say so plainly and ask;
+that is a real answer, and inventing a mechanism to fill the gap is not.
 
 Then open with what you found, and one question. Not four. A person answers one question well and a list
 badly, and the answers you get to questions two through four will be shaped by the answer to the first