Rewrite one technical update for three workplace readers
The engineering notes are accurate and nobody outside engineering will read them. Three shorter versions help, as long as the executive one doesn't end up the most confident of the lot.
What you'll make
three short versions of one technical update, each written for its reader, plus a list of the facts that must read the same in all three.
What you'll need
the current technical notes, the question each reader is really asking, ChatGPT, Claude, Copilot or Gemini in your work account, and about 15 minutes.
Example result.
Must stay identical in every version:
- 3 of 5 integrations moved to v2 and passed in test; 2 not started.
- Cutover proposed for 10 March, only if the load test passes. Load test not booked.
- The provider retires v1 on 31 March.1. Name each reader’s real question
Write one line per reader: who they are and what they need to know. “Finance: does this change what we pay or commit to?” is more useful than “Finance: make it about money”. If the notes don’t answer a reader’s question, that version should say so, not invent a paragraph to look tailored.
Why this works: a question gives the model something to answer. A job title gives it a stereotype to write to.
What you should see: three readers, three questions, each answerable (or honestly unanswerable) from the notes.
2. Ask for three versions and the facts that must not change
Paste the notes, or attach them with + in ChatGPT or Claude, the paperclip in Copilot Chat or Add files in Gemini.
Rewrite these technical notes for three readers: [reader A and their
question], [reader B and their question], [reader C and their question].
Keep every status, condition, date and gap exactly as the notes state
it. Change emphasis and explanation only. If the notes don't answer a
reader's question, say "not in the notes". Do not turn a test result
into a release, a proposal into a commitment or a partial check into a
complete one. Give three short versions, then a list of the facts that
must read the same in all three.Each bracket is one reader and the question from step 1.
Why this works: asking for the invariant list makes the model state what it is preserving, which you can then check.
What you should see: three versions of four to six sentences, and a short “must stay identical” list like the example result.
3. Read the versions side by side
Check the invariant list against the notes first, then read each version for its reader. Is the next decision or question clear? Then read all three together: a different tone shouldn’t hide a different status.
Why this works: each version can look fine alone. Contradictions only show when they sit next to each other.
What you should see: the same facts in all three, in different order and depth.
Check the result
- Every fact on the invariant list matches what the notes say.
- Each version keeps the conditions (“only if”, “proposed”, “not started”).
- A question the notes can’t answer says “not in the notes”.
- No version is more certain than the notes.
The usual failure: the shortest version becomes the most certain. Compressing for an executive drops “only if” and “2 not started”, and “proposed” quietly becomes “on track”. Spot it by underlining every condition in the notes and finding it in each version.
The [reader] version says [overstated claim], but the notes say
[what they say]. Restore that condition and keep the useful emphasis
for this reader. Check the same claim in the other two versions. Do
not add a cost, cause or delivery promise to make it sound complete.[reader] is the version with the problem; [overstated claim] is its wording; [what they say] is the notes’ wording.
Worked example: a payments API migration
Fictional example. An engineering lead pasted these notes:
- Payment provider retires its v1 API on 31 March.
- Charges, payouts and webhooks moved to v2 and passed in the test environment.
- Refunds and disputes: not started.
- Cutover proposed for 10 March if a load test passes. Load test not yet booked.
- Notes say nothing about any change to provider fees.The first executive version: “The v2 migration is on track for 10 March, ahead of the 31 March deadline.”
- The failure. “On track” drops the two integrations not started and the unbooked load test. The executive version had become the most confident one.
- The repair. The repair prompt, with “on track for 10 March”, gave: “Three of five integrations have moved and passed testing; refunds and disputes haven’t started. A 10 March cutover depends on a load test that isn’t booked yet. v1 stops working on 31 March, so the decision needed is when to book the load test.”
- The finance version got it right. “No change to what we pay is mentioned in the notes. The fixed date is 31 March, when v1 stops.” The engineering version gave the refunds and disputes work and the load-test dependency in detail. Same facts, three depths.
Task kit for this job: Download (ZIP) · Reusable instructions
Go deeper
Keep the decision request as asked
If the notes ask for approval of a test, don’t let a version ask for approval of the release. If no decision is requested, say so, or ask the notes’ owner what they need. Tailoring should make the real request clearer, not bigger. For telling facts from forecasts in the notes themselves, see separate facts, risks and predictions.
Use a timeline that keeps status visible
A small timeline can show done, in progress and proposed items as three different marks. Avoid putting every date on one confident line. Label each item with its status in words as well as colour.
Save the readers, not this week's facts
If you send the same three-reader update every fortnight, save the reader questions and the “keep every condition” rule as a reusable brief, and paste fresh notes each time. Save useful spreadsheet questions shows the same pattern for recurring analysis.