32 lines
2.7 KiB
Markdown
32 lines
2.7 KiB
Markdown
---
|
|
name: sg-prompt-sharpening
|
|
description: 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)
|
|
|
|
1. **Literal ask** — restate what was actually said, no elaboration.
|
|
2. **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.)
|
|
3. **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.
|
|
4. **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.
|
|
5. **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."
|