Two lightweight slash commands for Claude Code — /sharpen and /gosharp — that make a strong model produce better output by adding the few targeted nudges that actually move the needle, and nothing else.
They are deliberately small. The bet behind them: a frontier model already has the reasoning; what it's missing is the right prompt and the right context — not a heavy orchestration framework wrapped around it. So these complement the model instead of overriding it.
/sharpen <prompt> — A prompt compiler. Takes your rough prompt, mines the session context it arrives in, compiles for its destination (steering the current session vs briefing a fresh executor that shares none of your context), and doses the discipline — the few lines this task actually needs, chosen by expected failure mode, not the maximum amplifier set. Context always survives compilation; discipline gets what's left. When the refined prompt targets this session and the intent is clearly "do this", it keeps going and executes it — no pasting the output back. For a fresh executor, or when you only wanted the prompt, it stops at the prompt.
/gosharp <request> — An executor, not a compiler. Restates your intent visibly so you can catch a misread, matches its breadth to yours (broad stays broad), then derives its own checks from the task — where would a default pass satisfice, what's unverified, what shape should the answer take — rather than working a fixed list. Says what "done" looks like before starting, verifies before claiming done, and argues against its own conclusion before presenting. The deliverable is the result — not a plan for it, not a rewritten prompt.
Both are explicitly invoked only (disable-model-invocation) — they never auto-trigger. You reach for them on purpose.
Most prompts are underspecified. "Review this code" produces shallow output because the model doesn't know what to focus on, when to stop, or which failure modes to watch for. These commands encode that knowledge as targeted constraints:
- Context mining — weighs what the conversation already established, what the result will be used for next, and what in context might be stale, before interpreting the task.
- Task-type detection — different amplifiers for analysis, implementation, debugging, and research.
- Scope protection — distinguishes "X crashes when Y" (narrow debugging) from "X sucks" (broad assessment), so a broad request isn't quietly narrowed into one specific fix.
- Requirement alignment — "implement exactly what's asked" prevents gold-plating that misses the core ask.
- Coverage honesty — forces the model to state what it examined and what it skipped.
- Self-critique — argue against your own conclusion before finalizing, and change the answer if the counter-argument wins.
- Dosed discipline —
/sharpenpicks the few lines a task actually needs, by expected failure, instead of applying every amplifier: a strong executor on familiar ground gets a check or two (it fails by stopping early, not by reasoning badly); an edge-of-capability task or unknown executor earns more. Thinking tasks get questions, not contracts. - Compile, then execute —
/sharpennow executes the refined prompt when it's clearly a this-session "do this" — the round-trip of pasting its output back is gone. Prompts compiled for a fresh executor still stop at the prompt. - Free self-checks in
/gosharp— instead of fixed task-type amplifier blocks, it derives what most needs checking from the task at hand and holds those questions loosely while working: they steer, they don't demand answers. - Context-first compilation — files, state, and constraints always survive; discipline is woven into the task with the space that's left, never appended as a generic block.
- Context mining first — both commands now read the task in relation to the session before judging or reshaping it, not as text in a vacuum.
- Destination-aware compiling —
/sharpencompiles lean when steering the current session, and embeds files, environment, and discipline when the prompt targets a fresh agent that carries none of your context. - Situate step in
/gosharp— a small set of questions (what's already established, what would the user regret about the obvious interpretation, what does this touch, what's stale) that sharpen the visible restatement and plan. - Self-sweep —
/sharpenchecks its own output before returning: what question would make this refined prompt better that it doesn't yet raise?
/plugin marketplace add jp290/sharpen
/plugin install sharpen@sharpen
Then use /sharpen and /gosharp in any session.
# Global (available in all projects)
cp commands/sharpen.md commands/gosharp.md ~/.claude/commands/
# Or project-specific
cp commands/sharpen.md commands/gosharp.md .claude/commands/Then:
/sharpen review the auth module for security issues
/gosharp assess why the API is slow and fix the worst bottleneck
Both approaches were tested on the same prompt: "Build an app that allows to play Doodle Jump inside the browser on a phone."
| Raw | /gosharp | |
|---|---|---|
| Lines of code | 907 | 637 |
| Tool calls | 19 | 2 |
| Time | 203s | 126s |
| Visuals | Better (shooting, particles, detailed character) | Simpler (notebook aesthetic) |
| Playable on phone | No — touch only fired "shoot", no movement | Yes — touch-sides movement works when tilt denied |
| Code quality | Global scope, no cleanup on game over | IIFE, proper cleanup, easier to extend |
The raw version gold-plated while missing the fundamental requirement ("playable on a phone"). The sharpened version was less ambitious but actually delivered what was asked.
The sharpening didn't produce better code — it produced better requirement alignment.
- Quick task, context already loaded — just type normally; your
CLAUDE.mdhandles it. - Assessment / review / debugging —
/gosharp assess why the review page feels slow. - Writing a prompt for another session or agent —
/sharpen investigate the export pipeline quality. - Already-sharp prompt — skip both;
/sharpenwill tell you it isn't needed rather than over-process it.
Every line in these commands does one of three things: raises a question the model weighs while working, forces a visible artifact that later generation conditions on (a restatement, a plan), or sets a hard contract (output shape, scope, consequences). Lines that do none of those are noise that dilutes the ones that do — so there aren't any.
They are intentionally lightweight because heavier scaffolding (rigid multi-step frameworks, forced sub-agent orchestration) tends to make a strong model worse by replacing its own judgment with rote process. The job here is a light reminder to use abilities the model already has — not to bolt on capability it isn't missing.
Built from first principles, not collected from a "best practices" list.
MIT © 2026 jp290