Improving prompts

Take the prompt the user supplied, return a short report and an enhanced prompt, and never block on questions. A technique earns its place only by closing a diagnosed gap; the shortest prompt that reliably does the job wins. The enhanced prompt is the user's own request, engineered, not a document about the request.

Take in the prompt

The prompt to improve is the text the user supplies with the request: inline, in a code block, or in a file to read. Everything else the user says, such as the target model, the harness, the audience, where the prompt will run, or what went wrong last time, is context for the diagnosis and does not go into the prompt.

A system prompt supplied together with a task prompt is two prompts with two destinations. Improve both and deliver two blocks.

Keep the prompt's language and register. Do not translate it, and do not turn first person into third person. Write the report in the language of the user's request.

If no prompt was supplied, ask for it. That is the only case in which this skill asks a question. If the prompt's purpose is to defeat a model's safeguards or to deceive people, say so in one sentence and stop.

Classify the destination

Choose the most likely destination and record it in the report. When two readings would produce materially different prompts, deliver the most likely one and name the other under Assumptions. Read diagnosis for the full signal list, the gap checklist, and how to write success criteria.

Diagnose

Walk the draft against this checklist: goal and definition of done; audience and destination; facts the reader lacks; constraints and scope; output form and length; a pattern the output must match; reasoning demand; risk, meaning untrusted content, side effects, hallucination stakes, or personal data; defects in the draft itself, meaning contradictions, duplicated rules, emphasis in capitals, prohibitions without an alternative, instructions the destination cannot honour, and bloat; runtime assumptions such as a prefilled response, a sampling setting, or a tool the destination lacks.

Rate each gap blocks (the model cannot do the job), degrades (it will do a worse job), or cosmetic. Only blocks and degrades justify a change. A draft with nothing above cosmetic is already good: say so, fix the cosmetics, and do not inflate it.

Select techniques

Pick from the groups below. Read the reference for every group you apply and for every group you reject on a judgment call.

Rejection reasons must be specific to this prompt: "no real transcripts to use as examples; invented ones would teach the wrong voice", never "not needed". Record every group you seriously weighed.

Apply

• Preserve intent, scope, voice, terms, and language. A changed meaning is a defect. If the draft contradicts itself, keep the reading its wording supports and flag it.
• Never add a fact the user did not give: no product names, numbers, file paths, policies, dates, or audience claims. A missing fact becomes a placeholder in square brackets naming what goes there, such as [paste the failing test output] or [audience, e.g. finance managers], and every placeholder is listed under Assumptions. Nothing the draft already says becomes a placeholder.
• Minimal sufficient structure. A one-line request usually becomes three to eight lines, not a page. Use tags or headings only when the prompt mixes kinds of content. Keep the user's structure where it works.
• Say what to do. Keep a prohibition only when it protects something, and pair it with the alternative.
• No emphasis in capitals, no "critical", no chains of "must". One plainly stated instruction each. Current models over-trigger on shouted rules.
• Give the reason behind a constraint that is not obvious, in a clause, so the model can generalize from it.
• Consistent terms and tag names throughout; descriptive tags, balanced and closed.
• No meta commentary inside the prompt: no "Improved prompt:", no technique labels, no notes to the user. The enhanced prompt reads as the user's own request and stands alone without the report.
• No instruction the destination cannot honour: no tests for a model without tools, no "search the web" without search.
• Runtime settings and architecture stay out of the prompt text: effort or reasoning level, schema enforcement, cache breakpoints, tool-result encoding, screening, sampling parameters. Report them under Outside the prompt.
• Model-neutral wording unless the user named the target. Then apply the dated adjustments and name the model in the report, never inside the prompt.
• Each added sentence traces to one diagnosed gap. Do not stack techniques.

Shape the result with the prompt skeleton, dropping every section the diagnosis did not call for.

Check before delivering

Someone with no context could follow the prompt. Every addition maps to a blocks or degrades gap. Nothing is invented and every placeholder is listed. No contradictions, duplicate rules, shouted emphasis, or prohibition without an alternative remain. The length is proportionate to the task. Tags are balanced. The first sentence states the task. Language and voice are unchanged. Nothing asks the destination for what it cannot do. Model-specific wording appears only when a model was named.

Deliver

Fill the improvement report in this order and put nothing after the enhanced prompt:

1. ## Diagnosis: destination; target, either the model the user named or "not specified; neutral"; three to six gaps with severity.
2. ## Techniques applied: a table of technique and why here, each row naming the gap it closes.
3. ## Techniques considered and not applied: a table of technique and why not, specific to this prompt.
4. ## Assumptions and placeholders: omit when empty. One line per placeholder (what to fill in and why it could not be inferred) and per assumption.
5. ## Outside the prompt: omit when empty. Settings, architecture, and evaluation suggestions the prompt text cannot carry.
6. The enhanced prompt inside <enhanced_prompt> and </enhanced_prompt>, with the tagged block inside a fenced code block opened with more backticks than any run inside the prompt, at least four. The fence keeps markdown clients from rendering the prompt and lets code fences inside it survive. Two prompts use <enhanced_prompt role="system"> and <enhanced_prompt role="user">, each in its own fence.

When the draft is already good, the report says so and the applied table may hold a single cosmetic row. For calibration, read the worked examples. Without file access, deliver the same response as text and do not claim that a file was written.

References