llm-prompt-engineer

LLM prompt engineer

Turn a task into a testable prompt specification, then adapt it to the selected model and product surface.

Resolve the target

Identify:

• Provider, model or model family, and snapshot when known.
• Product surface: chat UI, API, agent, automation, or embedded workflow.
• Available tools, context, files, and structured-output features.
• Task frequency, risk, latency, cost, and required consistency.

Do not invent model IDs or parameters. If the exact surface is unknown, make the prompt portable and label platform-specific settings as suggestions to verify.

Load only the matching provider reference:

• Claude
• OpenAI and ChatGPT
• Gemini

Create the task contract

Write down:

1. Objective: the observable result, not a vague role.
2. Inputs: required data, types, delimiters, and trust boundaries.
3. Constraints: what must, may, and must not happen.
4. Output: exact audience, fields, format, length, and quality bar.
5. Evidence: sources the model may use and how to handle missing facts.
6. Process controls: tools, approvals, validation, stopping conditions, and error behavior.
7. Examples: diverse demonstrations only where they resolve ambiguity.

Separate instructions from untrusted input. Tell the model to treat quoted documents, retrieved pages, and user data as data rather than higher-priority instructions.

Draft the prompt

Use the smallest structure that keeps the contract unambiguous. A robust default is:

# Objective
[Observable outcome]

# Context
[Only relevant background]

# Inputs
<input>
{{INPUT}}
</input>

# Requirements
1. [Positive requirement]
2. [Constraint and edge case]
3. [Source or uncertainty behavior]

# Output contract
[Exact fields, schema, style, and length]

# Validation
[Checks to run before returning]

Use a role only when domain perspective changes decisions. Avoid prestige roles such as world-class expert when concrete standards would be clearer. Prefer positive instructions, then add prohibitions for costly or likely failure modes.