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
- Whatever the user points at: pasted text, a named file, a report in the
reports folder. Read it if it is a file.
- 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
- 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.
- Numbers stay exact. No rounding money, counts or dates. A ticket or
pull request number that names an action stays.
- 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.
- Unclear stays unclear. Where the source is ambiguous, say "the
original does not say" - never resolve ambiguity by guessing.
- Lead with the point. No preamble, no "here is a simpler version" -
the first line is already the answer.
- 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.
- Code and commands are exact strings. Never paraphrase what someone
would type or run; explain around it.
- 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.
1---2name: os-say-simple3description: 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.4---5
6# os-say-simple
7
8A text exists and the user cannot use it. This skill rewrites it into words
9they can act on - the pack's rescue skill: the others fire at moments of work,
10this one whenever any text, including your own, needs saying again properly.
11It changes only the words. Never the facts.
12
13## Language
14
15Write in the language the user speaks in this session. Detect it from the
16conversation. Keep code, file names and identifiers in English.
17
18## When to use
19
20- The user asks for simpler or shorter, in any phrasing: "say it simply",
21 "in plain words", "what does this mean", "I don't understand", "too long",
22 "wait, what?", "bro".
23- The user pastes text and asks what it says.
24- The user gives the skill a number - they want exactly that many points.
25
26Not this skill:
27
28- "Is this true?" is verification - `os-check-work`; a restatement stays
29 exactly as true as its source.
30- "What do I do?" right after an answer that asked the user to act is a
31 walkthrough - `os-step-by-step`. Asked about the road ahead, it is
32 `os-whats-next`.
33
34## What text to restate
35
361. Whatever the user points at: pasted text, a named file, a report in the
37 reports folder. Read it if it is a file.
382. Nothing pointed at: your own last substantial answer. A bare "wait, what?"
39 always means the thing you just said.
40
41## The controlled-language rules
42
43Drawn from the ideas behind ASD-STE100, the Simplified Technical English
44standard from aerospace manuals. This pack follows the ideas; it does not
45claim conformance to the standard.
46
47- One sentence, one idea. In instructions: one action per sentence.
48- Active voice. Name who does what - "the check refused the deploy", never
49 "the deploy was refused".
50- Short sentences. A sentence that needs a breath in the middle is two.
51- One word, one meaning - and one meaning, one word. Never rotate synonyms
52 for the same thing; the reader will assume the difference is meaningful.
53- Present tense unless the time itself is the fact.
54- Lists over dense paragraphs - but a list is not permission to drop the
55 connections between items.
56
57These rules shape every restatement - and when a term has to stay (rule 6),
58the sentences around it obey them with the term kept exact.
59
60## With a number
61
62`3` means exactly three points. Most important first, one sentence each.
63
64- Fewer real points than asked for: give the real ones and say the source
65 holds no more. Never pad.
66- A warning or a risk is always one of the points. It outranks good news.
67
68## Hard rules
69
701. **Add nothing, drop no bad news.** Every warning, risk, number and caveat
71 in the source survives the rewrite. A summary that loses the ⚠ line is a
72 lie by omission. Security, data loss and anything hard to undo get spelled
73 out in full - the pack-wide exception applies here too.
742. **Numbers stay exact.** No rounding money, counts or dates. A ticket or
75 pull request number that names an action stays.
763. **As true as the original, no truer.** The source's claims stay claims:
77 "the report says the tests pass", not "the tests pass" - unless this
78 session verified it. Offer `os-check-work` when the user needs true.
794. **Unclear stays unclear.** Where the source is ambiguous, say "the
80 original does not say" - never resolve ambiguity by guessing.
815. **Lead with the point.** No preamble, no "here is a simpler version" -
82 the first line is already the answer.
836. **A term with no plain equivalent** gets described by what the user would
84 see or do, with the term once in brackets - same move as the whole pack.
857. **Code and commands are exact strings.** Never paraphrase what someone
86 would type or run; explain around it.
878. **Aim for half the length or less** - except where rule 1 or an exact-N
88 request forbids it.
89
90## Known gotchas
91
92- **"I don't understand" about your own answer is feedback, not an attack.**
93 Restate; do not defend, do not re-explain at the same altitude, do not pad
94 the restatement with justification.
95- **Restating is not editing.** If while restating you notice your original
96 was wrong, that is a correction - say so plainly. Never fix it silently
97 inside the "simpler" version.
98- **Mid-task "wait, what?"** - restate, then continue the task. Do not lose
99 the thread the question interrupted.
100- **A text that is already plain** gets one line saying so and nothing else.
101 Manufacturing a different version to look useful is padding.
102- **No number given, long source** - the one-screen rule from the rest of the
103 pack applies: about ten lines, fifteen at the ceiling.