ChatGPT vs Claude: How to Write Prompts for Each

ChatGPT vs Claude: How to Write Prompts for Each

Reliable AI work starts with an explicit agreement about what should be produced and how it will be judged. This paper offers an operational framework rather than a ranking of products or a prediction that one prompting trick will solve every task. Where capabilities depend on a particular model, account or integration, verify them in the environment you actually use.

Key takeaways

• Define the desired outcome before choosing syntax or tooling.
• Separate instructions, supporting evidence and illustrative examples.
• Make constraints testable and assign ownership for important decisions.
• Evaluate representative outputs rather than trusting a single impressive response.
• Use Brief Prompting to gather missing context before execution.

Start with the same task definition

Comparisons often focus on personality when the largest source of variation is an incomplete brief. Both systems need to know the intended outcome, audience and evidence boundaries. Establish these before adapting syntax. Otherwise you may attribute an improvement to the model when the second attempt simply included information omitted from the first.

A practical implementation

Begin with a real task that someone can review. Identify the information the model must receive, the decision it is allowed to make and the point where a person must take responsibility. Write those boundaries into the brief before generating the deliverable. This keeps the workflow understandable even when the underlying model changes.

Goal: draft an onboarding email. Audience: new administrators. Outcome: complete setup. Source: supplied setup guide. Constraint: do not invent features or promise assistance not listed in the guide.

Review the result against the request, not against how polished it sounds. Check whether the required information is present, whether unsupported assumptions have appeared and whether the intended reader can act on the answer. If a requirement fails, name that failure explicitly instead of asking for a vague improvement.

A useful comparison keeps the intended deliverable constant. If you ask one system for an executive summary and the other for detailed analysis, the outputs cannot support a meaningful judgment about model suitability. Normalize the task first and then examine where each answer needs correction.

Use markdown as a ChatGPT default

Markdown headings make an instruction easy for a person to inspect and revise. Separate the task, context, requirements and output format rather than mixing them in one paragraph. This is a practical convention, not a rule that ChatGPT cannot interpret XML or ordinary prose. Clear labels matter more than decorative formatting.

A practical implementation

Begin with a real task that someone can review. Identify the information the model must receive, the decision it is allowed to make and the point where a person must take responsibility. Write those boundaries into the brief before generating the deliverable. This keeps the workflow understandable even when the underlying model changes.

# Goal
Explain the migration process to a nontechnical customer.
# Sources
Use only the supplied guide.
# Output
Five numbered steps, followed by unresolved questions.

Review the result against the request, not against how polished it sounds. Check whether the required information is present, whether unsupported assumptions have appeared and whether the intended reader can act on the answer. If a requirement fails, name that failure explicitly instead of asking for a vague improvement.

Do not turn a formatting convention into a superstition. If a simple heading structure works well in both systems, it may be the easiest shared standard. Add tags when clearer boundaries help, not because every task requires an elaborate markup language.

Use XML as a Claude default

XML-style tags are useful for separating instructions from reference material, particularly when a brief contains several documents or examples. Choose descriptive tag names and keep nesting simple. The tags create boundaries; they do not authenticate content or prevent all instruction-following mistakes. Claude can also work with markdown and plain language.

A practical implementation

Begin with a real task that someone can review. Identify the information the model must receive, the decision it is allowed to make and the point where a person must take responsibility. Write those boundaries into the brief before generating the deliverable. This keeps the workflow understandable even when the underlying model changes.

<goal>Explain the migration process to a nontechnical customer.</goal>
<sources>Insert approved migration guide here.</sources>
<output>Five numbered steps followed by unresolved questions.</output>

Review the result against the request, not against how polished it sounds. Check whether the required information is present, whether unsupported assumptions have appeared and whether the intended reader can act on the answer. If a requirement fails, name that failure explicitly instead of asking for a vague improvement.

A reference example should never silently expand the permission to use sensitive information. Before pasting material into either system, check whether it is approved for that environment. Remove personal details and confidential content that are unnecessary for the intended transformation.

Port meaning rather than just punctuation

A successful cross-model conversion preserves priorities and source boundaries. Do not blindly wrap a tangled prompt in tags and assume it is improved. First remove contradictory directions, clarify mandatory requirements and distinguish examples from facts. Then express the same brief using the structure your team can maintain most easily.

A practical implementation

Begin with a real task that someone can review. Identify the information the model must receive, the decision it is allowed to make and the point where a person must take responsibility. Write those boundaries into the brief before generating the deliverable. This keeps the workflow understandable even when the underlying model changes.

Preserve the objective, audience, factual restrictions and acceptance criteria. Convert headings into descriptive tags without adding new requirements or weakening existing constraints.

Review the result against the request, not against how polished it sounds. Check whether the required information is present, whether unsupported assumptions have appeared and whether the intended reader can act on the answer. If a requirement fails, name that failure explicitly instead of asking for a vague improvement.

A useful comparison keeps the intended deliverable constant. If you ask one system for an executive summary and the other for detailed analysis, the outputs cannot support a meaningful judgment about model suitability. Normalize the task first and then examine where each answer needs correction.

Give examples a precise job

Examples can demonstrate tone, granularity or layout, but the model needs to know which quality to imitate. A reference article may have the right pacing and the wrong factual claims. Label it accordingly. Real published references are useful when inspected for relevance, not treated as automatically authoritative or copied into the final answer.

A practical implementation

Begin with a real task that someone can review. Identify the information the model must receive, the decision it is allowed to make and the point where a person must take responsibility. Write those boundaries into the brief before generating the deliverable. This keeps the workflow understandable even when the underlying model changes.

Use the reference only for paragraph length and directness. Do not reuse its wording, statistics, company names or factual claims. Use the approved fact sheet for content.

Review the result against the request, not against how polished it sounds. Check whether the required information is present, whether unsupported assumptions have appeared and whether the intended reader can act on the answer. If a requirement fails, name that failure explicitly instead of asking for a vague improvement.

Do not turn a formatting convention into a superstition. If a simple heading structure works well in both systems, it may be the easiest shared standard. Add tags when clearer boundaries help, not because every task requires an elaborate markup language.

Make source handling explicit

Neither a confident tone nor an elegant citation proves an answer is grounded. Supply sources directly when accuracy depends on specific documents, and request traceable references to those sources. If browsing is available, define the scope and ask for verification. Tool availability varies across products, accounts and configurations; do not assume every conversation can search.

A practical implementation

Begin with a real task that someone can review. Identify the information the model must receive, the decision it is allowed to make and the point where a person must take responsibility. Write those boundaries into the brief before generating the deliverable. This keeps the workflow understandable even when the underlying model changes.

For each substantive factual claim, identify the supporting source section. If the source does not establish the claim, omit it or label it unresolved. Do not invent URLs or quotations.

Review the result against the request, not against how polished it sounds. Check whether the required information is present, whether unsupported assumptions have appeared and whether the intended reader can act on the answer. If a requirement fails, name that failure explicitly instead of asking for a vague improvement.

A reference example should never silently expand the permission to use sensitive information. Before pasting material into either system, check whether it is approved for that environment. Remove personal details and confidential content that are unnecessary for the intended transformation.

Specify reasoning outcomes, not hidden transcripts

For analytical tasks, request a concise explanation, relevant assumptions and checks the reader can verify. An instruction to reveal every internal thought is unnecessary and may not be supported. Focus on observable work: calculations, evidence, alternatives and limitations. Match the depth of the requested explanation to the decision the reader needs to make.

A practical implementation

Begin with a real task that someone can review. Identify the information the model must receive, the decision it is allowed to make and the point where a person must take responsibility. Write those boundaries into the brief before generating the deliverable. This keeps the workflow understandable even when the underlying model changes.

Recommend one option. Provide the decisive evidence, key assumptions, main trade-off and a check that could overturn the recommendation. Keep the explanation concise and auditable.

Review the result against the request, not against how polished it sounds. Check whether the required information is present, whether unsupported assumptions have appeared and whether the intended reader can act on the answer. If a requirement fails, name that failure explicitly instead of asking for a vague improvement.

A useful comparison keeps the intended deliverable constant. If you ask one system for an executive summary and the other for detailed analysis, the outputs cannot support a meaningful judgment about model suitability. Normalize the task first and then examine where each answer needs correction.

Treat structured data as a separate requirement

Markdown tables and XML-delimited instructions are not the same as validated machine-readable output. If software consumes the answer, define the actual output schema. Use native structured-output capabilities when available and validate the result outside the model. Correct types do not guarantee correct meaning, so enforce business rules separately.

A practical implementation

Begin with a real task that someone can review. Identify the information the model must receive, the decision it is allowed to make and the point where a person must take responsibility. Write those boundaries into the brief before generating the deliverable. This keeps the workflow understandable even when the underlying model changes.

Return a JSON object with status, summary and source_ids. If evidence is missing, use status needs_review and an empty source_ids array. Do not include surrounding commentary.

Review the result against the request, not against how polished it sounds. Check whether the required information is present, whether unsupported assumptions have appeared and whether the intended reader can act on the answer. If a requirement fails, name that failure explicitly instead of asking for a vague improvement.

Do not turn a formatting convention into a superstition. If a simple heading structure works well in both systems, it may be the easiest shared standard. Add tags when clearer boundaries help, not because every task requires an elaborate markup language.

Compare models with controlled tests

Run both systems on the same brief and source set, then compare against an explicit rubric. Include repeated trials when variation matters. Record the exact model and relevant settings instead of treating ChatGPT or Claude as a single permanent capability. Product names cover changing models, tools and account-level features.

A practical implementation

Begin with a real task that someone can review. Identify the information the model must receive, the decision it is allowed to make and the point where a person must take responsibility. Write those boundaries into the brief before generating the deliverable. This keeps the workflow understandable even when the underlying model changes.

Score both outputs for source fidelity, task completion, audience fit and format compliance. Cite specific passages. Do not favor an answer merely because it is more verbose.

Review the result against the request, not against how polished it sounds. Check whether the required information is present, whether unsupported assumptions have appeared and whether the intended reader can act on the answer. If a requirement fails, name that failure explicitly instead of asking for a vague improvement.

A reference example should never silently expand the permission to use sensitive information. Before pasting material into either system, check whether it is approved for that environment. Remove personal details and confidential content that are unnecessary for the intended transformation.

Iterate with targeted feedback

When a draft disappoints, identify the failure precisely. A request to make it better gives the model little direction and may damage parts that already work. Preserve the accepted sections and specify the smallest required change. If the problem is missing evidence, supply evidence rather than asking for a more confident rewrite.

A practical implementation

Begin with a real task that someone can review. Identify the information the model must receive, the decision it is allowed to make and the point where a person must take responsibility. Write those boundaries into the brief before generating the deliverable. This keeps the workflow understandable even when the underlying model changes.

Keep the structure and verified facts. Rewrite only the introduction for a skeptical technical audience. Remove unsupported benefits and list any missing evidence separately.

Review the result against the request, not against how polished it sounds. Check whether the required information is present, whether unsupported assumptions have appeared and whether the intended reader can act on the answer. If a requirement fails, name that failure explicitly instead of asking for a vague improvement.

A useful comparison keeps the intended deliverable constant. If you ask one system for an executive summary and the other for detailed analysis, the outputs cannot support a meaningful judgment about model suitability. Normalize the task first and then examine where each answer needs correction.

A reusable operating checklist

Stage	Required decision	Evidence of completion
Brief	What outcome and audience matter?	A written objective and acceptance criteria
Inputs	Which sources control?	Labeled, current source material
Execution	What may the model do?	Explicit tool and output boundaries
Review	Who verifies the result?	Named reviewer and recorded corrections
Maintenance	When should instructions change?	Version owner and evaluation notes

Use this checklist as a conversation aid, not a compliance performance. If a row has no meaningful answer, the task is probably underspecified. Resolve the missing decision or deliberately narrow the deliverable. A provisional draft with clear limits is often more useful than an apparently complete answer built on hidden assumptions.

Put the brief into practice

PromptDeck turns a rough idea into one ready-to-paste prompt by interviewing you one question card at a time. Quick uses about eight questions, Standard about fifteen and Deep about twenty-five. Choose depth according to complexity and consequences, rather than assuming a longer interview is always better.

The method collects goal, audience, context, constraints, tone, format, examples, what to avoid and success criteria. PromptDeck writes markdown headings for ChatGPT and XML tags for Claude. It can also find real published reference examples on the web, and there is a ChatGPT/Claude connector. Inspect references before relying on their facts or using them as style guidance.

There is one free prompt. Pro costs €9 per month with 100 credits, or €79 per year. Try PromptDeck free with a task you already understand well enough to evaluate. Compare the result with your usual process and record what improved, what still needed revision and which missing answer would have prevented that revision.

For the underlying method, read the Brief Prompting guide and learn Brief Prompting. Explore concrete starting points in the library, or revisit common prompt mistakes. The aim is not to collect more templates, but to make each important request easier to specify and verify.

FAQ

Does better prompting guarantee accurate output?

No. Clear instructions improve the conditions for useful output, but models can still misunderstand sources or produce unsupported claims. Verify material facts and use appropriate human review before consequential decisions or publication.

Do longer prompts always work better?

No. Relevant context and clear priorities matter more than length. Remove redundant material and resolve contradictions. Use a longer brief when complexity requires it, not as a substitute for deciding what matters.

Can one brief work with ChatGPT and Claude?

Yes. Preserve the objective, sources, constraints and acceptance criteria, then adapt the presentation if helpful. Markdown headings and XML tags are practical packaging choices, not exclusive requirements or guarantees of performance.

When should a team use an interview instead of a template?

Use an interview when the requester has a rough idea but has not articulated the audience, boundaries or definition of success. Use a stable template when those decisions are already known and the workflow repeats with predictable inputs.

What should we do when evidence is missing?

Ask for the missing source, narrow the task or label the conclusion as unresolved. Do not encourage the model to fill an evidentiary gap with confidence. A clearly stated limit is more useful than an unsupported answer.