Itsthatotherguy Refine Ask
Turn a rough request into one that commissions exactly the work wanted. The output is a rewritten ask plus the swaps behind it — never the work itself.
The rule
Never perform the refined ask. Not even when it is small, obvious, and one tool call away. The deliverable is the wording. Stop at the rewrite; the user sends it.
The one file this skill may write is its own references/verb-lexicon.md, and only after the user accepts a
proposed word. That is the sole exception — it is not a precedent for acting on the ask itself.
When to use
A request is about to be sent and the wording feels approximate — the verb may commission different work than the work wanted, the target is a gesture rather than a name, or the shape of the answer was never stated. Also for diagnosing an answer that came back off-target: refine the ask that produced it.
Pass
Read the raw ask, then apply four lenses in order. Keep the size of the request fixed throughout — see Gotchas.
- Verb — name the operation actually wanted. Before choosing a replacement, read
references/verb-lexicon.md; it separates the verbs that get confused and states what each one commissions. A verb is wrong when the work it names is not the work wanted, not when a fancier word exists. - Scope — replace gestures with names. "The codebase" → the files, module, or route actually meant. State what is out of scope when the boundary is not obvious from what is in it.
- Deliverable — say what comes back and in what form: a patch, a ranked list, a number, a recommendation with reasoning, a yes/no. Most vague asks are vague here rather than in the verb.
- Bar — state what would make the answer unusable: a standard to hold to, a file not to touch, a budget, a constraint that rules out the obvious approach. Include only what the user actually implied.
Then sweep for words carrying two plausible readings — "safe", "clean", "better", "simple", "robust", "proper", "handle", "sort out", "look at". Either replace each with the specific reading meant, or, when the right reading is genuinely unknown, list it under Still unclear rather than guessing.
Harvest
The lexicon is grown by use, and this skill is what grows it. After the rewrite, check whether this ask surfaced a word the lexicon does not yet separate. A candidate must clear all three tests:
- It appeared here — in the raw ask, or chosen as a replacement for something in it. Never propose a word from imagination; the lexicon records vocabulary actually reached for.
- The lexicon does not already cover it — re-read the relevant cluster to check rather than assuming. A word already separated under a near-synonym needs no row of its own.
- It is confusable — it gets swapped for a neighbouring verb, or it carries two readings. A word with exactly one meaning teaches nothing and costs a row.
Propose at most three per run, and propose none when nothing clears the bar — that is the ordinary outcome, not a failure to look. For each candidate, state the exact row and its destination: a row in an existing cluster, a row in Words carrying two readings, or a new cluster. Open a new cluster only for four or more related verbs; fewer than that belongs in the nearest existing one, or the lexicon fragments into headings.
Then offer the edit and stop. Apply nothing until the user answers — accepting all, naming the ones they want, or
declining. On acceptance, edit references/verb-lexicon.md in place, matching the surrounding table format, and
report which rows landed where. Add only what was accepted; leave the rest unproposed rather than queued.
Output
Use this shape exactly. Drop any of the last three sections when empty.
**Refined ask**
```
<the rewritten request, ready to copy and send>
```
**Swaps**
- <original word or phrase> → <replacement> — <why, one line>
**Assumed**
- <an assumption filled in that the raw ask did not state>
**Still unclear**
- <a question whose answer would change the refined ask>
**Proposed for the lexicon**
1. <word> → <cluster or table it joins> — <the row, written out>
Add these? (all / the numbers you want / no)
The refined ask goes in a bare fenced code block — no language tag, no blockquote, no surrounding quotes. It is meant to be copied and sent verbatim, and any prefix character travels with it. Nothing else in the output gets a fence; the ask is the only part that leaves this conversation.
Write the ask itself as plain prose with no markdown inside the fence — no backticks around paths or identifiers, no bold, no bullets. A fence renders its contents literally, so markup that would have styled the text elsewhere survives the copy as stray characters. Backticks in Swaps and the other sections are fine; those are read here and never copied.
Keep Swaps to the changes that alter what an agent would do. Cosmetic rewording does not earn a line.
Gotchas
- Refining is not expanding. A one-line ask refines into a one-line ask. Adding phases, deliverables, or "while you're in there" scope is scope creep wearing precision as a costume.
- Vagueness is sometimes deliberate. An open-ended request genuinely wants an open-ended answer — "explore" and "have a look at" are correct verbs for exploration. Flag a suspected mismatch under Still unclear; do not overwrite intent.
- Invent no requirements. Everything in the refined ask traces to something the user said or clearly implied. A constraint that arrived from nowhere is a worse error than the vague word it replaced.
- Preserve the user's voice. Return their sentence sharpened, not a reformatted spec with headings.
- A proposal is not an edit. The lexicon changes only after an explicit answer. Silence, or a reply about something else, means no.
- One swap can be enough. When the raw ask is already precise, say so and return it unchanged. A skill that always finds five problems is not reading.
Resources
references/verb-lexicon.md— the verb clusters and the distinctions between them; read before swapping a verb, and edit in place when the user accepts a harvested word.