support-faq

When to invoke this skill

Reads customer messages, finds the questions that keep coming back, and writes each one asked three or more times as an FAQ entry — the question in the customer's words, the business's approved answer, and the messages that asked it. Use when asked to "update the FAQ", "what do customers keep asking", or after /support-reply flags a repeat. Mochi's skill.

The hard boundary

• Counted, not felt. A question earns an entry only with three or more messages you can cite. Two is a watch-list line, not an entry.
• Approved answers only. The answer comes from DESIGN.md's ## Support rules, a policy file the person names, or a reply that was actually sent (Status: sent in support-<inbox>.md). No source → the entry is written with Answer: NEEDED — <what the person must decide>. Never invent policy to finish an entry.
• Publishes nothing. FAQ.md and the help-page draft are files in this folder. Putting them on a website or helpdesk is the person's step, or a separate request with its own yes.
• No customer's private details in an entry. Cite messages by date and a short id (2026-09-14 · ticket 4812), never by email address or full name.

What you need first

• The messages — support-*.md files here, an export (CSV, mailbox file, helpdesk export) or a folder. Ask for a path if none is here.
• The period — default: everything given. Ask only if the person said "recent".

Ask in a SINGLE message, then wait.

What you read first

• FAQ.md, if present — existing entries are updated, never duplicated.
• DESIGN.md — tone and ## Support rules.
• Every message in scope, start to end.

Procedure

1. Load the inputs above.

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. Extract one line per message into .localstack/work/{date}-faq/questions.md: message id, date, the question in one plain sentence. A message with several questions gets several lines.

3. Group lines that ask the same thing, even in different words. Say the grouping rule you used at the top of the scratch file. Count each group.

4. Answer each group of 3+ from an approved source (above), quoting the source's heading or the sent reply's date. Conflicting sources → the entry says both and asks the person to choose.

5. Write FAQ.md (create it with # FAQ and an Updated: YYYY-MM-DD line; update existing entries in place, never delete one):

## <The question, in the customer's words>
<The answer, short, in DESIGN.md's tone — or "Answer: NEEDED — <decision>">

_Asked N times · sources: <id, date>; <id, date>; … · answer from: <rule or sent reply>_

Then ## Watch list — groups asked twice, one line each with their ids.

6. Help-page draft — only if asked. faq-page-draft.md: the same entries, customer-facing, without the source lines, grouped by topic. Say plainly it is a draft for the person to publish.

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 messages read, entries added / updated, and answers still NEEDED. One TODO per NEEDED answer (- [ ] decide the answer: <question> (support-faq)).

7. Report. Messages read, groups found, entries written, answers the person still owes. Point /support-reply at FAQ.md — it reads it.

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

• Every entry's count can be checked by opening the cited messages.
• No answer exists that the business did not already give.
• Five entries that stop real repeat questions beat thirty that pad a page.