Cheat Sheet: Prompt Engineering

A dense revision pass on prompt engineering for Amazon Bedrock: what each technique buys you, when to reach for it, and where the tempting wrong answer lives.

Techniques at a glance

Decision rules

• If the task is simple and common, then zero-shot; do not spend tokens on examples.
• If the format keeps drifting, then few-shot with 2 to 5 tight examples.
• If reasoning has multiple steps, then chain-of-thought; expect more tokens and latency.
• If the task is trivial, then skip chain-of-thought; it wastes tokens for no gain.
• If the model must use tools, then ReAct: reason, act, observe, repeat.
• If you need machine-readable output, then tool or function calling, not JSON asked for in prose.
• If you asked for JSON in prose and parsing fails, then move to function calling.
• If role, tone, or rules must persist, then put them in the system prompt.
• If user content sits beside instructions, then wrap it in delimiters.
• If the same prompt runs many times with inputs, then build a template.
• If a prompt change needs rollback or audit, then version it in Bedrock Prompt Management.
• If output must be deterministic, then temperature 0 and a low top-p.
• If output should be varied or creative, then raise temperature and top-p.
• If responses get truncated, then raise max tokens.
• If safety or compliance is required, then add Guardrails; a system prompt alone is not enough.
• If a prompt injection slips through delimiters, then rely on Guardrails and least privilege, not the fence.

Traps

• Treating a system prompt as a security boundary. It steers behaviour; it does not enforce it. Pair it with Guardrails.
• Treating delimiters as a full defence against prompt injection. They help the model separate data from instructions, but they are not a hard boundary.
• Asking for JSON in prose and assuming it always parses. It is unreliable; tool or function calling enforces the schema.
• Adding chain-of-thought to trivial tasks. It burns tokens and adds latency with no accuracy gain.
• Piling in more few-shot examples to fix a reasoning gap. Examples fix format, not multi-step logic; use chain-of-thought.
• Cranking temperature to fix wrong answers. Temperature changes variety, not correctness.
• Setting temperature and top-p both high and expecting stable output. Combined randomness widens the spread.
• Confusing top-k and top-p. Top-k caps the candidate count; top-p caps cumulative probability mass.
• Forgetting max tokens covers output, so truncation looks like a model fault.
• Hardcoding prompts in application code instead of managing and versioning them.
• Expecting ReAct without any tools defined. No tools means nothing to act on.
• Putting untrusted user text directly next to instructions with no delimiters.

Say it in one line

1. Zero-shot gives instructions only; few-shot adds a handful of examples to shape output.
2. Few-shot fixes format and edge cases, not multi-step reasoning.
3. Chain-of-thought helps layered problems and wastes tokens on trivial ones.
4. ReAct interleaves reasoning and tool calls: reason, act, observe, repeat.
5. Tool or function calling enforces structured output against a schema.
6. JSON requested in prose is unreliable and can fail to parse.
7. System prompts set role, tone, and standing constraints across turns.
8. A system prompt is a control, not a security boundary; pair it with Guardrails.
9. Delimiters separate instructions from untrusted data and add a partial, not full, security boundary.
10. Prompt templates make a prompt reusable across varying inputs.
11. Bedrock Prompt Management versions prompts for testing, rollback, and audit.
12. Temperature and top-p control randomness; top-k caps candidate tokens; max tokens caps output length.
13. Low temperature and top-p for deterministic tasks; raise both for creative ones.
14. Guardrails enforce safety and compliance that prompts alone cannot.