Prompt engineering: define a task that can be checked

Write the contract

An incident commander needs a summary of 47 alert events for an on-call handoff. Give the model the event list, a five-bullet output limit, the audience, and the instruction to mark uncertain causes as uncertain. Require each proposed action to name the event that supports it. Do not ask for a confident root cause when the log contains only correlated timing. If the task will modify code, name the repository area, forbidden changes, and the test that demonstrates success. The model can suggest a path; the operator still checks it against the system.

Task: Draft an on-call handoff from the 47 attached alert events.
Audience: The next shift, familiar with the payment service.
Output: Five bullets: impact, timeline, current state, open questions, next actions.
Constraints: Do not invent a root cause or include customer identifiers.
Evidence: Tie every action to an event ID; label missing evidence.
Success check: An operator can locate every stated event and run the listed checks.

Cost and verification

More context consumes tokens and can increase latency and review time. Adding unrelated material may also obscure the relevant evidence. Start with the smallest complete input, then add a missing log or policy only when the first result shows a real gap. Review factual claims against the supplied events, not fluency. For recurring tasks, save the contract and a few expected outputs so a later wording change can be tested.

Common Mistakes

• Do not use an adjective such as better as the sole success criterion.
• Do not ask the model to infer missing records as facts.
• Do not put private identifiers into a prompt merely to make it concrete.

Connected lessons

• Prompt Engineering
• Prompt context: separate instructions from retrieved material
• Prompt evaluation: test failures before rewriting the wording
• ChatGPT / Codex: Write a prompt you can verify

Apply this next

• Prompt intent: turn an open request into an acceptance check
• Prompt inputs: normalize records before asking for conclusions
• Project: evaluate an incident handoff prompt

Next decision

Check whether the right facts reached the workflow and whether the result is safe at its destination.

• Prompting, retrieval, or training: choose the failing layer
• Numeric prompts: let code calculate and the model explain

Apply the boundary

Use the artifact's source and destination to decide what must be checked before the result is accepted.

• Coding prompts: name the files, behavior, and proof

Continue with: Zero-shot baseline: measure the task before adding demonstrations.

Continue with: Document prompts: define the reader's decision before drafting.

Continue with: Architecture prompts: start with constraints and an owner.

Continue with: Recurring prompts: define the trigger and stop condition.