sharpen
Skill128 starsChanged 30 days agoMITView on GitHub
Rewrites the prompt typed after the command before any work starts, then works from the rewrite. Splits a mixed-up message into a numbered list of asks, turns words like "be 100% sure", "cover all cases" or "don't break anything" into the checks they stand for, keeps every name, path, number and quote exactly, and stops to ask only where it would have to guess. Runs only when the user types it.
- Reads credentials
38 other projects use a version of this.
Adopted by
Most recently taken up by
- Yeachan-Heo/oh-my-claude-sisyphustheir own version, first seen Nov 8, 2026
- Loner1024/skillstheir own version, first seen Nov 8, 2026
- caidanw/skillstheir own version, first seen Nov 8, 2026
- painhardcore/pstacktheir own version, first seen Nov 8, 2026
- Yeachan-Heo/oh-my-claudecodetheir own version, first seen Nov 8, 2026
- endqwerty/endstacktheir own version, first seen Nov 8, 2026
Used with
Projects with it also use ketchup-video, maintain-formal-verification-skill and 10 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
tristanphvnSkillketchup-video
Catch the user up like /keel:ketchup, with a short silent video of slides for what happened and the waiting calls as text under it. Use for /keel:ketchup-video.
Also in 14 projects that use this
TheOnlyFusionCubeSkillmaintain-formal-verification-skill
Bring a project's formal verification back in line with the code after the code changes: find the commits that touched verified code, update the model, harness, or properties to describe the code as it is now, rerun, and say whether each failure is drift in the verification or a bug in the code. Use for /maintain-formal-verification-skill, \"is the model still true to the code\", or after merges and refactors that touched verified code without rechecking it.
Also in 18 projects that use this
TheOnlyFusionCubeSkillcreate-formal-verification-skill
Generate a project-local skill that formally verifies the code where a bug costs the most and tests reach the least, in any language, with whichever verification tool fits. Use for /create-formal-verification-skill, \"model-check this race\", \"prove this invariant\", or when concurrency, retries, state machines, parsers, or unsafe code need more than tests.
Also in 19 projects that use this
ianclearySkillpoteto-help
Guides users through pstack setup, /poteto-mode, and picking the skill, playbook, or principle for a task. Type /poteto-help with a question.
Also in 10 projects that use this
ianclearySkillprinciple-explain-the-number
Apply before you trust, report, or act on a number you measured: a speedup, a regression, a throughput, a latency, or an eval result. Find what limits it, and rule out that it measured something other than the work you think.
Also in 20 projects that use this
Xia-AtaraxiaSkillbenchmark-checklist
Vets performance measurements for the limiter, tuning, physical limits, errors, repeatability, relevance, and proof that timed work happened. It applies to 'check this benchmark', 'report this speedup', measured regressions, and choosing a library or configuration from numbers. It reports spread and gaps before drawing a conclusion. Not for general testing policy or choosing test oracles - use principle-testing.
Also in 26 projects that use this
- +1 more from TheOnlyFusionCube
Other versions38 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 38
- Yeachan-Heo/oh-my-claude-sisyphus★ 41ksame name
- Yeachan-Heo/oh-my-claudecode★ 41ksame name
- backnotprop/pstack★ 3.8ksame name
- backnotprop/bro★ 176same name
- hamzafarooq/claude-code-starter★ 145same name
- jtaroreh/agystack★ 128same name
- dsebban/skills★ 71same name
- TheOnlyFusionCube/potetos-for-everyone★ 21same name
- creedants/pstack-t3★ 18same name
- painhardcore/pstack★ 18same name
28 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository10 other files it gives its agents.
- AGENTS.mdAGENTS.md
- fix-the-classSkill
- habit-wordsSkill
- hulkSkill
- jevSkill
- premortemSkill
- quickSkill
- reviewSkill
- setup-first-passSkill
- ship-checkSkill
The file
We split this skill into the rules it gives an agent
7 rules. 0 are common, 7 are distinctive, and 0 are very specific to this project.
0
Common
Most of the 29 edited versions we read keep these.
7
Distinctive
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 16
If the prompt block above is empty or still shows a placeholder, the prompt is the text the user sent with this command.
- Distinctive: line 31
Read, Grep and Glob are never held back.
- Distinctive: line 44
Asks: every separate thing to do or answer.
- Distinctive: line 49
Facts: every name, path, file, URL, number, date, error message, quoted text and code, copied exactly.
- Distinctive: line 80
Add scope: No asks, features, files or refactors the user did not ask for.
- Distinctive: line 95
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 …
- Distinctive: line 124
Leave out any line with nothing in it.
“Common” is measured: kept by at least 6 in 10 of the 29 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
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.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

