Claude Prompt Templates with XML Structure & Artifacts

You are an expert prompt engineer who specializes in Claude.

<rough_request>
[Paste the task you want Claude to do, in your own words]
</rough_request>

Rewrite the rough request into a production-ready Claude prompt. Follow these rules:
1. Open with a one-sentence role for Claude.
2. Put all variable input inside clearly named XML tags (for example <document>, <data>, <audience>), using {{PLACEHOLDER}} variables.
3. Put the step-by-step task inside <instructions> as a numbered list.
4. Add a <constraints> block with tone, length, and anything Claude must not do.
5. Add one short <example> of the desired output if the format is non-obvious.
6. Specify the output tag Claude must answer inside, such as <answer>.

Return the finished prompt inside <prompt> tags, then list in <notes> any assumptions you made and the questions I should answer to improve it.

You are a senior front-end engineer and product designer.

<goal>
[Describe the tool, e.g. "a mortgage calculator with an amortization chart"]
</goal>

<requirements>
- Deliver one complete, self-contained HTML file with inline CSS and JavaScript. No external dependencies or build step.
- Responsive layout that works from 360px to desktop width.
- Accessible: semantic HTML, labelled form controls, visible focus states, and WCAG AA color contrast.
- Validate user input and show friendly inline error messages.
- Include sensible default values so the tool is useful the moment it renders.
</requirements>

Before writing code, list in <plan> the components, state, and interactions in under 8 bullets. Then output the full file as a single Artifact. After the Artifact, suggest 3 concrete enhancements I could ask for next.

<document>
<source>[Document name or URL]</source>
<document_content>
[Paste the full document here]
</document_content>
</document>

You are a meticulous senior reviewer. My goal for this review is: [e.g. "decide whether to sign this vendor agreement"].

<instructions>
1. First, extract the passages most relevant to my goal and place them word-for-word inside <quotes>, each numbered.
2. Using only those quotes, identify issues, risks, ambiguities, and missing items. Cite the quote number for every finding.
3. Rate each finding High, Medium, or Low and propose a concrete fix or question to raise.
4. If the document does not contain enough information to judge something, say so instead of guessing.
</instructions>

Return your findings inside <review> as a table (Finding | Quote # | Severity | Recommended Action), followed by a 3-sentence executive summary inside <summary>.

<documents>
<document index="1">
<source>[Source 1 title]</source>
<document_content>[Paste source 1]</document_content>
</document>
<document index="2">
<source>[Source 2 title]</source>
<document_content>[Paste source 2]</document_content>
</document>
</documents>

You are a research analyst. My research question is: [your question].

<instructions>
1. Summarize each document's position on the question in 2 to 3 sentences, citing it as [1], [2], and so on.
2. List the points where the sources agree.
3. List the points where they contradict each other, and explain which evidence is stronger and why.
4. Identify gaps that none of the sources address.
5. Do not introduce facts that are not in the documents.
</instructions>

Answer inside <synthesis> using the headings: Per-Source Summary, Consensus, Contradictions, Gaps, Bottom Line.

You are a staff software engineer who values small, reversible changes.

<codebase>
<file path="[path/to/file1]">
[Paste file contents]
</file>
<file path="[path/to/file2]">
[Paste file contents]
</file>
</codebase>

<goal>[e.g. "split the payment module into testable units without changing behavior"]</goal>

<constraints>
- Preserve all public behavior and APIs unless I explicitly approve a change.
- Match the existing language version, style, and libraries. Do not add new dependencies.
- Keep each step small enough to review in one sitting.
</constraints>

First, inside <analysis>, describe the current structure, code smells, and risks. Then inside <plan>, give a numbered sequence of refactor steps, each with the tests that prove behavior is unchanged. Finally, inside <step_1>, write the complete code and tests for step 1 only.

You are a principal engineer performing a pull request review.

<pr_description>
[What the change is supposed to do]
</pr_description>

<diff>
[Paste the unified diff]
</diff>

<instructions>
Review the diff for, in priority order:
1. Correctness bugs and unhandled edge cases.
2. Security issues: injection, authentication or authorization gaps, secrets in code, unsafe deserialization, missing input validation.
3. Performance regressions such as N+1 queries or unbounded loops.
4. Missing or weak tests.
5. Readability and naming.
For each finding, cite the file and line, describe the failure scenario, and give a concrete fix. Do not comment on formatting a linter would catch.
</instructions>

Return findings inside <findings> grouped as Blocker, Should Fix, and Nit. End with <verdict> set to Approve, Approve with changes, or Request changes, plus a one-sentence reason.

You are a precise data-extraction engine.

<schema>
{
  "vendor_name": "string",
  "invoice_number": "string",
  "invoice_date": "YYYY-MM-DD",
  "total_amount": "number",
  "currency": "ISO 4217 code",
  "line_items": [{"description": "string", "quantity": "number", "unit_price": "number"}]
}
</schema>

<input>
[Paste the raw text, email, or OCR output]
</input>

<rules>
- Extract only values that are explicitly present in the input. Use null for anything missing. Never invent values.
- Normalize dates to YYYY-MM-DD and amounts to plain numbers without currency symbols.
- If a value is ambiguous, choose the most likely reading and record it in the "warnings" array.
</rules>

Return only valid JSON matching the schema, plus a top-level "warnings" array of strings, inside <json> tags. Output nothing outside the tags.

You are an expert at writing system prompts for Claude assistants.

<assistant_purpose>
[e.g. "a support assistant that answers questions about our SaaS billing"]
</assistant_purpose>

<audience>[Who will talk to this assistant]</audience>

<knowledge>
[Paste product facts, policies, or reference docs the assistant must rely on]
</knowledge>

Write a system prompt that includes:
1. A clear role and the single most important goal.
2. Tone and style guidelines with one short example reply.
3. What the assistant must do when it does not know the answer, including when to escalate to a human.
4. Hard boundaries: topics to decline, and a rule never to reveal internal notes or make up policies.
5. Output formatting rules (length, lists, when to ask a clarifying question).

Return the system prompt inside <system_prompt>. Then, inside <test_cases>, give 5 tricky user messages I should use to test it, including one off-topic request and one ambiguous question.

You are a solutions architect.

<system_description>
[Describe the system: users, services, data stores, third-party APIs, and how requests flow]
</system_description>

<instructions>
1. Inside <thinking>, list the components and every connection between them, including the protocol (HTTPS, gRPC, queue, and so on).
2. Produce one Mermaid flowchart (graph LR) as an Artifact. Group components into subgraphs by trust boundary: Client, Edge, Services, Data, External.
3. Label every arrow with the action and protocol.
4. Below the Artifact, inside <decision_log>, list the top 5 architectural decisions visible in the diagram, the trade-off each one makes, and one risk to watch.
</instructions>

Keep node labels under 4 words so the diagram stays readable.

You are a senior copy editor.

<style_examples>
<example>[Paste a paragraph written in the target voice]</example>
<example>[Paste a second paragraph in the target voice]</example>
</style_examples>

<style_rules>
[Optional: e.g. "American English, active voice, no jargon, sentences under 25 words"]
</style_rules>

<draft>
[Paste the draft to edit]
</draft>

<instructions>
1. Infer the voice from the examples: sentence length, vocabulary, formality, and rhythm. Describe it in 3 bullets inside <voice_profile>.
2. Edit the draft to match that voice and the style rules. Keep the author's meaning and all facts unchanged.
3. Do not add new claims, statistics, or quotes.
</instructions>

Return the edited text inside <edited_draft>, then a table inside <changes> listing the 5 most significant edits (Original | Revised | Reason).