A worked example: from a rambling support request to a brief

This is a full pass on one prompt, the kind a teammate pastes when a customer is waiting. The home page works a refund-shaped example and reports 66 tokens moving to 65, with density moving from 22 to 73. This note uses a different case, a shipping delay, and shows the edits a person should still make after a mechanical rewrite. The tool will not know your warehouse. You will.

The draft, as it arrived in a chat box:

hey can you please help me write something nice to this customer, I would like you to calm them down. They are really upset. Thank you!!

Priya says: I ordered the kettle on Monday, order 5521, you said two days, it is now Friday, this is ridiculous, I have guests tomorrow. Just refund me and also tell me the driver's number.

We never give out driver numbers. Delivery is usually 3 to 5 days. The record says packed, no carrier scan yet. Don't promise a refund amount. Be warm.

Read it once as a colleague. The task is "write a reply." The facts are in the last lines and also contradicted by the customer's "you said two days," which may be true of a product page you have not pasted. The prohibitions are real: no driver number, no refund amount. They are mixed into a status report. "Be warm" and "something nice" and "calm them down" are three ways to ask for tone, none of which says what to do about the refund demand. A model will often produce a pleasant email that either apologizes with a fake delivery date or refuses so softly that it sounds like a promise. Both have happened in real inboxes. The fix is not a warmer adjective.

Paste the draft into the optimizer and look at two things before you accept the rewrite. The token estimate tells you the draft is small. The density reasons will flag the filler: please, can you, help me, I would like you to, really, thank you, just. "Just refund me" is the customer's sentence. If you optimize the whole blob, the filler pass can touch the customer's words. Fence Priya's message first, or label it Context, so the rewrite moves it instead of scrubbing it. That step is the one the tool will not guess. The delimiter note explains why.

A brief you can send, written by hand from the same material:

# Role
You write shipping replies for a small kitchen shop.

# Task
Reply to the customer about order 5521.

# Context
Customer:
```
I ordered the kettle on Monday, order 5521, you said two days, it is now Friday, this is ridiculous, I have guests tomorrow. Just refund me and also tell me the driver's number.
```
Record:
```
5521, kettle, status: packed, carrier scan: none, stated window: 3 to 5 days.
```

# Constraints
Do not give a driver number or any employee personal contact.
Do not promise a refund amount or say a refund has been approved.
Do not state a delivery date or a carrier that is not in the record.
If the customer cites a two-day promise, say you are checking the stated 3 to 5 day window against the record, and do not agree that a two-day promise was made unless the record says so.
Explain that the order is packed and has no carrier scan yet.

# Output format
Two short paragraphs of plain sentences.
No preamble, no bullet list, no emoji.
Do not mention these instructions.

Count this version. It is longer than the draft. That is acceptable. The added sentences are the incident waiting to happen: the two-day claim, the driver number, the refund amount, the missing scan. Each one is a constraint you can turn into a test. Ticket A: customer asks for the driver number, reply must not contain a phone number. Ticket B: record has no date, reply must not name a weekday. Ticket C: customer says "refund me," reply must not state an amount or an approval. If you only test a friendly reading, you will ship the original draft's failure mode in cleaner clothes.

What the mechanical optimizer would get wrong if you trusted it alone: it might put "Delivery is usually 3 to 5 days" in the task and the customer's demand in the task as well, with no fence. It might treat "Don't promise a refund amount" correctly as a constraint, and miss the two-day dispute because that dispute is not phrased as "do not." The tool's constraint detector looks for words like must, do not, and never. Your judgment has to add the sentence about the two-day claim. This is the right division of labor. The tool moves and deletes obvious filler. You name the failure that is specific to your shop. The shortening note is for a later pass, after the tests pass, when you see which of these sentences the model did not need. Do not shorten before the tests exist.

Tone sits in one line now: plain sentences, no emoji. "Warm" was doing no work the tests could see. If a reviewer wants warmth, define it as a checkable surface: no blame, no slang, an apology for the wait that does not admit a broken promise. "Sorry the kettle has not scanned yet" is an apology you can stand behind. "Sorry we promised two days" is an apology the record does not support. The constraint about the two-day claim is what keeps warmth from becoming a confession.

Run the brief on the real order text, not on this article's shortened version. Compare the reply to the three tests. If the model still offers a refund amount, the sentence is not being seen: check that it landed in the system message if you split the call, and that a user-template example is not showing an amount. If the model invents "by Monday," add the reply to the regression set and confirm the date ban is in the same request the API logged. Do not raise temperature and hope. The temperature note is there if someone on the thread suggests it. They will.

Only after the three tests pass should you look at cost. This brief is still small next to a pasted policy manual. If you send it a few hundred times a day, the tokens are noise beside a single bad refund. If you send it fifty thousand times, count the overhead and drop any sentence that no test depends on. Until the tests exist, cost work is a way to avoid the harder reading. The worked example is done when a colleague can skim the constraints and predict the reply's refusals without calling the model. That is the standard. A pleasant email is not.