無料GitHub で公開

os-ask-simple

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" - in any language. ALWAYS invoke it too when the user asks for your view on a technical choice: whether it is worth doing, more than the problem needs, or replaceable by something simpler, and which option you would take. Invoke it even when the code makes the answer look obvious: the checks are what make the answer more than a guess. 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.

kharmanskyi/open-steps

インストール方法を見る

含まれるファイル（2）

SKILL.md5.3 KB
references/01-sign-in-now-or-later.md2.8 KB

SKILL.md（原文）

インストールする前に、エージェントに与えられる指示の中身を確認できます。

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 your tool's question picker where it has one (in Claude Code, AskUserQuestion). Offer two to four, each with a one-line trade-off in plain words, the recommended one first and marked (Recommended).

Keep the heading to 12 characters or fewer and each label to one to five words. Claude Code's picker has the same limits, and short labels read well as plain text too. Where there is no picker, write the same question and options as plain text, the recommended one first and marked.

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.

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

ログインしてレビューを書く

同じリポジトリのスキル

概要と使いどころ

os-big-picture

無料

ALWAYS invoke this skill when the user asks where the project as a whole stands - "where are we", "what's the big picture", "what have we built", "what is in this project", "map the project", "what does this thing even do", "what is stale", "what can we delete", "update the roadmap" - in any language, and whenever a session report has just been written. It keeps one file, BIG-PICTURE.md: what the product is, every feature with how far it got, which parts nobody has touched, and what is queued next. Age and wiring are measured from git; how far a feature got comes from the reports or says "not checked". Where a tracker is connected it offers to open the queue as tickets, after a yes and never before. Never invents work, never deletes code.

日本語の概要は準備中です。原文の説明を表示しています。