Prompt engineering turns an intention into a task the model can execute and the system can test. Small changes in wording or generation settings can shift output quality because an LLM samples from a probability distribution rather than following a fixed program.

In production, the prompt is part of the system interface. It needs explicit behavior, version control, and evaluation like any other executable contract. This hub covers the basic mechanics. Its child notes handle in-context learning, reasoning, prompt composition, and automated optimization in more depth.

Prompt Anatomy

Four elements cover most prompt contracts:

• Instruction names the exact task.
• Context supplies domain facts or constraints.
• Input data contains the material to process now.
• Output indicator defines the required answer shape.

The following prompt uses all four:

Instruction: Extract security risks from the incident note.
Context: You are helping a SOC analyst. Keep findings actionable and concise.
Input data: "API keys were stored in plain text logs for 3 days in staging."
Output indicator: Return JSON with fields risk, impact, mitigation.

Each element removes a different ambiguity. The instruction narrows behavior, context guides interpretation, input anchors the current case, and the output indicator constrains the result.

LLM Settings

Prompt text describes the task. Generation settings control sampling and output limits.

• Temperature raises or lowers sampling randomness.
• Top-p restricts candidate tokens to a cumulative probability mass. Lower values narrow the set.
• Max tokens caps generated length and therefore limits part of the cost and latency.
• Stop sequences terminate output when the model emits a specified string.

These starting ranges are heuristics. Production values need task-specific evaluation on the chosen model.

A simple starting policy is to tune temperature first and leave top-p near its default until an evaluation shows that both need adjustment.

Instruction Prompting

Instruction prompting states the task and result format directly. It works when the requested behavior is specific enough to observe and test.

A useful instruction usually contains:

• A task verb such as classify, extract, summarize, or transform.
• An explicit format such as a JSON schema, table columns, or a fixed label set.
• Relevant constraints on length, forbidden content, confidence, or tone.

Example 1 (name normalization):

Convert the person name to this format: <Last name>, <First name>.
If suffix exists, keep it after first name.
Input: "Nikita Reshetnik"
Output:

Example 2 (PII redaction):

Redact all personal data from the email.
Replace names with [NAME], phones with [PHONE], and emails with [EMAIL].
Return only redacted text.
Input: "Hi John, call me at 410-805-2345."

When outputs drift, tightening the output indicator is usually cheaper than adding another prompting technique.

Role Prompting

Role prompting supplies a perspective that changes style, depth, or framing. The role modifies task execution. It does not replace the task.

• It fits tasks where voice or audience matters.
• Accuracy boundaries still need to be explicit.
• Concrete roles work better than vague personas.

Illustrative contrast:

Standard: Write a review of this pizza place.
Role-based: You are a food critic writing for a city newspaper. Write a review of this pizza place in 120-150 words, focusing on crust texture, sauce balance, and service.

The second version gives the model a concrete perspective and observable review criteria. The role alone would not provide those constraints.

Choosing a Technique

This flow is a useful first pass:

flowchart TD
    A[Start with task goal] --> B{Simple direct task}
    B -->|Yes| C[Use instruction or zero shot]
    B -->|No| D{Need strict output shape}
    D -->|Yes| E[Use structured output or schema; add examples for semantics]
    D -->|No| F{Needs deeper reasoning}
    F -->|Yes| G[Use reasoning scaffolding plus verification]
    F -->|No| H{Multiple dependent steps}
    H -->|Yes| I[Use prompt chaining]
    H -->|No| J[Use role plus instruction]
    C --> K[Evaluate and iterate]
    E --> K
    G --> K
    I --> K
    J --> K

Strict output shape needs structured output or schema validation. Examples can clarify semantics that the schema cannot express. A task that cannot fit one instruction may need Prompt Composition. In both cases, representative evaluation matters more than eliciting hidden reasoning traces; meta prompting is only one way to generate candidate instructions.

Pitfalls

• Indirect prompt injection from retrieved content. A document, web page, or tool result may contain malicious instructions that the model mistakes for trusted guidance. Keep trusted instructions separate from untrusted data, restrict tools by policy, and validate outputs.
• Correct shape, wrong content. JSON can pass schema validation while carrying invented values. Add semantic checks for ranges, required relationships, and source-grounded claims.
• Token budget collapse. Long context and verbose generations can crowd out critical instructions or examples. Control the input and output budgets together, then monitor truncation rather than assuming the model saw everything.

Questions

Why must prompt structure and model settings be designed together?

The prompt defines the task, context, constraints, and expected output, while model settings control sampling and output limits. Clear instructions can still produce unstable results when sampling is too random for the task. Conservative settings cannot repair an ambiguous instruction or a missing output contract. Both parts should be tested together on the same task-specific evaluation set because changing either one can change quality, consistency, latency, and cost.

When is few-shot prompting a better fit than pure instruction prompting?

Few-shot prompting is useful when the expected meaning, label boundary, or output convention is easier to demonstrate than to describe. A small set of representative examples can show how close cases should be handled and make repeated outputs more consistent. Examples do not replace a schema when the shape must be strict. Start with the smallest set that improves held-out results, then add edge cases only when evaluation shows a real gap because every example consumes context.

How can an accurate but verbose and expensive prompt be tightened?

First identify whether the cost comes from repeated instructions, unnecessary examples, oversized context, or a verbose output contract. Remove duplicated input and state the required length and shape directly. max_tokens is a safety cap rather than the main way to request a concise answer because a low cap can truncate a valid response; stop sequences help only when the output has a reliable delimiter. Compare token usage, task quality, and truncation or failure rates after each change so a cheaper prompt does not quietly become less accurate.

References

• Prompt Engineering Guide
• OpenAI Prompt Engineering Guide
• Anthropic Prompt Engineering Overview