LucioLiu/sharpen-first

---

name: sharpen-first description: Sharpen the axe before cutting wood. Trigger when the user's goal is vaguely stated (one sentence with multiple reasonable readings), a big task lacks success criteria, the user admits they haven't thought it through, or the user says "sharpen first" / "磨刀": use fool-proof questioning (max 5 questions, multiple-choice preferred, every question carrying a recommendation, assume-and-proceed when unanswerable) to grind the fuzzy request into a one-page consensus sheet before starting work; "grill me" / "烤我" enters deep-grill mode (question cap lifted, decision-tree cross-examination); when the user wants to take it to another AI, output the seven-part prompt (with assumptions and open-items columns).

English | 简体中文

Sharpen first (clarify before you start)

What this is: a "requirement clarification" discipline. When a user can't clearly say what they want (fragmented phrasing, a fuzzy goal, an idea that hasn't taken shape yet), the agent doesn't guess and doesn't dump an open-ended question back on the user — it uses fool-proof questioning to sharpen the requirement into a written consensus, then starts working. Why: the number-one cause of bad output isn't a dumb model, it's a mushy requirement. Starting on mush means the faster you run in the wrong direction, the more you waste. Sharpen the axe before cutting wood. Lineage: combines obra/superpowers brainstorming (one question at a time / multiple-choice first / options carry trade-offs) + GitHub spec-kit /speckit.clarify (coverage scanning / impact-ranked ordering / a 5-question cap / write-back of answers) + the four-slot Intent Extraction pattern (goal / constraints / context / output form), adapted for general, non-development work — those tools were built for writing code, this one is built for "any task that's unclear." 1.2 added: the grilling family from mattpocock/skills (deep-grill mode / branch-by-branch decision-tree interrogation / facts-vs-decisions boundary / dependency-ordered question batching) + blind-spot probing. A Nuwa-system product.

1. When to sharpen (trigger judgment)

Three signals — hitting any one triggers the full flow:

1. The goal has multiple readings — you can think of two or more plausible things "he might mean," and picking the wrong one isn't cheap;
2. A big task has no standard — a task you expect to run multi-step / multi-file / over half an hour, with no stated success criteria or boundary;
3. The user admits it themselves — "I haven't really thought this through / something like that / your call / you know, that kind of thing…"

Manual trigger: the user says "sharpen it / sharpen first" → unconditionally enter the full flow.

Deep-grill mode (interrogation): the user says "grill me / interrogate me thoroughly" → the 5-question cap lifts, and the playbook switches to interrogation: treat this task's decision space as a decision tree and walk it branch by branch from the root — each time, pick the currently heaviest undecided decision and ask one question about it (still with a recommendation, still one at a time), finish that branch, then switch branches; only wrap up the consensus sheet once neither side can name a new undecided item (true shared understanding). The escape hatches from regular mode still apply in deep-grill (can't answer → proceed on assumption, switch branches), but follow-up questions on the same branch are allowed — the "never press the same question twice" rule is waived here, since digging deeper is exactly what the user ordered. Deep-grill only activates when the user explicitly says so, never by default: the default fool-proof mode protects people who struggle to articulate; deep-grill serves people who actively want to be interrogated.

Small, fuzzy tasks take a shortcut: skip the full flow, and cover it with one line of "guess-and-confirm" — "I understand you want X (I filled in assumption Y) — is that right?" A nod from the user and you proceed. Don't launch a five-question interrogation over something small. Arbitration rule (when a signal collides with the shortcut, this decides it): a small task takes the guess-and-confirm shortcut even if it hits signal 1 or signal 3; the full flow is reserved for tasks that hit a signal and are large in scope / expensive to redo if you guess wrong. Something like "make this document look nicer" is a one-line guess-and-confirm, even though "nicer" has a hundred possible readings.

No trigger: for a clearly stated task, just do it. Don't sharpen for the sake of ritual.

2. How to ask (five fool-proofing rules)

Questions only ever orbit four core elements: purpose (why / for whom), boundary (what not to do / what not to touch), success criteria (what "good" looks like), output form (what shape the deliverable should take).

Dual question-generation engine: the four-core-element gap check only answers "what does he want." Before picking each question, also run blind-spot probing:

• What is he least sure about right now? (where is his own uncertainty)
• Given the current situation, what's the biggest omission? (which premise / stakeholder / risk has nobody mentioned)
• What has he not noticed? (options he assumes don't exist, dependencies he assumes don't matter)

Questions that grow out of blind-spot probing are often worth more than questions from the four-core-element gap check — rank them higher by impact. The four core elements ask "what do you want," blind-spot probing asks "what haven't you seen"; a consensus sheet sharpened only with the former inherits the user's blind spots unchanged.

1. Multiple-choice first: give 2-4 concrete options per question, put your most-recommended one first and mark it (recommended). Picking is easier than imagining — people who struggle to articulate can't answer open questions well, but they can pick from options. (Inside Claude Code, the AskUserQuestion tool for an option UI works best; without it, list A/B/C in plain text.) On a cold start, if even the deliverable's category is unclear (a document? a webpage? a paragraph?) → the first question always anchors the category first — until the category is anchored, everything after it just spins.
2. Every question ships with its own escape hatch: if the user answers "whatever / don't know" → immediately adopt your recommended option, flag it on the consensus sheet as [Assumption: XXX, unconfirmed], and keep going. Never press the same question a second time. The cost of a wrong guess is rework — but never push a user until they give up. The one exception (the minimum-goal anchor): everything else can proceed on assumption, but when the user won't even pick for the deliverable's category / form, you're allowed one more guess-and-confirm line ("so I'll go ahead and build an X?") — a consensus sheet whose goal column is pure guesswork is castle in the air.
3. Adaptive pacing: by default, ask only 1 question at a time (people who struggle to articulate dread being hit with a whole screen at once); only once the user's last several answers have been crisp and decisive may you batch 2-3 questions on one screen to speed up — the first round is always a single question. The second hard condition for batching: mutual independence — if one answer would change how another question is asked or what its options are, they may not share a screen (the user would be forced to answer into an assumption-shaped void); split rounds by dependency order, ask upstream before downstream (the first question anchoring the category is exactly the root of that dependency order).
4. Hard cap of 5 questions total: pick the most worth asking by "impact × uncertainty" and ask those first; whatever's still unsharpened after 5 questions gets flagged [Open] and wraps up there — don't wear the person out. (The "help you think" step where the user picks a direction doesn't count against the 5.)
5. Probe before you ask: never ask the user something you can find out yourself (by reading files, context, or history). One-line rule of thumb: facts are yours to look up, decisions are his to make the call on — every question that actually gets asked should be a decision question (only he can make that call), not a fact question (an answer you could have looked up yourself).

3. When the idea hasn't taken shape: upgrade from "asking" to "helping think"

Signal: the user isn't unclear in how they express it — there's genuinely no answer in their head yet ("I just feel like we should do something," "what do you think," "help me think this through"). Pure questioning draws blanks — they can't answer not because the question is bad, but because the answer doesn't exist yet.

Switch to this playbook:

1. Restate their fragmentary thoughts as 2-3 possible directions, each with one line of trade-offs plus your recommendation;
2. Let them pick (or revise one direction), then go back to the questioning flow to sharpen the details.

People only know what they want — and don't want — once they see a concrete option in front of them.

4. Wrapping up (two modes)

Default mode: consensus sheet (start working directly once sharpened)

One page, five sections:

[Goal] One line: what, for whom, why
[Out of scope] Boundaries and explicit exclusions
[Success criteria] What "done" and "good" look like
[Key assumptions] Every item flagged [Assumption] — the first place to check when something goes wrong
[Open items] Points not yet sharpened, to be aligned on when they come up during execution

The [Success criteria] section rejects bare adjectives — "fast / nice-looking / clear" must be translated into "how it's checked" (shown to whom, compared against what, what result counts as a pass). A criterion you can't say how to check is the same as not having written one.

For small tasks, a spoken restatement-and-confirm is enough; for big tasks, write it to a file (in the task's working directory), and only start work once the user has confirmed the consensus sheet. Confirmation-presentation discipline: put the full consensus sheet directly in the conversation for the user to confirm (and tell them explicitly "here's all you need to answer") — the file on disk is only a record. Never make the user open a file to find what they're supposed to confirm.

(Optional but strongly recommended) an idea archive: on first use, agree with your principal on an archive directory, and from then on file a copy of every confirmed big-task consensus sheet into it — over time it becomes a record of "things the principal has already thought through." Next time sharpen-first's "probe before asking" step runs, check it first for anything similar — and it's mandatory to check when the principal says "the one I mentioned last time."

Take-away mode: the seven-section prompt

The user says "turn this into a prompt for me / I want to feed this to XX" → output:

[Goal] [Context] [Constraints] [Output requirements] [Success criteria]
[Assumptions & open items] ← every item you made a call on without confirmation, plus every unsharpened point, none omitted
[Final Prompt] ← the first six sections fused into one complete, copy-paste-ready instruction;
              assumptions are written in with the phrasing "(unless stated otherwise, treat as XXX)"
              so the downstream AI also knows which parts were guessed

Mapping from the consensus sheet's five sections to the seven: Goal → [Goal]; Out of scope → [Constraints]; Success criteria → [Success criteria]; Key assumptions + Open items → [Assumptions & open items] (must not evaporate); Context and Output requirements are filled in from the clarification conversation.

Wrap-up self-check (anti-hand-waving)

Before delivering, ask yourself four questions: ① Do any of these sections contradict each other? ② Is "Goal" still vague enough to fit two different approaches? ③ Are every [Assumption] and [Open item] (or, in take-away mode, the [Assumptions & open items] section) explicitly listed with none omitted? ④ Has blind-spot probing actually been done — has "the thing he's least sure about" been directly addressed by the consensus sheet (landing in success criteria, key assumptions, or open items counts; being silently skipped doesn't)?

5. After work starts: the consensus sheet is the anchor (course-correction)

• If, during execution, what's actually being done drifts from the consensus sheet, or a new decision point surfaces that the sheet didn't cover → stop, and check back against the consensus sheet with the user — don't put your head down and keep going. The course-correction check also uses multiple-choice-with-recommendation, and spells out the switching cost: "Found during execution that B might be better: [stick with A / switch to B / combine both] (recommend B, because X; switching cost: roughly Y of the A work already done becomes waste)" — don't just toss out an open "want me to change it?" and kick the decision back to the user.
• When execution reaches an [Open item] → ask then (this doesn't count against the 5-question cap). Restriction: open items only get asked when execution naturally reaches them; anything that could have been clarified during the sharpening phase may not be stuffed into "open" and dragged into a chain of follow-up questions after work starts — that's dodging the 5-question cap, not genuinely leaving something open.
• If the user changes the requirement mid-execution → update the consensus sheet first, then continue — don't let it turn into a stale artifact.

Pitfalls (anti-pattern table)

Anti-pattern	Why it's wrong	Correct action
Guessing and going	Guessing hard when information is insufficient wastes the whole output	Hit any of the three signals → sharpen first; your biggest problem usually isn't the doing, it's not asking
Interrogation-style questioning	Firing seven or eight open questions at once = kicking the work of organizing the requirement back to the user	That's your job: multiple-choice, one at a time, with a recommendation
Nagging	Asking the same question three different ways, wearing the user down	One escape hatch per question: proceed on assumption if they can't answer
Over-sharpening	Running the full flow even on a clear, small task	Just do it if none of the three signals hit; cover small-and-fuzzy with one line of guess-and-confirm
Sharpening without anchoring	The consensus sheet gets written and forgotten, execution still drifts	Course-correction is the second half of the consensus sheet's value
Assumptions left unflagged	Making a call for the user without leaving a trace makes it untraceable when it goes wrong	Every call made on the user's behalf must carry an [Assumption] flag
Skipping blind-spot probing	All four core elements are covered, but the consensus sheet still inherits a pitfall the user never saw	Run blind-spot probing before picking each question: least sure / biggest omission / hasn't noticed
Deep-grill uninvited	The user never asked to be interrogated but gets an uncapped barrage anyway = the entire fool-proofing discipline thrown out	Deep-grill only ever triggers on the user's explicit request; the default is always fool-proof mode

Version & update self-check

• Current version: 1.2.0 · Official address: https://github.com/LucioLiu/sharpen-first
• How to self-check: installed via plugin marketplace → run claude plugin update sharpen-first (or turn on auto-update); installed via gh skill → run gh skill update; manually copied installs have no update channel — revisit the official address, compare the version number in this section, and re-copy if it doesn't match.

---

Both language editions are maintained in sync. If they ever diverge, the Chinese edition is authoritative — please open an issue if you spot one.