Some messages you only get to send once — a reorg note, a piece of hard feedback, an org-change announcement. Send it cold and you over-promise, leak a name, or sound either robotic or falsely upbeat. This system gives you a careful first draft: honest about the hard part, kind without being saccharine, free of promises you can't keep, with [placeholders] for the details only you can confirm — a shape you own and read word-for-word before it goes anywhere near send.
- What's actually happening and what's genuinely decided versus still open — be honest with yourself here, because the message can only be as clear as your own clarity.
- Who it's for, the relationship, and the one thing they most need to know — and what you can NOT yet say (legally, or because it isn't decided).
- Your real constraints: what you can promise, what you can't, and any details (dates, names, numbers) that must stay as placeholders until confirmed.
-
Brief Claude on the situation and the guardrails — including what NOT to say
Sensitive messages go wrong by saying too much, not too little. Set the guardrails before any drafting: what's confirmed, what's off-limits, and that nobody gets named — so the draft starts inside the lines.
you askI need to write a sensitive [reorg / feedback / org-change] message. Here's the situation: [brief]. Before drafting, read it back to me: who this is for, the one thing they most need to know, what is actually decided vs still open, and what I must NOT say or promise yet. Keep all individual names out — use roles or [placeholders]. Don't write the message yet.what you get back A short read-back — audience, the core message, decided-vs-open, and an explicit "won't say" list — that catches a wrong assumption now, before it's wrapped in three careful paragraphs.
The 'read it back to me first' move matters most here: confirm Claude has the situation right before it writes a word, because the cost of a wrong sensitive message is high.
-
Draft for honest and kind — not upbeat
Ask for the hard balance explicitly. The failure modes are corporate-cold and falsely cheerful; name both so the draft is direct about the difficulty and still human.
you askNow draft the message: honest about the hard part, kind and respectful, plain English, no corporate euphemism and no false cheer. Don't over-promise — where I can't commit, say what we can and can't say yet. Lead with the thing they most need to know. Keep it short. Use [placeholders] for any date, name, or number I still have to confirm.what you get back A tight draft that names the hard thing directly, stays warm without sugarcoating, makes no promise you flagged as off-limits, and carries visible
[placeholders]exactly where you still owe a confirmed detail. -
Pressure-test how it will land
Before you touch a word, have Claude read it as the recipient. The gap between what you meant and what they'll hear is where sensitive messages do damage.
you askRead this back as the person receiving it. What's the first feeling it creates? What question will they immediately have that the message doesn't answer? Where might it sound like a promise I didn't mean to make, or where am I burying the real point? Flag anything that could read as cold, evasive, or over-promising.what you get back A recipient's-eye read — "opens warm but the 'what happens to my role' question is unanswered until paragraph 3", "'we'll take care of everyone' reads as a guarantee" — pointing you at the exact lines to fix.
This is the step that prevents the 11pm rewrite after it's already sent. Spend the time here, not in the reply thread.
-
Tighten, then leave it ready for your word-for-word read
Do a final pass on the flagged lines, then deliberately stop — the draft is a shape you own, and the last act is always a human reading every word before send.
you askTighten the lines you flagged: answer the immediate question earlier, soften nothing that should stay honest, and remove any accidental promise. Give me the final draft with every [placeholder] clearly marked, and a one-line checklist of what I personally need to confirm before sending.what you get back A clean final draft with the flagged issues fixed,
[placeholders]clearly marked, and a short confirm-before-send checklist — ready for you to read aloud, fill in, and own.Read every word yourself, out loud if you can. Claude gives you a shape; you own what actually ships and what it promises.
- Hard 1:1 feedback: keep it private and specific — ask for the observation, the impact, and the ask, with
[placeholders]for concrete examples only you witnessed. Never let a named third party's complaint go in verbatim. - Org-wide announcement: add a short anticipated-questions list and a clear next step ("[date] all-hands, questions to [channel]"), so the message answers the obvious follow-ups instead of spawning a hundred DMs. When the message is part of a reorg or rollout, Run an org change without losing the room orchestrates the sequencing, manager pack, and FAQ around the craft you build here.
- Arabic or bilingual messages: a sensitive message is exactly where machine translation fails — tone, formality, and what's deliberately left unsaid carry the weight, and they don't survive a round-trip through English. Draft it natively in Arabic and adapt the register; a tone-deaf translation of a layoff or reorg note does more damage than the news itself. Have a fluent person read it word-for-word, the same way you would the English.
- Reuse the structure, never the content (Power Track): save the brief → draft → pressure-test flow as a
/sensitivecustom command (see the Playbook's Capabilities tab), but rewrite the specifics every time — these messages should never feel templated to the person reading them. Custom commands are the opt-in Power Track — on Desktop you keep the flow as a saved note and run it fresh for each message.
- Keep individual names, performance details, and anything confidential OUT of the prompt — use roles and
[placeholders]. The draft only needs the shape of the message, not the private facts behind it, and people data goes only in tools your company has approved. - Claude has no idea what's actually decided or legally safe to say. It will happily write a confident promise you can't keep — you are the one who knows the real constraints, so verify every commitment in the draft against what's truly agreed.
- Claude drafts; you own and send. A human reads every word, fills every placeholder with a confirmed fact, and takes responsibility for how it lands — for the hardest messages, a second trusted person (HR partner, manager, counsel) reads it before it goes out.
you'll end up with A sensitive message you can stand behind — honest about the hard part, kind without over-promising, names kept out and details left as placeholders — pressure-tested for how it lands and ready for the word-for-word read that only you can do.
Questions people ask
- What do I need to prepare before starting?
- You need clarity on what is actually decided versus still open, who the message is for and what they most need to know, and your real constraints — what you can promise, what you cannot, and any details that must stay as placeholders until confirmed. The draft can only be as clear as your own clarity going in.
- Should individual names or performance details go into the prompt?
- No. Use roles and `[placeholders]` instead of real names, and keep performance details and anything confidential out of the prompt entirely. The draft only needs the shape of the message, not the private facts behind it — people data goes only into tools your company has approved.
- Can I reuse the same draft structure for different sensitive messages?
- You can reuse the flow — brief → draft → pressure-test → tighten — saved as a `/sensitive` custom command. But rewrite the specifics every time. These messages should never feel templated to the person reading them; the structure is reusable, the content is not.
- What if Claude writes a promise I can't actually keep?
- Claude has no visibility into what's truly decided or legally safe. It will confidently draft commitments you haven't approved. That is exactly why every placeholder must be filled with a confirmed fact before the message sends, and why the tighten step explicitly removes any accidental promise the pressure-test flagged.