$npx -y skills add anthropics/knowledge-work-plugins --skill draft-responseDraft a professional customer-facing response tailored to the situation and relationship. Use when answering a product question, responding to an escalation or outage, delivering bad news like a delay or won't-fix, declining a feature request, or replying to a billing issue.
| 1 | # /draft-response |
| 2 | |
| 3 | > If you see unfamiliar placeholders or need to check which tools are connected, see [CONNECTORS.md](../../CONNECTORS.md). |
| 4 | |
| 5 | Draft a professional, customer-facing response tailored to the situation, customer relationship, and communication context. |
| 6 | |
| 7 | ## Usage |
| 8 | |
| 9 | ``` |
| 10 | /draft-response <context about the customer question, issue, or request> |
| 11 | ``` |
| 12 | |
| 13 | Examples: |
| 14 | - `/draft-response Acme Corp is asking when the new dashboard feature will ship` |
| 15 | - `/draft-response Customer escalation — their integration has been down for 2 days` |
| 16 | - `/draft-response Responding to a feature request we won't be building` |
| 17 | - `/draft-response Customer hit a billing error and wants a resolution ASAP` |
| 18 | |
| 19 | ## Workflow |
| 20 | |
| 21 | ### 1. Understand the Context |
| 22 | |
| 23 | Parse the user's input to determine: |
| 24 | |
| 25 | - **Customer**: Who is the communication for? Look up account context if available. |
| 26 | - **Situation type**: Question, issue, escalation, announcement, negotiation, bad news, good news, follow-up |
| 27 | - **Urgency**: Is this time-sensitive? How long has the customer been waiting? |
| 28 | - **Channel**: Email, support ticket, chat, or other (adjust formality accordingly) |
| 29 | - **Relationship stage**: New customer, established, frustrated/escalated |
| 30 | - **Stakeholder level**: End user, manager, executive, technical, business |
| 31 | |
| 32 | ### 2. Research Context |
| 33 | |
| 34 | Gather relevant background from available sources: |
| 35 | |
| 36 | **~~email:** |
| 37 | - Previous correspondence with this customer on this topic |
| 38 | - Any commitments or timelines previously shared |
| 39 | - Tone and style of the existing thread |
| 40 | |
| 41 | **~~chat:** |
| 42 | - Internal discussions about this customer or topic |
| 43 | - Any guidance from product, engineering, or leadership |
| 44 | - Similar situations and how they were handled |
| 45 | |
| 46 | **~~CRM (if connected):** |
| 47 | - Account details and plan level |
| 48 | - Contact information and key stakeholders |
| 49 | - Previous escalations or sensitive issues |
| 50 | |
| 51 | **~~support platform (if connected):** |
| 52 | - Related tickets and their resolution |
| 53 | - Known issues or workarounds |
| 54 | - SLA status and response time commitments |
| 55 | |
| 56 | **~~knowledge base:** |
| 57 | - Official documentation or help articles to reference |
| 58 | - Product roadmap information (if shareable) |
| 59 | - Policy or process documentation |
| 60 | |
| 61 | ### 3. Generate the Draft |
| 62 | |
| 63 | Produce a response tailored to the situation: |
| 64 | |
| 65 | ``` |
| 66 | ## Draft Response |
| 67 | |
| 68 | **To:** [Customer contact name] |
| 69 | **Re:** [Subject/topic] |
| 70 | **Channel:** [Email / Ticket / Chat] |
| 71 | **Tone:** [Empathetic / Professional / Technical / Celebratory / Candid] |
| 72 | |
| 73 | --- |
| 74 | |
| 75 | [Draft response text] |
| 76 | |
| 77 | --- |
| 78 | |
| 79 | ### Notes for You (internal — do not send) |
| 80 | - **Why this approach:** [Rationale for tone and content choices] |
| 81 | - **Things to verify:** [Any facts or commitments to confirm before sending] |
| 82 | - **Risk factors:** [Anything sensitive about this response] |
| 83 | - **Follow-up needed:** [Actions to take after sending] |
| 84 | - **Escalation note:** [If this should be reviewed by someone else first] |
| 85 | ``` |
| 86 | |
| 87 | ### 4. Run Quality Checks |
| 88 | |
| 89 | Before presenting the draft, verify: |
| 90 | |
| 91 | - [ ] Tone matches the situation and relationship |
| 92 | - [ ] No commitments beyond what's authorized |
| 93 | - [ ] No product roadmap details that shouldn't be shared externally |
| 94 | - [ ] Accurate references to previous conversations |
| 95 | - [ ] Clear next steps and ownership |
| 96 | - [ ] Appropriate for the stakeholder level (not too technical for executives, not too vague for engineers) |
| 97 | - [ ] Length is appropriate for the channel (shorter for chat, fuller for email) |
| 98 | |
| 99 | ### 5. Offer Iterations |
| 100 | |
| 101 | After presenting the draft: |
| 102 | - "Want me to adjust the tone? (more formal, more casual, more empathetic, more direct)" |
| 103 | - "Should I add or remove any specific points?" |
| 104 | - "Want me to make this shorter/longer?" |
| 105 | - "Should I draft a version for a different stakeholder?" |
| 106 | - "Want me to draft the internal escalation note as well?" |
| 107 | - "Should I prepare a follow-up message to send after [X days] if no response?" |
| 108 | |
| 109 | --- |
| 110 | |
| 111 | ## Customer Communication Best Practices |
| 112 | |
| 113 | ### Core Principles |
| 114 | |
| 115 | 1. **Lead with empathy**: Acknowledge the customer's situation before jumping to solutions |
| 116 | 2. **Be direct**: Get to the point — customers are busy. Bottom-line-up-front. |
| 117 | 3. **Be honest**: Never overpromise, never mislead, never hide bad news in jargon |
| 118 | 4. **Be specific**: Use concrete details, timelines, and names — avoid vague language |
| 119 | 5. **Own it**: Take responsibility when appropriate. "We" not "the system" or "the process" |
| 120 | 6. **Close the loop**: Every response should have a clear next step or call to action |
| 121 | 7. **Match their energy**: If they're frustrated, be empathetic first. If they're excited, be enthusiastic. |
| 122 | |
| 123 | ### Response Structure |
| 124 | |
| 125 | For most customer communications, follow this structure: |
| 126 | |
| 127 | ``` |
| 128 | 1. Acknowledgment / Context (1-2 sentences) |
| 129 | - Acknowledge what they said, asked, or are experiencing |