Ask First

Version: 1.0.0

Author: RosBradley · https://github.com/RosBradley/ask-first

A short request leaves a lot unsaid, and a long conversation piles up more than the user wants to read and answer. This skill turns that around: at any point, before a task or in the middle of one, ask the questions that would change the result, one at a time, each with a few ready answers to pick from. Your recommended answer is always first, so the user can move fast by taking it, and the last answer is always the user's own words.

Commands

• The command can be anywhere in the message: ask first: write a launch plan, Write a launch plan. .askme, or .ask alone. Case doesn't matter, so .Ask, .AskMe and Ask first count.
• Everything else in the message is the task. Leave the command words out of it.
• .ask and .askme always carry the dot. ask alone is an ordinary word.
• ask first counts only when the user is telling you to ask before you start. "Write a rule for new hires: ask first before deleting files" is about someone else: help with it without this skill.

Before the first question

1. Work out the task. It is the rest of the message; with no task in the message, it is the work in progress in this chat. With neither, the first question asks what the interview is about.
2. Learn what can be learned without asking. Read the files, earlier messages and sources the task points to. Never ask the user something you can look up.
3. List the decisions that would change the result, most important first. Keep the ones where the user's answer matters: goals, audience, scope, constraints, trade-offs, and things the user probably hasn't thought about. Drop anything with an obvious default; just use the default and say so in the summary.
4. Say in one line what the interview is about and roughly how long it is: Interviewing you about the NERC CIP program: about 6 questions.

Asking

Ask one question per message, so each answer can shape the next question. Each question has:

• A number and the running estimate: Q3 of ~6. Update the estimate as answers open or close topics; it's an estimate, not a promise.
• The question in one sentence.
• 2 to 4 answers. Your recommendation is first and labeled (Recommended). Each answer gets a short line on what it means or what it costs, so the choice can be made without more research.
• A free-form answer last, so the user can write in their own.

Answers are real alternatives, not one good choice with filler around it. When there is no clear best choice, still put first the one you would pick, and say why in its line.

When the app can show clickable choices

If this app gives you a way to show a question as choices the user can click or tap (a question tool such as AskUserQuestion in Claude Code, or the interactive options in claude.ai or ChatGPT), use it. Put the recommended answer first, with (Recommended) at the end of its label, and keep the Q3 of ~6 count in the question or its header. If the app adds its own free-form answer (such as Other), don't add another; if it doesn't, make the last choice Something else - write your own.

Batch option: when the app's question tool can ask several questions in one step and the next 2 to 4 don't depend on each other's answers, ask them together. Ask a question on its own whenever its answer would change what comes next.

Otherwise (text)

When the app can't show clickable choices, or you aren't sure it can, write the question as plain text, in this layout, with no bold or other formatting, so it reads the same in every app:

Q3 of ~6: Who will run the NERC CIP program day to day?

A. An existing staff member, part time (Recommended) - fits a small district's budget
B. A new full-time compliance hire - steadier, but a new salary
C. An outside consultant - fast expertise, ongoing cost
D. Something else - write your own

Reply with a letter, rec, or your own words.

Letters, not numbers, so a letter is never mistaken for a number in an answer ("3 days"). One line per answer, so it fits a phone screen. The last letter is always Something else - write your own, and the last line is always the reply hint.

The user answers with a letter, with rec for the recommendation, or in their own words. Read an answer in their own words as it is meant; if it is unclear, ask about it once, briefly, then move on.

Decision summary

When the decisions that matter are made, stop asking. Then:

1. Show the decisions as a short numbered list, one line each: the user's answers, and any defaults you chose without asking, marked (default).
2. Ask a last question to check you understood: Yes, that's right (Recommended), Change something, and the free-form answer. Ask it the same way as the interview questions, with clickable choices when the app has them. It confirms the decisions; it isn't a request for permission, so don't switch to text for it.
3. On Yes, that's right, do the task, using every decision in the list. On a change, update the list, show it again, and ask again.

The interview is never the end in itself. Keep it to the questions that change the result.