Prompt Engineering for ChatGPT and Claude: Practical Exercises and Evaluation

Editorial approach: this is an educational explanation using illustrative exercises, not a record of a client deployment or a claim of tested commercial results. Check linked original sources before applying the methods to sensitive information.

Prompt engineering is the practice of specifying a task clearly, supplying useful context, describing the desired output and evaluating the result. It is less about a mysterious phrase than about making work testable. Here is a repeatable method for practising with ChatGPT, Claude, or another suitable model.

01. Strategic Opportunity: prompts as instructions, not guarantees

A vague request such as “improve this” leaves the task, audience and success criteria undefined. A stronger request specifies what should be preserved, what should change and what an acceptable answer looks like. Anthropic's published prompting guidance stresses clear, direct instructions and the use of context and examples. The applicability of individual techniques can vary by model and version. CLAUDE_PROMPT

Prompt engineering is useful for learning, drafting and analysis, but cannot make an unsupported claim true or remove the need to verify a consequential output. A prompt with a source attached can still produce a summary that misstates the source. Treat prompting and source verification as complementary disciplines.

02. Practical learning outcomes

You should be able to state a task in one sentence, separate instructions from reference content, define a target audience, set an output structure and evaluate omissions or inaccuracies. Successful prompting means obtaining a result suitable for review—not merely obtaining a confident or elaborate result.

Use the five-field structure: Task / Context / Constraints / Output / Checks. Task says what is required. Context provides only authorized necessary background. Constraints explain boundaries, such as “do not add facts.” Output specifies format. Checks give the reviewer observable criteria. The model's own self-check can help organize revision, but does not substitute for independent inspection.

03. A genuine practice pathway

Exercise 1 — rewrite without invention. Take a short paragraph that you wrote. Ask: “Rewrite this for a nontechnical reader in 120–150 words. Preserve all named facts, dates and qualifiers. Do not add examples or claims. Then list any wording whose meaning may have changed.” Compare before and after. Record every changed claim. A successful result preserves meaning and makes the target audience's reading task easier.

Exercise 2 — structured extraction. Supply a fictional meeting note with three decisions, two open issues and several dates. Request a table with columns for item, status and exact supporting phrase. Verify each table cell against the note; mark invented entries as failures.

Exercise 3 — answer with source boundaries. Ask for a summary restricted to a provided passage; require an “unsupported by provided material” response where needed. Include one question not answered by the passage, and check whether the model admits that the answer is unavailable.

These are designed classroom exercises, not observed benchmark results. The proposed educational CTA is Explore Practical AI Learning → /learn-ai/.

04. Distinctive advantage: a reproducible prompt worksheet

Use a worksheet with columns: task ID; prompt revision; model/provider; visible model identifier if available; test date; input material; expected elements; observed output; and reviewer notes. This prevents a favorite example from being mistaken for general proof.

Original rubric — score each dimension 0, 1 or 2: Task compliance (missed / partial / complete); factual grounding (unsupported / mixed / supported by given input); format fidelity (wrong / partly correct / correct); clarity (confusing / usable / clear); and uncertainty handling (conceals limits / partial / explicit). The rubric is editorial guidance; it has not been statistically validated. Keep the same input and criteria when testing different prompts or tools.

05. Evidence and tool-specific cautions

Vendor documentation can explain recommended interaction patterns but is not an independent comparison of vendor accuracy. Claude's documentation describes model-specific prompting practices; a recommendation appropriate for one model should not automatically be attributed to every ChatGPT or Claude version. CLAUDE_PROMPT

Do not publish claims such as “Claude is more accurate than ChatGPT” or “this prompt always works” without a defined benchmark, sampling plan, date, settings and replicable measurement. Even an apparently correct sample output proves only that the particular attempt passed its specific review criteria.

Explore prompting and AI learning

06. Learning experience: baseline, revision, controlled comparison

Begin with a baseline prompt. Save the original input and output. Revise only one meaningful instruction, such as the output format or requirement to quote source passages. Run a second attempt and compare against the same rubric. Then repeat with a different example so you can detect whether the improvement generalizes beyond one passage.

If two providers are compared, disclose the testing date, interface and model identification visible to the tester; never imply identical hidden defaults. A better result in one test is not sufficient to rank an entire platform.

A safe demonstration uses synthetic or public sample data. If the task involves internal personnel files, customer records or protected research, obtain permission and follow the organization's data policy before providing information to a tool.

Extended practice: how to document improvement without overstating it

Construct a tiny set of three different inputs: a simple paragraph, a paragraph containing a qualifying exception, and a paragraph with deliberately missing information. Use the same output contract on each. For every attempt, record whether the model preserved the exception and whether it admitted that the missing information was not available. A prompt that works only on the easiest input does not demonstrate robust behavior.

Use the following evaluation sheet for a single task: objective; test input; expected supported facts; forbidden additions; expected format; model or interface label; test date; reviewer; observed deviations; and action taken. A reviewer should be able to reproduce the evaluation from the saved inputs. If the platform's exact model identifier is unavailable, record that limitation rather than inventing it.

Exercise 4 — deliberate ambiguity. Write a prompt saying “prepare a short summary” without specifying audience or purpose. Then revise it to say who will read the summary, what they need to decide, the maximum length, and how to flag missing source evidence. Compare whether the second prompt makes the output easier to judge. The intended lesson is testability, not a promise that more instructions necessarily improve every result.

Exercise 5 — source conflict. Supply two clearly labeled fictional policies with different effective dates. Request a comparison that retains both dates and avoids declaring which policy governs unless the text says so. The review criterion is whether the output preserves disagreement. This is especially useful for learners who rely on AI when synthesizing research materials.

Exercise 6 — refusal to invent. Give the model a partially complete fictional project record and request a status table. Instruct it to mark fields with no documentary support as “not provided.” A strong evaluation rewards correct identification of missing data, not an apparently complete table. In professional practice, an honest unknown is often preferable to confident speculation.

Troubleshooting checklist

When an output fails, determine whether the task was vague, relevant context was missing, the input itself was contradictory, the required format was impractical, or the model produced an unsupported fact despite adequate instructions. Correct the diagnosed issue and retest. Changing many variables simultaneously prevents the learner from identifying which revision mattered. Preserve failed outputs in the practice record; they are part of the evidence rather than material to hide.

07. Decision questions and common failures

Why did a clear prompt still fail? The model may misunderstand a term, lack needed data, ignore a constraint or generate an unsupported assertion. Revise the task and review the source; do not assume repetition will correct the evidence gap. Should I specify a role? A role can clarify expected tone or audience, but it does not confer actual expertise or credentials. Should I ask for citations? Yes where sources matter, but verify every cited source and passage independently.

Can external documents change the model's behavior? Yes, untrusted material can contain instructions that try to redirect an assistant. OWASP describes indirect prompt injection through websites or files and recommends maintaining boundaries between instructions and untrusted content. OWASP

When should I stop experimenting? When the source cannot support the requested answer, when sensitive data cannot be safely handled, or when the use case demands qualified human judgment. Escalate rather than trying to find a more persuasive prompt.

08. Strategic conversion: practise with evidence

Choose one low-risk real task, document an initial prompt, improve its clarity, and judge it with a written rubric. Continue through the existing AI learning hub. Explore Practical AI Learning → /learn-ai/ (CTA proposal requiring approval). This page does not advertise a workshop enrollment or other unverified offering.

Primary sources for fact-check and attribution

• CLAUDE_PROMPT: https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/prompt-templates-and-variables
• OWASP: https://genai.owasp.org/llmrisk/llm01-prompt-injection/