Prompt engineering: a practical guide with tips and examples

If you ask a language model a vague question, it will give a vague answer. If you request "something about customer retention", the model will produce general paragraphs that could apply to any business in any industry. This result does not indicate that the model is unhelpful. The model is following your instructions, which lacked specific details.

Prompt engineering is the process of turning a general request into a specific instruction that a model can follow. This involves defining the task, the intended audience, and the criteria for a successful response. It also requires organising prompts with roles, context, and constraints. Effective techniques include using chain-of-thought reasoning and providing few-shot examples. Changes to a prompt should be tested individually to measure their impact.

Prompt engineering is the process of turning a vague request into an instruction that a model can follow accurately. It is a title for a task that consists of writing clearly according to a specific set of rules.

At Shipshape Data, we build data and AI systems for our clients. We have observed that the difference between teams that get consistent value from AI and those that do not is how they approach prompting. Successful teams treat prompts as formal briefs rather than temporary questions.

This guide explains the factors that affect output quality. It covers how to define a task, how to structure instructions to remove ambiguity, the specific patterns you should learn, and the correct way to test a prompt. You do not need to buy a subscription to a marketplace or attend a course to learn these skills; you only need to be specific.

The definition of prompt engineering

Prompt engineering is the process of designing inputs for a large language model to ensure the output meets your requirements consistently. You provide the instructions, and the model follows them literally based only on the information included in the prompt. If you omit specific details, the model will make its own assumptions, which often do not align with your intended results. A more detailed definition of this process is available in what prompt engineering is.

No specific phrases will guarantee a better response, despite claims made on social media. The difference between an effective prompt and an ineffective one is the same as the difference between a good and bad creative brief. The model must understand what you want, who the audience is, and what criteria define a successful result.

Why the gap matters more than teams expect

Most AI implementations fail for a simple reason. The problem is not the model or the infrastructure, but the instructions people provide. A support chatbot might use an inappropriate tone. A summarising tool might omit a critical detail. An automation might function technically but produce results that users do not trust enough to use without supervision. These issues occur because the prompts assume the model will understand context in the same way a human colleague does.

If you write effective prompts, you will see practical benefits. You will spend less time correcting drafts, and fewer people will stop using the tool to do the work manually because "the AI version needs too much fixing," which improves performance for your existing systems.

The origins of the confidence gap

Teams that struggle with their results often describe a particular kind of failure. The generated content may be correct, yet it remains generic. It appears plausible and is on topic, but it does not assist with the task. This occurs because the prompt gave a subject rather than a precise task. "Write about our product" yields filler text. "Write three subject lines for re-engaging customers who have not logged in for 60 days, using our current tone, under 45 characters each" produces usable content.

Same model. Different instruction.

Start with the task

The most effective approach in prompt engineering is to describe the exact output you need instead of the topic you wish to discuss. Most people do not do this, leading to poor initial results.

Describe the result rather than the topic

"Tell me about customer retention" represents a broad topic. It lets the model explore an entire field without guidance on what information to omit. By contrast, "write three email subject lines that encourage inactive customers to re-engage with our software platform." gives specific instructions. This version defines the desired format (subject lines), the required number (three), the objective (re-engagement), and the target group (inactive customers). Each extra detail reduces the chance that the model will produce irrelevant results.

Answer these questions for yourself before writing the prompt:

• The output should take the form of an email, a list, code, or an analysis, depending on what the prompt requests.
• Who reads or uses this output, and for what?
• How much detail or technical depth is required?
• Does the output have to meet specific requirements for length, tone, or content?

If you cannot answer two or three of those questions before you start typing, you are not ready to write the prompt. You are still defining your requirements, and the model cannot make those decisions for you.

We performed this comparison with a client's marketing team last year. Their initial prompt for a product update email was a single line: "write an announcement for our new feature." The result was generic and missing distinguishing details. We revised the prompt to: "write a 150-word email announcing our new bulk-export feature to existing customers who have asked for it before, in a direct tone with no exclamation marks, ending with a single link to the docs." Using the same model and feature, the team could send the second version without any manual edits.

Feed it context before you ask for anything

Context stops the model from giving generic or unoriginal responses. If you request marketing copy without specifying the industry, audience, or tone, the output will be vague because that version applies to every possible scenario. When you provide details about your industry, your readers, your brand voice, and your specific constraints, the model limits its possible answers to those that are actually useful.

A prompt without context does not create a clear error. Rather, it yields a generic answer drawn from general data, which rarely satisfies a user's particular needs.

To achieve this, you need to declare your identity or the role the model must assume. You should also specify the intended audience, enumerate any relevant technical or business rules, and clarify the particular problem the output must address. Including these statements makes the first draft usable instead of needing a full rewrite.

Provide the instruction in a specific format

When a prompt is written as one long paragraph, the model must determine which parts are most important. If you arrange your prompt in a consistent structure, the model will process it in line with your intentions. This format also helps you spot missing information before submitting the request.

Assign a role

Telling a model to act as a specific role, a data analyst, a customer success manager, a technical writer, does real work before you have written a single instruction. It activates a set of behavioural and stylistic defaults tied to that role, so you aren't left specifying every convention by hand. A basic role-based shape looks like this:

You are a [specific role] with expertise in [relevant area].
Your task is to [specific action] that [specific outcome].
The output should [format and requirements].

Filled in for a real case:

You are a customer success manager at a B2B software company.
Your task is to write a response email to a client who reported
slow performance issues. The output should acknowledge their concern,
explain our investigation process, and set expectations for resolution
within 48 hours. Use a professional but warm tone.

This serves as a simple brief. It is written in the same style you would use to guide a new employee in their first week. This method works because it limits the information left to chance, which is why clear instructions are effective for people.

Break complex prompts into labelled sections

When a task has more than two or three requirements, a single paragraph becomes hard for you or the model to read. You should instead split the text into labelled sections.

Role: who the model should act as
Task: what you need created
Context: background information
Format: output structure
Constraints: limitations or requirements
Examples: sample outputs, if helpful

These labels are not merely decorative. Writing them assists you in spotting empty sections. An empty section often corresponds to the part that would have made the output fail.

Apply constraints to limit the output

Constraints prevent a model from producing something that is technically correct but practically useless. Word count, tone, reading level, required sections, items to exclude: the more of these you specify up front, the less time you will need to revise later. Say "under 200 words, no jargon, one call to action" instead of hoping the model infers your preferences from the rest of the prompt. It will not. It has no memory of your last five conversations with your editor.

Useful patterns to keep in mind

Beyond the basic structure, several specific patterns tackle problems that simple instructions do not solve well. You will not need every pattern for each task, but each is useful for particular types of work.

Chain-of-thought prompting for anything with steps

When a task needs multiple steps of logic, maths, or trade-off evaluation, you can lower errors by telling the model to show its work before giving a final answer. This method works because it forces the model to process intermediate steps rather than instantly producing a likely conclusion. You can find more detailed templates in our full breakdown of chain-of-thought prompting. The basic approach is to add a single line to your prompt:

Task: [your request]
Instructions: Before giving your final answer, think through this
step by step and show your reasoning.

Use this for calculations, multi-step logic, or any task where you would check a junior colleague's work before trusting the result.

Few-shot examples when showing beats describing

Some formats are easier to demonstrate than to explain. Give the model two or three examples of the transformation you desire. Then supply your actual input. The model will follow the pattern more accurately than if you wrote the rules in text. Use this method when your output needs a specific structure, a particular tone, or a change that is hard to describe.

Here are examples of the output I need:

Example 1:
Input: [sample input]
Output: [desired output]

Example 2:
Input: [sample input]
Output: [desired output]

Now complete this:
Input: [your actual input]
Output:

Formatting control for anything downstream

If you need output for a spreadsheet, a database, or another script, you should describe the required structure and supply a schema. You can request JSON, a specific markdown layout, or a CSV with named columns to avoid manual reformatting. This is especially useful when you run the same prompt many times each week.

Return your response in the following JSON structure:
{
  "summary": "brief overview",
  "key_points": ["point 1", "point 2", "point 3"],
  "recommendation": "actionable next step"
}

Test it properly

Your first prompt is rarely the best version, and that is acceptable. The main skill in prompt engineering is using a method to spot specific errors and fix them, rather than trying to write a perfect instruction on the first try.

Write down what you tried

Maintain a basic log of the prompt, the output, a quality rating, and the specific errors, such as a generic tone or missing sections. Note the adjustments you made for the next attempt. This process may seem like extra work, but after two weeks you will likely notice recurring failure patterns across various tasks. This information will show exactly how the model reacts to your specific instructions.

Modify only one element at a time

If you change the role, context, and constraints in one revision and the output improves, you will not know which specific change caused the improvement. You should change one element at a time, run the prompt, and compare it to the previous version. This process takes more time at first but is faster over a month. It prevents you from repeating the same mistakes on each new task.

The variables that most affect results, in approximate order, are the specificity of the role definition, the amount of context provided, how strictly the output is limited, the requested format, and whether an example is included. Most teams find that context and constraints are more important than using sophisticated wording.

Retain the effective ones

Store prompts that work well in a location your team can access later. Organise them by use case, customer communications, internal reporting, and code review, allowing the next person to use a proven starting point. Creating a prompt library is easy to set up and eliminates a surprising amount of repeated, wasted effort.

How this relates to the overall context

Prompt engineering serves as an effective starting point, and many teams adopt it as their entire artificial intelligence strategy. They concentrate on enhancing prompts to achieve better results. Nevertheless, this approach has limits. When a model uses your company data, which is becoming the standard use case, refining a prompt cannot make up for outdated records or missing context. It also cannot repair data warehouses that have been neglected since a migration three years ago. We see this frequently with our clients. Usually the prompt is not the primary issue; the underlying data is the problem.

At Shipshape Data, we create the data foundations needed to make AI systems reliable. Our goal is to avoid the common situation where a project works well as a demo but later gets abandoned. We collaborated with a client whose support-summary prompt worked correctly during testing but failed in production. The failure happened because many tickets needed order data from a system that had not been integrated.

Prompts cannot resolve a missing underlying connection. Prompt engineering enhances the usefulness of a strong foundation. It is not a substitute for a foundation.

Where to start

Select one task your team spends a lot of time on, such as responding to customers, creating weekly reports, or writing code review comments, and apply the structure from this guide to it: role, task, context, format, and constraints. Test the new structure carefully. Make only one change at a time. Retain the version that works best and share it with the next person who needs to perform the same task. If you automate this task, use the same careful approach, but remember that the structure must work reliably without supervision.

You can locate a more detailed checklist in our 13 prompt engineering best practices after you understand the basics. The key elements are specificity, structure, and consistent testing. If you would like an assessment of whether your current data setup can support your intended project, talk to us.

Beyond the reading stage and ready to build? Our AI development team delivers systems like this on governed data, scoped to production from day one.

Frequently asked questions