Claude prompt improver
Paste a rough prompt, get a model-ready version that follows Claude's conventions. Free. No sign-in.
no sign-in · nothing stored · free
What good Claude prompts look like
Claude prompts are easiest to inspect when each kind of information has a clear boundary. Anthropic documents XML-style tags as one way to separate instructions, context, examples, and input data. The tags are not a ritual and the names are not fixed. Their value is practical: a reviewer can see what is evidence, what is a task, and what the answer must contain. This is especially useful when the prompt includes long documents, multiple examples, or text that might itself contain instructions.
Use tags to give different material different jobs
Wrap blocks in simple, consistent tags such as <context>, <source>, <task>, <constraints>, and <format>. Nest tags only when the hierarchy matters. For example, several <document> blocks inside <sources> can carry a title or date without mixing metadata into the prose. Do not tag every sentence. A short request can remain plain text; tags earn their place when they remove ambiguity or make a long prompt easier to maintain.
Put long source material before the question
For document work, present the source text as a bounded block and place the specific questions after it. Say whether Claude should rely only on the supplied material or may add general knowledge. If the answer must be traceable, request clause numbers, page references, or short quotations from the source. A summary request alone leaves the model to decide what matters; a decision-focused question tells it what evidence to prioritize.
Give examples a separate boundary
Examples are useful when the required tone or schema is difficult to describe. Put them in an <examples> block and label input and output separately. One representative example is usually better than several near-duplicates. State what the example demonstrates, such as the level of detail or the JSON keys, so surface details are not copied accidentally. If the source document contains its own example text, keep that outside the instruction examples.
Write a testable output contract
Name the sections, fields, length, and evidence standard. "Return Summary, Risks, Missing information, and Recommendation" is reviewable in a way that "analyze this thoroughly" is not. For structured data, provide the exact keys and say how unknown values should be represented. For prose, define the reader and the action they need to take. Avoid asking for hidden reasoning; ask for a concise rationale and the evidence that supports it.
Tell Claude how to handle conflicts and gaps
Documents often disagree, omit dates, or use the same term differently. Add a rule for those cases before they occur: identify the conflict, cite both sources, and do not resolve it without evidence. Ask for a short list of missing inputs when a confident answer would require facts that are absent. This produces a more useful boundary than a blanket instruction to be accurate, because it describes observable behavior you can check.
Keep the instruction hierarchy explicit
When a prompt contains quoted emails, contracts, web pages, or user submissions, state that the enclosed content is data to analyze, not instructions to follow. Put the actual task outside that content. This matters even when the material is benign because copied text can contain requests addressed to another reader. A clear hierarchy also makes the prompt reusable: you can replace the source block without rewriting the operating rules around it.
Before and after
The document, task, review rules, and answer shape are separate objects. The rewrite defines whose risk matters, names the risk categories, and requires a clause reference for each finding. It also gives Claude an honest response when the contract is silent: identify the missing term instead of filling the gap.