Claude Prompt Generator: Free Tool + Templates (2026)

Anthropic's guidance is consistent: be clear and direct, give Claude a role, provide context and examples, and use structure to separate instructions from data. The full checklist lives in the prompt engineering overview.

**Role.** Open by telling Claude who it is and the standard it is held to: 'You are a senior technical editor reviewing API documentation for accuracy.' A role narrows the response space far more efficiently than a longer instruction list.

**Context.** Give Claude the inputs it needs and nothing it doesn't — the audience, the constraints, the source material. Claude does not know your situation; spell it out. For long inputs, put the data first and your instructions last, which Anthropic notes improves response quality on long-context tasks.

**Output format.** State the exact shape you want: a numbered list, a JSON object with named keys, a two-paragraph summary, a table. If structure matters, show a one-line example of it. Ambiguity in the output spec is the single most common reason a prompt 'almost' works.

This skeleton maps directly onto role / context / output. Fill the brackets and delete what you don't need.

``` You are a [ROLE] with [RELEVANT EXPERTISE]. Task: [ONE-SENTENCE GOAL]. Context: - Audience: [WHO READS THIS] - Constraints: [LENGTH, TONE, MUST-INCLUDE, MUST-AVOID] - Source material: [PASTE OR DESCRIBE] Instructions: 1. [STEP] 2. [STEP] 3. If anything is ambiguous, ask before answering. Output format: [EXACT STRUCTURE — e.g., a markdown table with columns X, Y, Z] ```

The final 'ask before answering' line is optional but useful for high-stakes tasks — it gives Claude permission to surface gaps instead of guessing.

Anthropic's docs recommend using tags to separate distinct parts of a prompt so Claude can tell instructions from data. This is especially helpful when you paste a long document.

``` You are a contracts analyst. <document> [PASTE THE FULL CONTRACT HERE] </document> <task> List every obligation that falls on the buyer, with the clause number, in a markdown table: | Clause | Obligation | Deadline | </task> If a deadline is not stated, write "not specified". ```

Putting the document inside its own tag block keeps Claude from confusing the source text with the instruction, and the explicit fallback ('not specified') prevents fabricated values.

When you need every output to look identical, show one or two worked examples. This is the few-shot technique formalized in Brown et al. 2020 (arXiv:2005.14165).

``` Rewrite each support reply to be warmer but still concise. Example: Input: "Ticket closed. No refund per policy." Output: "I've closed this ticket. Our policy doesn't allow a refund here, but I'm happy to explain why or look at other options." Now rewrite: Input: "[YOUR TEXT]" Output: ```

Two or three examples usually lock the format. More than that rarely helps and just spends tokens.

Pick the model by task difficulty, not by default. Reach for Opus on hard reasoning, code, and long-context work; Sonnet for the everyday balance of quality and cost; Haiku for high-volume, latency-sensitive jobs. Prices below are list API rates as of June 2026, per Anthropic's pricing page.