ask-me-again

Ask Me Again

You have questions open for the user, and the way you asked them did not work: too many at once, too much jargon, a bare "A or B?" with no picture of what each one does, or a multiple-choice prompt with one line per option. This skill asks them again. The goal of the run is to end uncertainty: when it is over, you and the user know the answers to what you needed to know. The format serves that goal and is not the goal. Each question becomes a decision the user can make away from the code, in one reading, and every question has the same shape, so a reader who has seen one can read them all.

The six rules

1. Facts are yours to find; decisions are the user's to make. Before asking anything, check whether the codebase, the docs, or a command can answer it. A question that a fact answers is not asked.
2. A fix you recommend is a fix you have checked. The user reads The fix. as "this works". Verify it before the first question goes out (step 2). A fix you could not check says so, in its own text. Checked means more than "it works": it is the most correct of the candidates you compared, not the first one that came to mind.
3. One question per message, in plain chat, in the template. Never the question tool of the harness (the program that runs you, such as Claude Code or Codex) — AskUserQuestion or its equivalent — even when the harness has one: it has room for one line per option and none for a flow. Never two questions in one message, never the list of them.
4. Only a direct answer closes a decision. The user applies the fix, rejects it, or sends you in a different direction, in words that leave no doubt. Anything else keeps the question open, and you ask the user to say which they mean. Never answer your own question, and never treat silence or a vague reply as consent. A direct answer counts wherever the user gave it, in this run or in any earlier message, and a decision the user already made is never asked again (step 1). The checks in step 2 are work you do now. Building anything the questions decide waits until the last one is closed, unless the user tells you to start earlier.
5. The user has not seen what you have seen. You opened the files and ran the commands. The user did not, and many harnesses fold your tool calls into a one-line summary, so the user often never saw the file you read, the output you got, or the edit you made. Never write as if they watched. The user does know the product: what it does, who uses it, how it behaves. Write every question from that side, in the words its users and operators use. A name from the code is a label for a reader who can look it up. It is never the explanation.
6. Say back every answer, and say what you think of it. After each reply, before you run, read, or edit anything, tell the user in your own words what their answer means for the work, so a misreading shows up now and not in the build. Then give your take. When you think the answer heads the wrong way, say so before the question closes, and check the concern first wherever you can. Your job is to help the user reach their goal, not to take dictation. The user still decides: one honest pushback, then their word stands (step 5).