Add constraints and examples

Start with constraints that protect correctness and use:

1. Evidence: Which sources may the answer use? What should happen when information is absent?
2. Scope: What belongs in the answer, and what is out of scope?
3. Audience: What can the reader reasonably know?
4. Output: Which fields, sections, length, or order are required?
5. Action: What should the reader decide or do?
6. Safety: Which private data, claims, or autonomous actions are prohibited?
7. Style: Which voice and wording preferences matter?

Resolve conflicts explicitly. For example: “Accuracy outranks brevity. Stay under 150 words unless a necessary safety warning requires more.” Priority rules help when requirements compete.

“Brief” is subjective. “No more than six bullets” is observable. “Use simple language” becomes “write for a reader with no finance background and define APR on first use.” “Use sources” becomes “attach a source and date to every market-size figure; omit figures without support.”

Testability does not require turning all writing into numbers. A tone can be described with behavioral signals: “acknowledge the delay once, avoid blame, state the next action directly, and do not use exclamation marks.”

Examples are valuable when format, classification, or voice must repeat. Provide a representative input and desired output. Highlight the feature to imitate:

Example input: “Mina to confirm inventory sometime next week.”
Desired action item: “Confirm inventory — Owner: Mina — Due: TBD.”
Rule shown: do not convert vague timing into an invented date.

One clear example can outperform a paragraph of abstract instructions. Several varied examples are better for a reusable process, especially when they show boundary cases.

A counterexample shows what to avoid and why:

Avoid: “Mina will confirm inventory by Tuesday.” The source says only “next week,” so Tuesday is unsupported.

Always pair a bad example with the correct behavior. Otherwise, the prompt may repeat the undesirable language. Do not include sensitive real records merely to demonstrate a pattern; create a fictional or redacted example.

Models may imitate incidental details. If every example uses three bullets, the assistant may infer that three is required. If every sample customer has an English name, coverage may narrow. Vary irrelevant features while holding the intended pattern stable.

Examples can also become stale. A template based on an old policy may keep producing compliant-looking but outdated text. Date and review reusable examples, and separate policy facts from writing patterns.

If the first output misses tone, first add a positive tone description. If that remains inconsistent, add a short example. If the format keeps drifting, provide a skeleton with labeled fields. Move toward more concrete guidance only as needed; this keeps the prompt understandable and adaptable.

A useful revision might say:

Revise using only the notes. Output exactly four sections: Decision, Evidence, Actions, Open Questions. Each action needs action, owner, and due date. Use TBD for missing fields. Match the concise style of the example, but do not copy its names or facts.

Before reusing it, scan for contradictory limits, duplicated rules, hidden private data, obsolete examples, and requirements that cannot be checked. Ask a colleague to interpret it without seeing your intent. If two reasonable readers understand it differently, clarify the specification.