- 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.
GitHubで見る