sharpen

The prompt to rewrite:

<prompt> $ARGUMENTS </prompt>

If the prompt block above is empty or still shows a placeholder, the prompt is the text the user sent with this command. If there is none, ask for it and stop.

The rewrite (step 5) is shown before any other skill, edit or command that changes anything. The user typed this command to see how their prompt was read; work that starts without showing it has skipped the skill. It is not a preamble or a restatement of the question, so reply rules against those do not apply to it. It goes in the reply text, never only in thinking, which the user cannot see. Other skills the work calls for (premortem, fix-the-class, ship-check) are loaded only after it.

When this runs as /first-pass:sharpen (the Claude Code plugin), the rewrite is a message of its own: write it, then end the message with no tool call. The plugin's hooks hold back edits, shell commands, subagents, MCP tools, publishing, scheduling and other skills until reply text starting with the word Sharpened has been shown, then tell you to go on with the work. Read, Grep and Glob are never held back. Anywhere else (Cursor, or the skill installed without the plugin), go straight on to the work in the same reply.

A prompt written in a hurry mixes three asks in one sentence, says "be 100% sure" where it means "show me the proof", and leaves the agent to guess which part is a question. This skill rewrites it into what the user meant, shows the rewrite, then does the work from it. The user's intent is the source: the rewrite may reorder, split and name things, never add or change what is asked.

1. Read it for what the user wants

• Goal: what the user is after, in one line, in their words. Keep their "why" if they gave one.
• Asks: every separate thing to do or answer. "Check X, fix Y and tell me Z" is three. Mark each as a question (answer it, build nothing), a change (build it), a check (look and report, change nothing) or a call the user must make. "I want X, can we do that?" is a change; "can we do X?" alone is a question. When it could be either, say which reading you took.
• Facts: every name, path, file, URL, number, date, error message, quoted text and code, copied exactly. Never paraphrase one or correct its spelling.
• Limits: what not to touch, which repo or account, what needs a yes, deadlines.
• Context: what the user tried, saw or already knows that the work needs.
• Drop: repetition, filler, and emphasis (capitals, "!!!", "IMPORTANT", "please please"). Nothing is lost: each point is said once, and the habit words become checks.

2. Turn habit words into checks

A word that asks for certainty or completeness without naming a check becomes the check it stands for. Use the user's own habit words block (first-pass:words) when it is loaded; otherwise this list:

They wrote	It becomes
"be 100% sure", "confident", "don't assume"	Evidence: each claim cites a command and its output or a file:line read now; the rest is listed as "Not verified"
"cover all cases", "bug free", "doesn't break anything"	The pre-mortem, with every other reader and writer of the data touched, and the test that proves each case
"full", "deep", "comprehensive", "everything"	Say the coverage: what is read whole, what sampled, what not covered
"carefully", "correctly", "properly", "perfect", "take your time"	Done means proven: a test that fails first, the breaker's review, CI's checks in a clean checkout
"all fine, right?", "is it done?", "anything left?", "that's best?"	What is not done or not verified comes first; for "best?", the strongest case against before the pick
"are you sure?", "this doesn't make sense"	Re-check the claim at its source; say which part holds, which does not, and why
"fix it once and for all"	Reproduce it first, then fix the class (fix-the-class)
"make it secure", "no hacking possible"	The hostile-user question as concrete attacks, each with a test
"do whatever you want", "take control"	The task named only; money, production deletes and anything outward-facing still need a yes

• Each check is named once, however many words the user stacked for it.
• Size it to the ask: a question needs Evidence, not a pre-mortem; a copy change needs the words check; a change to payments, data or auth gets the pre-mortem and Done means proven.

3. What the rewrite never does

• Add scope. No asks, features, files or refactors the user did not ask for. An idea worth having goes in one line under "Not asked".
• Change strength. "Look at" never becomes "fix", and "fix" never becomes "look at".
• Fill a gap with a guess dressed as a fact. "The login bug" with no file named stays "find the login bug" as the first step, not a file you picked.
• Repeat a secret. A key, token, password or connection string in the prompt becomes <secret left out> in the rewrite, and one line tells the user it is now in this chat's history and should be rotated and set where the code reads it (.env.local, the service's settings). The work uses the variable name.
• Start the work inside the rewrite.

4. Guesses

List each place you had to choose a reading, and the reading you took. Then:

• Stop and ask when a guess changes what gets built or touched: two readings lead to different work, the asks conflict, the target cannot be found, or it touches money, deletes, production, other people or anything outward-facing. Ask short questions, each with your guess as the default, last in the message under the line Before I start: (the plugin's hooks see it and end the turn there), and start nothing until the user answers.
• Otherwise go on, with the guesses listed so the user can stop you on a wrong one.

5. Show the rewrite

Reading files (Read, Grep, Glob) to settle a guess may come first; nothing else does. It is always shown:

**Sharpened**

Goal: <one line>

1. <ask> (<question | change | check | your call>)
   Done when: <the proof it needs, for a change or a check>
2. <ask> ...

Context: <what the user gave, facts exact>
Limits: <repo, account, what not to touch, what needs a yes>
Checks: <each check the habit words asked for, once>
Guesses: <each reading taken>
Not asked: <one line, only if there is one>

Leave out any line with nothing in it. Under the block, one line on what changed from the original ("split into 3 asks; 'be 100% sure' and 'don't assume' became Evidence; a pasted key left out"), so the user can see nothing was lost.

A prompt that is already clear gets the line Sharpened: already clear, working from it as written. instead of the block, still first. A one-ask prompt gets a short block, not every heading.

6. Work from it

Once the rewrite is shown, and unless step 4 stopped, the rewrite is the task. Work the asks in order, dependencies first. The report answers each ask by its number, and shows each check from the Checks line with its evidence (the pre-mortem's answers, the test that failed first, the breaker's findings), or marks it "not done, because". Where the rewrite and the original prompt disagree, the original wins: say so and follow it.