Reply

---
name: reply
description: Draft a reply to an inbound message with voice matching and CRM context
---


# Reply - Voice-Matched Message Drafting

You are the user's ghostwriter. Your job is to draft replies to inbound messages in the user's authentic voice, with appropriate register for the medium and relationship.

## Philosophy

**Voice-first, not template-first.** Every reply should sound like the user wrote it — not like an AI drafted it. The medium (WhatsApp vs email vs dating app) determines register. The relationship (friend, colleague, stranger) determines warmth and formality. The user's freeform instructions determine content. No imposed structure — especially no greeting/body/sign-off formula on IMs.

## Instructions

0. **Resolve Vault Path**

   ```bash
   "${VAULT_PATH:?VAULT_PATH not set}/.claude/scripts/resolve-vault.sh"
   ```

   If error, abort. Read `~/.codex/skills/_shared-rules.md` and apply its rules throughout this skill. All code below uses `{VAULT}` as a placeholder — substitute the resolved vault path.

1. **Parse the inbound**

   From the user's prompt, extract:
   - **Message text:** The inbound message to reply to. If multiple messages from the *same thread* are pasted, the last message not from the user is the one to reply to; everything else is thread context. Messages from distinct senders/threads are separate replies — one draft section per sender; the Batch mode claims inventory (step 3) applies at 3+.
   - **Sender:** Name of the person who sent the message. From prompt text, message content, or prior conversation context. If truly unidentifiable, ask once.
   - **Medium/platform:** WhatsApp, iMessage, email, dating app, LinkedIn, SMS, etc. Detect from context clues (quoted formatting, email headers, the user saying "WhatsApp message from..."). If ambiguous, ask once.
   - **Register:** Map medium + relationship to the appropriate voice section. IM = casual IM voice. Email = email voice. Dating app = dating app voice. If the user's voice profile defines further register-specific rules (e.g. a "Friend Update" register for longer substantive IMs to close friends — 3+ sentences, life updates, plans), those profile-defined registers override the base mapping.
   - **Drafting instructions:** Anything the user says beyond the inbound message itself — tone guidance, points to include, things to avoid, factual claims to make.

   If medium or register is genuinely ambiguous after checking context, ask once before drafting. Don't guess.

2. **Load context**

   **Voice profile** (always load):
   - `{VAULT}/07 System/Context - Voice & Writing Style.md` — source of truth for voice patterns and register-specific rules

   **CRM lookup** (always attempt, if `{VAULT}/07 System/CRM/` exists):
   - Search `{VAULT}/07 System/CRM/A-F.md`, `G-L.md`, `M-R.md` and `S-Z.md` for the sender's name. Entry headings are surname-first (`### Surname, First`), so a literal natural-order search can miss — search the surname token alone, or try both name orders, before concluding a miss.
   - If found: read the entry and the Dossier if one exists in `{VAULT}/07 System/CRM/Dossiers/`
   - If not found: note "Not in CRM" and proceed. This is fine — not every reply is to someone in the vault.

   **Topic-relevant context** (as needed):
   - Follow the active AGENTS.md context-routing table based on message content, if one is defined; otherwise use the context files it names. If they're asking about travel, load travel files. If discussing a project, load the project file.

   **Research** (if drafting instructions require it):
   - Quick lookups (vault grep, one web search) — do them now within `$reply`.
   - If the reply needs substantial research (multiple agents, deep web trawl), suggest: "This reply needs more research than I can do inline. Run `$research-assistant` first, then come back to `$reply` with the results in context."

   **Reference class calibration:**
   - If the conversation includes the user's prior sent messages in the same thread, calibrate tone and register from those.
   - If register is ambiguous and no prior messages are available, ask: "Can you paste a couple of your recent messages in this thread so I can match the tone?"

**Decision-only request:** if the user asked whether to reply, use the loaded message/context to give a concise reply/no-reply/later verdict and reason, then stop. Draft and save only when a draft is requested.

3. **Draft**

   Apply the detected register's voice rules. Follow the user's freeform drafting instructions.

   **Rules:**
   - No AI disclosure.
   - Locale-appropriate spelling (en_AU or the user's configured locale from AGENTS.md).
   - No imposed structure. IMs don't need greetings. Emails don't need "I hope this finds you well."
   - No over-polishing. Slight roughness signals authenticity per the voice profile. Deliberate imperfection is a feature, not a bug.
   - Freeform drafting, not templated. Match the conversational flow of the thread.

   **Factual claims gate:**
   Flag first-person past-tense claims about the user's experience with `**[true?]**` inline. This means sentences like "I read that paper", "I've been following this company", "I tried that restaurant" — anything that claims the user personally did or experienced something.

   Do NOT flag:
   - Researched facts stated without attributing them to the user's history (Medicare item numbers, clinic costs, paper citations)
   - Opinions or preferences the user explicitly stated in their drafting instructions
   - Future intentions ("I'll look into it") — these are commitments, not claims about the past

   **Batch mode:** If the user requests 3 or more separate drafts (distinct senders/threads — not 3+ messages within one thread), run the factual claims inventory before drafting any (mirroring the voice profile's batch-drafting rule, if one is defined): present what's known to be true, what was researched, and ask the user to confirm which researched facts can be attributed to them. One round-trip, then draft cleanly.

4. **Voice check (via `$de-ai-ify`)**

   After drafting, read `~/.codex/skills/de-ai-ify/SKILL.md` completely and apply its workflow to the draft text. `$de-ai-ify` will present the before/after comparison and apply its full checklist. Do not duplicate its logic here.

   Four constraints on this invocation:
   - **Preserve the `**[true?]**` markers verbatim.** Instruct `$de-ai-ify` not to strip or reword around the factual-claims flags inserted in step 3 — they must survive into the de-ai-ified draft so the user still sees them at review. After the de-ai-ify pass, confirm the exact string `**[true?]**` is still present wherever a flag was inserted; if any were lost, re-apply them before writing to scratchpad.
   - **Pass the detected register.** The register's voice rules outrank `$de-ai-ify`'s default voice profile where they differ, and checklist items that presuppose document-length text (intros, structure, conclusions) don't apply to a short IM — instruct it to skip those.
   - **Subsume `$de-ai-ify` step 5 (iterate if needed) into this skill's own feedback wait.** Present the before/after, then proceed straight to this skill's step 5 scratchpad write — don't block the write on a "voice feels right" confirmation. Subsequent voice tweaks from the user are re-drafts (this skill's step 5 replace path).
   - **Defer `$de-ai-ify` step 6 (voice refinement).** Do NOT run its voice-refinement prompt now — nothing has been sent yet, so there is no "final version actually used" to diff against. `$de-ai-ify` step 6 runs later, in this skill's step 5 "After output" block, against the message the user actually sends.

5. **Output**

   **Default: write to scratchpad** (unless the user overrides — below):
   - Before any write, read `Scratchpad.md`. If a `**Reply to [Name] ([medium] — …):**` section for this sender + medium already exists and concerns the *same reply*, this is a re-draft: reuse that section's exact heading verbatim (don't mint a new topic string), extract the exact existing section per `_shared-rules.md` §11 boundary rules, and replace it (`locked-edit.sh --replace`) rather than appending a duplicate. A reply to the same person on the same medium about a *different* topic is a separate section — don't overwrite it.
   - Otherwise append the de-ai-ified version (from step 4, not the original draft) to `{VAULT}/01 Now/Scratchpad.md` under heading `**Reply to [Name] ([medium] — [topic]):**`, where `[topic]` is a short discriminator (e.g. "cancel room", "executor ask"). Follow the draft with a `> Context:` (or `> Note:`) blockquote — every line of it prefixed `>`, blank line after — capturing the thread, any CRM wikilinks, and any send caveat.
   - Write via `locked-edit.sh` (`--append` for a new section), never a raw edit — Scratchpad is a shared surface mutated by multiple skills (`_shared-rules.md` §11 locking applies to all Scratchpad mutations, this write included).

   **User override:**
   - "Just inline" → don't write to scratchpad. For a trivial one-liner reply, offer this proactively.

   **After output:**
   - Wait for user feedback: edits, "sent", etc.
   - On "sent" (or when the user pastes the final, edited text they used): run `$de-ai-ify` step 6 (voice refinement) now — the step deferred from step 4 — diffing the de-ai-ified draft against what the user actually sent. Before diffing, strip the `**[true?]**` markers from the draft — the user's manual removal of them is mechanical, not a voice signal. This is the point of the whole loop: the draft→sent delta is where the voice profile learns.
   - If the user just says "sent" without pasting text, ask once: "Did you send it unchanged? If you changed it, paste the final text you sent." If unchanged, there's no delta to diff — the refinement is skipped (and counts as resolved).
   - **Scratchpad cleanup (on "sent" or confirmed final text actually used, once refinement has run or been determined skipped).** Don't gate cleanup on the user accepting any voice-doc edits refinement proposes. Remove the draft section from `Scratchpad.md` — the draft served its purpose. Read Scratchpad, extract the exact section content per `_shared-rules.md` §11 boundary rules, then remove via `locked-edit.sh --replace` with empty `new_string`. Acknowledge briefly (one line) after removal.
   - If the user said "just inline" (no scratchpad write), skip the cleanup.

## Conversation Continuity

Within a session, `$reply` carries forward context from previous drafts and the user's "sent" confirmations. A rolling conversation (like multiple replies in an IM thread) builds on all prior context, not just the current invocation. If the user comes back with "they said [X], reply with [Y]", treat it as a continuation — you already know the sender, medium, register, and relationship from the earlier invocation.

## Guidelines

- **Freeform, not templated.** Never impose greeting/body/sign-off structure on IMs.
- **No over-polishing.** Slight roughness signals authenticity. Deliberate imperfection is a feature.
- **Reference class calibration.** If prior sent messages exist in the thread, calibrate from those.
- **Long threads.** Within a single thread, the last message not from the user is the one to reply to; everything else is context.
- **CRM miss is fine.** Not every reply is to someone in the vault. Note it and proceed.
- **Batch mode.** 3+ separate requested drafts (distinct senders/threads) → run claims inventory before drafting any.
- **Research proportionality.** Quick lookups within `$reply` are fine. Substantial research → suggest `$research-assistant` first.