prompt-engineering.siExample 1: summarize without inventing commitments
Before: “Summarize this meeting.” A readable summary can still be operationally wrong if it turns proposals into commitments. Give the model a distinction to preserve.
Summarize the supplied meeting notes for people who missed the meeting. Return: decisions made, action items, open questions. Only label an item a decision if the notes record agreement. Only assign an owner or due date when explicitly stated. Use “not specified” otherwise. Include a short source excerpt for each action. Notes: [paste notes]
Check: supply notes saying “Perhaps Mira could review it.” The result should not list Mira as a confirmed owner. This single counterexample tests whether the distinction matters in practice.
Example 2: compare options without fake precision
Before: “Which vendor is best?” The model has no agreed definition of best. A weighted table can look rigorous while hiding invented weights.
Compare vendors A and B using the evidence below. Criteria: integration effort, support coverage, data export, and total first-year cost. Create a table with evidence, uncertainty, and practical consequence for each criterion. Do not invent missing prices or scores. Finish with a provisional recommendation and the one missing fact most likely to change it. Evidence: [paste verified vendor information]
Check: remove one vendor’s support details. Does the response acknowledge a gap, or does it silently fill the cell? A gap is useful information for the buyer.
Example 3: improve writing while preserving meaning
Before: “Make this more professional.” That request may produce longer sentences and vague confidence. Specify the reader’s action and protected facts.
Edit this message so a customer can understand the delay and the next step. Preserve all dates, amounts, and commitments exactly. Use plain language and an accountable tone. Do not promise a resolution date that the original does not give. Return the revised message, then a short list of any ambiguity that needs human confirmation. Message: [paste draft]
Check: compare every number and commitment with the source. The revised text should not change “aim to respond” into “will resolve.” Stronger wording can accidentally create a new promise.
Example 4: make missing data explicit
Before: “Extract the customer details as JSON.” That leaves field names, types, and unknown values undefined.
Extract exactly these fields from the text: customer_name, order_id, requested_action. Return one JSON object, with each value a string or null. Use null when the text does not explicitly provide a value. Do not infer identity from a signature fragment. Return no commentary outside the JSON. Text: [paste text]
Check: parse the result as JSON, then verify that it contains exactly the specified fields. Valid syntax does not prove that the values came from the source.
Choose the smallest change that addresses the failure
Use a format requirement for inconsistent structure, an evidence rule for invented facts, a contrasting example for a boundary error, and a clear audience for mismatched explanation depth. Adding all possible instructions can create contradictions and obscure the task.
Keep a copy of the original prompt. If the revision fixes an edge case but makes normal cases worse, you need that baseline to see the trade-off. The template library provides starting points; the builder turns your requirements into a reusable brief.