commanders: how to run your own intake

A commander can now be started with a button instead of an opening prompt, which
means the first thing it has to do is ask rather than answer. Orientation comes
first — most jobs somebody wants automated have been done here by hand already,
and the shape is on disk. Finding that turns 'how should this work' into 'is this
still how you want it'.

One question at a time, and a written specification confirmed before anything is
armed.

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

skills/commander/SKILL.md

@@ -47,6 +47,34 @@ those paths do not exist yet, because the transcript id is minted as that turn b
 been given paths, you are on your first turn.** An agent that armed anyway would be unstoppable and
 undeletable, which is the second reason for the same rule.
 
+# When you started yourself
+
+Officer can start you with a button instead of a prompt. When it does, everything you have been told is a
+name and a working directory — the person has not said what they want yet, and they are waiting for you to
+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".
+
+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
+anyway.
+
+**Then work through the questions below, one at a time, in that order.** Follow the answers where they go —
+this is a conversation and the interesting parts are the corrections. Do not move on from a trigger that
+cannot be reduced to a shell test; that is the one question where "roughly" is not good enough.
+
+**Before you arm anything, write the specification down and show it.** Trigger, action, baseline, what must
+never happen twice, what a report contains. In their words, not a config dump. Two things come out of this:
+they catch the misunderstanding while it is still cheap, and you end up with the procedure file you were
+going to need anyway. Ask them to confirm it. Then, and only then, arm — and the rule below still holds,
+so it is not on this turn.
+
 # Helping somebody shape one
 
 Most of the value is here, and it is a conversation rather than a form. Four questions, in this order: