2.7 KiB
2.7 KiB
name, description
| name | description |
|---|---|
| prompt-sharpening | Use when a user's request is short, vague, terse, or could reasonably be interpreted more than one way, before investigating or writing any code — expands the raw ask into an explicit interpretation set, surfaces assumptions, and defines success criteria so execution matches intent on the first try. |
Prompt Sharpening
Overview
Clear-sounding requests often hide multiple interpretations — silence that ambiguity by running this pass before acting.
The pass (do this before investigating, and again after a first skim)
- Literal ask — restate what was actually said, no elaboration.
- Plausible interpretations — list every reading that changes what you'd build or which files you'd touch. Actively check: does this specific project have an obvious candidate the words don't rule out but also don't name? (e.g. "trang chủ"/"homepage" in a project whose actual flagship surface is a heavy 3D experience gated behind that homepage — that's a candidate, not a footnote.)
- Diverge or converge? If the interpretations lead to the same first investigative step (same files, same starting point), proceed and state your assumption inline as you go. If they diverge — different files, meaningfully different effort/risk, or a decision only the user can make — ask ONE targeted question before doing real work (AskUserQuestion if options are enumerable). Don't ask about things that don't change what you'd do.
- Success criteria — state a concrete, checkable definition of "fixed"/"done" before starting, derived from the user's actual complaint. Don't invent metrics after the fact that happen to match whatever you built.
- Scope boundary — one line on what this will NOT touch, so a small ask doesn't quietly grow.
Rationalizations to reject
| Excuse | Reality |
|---|---|
| "The problem statement is clear enough" | Clear-sounding ≠ unambiguous. If 2+ real interpretations lead to different files or effort, it isn't clear. |
| "Asking wastes time" | One targeted question costs 10 seconds. Building the wrong fix costs a full redo. |
| "I skimmed and found a plausible cause" | Skimming finds A pattern, not THE pattern. Check for the project's own obvious candidate before settling on the generic one. |
| "I'll define success after I see what I built" | Post-hoc criteria bend to match the output. Define them first, from the complaint as stated. |
Handoff mode
If the sharpened result is meant for a different AI/session/agent (not yourself), the bar is higher: the output must be fully self-contained — exact file paths, decisions already made, what's explicitly out of scope, and a concrete success check. No "as discussed above" — the reader has no "above."