From f8c832d538fffa2691d4c9b56cd4faea80249437 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Andr=C3=A9=20Padez?= Date: Sat, 22 Aug 2026 23:09:07 +0000 Subject: [PATCH] commanders: orient in whatever this place is, not in a repository MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 --- skills/commander/SKILL.md | 24 ++++++++++++++++++------ 1 file changed, 18 insertions(+), 6 deletions(-) diff --git a/skills/commander/SKILL.md b/skills/commander/SKILL.md index 1764a91..bcc463e 100644 --- a/skills/commander/SKILL.md +++ b/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