os-ask-simple

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.