Initial Smartgift skills marketplace: smartgift-dev (md-writing), smartgift-common (prompt-sharpening)

2026-07-20 14:49:49 +07:00
commit b5cdb9f489
8 changed files with 281 additions and 0 deletions
@@ -0,0 +1,31 @@
+---
+name: 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."