Prompt Engineering: A Practical Guide

Prompt engineering is the practice of designing input interfaces for large language models. It translates human goals, business context, and output requirements into instructions a model can execute consistently, then uses tests to verify the results.

A useful prompt usually contains a task, context, constraints, examples, and an output format. Production use adds version control, evaluation datasets, failure handling, and safety boundaries. Together, these parts determine whether a model can produce acceptable results across different inputs.

What is prompt engineering?

A large language model receives a context and predicts the most suitable continuation. Prompt engineering organizes that context so the model has the information required to complete a task.

From a software engineering perspective, a prompt resembles a function interface:

type InstructionInput = {
  instruction: string;
  context: string;
  constraints: string[];
  examples?: Array<{ input: string; output: string }>;
  outputSchema: object;
};

type ModelOutput = {
  result: unknown;
  evidence?: string[];
  confidence?: number;
};

instruction defines the task, context supplies knowledge, constraints set boundaries, examples demonstrate a pattern, and outputSchema establishes the contract between the model and downstream software.

Prompt engineering commonly covers four areas:

1. Design: convert an ambiguous request into explicit instructions.
2. Orchestration: divide complex work and coordinate model, retrieval, and tool calls.
3. Evaluation: measure accuracy, format compliance, and consistency with representative samples.
4. Maintenance: version prompts, models, and parameters, then run regression tests.

Why does prompt engineering exist?

Natural language often omits assumptions. People fill those gaps through shared experience, while a model infers them from the current context. A request such as “analyze this” could mean finding a root cause, extracting a summary, comparing options, or generating an action plan.

Large language models are probabilistic. Changes to the model, sampling parameters, or input can change the result. Prompt engineering keeps that variation within acceptable limits by clarifying the goal, narrowing the search space, and defining acceptance criteria.

It addresses three recurring engineering problems:

Prompt quality therefore depends on executability and verifiability. Plain language works well when the essential fields are complete.

What problems does it solve?

Aligning the task with its purpose

“Summarize this incident report” leaves the intended use unclear. An on-call engineer needs a timeline and mitigations, management needs impact and risk, and the development team needs a root cause and repair plan. Defining the reader and purpose helps the model choose the right information density and structure.

Supplying required context

Internal documents, live databases, and the current page must reach the model through context or tools. A prompt can carry that material directly or receive content from a retrieval system. Once the model has a factual boundary, its answer can cite evidence from the input.

Fixing the output contract

When software consumes the result, the output format becomes an interface protocol. JSON Schema, enumerated values, and required fields reduce parsing failures and make field-level validation possible.

{
  "type": "object",
  "required": ["severity", "summary", "evidence", "actions"],
  "properties": {
    "severity": { "enum": ["SEV-1", "SEV-2", "SEV-3"] },
    "summary": { "type": "string" },
    "evidence": {
      "type": "array",
      "items": { "type": "string" }
    },
    "actions": {
      "type": "array",
      "items": { "type": "string" }
    }
  }
}

Dividing complex tasks

A complex task works better as several verifiable stages. A technology assessment, for example, can be divided into requirement extraction, candidate screening, evidence review, risk analysis, and recommendation. Each stage has a clear input and output, which makes failures easier to locate.

Creating repeatable quality standards

The prompt, model version, parameters, and evaluation set form a reproducible experiment. A team can compare accuracy, latency, cost, and format compliance across two versions before selecting one.

Who uses it, and where?

Individuals can use prompts to improve a single conversation. Development teams working with recurring tasks, programmatic calls, and shared workflows add templates, version control, and automated evaluation.

Recurring execution, downstream software, and costly errors all justify treating prompts as engineering interfaces. A one-off exploration can begin with a short instruction and gain context or constraints as failures reveal missing information.

How to design a prompt

Analyze the most likely cause of increased latency in the orders API.

The result is for the on-call developer deciding whether to roll back the latest service deployment.
Return an event timeline, three root-cause hypotheses ranked by evidence strength, and a validation method for each hypothesis.

## Environment
- Service: orders-api v3.18.0
- Region: ap-southeast-1
- Database: MySQL 8.0
- Time range: 2023-12-14 09:00–11:00

## Observations
<metrics>
{{METRICS}}
</metrics>

## Deployment log
<deployments>
{{DEPLOYMENT_LOG}}
</deployments>

- Cite at least one item of input evidence for every root-cause hypothesis.
- Mark every inference as "needs_verification".
- Use information from <metrics> and <deployments>.
- Put missing data in the missing_information array.

Input: CPU remains stable. Database connection-pool usage rises from 42% to 97% after deployment.
Output:
{
  "hypothesis": "database connection-pool exhaustion",
  "evidence": ["connection-pool usage rose from 42% to 97% after deployment"],
  "status": "needs_verification"
}

Return JSON that follows the supplied schema.

Before responding, check:
1. Every required field exists.
2. Every hypothesis has evidence.
3. Information absent from the input appears in missing_information.
4. severity uses a value from the schema enum.

A complete example

## Role
You are an SRE specializing in Java services and MySQL performance.

## Objective
Determine whether the 09:42 service deployment caused the increase in orders-api latency, then recommend whether to roll it back.

## Context
<metrics>
{{METRICS}}
</metrics>

<deployments>
{{DEPLOYMENT_LOG}}
</deployments>

## Rules
- Build a minute-by-minute event timeline.
- Cite evidence for every conclusion.
- Mark each inference as needs_verification.
- Put missing data in missing_information.

## Output
Return JSON that follows incident-output.schema.json.

## Sense Check
Before responding, verify field completeness, chronological order, and evidence references.

This template contains a role, objective, context, rules, output contract, and quality check. These six fields provide a useful starting point for most technical tasks.

Common prompt frameworks and structures

Prompt frameworks are mnemonic templates for essential fields. Four structures cover a broad range of tasks: RTF for short tasks, STAR for analytical flow, CO-STAR for communication, and RODES for technical work with explicit quality checks.

RTF: a compact structure

RTF stands for Role, Task, and Format. It suits summaries, rewriting, classification, and format conversion.

Role: You are a TypeScript test engineer.
Task: Generate unit tests for the parseDuration function, covering normal values, boundaries, and invalid inputs.
Format: Return Vitest code and add one sentence describing the intent of each test group.

RTF is short and inexpensive to maintain. Tasks involving private knowledge, multiple steps, or strict quality criteria can add Context, Examples, and Check fields.

STAR: organizing an analysis

STAR stands for Situation, Task, Action, and Result. It comes from structured case presentation and also works well for incident reviews, problem analysis, and scenario planning.

Situation: After a service change, orders API P95 latency rises from 180 ms to 1.4 s.
Task: Determine the relationship between the change and the latency increase.
Action: Align deployment, traffic, GC, connection-pool, and slow-query timelines, then test hypotheses by evidence strength.
Result: Return the root cause, evidence, immediate mitigation, and long-term repair plan.

STAR preserves the causal chain from context through action to result, which helps technical tasks explain their analytical basis.

CO-STAR: controlling communication

CO-STAR stands for Context, Objective, Style, Tone, Audience, and Response. The framework was demonstrated systematically during Singapore’s 2023 GPT-4 prompt engineering competition. It suits technical articles, product explanations, and communication for a defined audience.

Context: The readers understand REST APIs and are learning event-driven architecture for the first time.
Objective: Explain the benefits and risks of migrating an order system from synchronous calls to an event-driven design.
Style: Technical blog post with an architecture example and failure scenarios.
Tone: Clear, restrained, and evidence-based.
Audience: Backend engineers with two years of experience.
Response: 1,200 words with an architecture flow, migration steps, risk table, and checklist.

Style, Tone, and Audience adapt the same technical material to different readers.

RODES: adding examples and a quality check

RODES stands for Role, Objective, Details, Examples, and Sense Check. It suits code review, technical research, and tasks that require a final review.

Role: You are a Node.js platform architect.
Objective: Evaluate three job-queue libraries and recommend one for production use.
Details: Compare throughput, retries, idempotency, observability, maintenance status, and migration cost.
Examples: Structure each conclusion as "choice / evidence / risk / validation".
Sense Check: Verify that every conclusion has a source and that versions and benchmark environments are explicit.

RODES puts examples and a final check directly into the structure, making it useful for technical tasks that require consistent output.

How to choose a framework

Clarify the goal, input material, main risk, and output consumer. Then choose the smallest structure that covers those requirements.

Structures can be combined. For example, use STAR to organize an incident’s causal chain, then use RODES to add constraints, reference examples, and a final check.

After choosing a structure, check three questions:

1. Does the primary failure risk come from missing knowledge, execution steps, or output format?
2. Which fields support programmatic validation?
3. Which inputs belong in a regression evaluation set?

How to evaluate prompts

Prompt evaluation fixes the model, parameters, prompt version, and test data. A single successful output verifies one sample, while an evaluation set measures overall quality.

Build an evaluation set

An evaluation set should represent the major types of production traffic:

• Normal inputs verify the main task.
• Boundary inputs cover empty values, long text, and extreme numbers.
• Ambiguous inputs verify that the model marks missing information.
• Adversarial inputs test whether instructions inside external material interfere with system rules.
• Historical failures protect previous fixes from regression.

Each case should contain an input, expected characteristics, and scoring rules. Classification tasks can store reference labels, while open-ended tasks can use a rubric.

Choose metrics

Deterministic checks suit structured tasks. Open-ended tasks can combine rules, model-based scoring, and human sampling. A model-based grader needs its own validation and a human-labeled calibration set.

Compare versions

Change one main variable in each experiment, such as prompt wording, examples, model version, or sampling parameters.

experiment: incident-analysis-v4
baseline_prompt: v3.2.0
candidate_prompt: v4.0.0
model: model-version-id
temperature: 0
dataset: incident-eval-2023-12
metrics:
  - schema_pass_rate
  - evidence_coverage
  - root_cause_accuracy
  - p95_latency_ms
  - average_cost

A candidate version should meet predefined quality, safety, latency, and cost criteria. Add newly discovered failure cases to the evaluation set.

Set acceptance criteria

A technical analysis prompt could use criteria like these:

Schema pass rate          >= 99.5%
Evidence coverage         >= 95%
Root-cause accuracy       >= 90%
Prompt-injection defense  >= 99%
P95 latency               <= 4s
Average cost per call     <= $0.02

Set concrete values from business risk and baseline results. High-risk use cases also require access control, human approval, audit logs, and deterministic validation.

Practical checklist

• The task, reader, and success criteria are explicit.
• Context includes sources, time ranges, and required terminology.
• Instructions and external data use clear delimiters.
• Constraints support programmatic or human checks.
• The output format matches its downstream consumer.
• Examples cover normal cases and critical boundaries.
• Missing information and inferences have explicit labels.
• Prompt, model, and parameter versions are recorded.
• The evaluation set contains real and historical failure samples.
• Acceptance criteria cover quality, performance, cost, and safety.

The main result of prompt engineering is a maintainable model interface: explicit requirements, bounded input, contracted output, and measurable quality.

References

1. Brown et al., Language Models are Few-Shot Learners, 2020.
2. Wei et al., Chain-of-Thought Prompting Elicits Reasoning in Large Language Models, 2022.
3. Yao et al., ReAct: Synergizing Reasoning and Acting in Language Models, 2022.
4. White et al., A Prompt Pattern Catalog to Enhance Prompt Engineering with ChatGPT, 2023.
5. Sheila Teo, How I Won Singapore’s GPT-4 Prompt Engineering Competition, 2023.
6. Twisted Brackets, Riding the Wave of Effective AI Prompt Crafting, 2023.