support-reply

When to invoke this skill

Writes a reply for each customer message the person points at — pasted, exported, in a file, or open in their browser's support inbox — built only from what the business has already said: its rules, its FAQ, and replies it has sent before. Use when asked to "reply to these customers", "answer this ticket" or "draft support replies". Mochi's skill; the FAQ side is /support-faq.

Never promises, never sends without a yes — the hard boundary

• Only approved answers. A refund, a discount, a delivery date, a feature, an exception to policy — a reply offers it only when the rules, the FAQ or a past sent reply already offers it, and the draft names which. Anything not covered gets an honest holding line ("I'm checking this with the team and will come back to you") and a question to the person, never a guess that reads like a promise.
• One yes per reply. Show the customer, the channel and the exact text, then ask. "Send them all", "yes to the rest" and silence are not a yes for the next reply. Auto mode skips ordinary questions, never this one.
• The person's own session, never a new one. Sending happens only in a support inbox, helpdesk or webmail the browser is already signed into. Never type a password, create an account or solve a CAPTCHA; a login wall ends sending and the rest stay drafts.
• No channel, no send. No browser the agent can drive, or the message came from a file → drafts only, and say so. Never fall back to an email tool, an API or a script.

What you need first

• The messages — a path, a paste, or the inbox to open.
• The rules — where the business's policy lives (refunds, delivery, hours, what support may offer). DESIGN.md's ## Support rules if it has one; else a file the person names; else ask.

Ask for everything still missing in a SINGLE message, then wait. Without rules, draft only what the FAQ and past replies already answer, and say at the top which rules you lacked.

What you read first

• DESIGN.md — tone, sign-off, and ## Support rules. It wins over your defaults.
• FAQ.md, if present — approved answers (/support-faq keeps it).
• Past replies — support-<inbox>.md entries with Status: sent, and any past-replies file the person names. A past reply is a precedent only when it was actually sent.
• The messages themselves, every one, start to end. Do not answer the first line of a long message.

Ground rules (non-negotiable)

1. Every answer has a source. Under each draft, list where each fact came from: rule: <file § heading>, FAQ: <question>, past reply: <date, customer>. A sentence with no source is cut or becomes a question to the person.
2. The customer's facts are the customer's. Order numbers, names and dates come from their message; never fill one in.
3. Kind and short. Answer the actual question first, in the business's tone; one clear next step; no filler apology chains.
4. Angry or legal is the person's call. Threats, chargebacks, legal or safety issues, and press get a draft marked needs you and no send offer until the person has read it.

Procedure

1. Load the inputs above. Name the inbox slug (<inbox>, e.g. email, shopify-chat) — lowercase, hyphens.

Scratch for this run lives in .localstack/work/{date}-{slug}/ — hidden, one directory per run, so a new run never clobbers an earlier one and the folder's top level stays the standard files. Scratch is disposable; old run directories may be deleted freely.

2. Read and sort. One line per message: customer, what they asked, which source answers it (or not covered), needs you if it is rule 4.

3. Draft one reply per message under the rules above.

4. Write them down. In support-<inbox>.md (create it with # Support — <inbox>; never remove an entry already there), per message:

### <Customer> — <one-line ask> — <date received>
Status: draft | needs you
- Sources: <rule/FAQ/past reply for each fact>
- Not covered: <what the person must decide, or "none">

<the reply text>

5. Send, one at a time — only if a channel is open. For each draft entry the person wants sent, open the conversation in their signed-in inbox, put the reply in exactly as written, and stop:

<Customer> — <channel>
<the exact text that will be sent>
Send this?

Send only on a yes for THIS reply; confirm it went (it shows in the thread or the sent folder). Then set Status: sent YYYY-MM-DD, or skipped, or failed — <what you saw>. Edit → show the new text and ask again.

Standard files. This folder is kept in files any agent already reads. Update them in place; never scatter output into new folders.

• AGENTS.md — create it if missing. localstack owns only the block between <!-- localstack:start --> and <!-- localstack:end -->; rewrite that block, never anything outside it. The block says what this folder is for, the rules (drafts only; nothing is sent without the user's explicit yes, one message at a time; no invented facts), a map of the files below, and one line per topic (its PLAN, its lead count, the next unticked step) and per report (its file and date).
• CHANGELOG.md — create it if missing (# Changelog). Add one bullet for this run under today's ## YYYY-MM-DD heading, newest date first: the skill, the topic, and the counts or outcome (e.g. - lead-search austin-dentists: 18 found, 3 skipped as already contacted).
• TODOS.md — create it if missing (# TODOs). Add each open next action as - [ ] <action> (<topic>); tick items this run finished; never delete lines.
• DESIGN.md — decisions meant to last (positioning, tone, channels to use or avoid). Read it before writing anything a person will see; add to it only when the user states or approves a decision.

For this step: the CHANGELOG line gives drafted / sent / needs-you counts, and each sent reply's customer and text exactly as sent. One TODO per needs you entry and per "not covered" decision (- [ ] decide: <question> (support <inbox>)). A question asked three or more times → a TODO to run /support-faq.

6. Report. Counts, what needs the person, and anything that stopped a send. Offer /support-faq when the same question keeps coming back.

Completion status. End the chat report with one of:

• DONE — completed, with the evidence named (files written, counts, URLs).
• DONE_WITH_CONCERNS — completed, and list each concern.
• BLOCKED — cannot proceed; say what blocked it and what was tried.
• NEEDS_CONTEXT — missing information; say exactly what is needed.

Quality bar

• Zero sends without their own yes; zero promises without a named source.
• A teammate reading support-<inbox>.md can see why every reply says what it says.
• A short holding reply that is true beats a confident one that commits the business to something nobody approved.