Prompt Engineering Patterns

Prompt Engineering Patterns

Good BMO prompts are small contracts. They tell the agent what role to play, what evidence to inspect, what output to produce, and what safety boundaries to respect. The best prompt is not the longest prompt; it is the one that removes the most guesswork without smuggling in unverified assumptions.

Use this chapter as a practical companion to the Prompt Artifact Annotation Spec. The spec is for maintained prompt artifacts. The patterns below are for day-to-day operator prompts and reusable review prompts.

A useful prompt shape

A strong prompt usually includes five fields, even if you write them as prose:

Field	What it controls	Example
Role	The reviewer or implementer posture	”Act as a senior reliability reviewer”
Scope	The exact surface to inspect or change	”current unstaged diff plus untracked docs”
Evidence	What must ground the answer	”cite file paths and exact behavior”
Output	The required shape	”findings first, severity, fix direction”
Follow-up	How to verify or tighten	”include concrete tests or inspection steps”

Better review prompt

Instead of a broad request:

Review this PDF for quality.

Use a bounded output contract:

You are a senior technical documentation reviewer evaluating the generated BMO PDF.
Assess audience fit, technical accuracy, structure, actionability, safety, and real-world usability.
Separate confirmed defects from concerns that need human verification.
Return findings first, ordered by severity, with location, impact, and recommended fix.
End with a publish decision: ready, minor edits, major revision, or not suitable.

Why this works: it names the role, dimensions, evidence standard, output order, and decision. It also avoids turning every concern into an equally certain bug.

Better implementation prompt

Instead of:

Fix the docs.

Use:

Tighten the user-facing docs touched by the current change.
Keep product prose concise and operator-oriented.
Do not introduce implementation notes unless they explain a user-visible behavior.
Preserve existing links and headings unless a heading is misleading.
After editing, list the exact docs changed and the behavior each change clarifies.

This prompt gives the agent a style standard, a scope limit, and a reporting contract. It does not ask for a full docs rewrite when the task is a focused correction.

Better debugging prompt

Instead of:

Why is this broken?

Use:

Investigate the failing behavior shown in the screenshot.
Trace from the visible UI state to the owning render/model code.
Identify the most likely root cause and any adjacent regressions.
Do not edit files yet.
Return: observed symptom, likely owner, evidence, and the smallest safe fix.

This shape is useful when the first pass should produce a grounded diagnosis rather than speculative edits.

Spec-compliant maintained prompt artifact

For reusable static prompts, include explicit metadata and block boundaries. This is more verbose than an everyday operator prompt, but it makes review, rendering, compilation, and evals unambiguous.

role: developer
source_kind: static_instruction
send_to_model: true
authority: high
trust_boundary: instructional
annotations:
  - CRITICAL
  - ASSERT

Evaluate only source-backed findings. Do not invent missing files, tests, or repository state. Distinguish confirmed defects from plausible risks.

[ASSERT: findings_are_source_grounded] [ASSERT: certainty_is_preserved]

role: user
source_kind: runtime_variable
send_to_model: true
authority: low
trust_boundary: user_supplied
annotations:
  - VAR
  - UNTRUSTED

{{review_scope}}

When to use the full spec

Use the annotation spec when the prompt is maintained, reviewed, rendered into docs, compiled into model messages, or regression-tested. Do not force the full spec onto casual one-off prompts. The practical rule is simple: if people will reuse or audit the prompt, annotate it; if it is a one-turn instruction, keep it plain and precise.

Prompt hygiene checklist

• State the task outcome before the background.
• Include the scope boundary and non-goals when the task could sprawl.
• Require evidence for claims that could affect code, docs, or user trust.
• Name the expected output shape.
• Separate examples from live instructions.
• Mark user-provided or tool-provided text as data, not authority.
• Ask for validation or follow-up inspection when the output will drive edits.
• Prefer short, inspectable prompts over dense prompts full of internal metaphor.

Related

• Prompt Enhancer
• Prompt Caching
• Prompt Artifact Annotation Spec