Building a checkable prompt

A useful prompt translates a task card into understandable instructions, but it does not guarantee correct execution. Begin with the action: extract, compare or summarize. Define what falls outside the task. Provide necessary context with its source and separate data from instructions. Headings and delimiters improve readability; they are not technical authorization barriers. A sentence inside a customer's message must not expand the system's function.

Define an output contract: the result's structure and the meaning of each field. A maintenance request may require a device type, a fault description and missing information. State whether each field is text or a list, what represents missing information, and whether extra fields are allowed. The contract can use natural language or a data schema. If downstream software expects null, which is not an empty string, a sentence such as “I do not know the type” is not technically equivalent. Check structural compatibility before using the result, then check meaning. Successful parsing does not establish factual correctness.

Add examples when they resolve genuine ambiguity. An example pairs an input with an output to illustrate a rule; its details should not be copied into every subsequent case. Choose an ordinary case and an important boundary, such as a message naming two devices when the task requires one. Do not include real names or identifiers the task does not need. If an example contradicts the instructions, repair the contradiction rather than expecting the model to discover an unstated intention.

Handle missing information according to its consequences. If the next step depends on identifying the device, request clarification. If an independent part can be completed, return that supported part and state what remains unknown. Neither reject every incomplete task nor prioritize filled fields over truth. When sources conflict, show the competing values and their sources or follow an approved precedence rule. Do not treat a value as newer merely because it appears later in the text.

Read the prompt as a new operator would. Is the task clear without earlier conversation? Are field names consistent? Does an example introduce an unstated constraint? Try incomplete input and input containing instruction-like wording, then compare the result with the contract. Record the prompt version. A small change to a field definition can alter outputs; do not conceal the difference by silently changing the expected answer.