os-ask-simple
Two jobs. Ask the question in words the user can answer, and screen the choice
before spending their attention on it. The screen is what earns the
recommendation - without it you are guessing in plain language, which sounds
trustworthy and is not.
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
- You are about to ask the user a technical question.
- You are about to offer options.
- The user asks whether something is worth it, too complex, or replaceable with
something simpler.
- The user proposes something and you suspect it is more than the problem needs.
Before anything: is this even a question for them?
Most questions should never reach the user; ask only when the answer genuinely
changes what gets built.
- Can you answer it by looking? Read the code, the config, the last report.
A question you could have resolved yourself costs them attention for nothing.
- Is there a conventional default? Take it and say you took it.
- Would both answers lead to the same work? Then it is not a fork.
Light form - every question
<The question in one plain sentence. No jargon; if a term is unavoidable, give a
three-to-five word analogy.>
Why it matters: <one line, in terms of the product, not the code>
What changes later: <one line>
Easy to undo: <yes, and how - or no, and why>
Then the options through the native picker: two to four, each with a one-line
trade-off in plain words, the recommended one first and marked (Recommended).
Picker limits: heading of 12 characters or fewer, two to four options, labels
of one to five words. Where the picker is not available, write the same content
as plain text.
Full form - six checks, for structural choices
Run the screen when the choice would add a dependency or a new moving part, add
something the user has to maintain, change the shape of stored data, cost more
than about a day, or be hard to reverse.
Show it as a table. Answer every row - "not checked" is allowed and honest;
silence is not.
| Check |
What goes in the answer |
| How long now |
Real effort, in hours or days, plus what has to be touched |
| Simpler substitute |
The simplest thing that would also work - or "none found", having looked |
| Extra work for you later |
Anything the user must do repeatedly afterwards: approvals, manual steps, watching a dashboard |
| Harder to change later |
What this locks in, and what would be expensive to move afterwards |
| Over-engineering |
Say yes when it is yes. A row that always answers "no" is decoration |
| Easy to undo |
Reversible, and how - or one-way, and why |
Then the recommendation, in one line, as an actual opinion.
Hard rules
- Always weigh doing nothing. "Change nothing" is a real candidate, often
the winner. If it lost, say in one line why.
- A recommendation is required. Never lay out options and stop. "It depends"
is not a recommendation - if it truly depends, say what it depends on and pick
the option that is right under the more likely condition.
- Recommend against the user's own idea when the screen says so. Plainly, in
one sentence, with the simpler substitute named. They asked for a filter, not
for agreement.
- Never recommend what you have not screened. If the six checks were skipped
because the choice looked small, say the choice looked small.
- One question at a time. Two questions in one message means the second gets
a careless answer.
- Watch your own bias. The most interesting thing to build is not the
recommendation. If an option is more fun to implement, that is a reason for
suspicion, not for preference.
Known gotchas
- Two options that end in the same place are one option. Do not pad the
picker to look thorough.
- "Over-engineering: no" answered reflexively kills the whole screen. The row
exists to be answered yes sometimes.
- Effort estimates are guesses. Say "roughly" and give a range. A confident
number that turns out wrong costs more trust than a range ever does.
- The user may pick the option you did not recommend. That is the point of
asking. Do it their way without re-arguing, and note the trade-off once.
1---2name: os-ask-simple3description: ALWAYS invoke this skill before asking the user any technical question or offering options, and whenever they ask to be asked in plain words - "ask simple", "ask me simply", "ask me in plain words" - or ask if something is worth doing or if something simpler would do, in any language. Rewrites the question in plain words and always ends with one marked recommendation. A structural choice first passes six checks, shown as a table: effort now, simpler substitute, extra work later, lock-in, over-engineering, easy to undo. Doing nothing is always weighed.4---5
6# os-ask-simple
7
8Two jobs. Ask the question in words the user can answer, and screen the choice
9before spending their attention on it. The screen is what earns the
10recommendation - without it you are guessing in plain language, which sounds
11trustworthy and is not.
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- You are about to ask the user a technical question.
21- You are about to offer options.
22- The user asks whether something is worth it, too complex, or replaceable with
23 something simpler.
24- The user proposes something and you suspect it is more than the problem needs.
25
26## Before anything: is this even a question for them?
27
28Most questions should never reach the user; ask only when the answer genuinely
29changes what gets built.
30
31- **Can you answer it by looking?** Read the code, the config, the last report.
32 A question you could have resolved yourself costs them attention for nothing.
33- **Is there a conventional default?** Take it and say you took it.
34- **Would both answers lead to the same work?** Then it is not a fork.
35
36## Light form - every question
37
38```
39<The question in one plain sentence. No jargon; if a term is unavoidable, give a
40three-to-five word analogy.>
41
42Why it matters: <one line, in terms of the product, not the code>
43What changes later: <one line>
44Easy to undo: <yes, and how - or no, and why>
45```
46
47Then the options through the native picker: two to four, each with a one-line
48trade-off in plain words, the recommended one first and marked `(Recommended)`.
49
50Picker limits: heading of 12 characters or fewer, two to four options, labels
51of one to five words. Where the picker is not available, write the same content
52as plain text.
53
54## Full form - six checks, for structural choices
55
56Run the screen when the choice would add a dependency or a new moving part, add
57something the user has to maintain, change the shape of stored data, cost more
58than about a day, or be hard to reverse.
59
60Show it as a table. Answer every row - "not checked" is allowed and honest;
61silence is not.
62
63| Check | What goes in the answer |
64|---|---|
65| How long now | Real effort, in hours or days, plus what has to be touched |
66| Simpler substitute | The simplest thing that would also work - or "none found", having looked |
67| Extra work for you later | Anything the user must do repeatedly afterwards: approvals, manual steps, watching a dashboard |
68| Harder to change later | What this locks in, and what would be expensive to move afterwards |
69| Over-engineering | Say yes when it is yes. A row that always answers "no" is decoration |
70| Easy to undo | Reversible, and how - or one-way, and why |
71
72Then the recommendation, in one line, as an actual opinion.
73
74## Hard rules
75
761. **Always weigh doing nothing.** "Change nothing" is a real candidate, often
77 the winner. If it lost, say in one line why.
782. **A recommendation is required.** Never lay out options and stop. "It depends"
79 is not a recommendation - if it truly depends, say what it depends on and pick
80 the option that is right under the more likely condition.
813. **Recommend against the user's own idea when the screen says so.** Plainly, in
82 one sentence, with the simpler substitute named. They asked for a filter, not
83 for agreement.
844. **Never recommend what you have not screened.** If the six checks were skipped
85 because the choice looked small, say the choice looked small.
865. **One question at a time.** Two questions in one message means the second gets
87 a careless answer.
886. **Watch your own bias.** The most interesting thing to build is not the
89 recommendation. If an option is more fun to implement, that is a reason for
90 suspicion, not for preference.
91
92## Known gotchas
93
94- **Two options that end in the same place are one option.** Do not pad the
95 picker to look thorough.
96- **"Over-engineering: no" answered reflexively kills the whole screen.** The row
97 exists to be answered yes sometimes.
98- **Effort estimates are guesses.** Say "roughly" and give a range. A confident
99 number that turns out wrong costs more trust than a range ever does.
100- **The user may pick the option you did not recommend.** That is the point of
101 asking. Do it their way without re-arguing, and note the trade-off once.
majiayu000