Refine

Use when the user invokes /refine or explicitly asks to have a raw, rambling, or dictated prompt sharpened into a precise instruction. If you notice a long or ambiguous prompt you MAY suggest sharpening, but NEVER run it uninvited. Do NOT use it to write or polish output prose such as emails, posts, or messages (that is a writing task, not prompt sharpening), and do NOT use it on an open idea whose intent is still unsettled (explore first, sharpen after).From its SKILL.md

Install

npx -y skills add 55xai/agent-skills --skill refine

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

4.7 KB, as published. Nobody here has run it

refine — prompt sharpener

Your task: take the user's raw prompt and distill it into a sharp instruction to yourself (the LLM, in this conversation). The output is an instruction, not polished prose — terse, structured, bullet-like is fine.

Rule 0 — never run uninvited

If you activated this skill yourself (model invocation) WITHOUT the user typing the refine command or explicitly asking for a prompt to be sharpened: STOP. Rewrite nothing. Ask briefly instead: "This prompt is a bit loose — want me to sharpen it first?" and wait for the answer. The user decides when to cut.

If the user explicitly invoked it: continue.

Input

The raw prompt to sharpen: $ARGUMENTS

If $ARGUMENTS is empty: briefly ask for the raw prompt and stop.

Boundaries — check these BEFORE sharpening

Prompts in, never prose out. Refine sharpens input to the LLM. If the end product of the request is polished prose for humans — an email, a post, a message, marketing copy — refine is the wrong tool, even when the request arrives through the refine command. Do not dodge this by treating the prose as "payload" and sharpening the instruction around it: a SHARPENED block that says "rewrite this email to sound better" is still prose polishing with extra steps. Say in one line that this is a writing task rather than a prompt to sharpen, and offer to help with the writing directly, outside refine. Corollary: the sharpened prompts refine produces are instructions — never apply human-facing style rules to them; terse and bullet-like is correct.
Unsettled intent? Do not converge. If the input is an open idea the user has not finished exploring (multiple candidate directions, "not sure what exactly", a hunch), produce NO sharpened block. Wrapping the idea as a crisp "exploration task" — with deliverable counts, rankings, or criteria the user never asked for — is still you choosing the frame for them. Say the intent is not settled yet, suggest exploring it in dialogue first (use a brainstorming skill if one is available), and offer to sharpen afterwards.
Same language as the input. Sharpen in the language the user wrote in.

Sharpening rules

Extract the core intent. Restate what the user actually wants in 1-2 sharp sentences. That is the core — everything else supports it.
Remove dictation filler. Speech tics ("uhm", "kind of"), repetitions, tangents, conversational wrapping ("could you maybe", "I was wondering if").
Make vagueness concrete. Soft verbs ("look at", "help with", "do something about") become precise verbs (analyze, compare, build, extract, rewrite, decide).
Make output and constraints explicit. If implied: state the desired format, scope, and what is in and out of scope.
Preserve the user's intent — add nothing. NEVER add scope, features, or assumptions the user did not ask for. YAGNI applies to intent. If unsure what is meant, do not guess — see rule 6.
Ask only on genuine ambiguity. If — and only if — a real ambiguity blocks a sharp rewrite: ask 0-2 clarifying questions, integrate the answer, then sharpen. Otherwise no questions.
Multiple tasks in one input. Sharpen them as numbered sub-instructions in the same block. Keep the user's order — never reprioritize silently. Ask about order only if it has real consequences (rule 6).

Example

Raw input: "uhm, could you maybe look at the onboarding flow a bit, I feel like people drop off somewhere, and I was also thinking should we do something about the welcome email, it seems pretty long"

SHARPENED:
1. Analyze the onboarding flow: identify where users drop off and
   propose concrete fixes. Analysis and proposals only — implement nothing.
2. Rewrite the welcome email to be shorter.

Flow (sharpen → show → run)

Produce the sharpened prompt. Show it in a clear block, e.g.:
```
SHARPENED:
<the sharp instruction>
```
If you asked clarifying questions (rule 6), do that before the block and integrate the answers.
Ask briefly: "Run it? (or edit it)"
On the user's yes: execute the task exactly as the sharpened prompt describes. If the user edits: update and show again.