message-drafting

name	message-drafting
description	Message drafting rules for emails, Slack, WhatsApp. Use when drafting messages on user's behalf, sending emails to company team, composing internal communications, or any message composition task. Covers draft review workflow, post-send disposition, company email addressing (role vs person), internal email format, and bilingual copypasta.
user-invocable	false

Message Drafting Rules

Core Workflow

🚨 Verify Before Asking Others (MANDATORY)

Before drafting ANY message that asks someone a question, exhaust self-service options first:

1. Check the codebase — grep/read source code in repos you have access to
2. Check docs/knowledge bases — CLAUDE.md, skills, CompanyProject_AI_KNOWLEDGE, READMEs
3. Check APIs/data — CRM, Gmail history, Sheets, rclone, any queryable source
4. Check logs/config — server logs, env files, admin panels

Only include questions you genuinely cannot answer from available resources. Every answerable question you send wastes the recipient's attention and erodes PA credibility.

Before finalizing any draft, audit each question: "Could I find this myself?" If yes — remove it, state the finding instead. The email should contain only the residual unknowns after self-service research.

• Authorized to draft messages in user's name (email, Slack, etc.)
• Default: ASK FIRST - show draft, wait for approval before sending
• Draft review: After drafting, tell user exactly how to review (e.g., "Draft is in Gmail compose window - check tab X" or "I'll paste the draft below for your review")
• Keep drafts visible/accessible - don't close windows or navigate away before user confirms

Copypasta Delivery (MANDATORY)

🚨 NEVER paste copypasta directly in the terminal. TUI output inserts extra whitespace when user copies, corrupting the message.

Delivery method (user will copy-paste manually):

1. Write draft to a temp .txt file (e.g., $env:TEMP/draft-<context>.txt)
2. Open it in the default text editor (start "" "path")
3. Tell user it's open for clean copy.

This applies to: WhatsApp drafts, message templates, any text the user will manually copy-paste into another app.

When PA sends via MCP (no manual copy-paste):

• Show draft inline in terminal for user review — no temp file, no editor
• The temp file exists to avoid TUI whitespace corruption during copy. If PA sends programmatically (Gmail MCP, Slack MCP), that corruption doesn't apply — user just needs to read and approve, not copy.

Exception: Short one-liners (< 2 lines) can stay in terminal — whitespace corruption is negligible.

External Communication Tone

🚨 Directive tone is for internal/subordinate messages ONLY. When drafting messages to external contacts, partners, guests, or their staff (EAs, assistants):

• Informational, not directive — state facts, don't give instructions. "The session takes 1.5-3 hours" NOT "please block 3 hours."
• Don't tell professionals how to do their job — an EA knows to block calendar time. A CEO knows to check their schedule. Provide the information, let them act on it.
• Explain the WHY behind asks — "good to have buffer to respect the chance of technical difficulties" > "good to have buffer." Context shows respect and professionalism.
• Give ranges, not just maximums — "1.5-3 hours" is more useful for scheduling than "3 hours." Ranges let the recipient plan realistically.

Don't Reopen Closed Topics

🚨 If someone approved something, don't invite them to reconsider.

• If guest/partner said "looks good" or "approved" → topic is closed. Don't add "feel free to suggest changes" or "happy to adjust" in follow-up messages about OTHER topics.
• Proactively re-raising an approved item signals uncertainty and can reopen a settled discussion unnecessarily.
• Exception: If PA spots a genuine issue with the approved content, flag it. But paraphrasing "might tweak" when someone said "assume the questions are good to go" = misread.

Post-Send Disposition (MANDATORY — Poka-Yoke)

🚨 Every sent email MUST be archived or snoozed. Never leave in inbox. NO EXCEPTIONS.

Before sending, the caller MUST explicitly declare disposition. This is a REQUIRED parameter, not optional:

• "disposition: archive" — thread is closed/fire-and-forget
• "disposition: snooze [date]" — expect a response or need to verify follow-through

🚨 Poka-yoke enforcement: When delegating email sends to gmail-agent or composing via MCP, the prompt/instruction MUST include an explicit disposition: declaration. If the caller (parent agent, PA, or any invoker) does not specify disposition, the gmail-agent MUST ask before sending — never default to "just send and leave in inbox." If PA is sending directly (not via agent), PA must declare disposition in its own response before calling send.

There are exactly two options: archive or snooze. "Neither" is not an option. "I'll handle it later" is not an option.

Immediately after sending, execute the disposition:

• Archive: gmail_modify → remove INBOX label
• Snooze: gmail_modify → remove INBOX label + add to schedule.yaml deferred section (Gmail snooze unavailable via MCP)
• Never skip this step. If send succeeds but disposition fails, retry disposition. Report both send and disposition status to user.

🚨 After sending, ALWAYS provide direct link to the posted message (Slack, email thread, LinkedIn post, etc.) so user can verify/access it directly.

Auto-Send Exception

Trivial internal confirmations to company team — e.g., "Done, secrets are set" after completing a task they requested. No draft review needed for obvious task-completion acks.

Company Email Addressing (Role vs Person)

• User says a role (e.g., "send to financial manager") → use the role email (e.g., [e-mail]). Lookup from Roles sheet.
• User says a person (e.g., "send to TEAM_MEMBER") → use the person's personal @your-company.com email. Lookup from Roles sheet. If personal email isn't in the Roles sheet, search Gmail (from:<firstname>@your-company.com OR from:<firstname.lastname>@your-company.com) to find it. Don't ask user — figure it out.
• Each company team member has their own personal domain email in addition to any role emails they hold. These are different addresses — don't conflate them.

Send-From Address Selection (MANDATORY)

New emails to company team (@your-company.com recipients)

🚨 Always send from [e-mail] — not [e-mail]. CEO-to-team emails come from the role address. Personal Gmail is for non-company correspondence only.

Replies

🚨 When replying to an email, ALWAYS reply from the same address the original was sent TO.

Before composing any reply:

1. Check the To: / Delivered-To: header of the incoming email
2. Set the From: / send-as address to match that recipient address
3. If the email was sent to [e-mail], reply FROM [e-mail] — not from [e-mail]
4. If send-as alias isn't configured for that address, flag to user: "This was sent to X but I can only send from Y. Proceed from Y or set up alias first?"

Why: Replying from a different address breaks support cases, confuses recipients, and can get rejected by ticketing systems (e.g., LinkedIn support incident 260209-021351).

Sent Email Corrections (MANDATORY)

🚨 NEVER resend or correct a sent email without user approval.

Once an email is sent, the recipient has it. Archiving on our end does NOT undo delivery. Rules:

1. Wrong thread / wrong content / wrong address discovered after send: Report the problem to user. Do NOT auto-resend a corrected version — that creates duplicates for the recipient.
2. User decides: They may say "resend corrected," "leave it," or "I'll handle it manually." PA waits.
3. Never assume archiving fixes a misfired email — archiving is local cleanup, not a recall.
4. If user approves a correction resend: Acknowledge in the corrected email that it's a resend (e.g., "Resending — previous email went to wrong thread, please disregard").

Why: Duplicate emails confuse recipients, look unprofessional, and can't be unsent. The blast radius of a correction can be worse than the original mistake.

Delegation Emails — Self-Sustaining Threads

SSoT for delegation pattern: ~/.claude/skills/delegation/SKILL.md. Read it. This section adds email-specific rules on top.

When the email being composed asks someone to do something (fix a bug, provide credentials, debug an issue, review a PR — anything with a deliverable), it is a delegation email and MUST include:

1. Definition of Done (in the email body)

Explicit, measurable conditions. The recipient should know exactly when they're done. Not "please look into this" — instead: "Done when: (1) bot responds to messages in chat X, (2) root cause identified, (3) creds sent via WhatsApp."

2. Callback Instructions (in the email body)

Tell the recipient what to reply with upon completion. This makes the thread self-sustaining — no external tracking needed.

When done, reply to this thread with:
- [Result/deliverable]
- [Any follow-up info needed]

My next step after your reply: [what requester will do]

Why "my next step": When the reply lands, whoever reads the thread (user or Claude Code PA) can immediately execute the next action without digging through external trackers. The thread carries its own memory.

3. Thread Self-Sustainability Principle

The goal: anyone reading just this email thread can reconstruct the full context and next actions. No Google Tasks entry, no separate Trello card, no "I'll remember to follow up." The thread IS the tracker.

This means:

• DoD is in the thread (what "done" looks like)
• Callback is in the thread (what to reply with)
• Next action is in the thread (what happens after reply)
• If the recipient forgets to include the callback, Claude Code PA can reconstruct it by reading the thread history

When NOT to force delegation structure

• Fire-and-forget informational emails ("FYI, trunk-based CI/CD is now live")
• Trivial ack emails ("Done, secrets are set")
• Emails where no action is expected from the recipient

Only apply when there's a deliverable you're waiting for.

Proportionality rule (routine tasks)

Full DoD + callback is for complex/ambiguous tasks. For routine tasks where the recipient knows their job:

• Skip callback entirely — don't ask for confirmation emails back. Operator submits, done. Only request callbacks when there's unreliability concern or caller explicitly wants tracking.
• DoD is optional or ultra-casual — "Submit in Slack" not a numbered checklist. If the task is their daily job, they know what "done" looks like.
• Judgment call: Would the recipient read the DoD and think "no shit"? Then cut it. DoD exists to remove ambiguity, not to patronize.

Internal Emails (to company team, @your-company.com)

• Remove pre-filled signature - select all in compose body, delete, then type draft
• First line: Hey <Name>, USER's ClaudeCode here.
• Then the actual message content
• No signature needed (it's clearly from PA)
• Attach relevant evidence: If user has screenshots, chat logs, or examples that illustrate the issue - ask user to attach them or offer to attach if available. Concrete examples > abstract descriptions.
• Include reference links: When the email references a task, card, doc, sheet, or any trackable item — include the URL in the email body. Recipients should have one-click access to the source, never have to search for it.
• FMR (For My Reference) links: When a link is for USER's reference only (not for the recipient to act on), tag it FMR: at the bottom of the message. Signals it's context for USER, not an ask.

Conciseness First (Internal Messages — MANDATORY)

🚨 Minimize noise in both directions. Team members are busy. Every sentence they have to read costs attention.

• Task-completion replies: Just say "Done." — no implementation details, no recap of what changed. They reported a problem, we fixed it, end of story.
• Only include details the recipient needs to act on. If they don't need to change behavior or make a decision based on what changed, don't explain what changed.
• Ask yourself: "Does the recipient care about this, or am I just showing my work?" If the latter, cut it.
• Details on request only. If they ask "what did you change?" — then explain.

Examples:

Situation	Reply
Bug report, we fixed it	"Done."
Credentials request, we set them	"Done."
Fix requires THEIR action to verify	"Fixed, please verify [specific thing]."
They asked a question	Answer the question. Nothing more.

Cross-Reference: Communication Style Corrections

When drafting replies to employees who exhibit communication anti-patterns (obvious questions, vague updates, missing context), cross-reference comm-style-corrections skill for the anti-pattern library and correction templates. Apply the correction inline in the reply — don't just answer, also teach. Especially relevant: "Kitbag questions" anti-pattern (asking things you could answer yourself).

Neutral Tone for Data-Gap Pings

When pinging employees about missing info, unanswered questions, or data gaps needed for calculations (salary, metrics, etc.):

• Focus on the gap, not the consequence — "Need your input on X to close out January numbers" NOT "Salary calculation is blocked waiting on you"
• Never mention salary/payment as leverage — it reads as a threat, not a question
• Frame as closing a loop — "Which is correct?" / "Was this published?" — neutral, factual

Directive Tone (Internal Messages)

🚨 Tell, don't ask. When communicating decisions or instructions to employees/team members:

• Give directives — state what needs to happen, not what "could" happen
• Never offer to discuss — if the decision is made, it's not a consultation
• No trailing questions — "Want to discuss?" / "Should this be a separate ticket?" / "What do you think?" are prohibited when the message conveys a decision
• Subordinates execute, they don't get vote — PA drafts messages that reflect the CEO's authority, not a peer collaboration

Bad: "The API should pull from the DB. Want to discuss the migration approach, or should this be a separate ticket?" Good: "The API should pull from the DB. Migrate the pricing data from the Sheet to the website database."