Write an FAQ from source documents
Builds an FAQ from scattered policies, emails and documents, phrasing entries as real readers ask them, tracing each answer to its source and listing conflicts and unanswered questions.
A good FAQ answers the questions people actually have, in the words they would use, so they stop emailing the organiser. Most FAQs fail because they are written from the document's structure instead of the reader's situation ("What is the scope of the policy?" instead of "Can I work from abroad for two weeks?"), because answers are padded or vague, or because they quietly paper over places where two source documents disagree. When the answer is wrong, the FAQ does more damage than no FAQ, so every answer must trace back to a source, and anything the sources do not settle must be visible to the owner, not guessed.
Build an FAQ for this audience: . Include at most questions.
- If there is no usable source material, ask for it and stop. If the sources are unlabelled, label them S1, S2, … in the order given and use those labels throughout.
- Imagine the reader's real situations: before, during and after the thing the sources cover, and what goes wrong. List the questions they would ask, phrased in their words (first person, plain language, specific: "What if my flight is cancelled?" not "Flight disruption procedures").
- Rank them by how many readers will ask and how costly a wrong guess would be (money, deadlines, safety, eligibility). Keep the top ; note the rest under Gaps as "not included".
- Answer each from the sources only:
- Lead with the direct answer (yes, no, the number, the deadline), then the condition or exception, then what to do or whom to contact.
- Quote exact figures, dates and limits as written in the source.
- End the answer with its source label(s) in brackets, for example "[S2]".
- If a source answers only part of the question, answer that part and say what is not covered.
- Where two sources disagree, do not choose silently. Give the most recent or most authoritative answer only if the sources make the order clear, and list every disagreement under Conflicts.
- Questions the audience will clearly ask but the sources do not answer go under Gaps with a suggested owner to answer them. Do not include them in the FAQ with an invented answer.
- Group the questions under three to six short headings in the order the reader will need them.
- No answer may contain a fact that is not in the sources. Plausible-sounding policy details are the main risk here.
- Answers under about 80 words each; link or point to the source for the full detail.
- Plain language: second person ("you"), active voice, no internal jargon unless the audience uses it.
- Do not reproduce personal data from the sources (names, phone numbers, personal emails) unless it is clearly meant as a public contact point.
FAQ
Grouped questions as ### Heading then **Question?** followed by the answer and source label.
Source map
Table: Source label · Source title or description · Questions it answers.
Conflicts
Bullets: the question, what each source says (with labels), and who should resolve it. "None found" if none.
Gaps
Bullets: questions readers will ask that the sources do not answer, plus any questions cut by the limit, each with a suggested owner. "None" if none.
Weak: What is the expense policy for meals? Meals are reimbursed in line with company policy. Strong: How much can I spend on dinner when I travel? Up to 40 EUR per person per day, including tips. Alcohol is not reimbursed. Keep the itemised receipt and submit it within 30 days. [S1]
2 required values still a placeholder; the assistant will ask for them.
details
- kind
- Prompt: a task you run by name to get one finished thing back
- domain
- Writing and communication
- category
- Business writing
- level
- Beginner
- made for
- Operations, People manager, Customer support, Anyone, personal use
- risk
- read-only
- version
- v1.0.0 · incubating
- reviewed
- 2026-10-03
- works in
- Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Antigravity, OpenCode, Windsurf, Zed, Continue, AGENTS.md, ChatGPT, claude.ai
use in
npx @hermes-hq/hodios install write-faq-from-documents --target claude-codenpx skills add hermes-hq/hodios-dist --skill write-faq-from-documents -a claude-codeclaude plugin marketplace add hermes-hq/hodios-distclaude plugin install hodios-writing-communication@hodiosThe plugin brings every entry in this domain at once.
pairs well with
All of Business writingSimplify a text to plain language
Rewrites a text in plain language at a target reading level while keeping every fact, obligation, right, deadline and condition intact, and shows a meaning check against the original.
simplify-to-plain-languageWrite an internal announcement
Writes an internal announcement of a reorg, policy change or launch that explains what is changing, why, the impact on each group and where to ask, plus an FAQ and a pre-send check.
write-internal-announcementReview a document for ambiguity
Finds statements in instructions, policies, requirements or agreements that readers could interpret two ways, explains each reading and its consequence, and proposes unambiguous wording.
review-document-for-ambiguityWrite an executive summary
Writes an executive summary of a long document that leads with the bottom line, the key points and the ask, using only facts from the source. Use before sending a report to busy readers.
write-executive-summaryWrite a project proposal or business case
Writes an internal project proposal or business case covering the problem, options, recommendation, cost, benefits and risks, and marks every missing number instead of inventing it.
write-project-proposalWrite a project status report
Writes a project status report with an evidence-based RAG status, progress, risks, decisions needed and next steps, formatted as an email, a document or a single slide.
write-status-report