Starter Writing skill
Write a support reply
Draft an accurate, useful customer-support response with a clear answer, safe next step, and honest limits.
Turn the available case record into a reply the customer can act on. Resolve the immediate question first, then add only the context needed to prevent another round trip.
Inputs
- Gather the customer's exact message, prior thread, account-safe facts, product behavior, and current policy.
- Confirm the channel, language, urgency, desired outcome, and any promised response time.
- Identify what is verified, what is inferred, and what still requires an owner.
Procedure
- Restate the customer's goal and the decision or answer the reply must deliver.
- Separate verified case facts from assumptions, internal notes, and facts that need checking.
- Lead with the answer, status, or acknowledgement in plain language.
- Give the smallest safe set of numbered actions, including where to click and what result to expect.
- Explain any limitation, delay, or policy rule without blaming the customer or another team.
- State what support will do next, who owns it, and when the customer should expect an update.
- Add one focused question only when the missing answer changes the next action.
- Check names, dates, links, product terms, tone, and accessibility before sending.
Boundaries
Never invent account status, technical causes, eligibility, refunds, deadlines, or commitments. Do not include private internal notes, credentials, security details, or another customer's data. Obtain permission before requesting sensitive diagnostics, and use the approved secure channel.
--- name: write-a-support-reply category: write description: Draft an accurate, useful customer-support response with a clear answer, safe next step, and honest limits. Use when replying to one support email, chat, ticket, review, or community question from verified case context. --- # write-a-support-reply Turn the available case record into a reply the customer can act on. Resolve the immediate question first, then add only the context needed to prevent another round trip. ## Inputs - Gather the customer's exact message, prior thread, account-safe facts, product behavior, and current policy. - Confirm the channel, language, urgency, desired outcome, and any promised response time. - Identify what is verified, what is inferred, and what still requires an owner. ## Procedure 1. Restate the customer's goal and the decision or answer the reply must deliver. 2. Separate verified case facts from assumptions, internal notes, and facts that need checking. 3. Lead with the answer, status, or acknowledgement in plain language. 4. Give the smallest safe set of numbered actions, including where to click and what result to expect. 5. Explain any limitation, delay, or policy rule without blaming the customer or another team. 6. State what support will do next, who owns it, and when the customer should expect an update. 7. Add one focused question only when the missing answer changes the next action. 8. Check names, dates, links, product terms, tone, and accessibility before sending. ## Boundaries Never invent account status, technical causes, eligibility, refunds, deadlines, or commitments. Do not include private internal notes, credentials, security details, or another customer's data. Obtain permission before requesting sensitive diagnostics, and use the approved secure channel. ## Done - The reply answers the customer's stated goal and contains only verified case facts - Every requested action is specific, safe, and checked against the current product or policy - Ownership and the next update time are written when the case remains open - The sent message is recorded in the case with links or evidence used to support it