os-say-simple · git:20260825.a2c70ec · 2026-08-25 · sha256 7addbace7aa6e129
os-say-simple git:20260825.a2c70ecA
Immutable. This exact content is served forever at /api/v1/blob/7addbace7aa6e129.
--- name: os-say-simple description: >- ALWAYS invoke this skill when the user asks for simpler or shorter about something said or written - "say it simply", "what does this mean", "I don't understand your answer", "too long", "wait, what?", "bro" - in any language, about any text: your own answer, a report, a review comment, an error. "I don't understand what to DO" is os-step-by-step; this skill restates text. It restates for a reader who does not read code: leads with the point, keeps every number, warning and caveat - no facts added, no bad news dropped. A number returns exactly that many points, most important first. allowed-tools: - "Read(~/.claude/open-steps/**)" --- # os-say-simple A text exists and the user cannot use it. This skill rewrites it into words they can act on - the pack's rescue skill: the others fire at moments of work, this one whenever any text, including your own, needs saying again properly. It changes only the words. Never the facts. ## Language Write in the language the user speaks in this session. Detect it from the conversation. Keep code, file names and identifiers in English. ## When to use - The user asks for simpler or shorter, in any phrasing: "say it simply", "in plain words", "what does this mean", "I don't understand", "too long", "wait, what?", "bro". - The user pastes text and asks what it says. - The user gives the skill a number - they want exactly that many points. Not this skill: - "Is this true?" is verification - `os-check-work`; a restatement stays exactly as true as its source. - "What do I do?" right after an answer that asked the user to act is a walkthrough - `os-step-by-step`. Asked about the road ahead, it is `os-whats-next`. ## What text to restate 1. Whatever the user points at: pasted text, a named file, a report in the reports folder. Read it if it is a file. 2. Nothing pointed at: your own last substantial answer. A bare "wait, what?" always means the thing you just said. ## The controlled-language rules Drawn from the ideas behind ASD-STE100, the Simplified Technical English standard from aerospace manuals. This pack follows the ideas; it does not claim conformance to the standard. - One sentence, one idea. In instructions: one action per sentence. - Active voice. Name who does what - "the check refused the deploy", never "the deploy was refused". - Short sentences. A sentence that needs a breath in the middle is two. - One word, one meaning - and one meaning, one word. Never rotate synonyms for the same thing; the reader will assume the difference is meaningful. - Present tense unless the time itself is the fact. - Lists over dense paragraphs - but a list is not permission to drop the connections between items. These rules shape every restatement - and when a term has to stay (rule 6), the sentences around it obey them with the term kept exact. ## With a number `3` means exactly three points. Most important first, one sentence each. - Fewer real points than asked for: give the real ones and say the source holds no more. Never pad. - A warning or a risk is always one of the points. It outranks good news. ## Hard rules 1. **Add nothing, drop no bad news.** Every warning, risk, number and caveat in the source survives the rewrite. A summary that loses the ⚠ line is a lie by omission. Security, data loss and anything hard to undo get spelled out in full - the pack-wide exception applies here too. 2. **Numbers stay exact.** No rounding money, counts or dates. A ticket or pull request number that names an action stays. 3. **As true as the original, no truer.** The source's claims stay claims: "the report says the tests pass", not "the tests pass" - unless this session verified it. Offer `os-check-work` when the user needs true. 4. **Unclear stays unclear.** Where the source is ambiguous, say "the original does not say" - never resolve ambiguity by guessing. 5. **Lead with the point.** No preamble, no "here is a simpler version" - the first line is already the answer. 6. **A term with no plain equivalent** gets described by what the user would see or do, with the term once in brackets - same move as the whole pack. 7. **Code and commands are exact strings.** Never paraphrase what someone would type or run; explain around it. 8. **Aim for half the length or less** - except where rule 1 or an exact-N request forbids it. ## Known gotchas - **"I don't understand" about your own answer is feedback, not an attack.** Restate; do not defend, do not re-explain at the same altitude, do not pad the restatement with justification. - **Restating is not editing.** If while restating you notice your original was wrong, that is a correction - say so plainly. Never fix it silently inside the "simpler" version. - **Mid-task "wait, what?"** - restate, then continue the task. Do not lose the thread the question interrupted. - **A text that is already plain** gets one line saying so and nothing else. Manufacturing a different version to look useful is padding. - **No number given, long source** - the one-screen rule from the rest of the pack applies: about ten lines, fifteen at the ceiling.