Writing Effective Prompts — Detail & Examples

Part of Prompt Engineering · overview: domain-4.html

In this page

A vague-to-specific prompt rewrite, the distinct roles of positive and negative examples, and why durable rules belong in the system prompt.

4.1aA vague prompt, tightened

WORKED EXAMPLE · ADDING SPECIFICITY AND AN EXAMPLE

BEFORE"Summarize this support ticket."

No stated length, so output length is inconsistent call to call.
No stated format, so sometimes it's a paragraph, sometimes bullets.
No example of what a good summary looks like for this specific use case (e.g. feeding a dashboard).

AFTER:"Summarize this support ticket in exactly 2 sentences: one stating the customer's issue, one stating the current status. Example: 'Customer cannot log in after a password reset. Status: escalated to engineering.'"

4.1bPositive vs. negative examples

Both matter, for different reasons

A positive example shows the target — what a good answer looks like.
A negative example shows a plausible-but-wrong answer and names exactly what's wrong with it — e.g. "Not: 'The customer had an issue and it's being handled' — too vague to be useful on a dashboard."
Negative examples are especially useful when a model keeps producing an almost-right answer; naming the specific way it's wrong closes gaps a positive example alone often doesn't.

4.1cSystem prompt vs. user turn

SYSTEM (durable)You are a support-ticket summarizer. Always output exactly 2 sentences: issue, then status.

USER (task-specific)Summarize this ticket: [ticket text]

Burying the durable rule ("always 2 sentences") inside a one-off user message instead of the system prompt means it has to be repeated every single turn, and is easy to forget on turn 2 or 3 — keeping it in the system prompt makes the constraint durable across the whole interaction.

Prompt Engineering Overview 4.2 Advanced Prompt Techniques →

Claude Certified Architect — Study NotesDWG 4.1