# Hodios paste pack: Business writing
Everything in Business writing from Hodios, the open prompt library by Hermes IDE: 37 entries, catalog 2026.1004.3.
Every entry is dedicated to the public domain under CC0 1.0. Copy, change and share them freely, no attribution needed.
Browse and search the library at https://hermes-ide.com/prompts
## How to use
Find an entry below and copy the text inside its block into ChatGPT, claude.ai or any chat. Replace each [PLACEHOLDER] with your own material. Personas, rules and styles work best as custom instructions or project instructions.
## Contents
- Business writing
- [Ask for help in team chat](#ask-for-help-in-team-chat) (prompt)
- [Ata de assembleia de condomínio](#write-condo-meeting-minutes) (prompt)
- [Dilekçe yazmak](#write-turkish-petition) (prompt)
- [Menulis surat undangan resmi](#write-indonesian-formal-invitation) (prompt)
- [Plan change communications](#plan-change-communications) (prompt)
- [Report writing track](#report-writing-track) (workflow)
- [Write a briefing note](#write-briefing-note) (prompt)
- [Write a business requirements document](#write-business-requirements) (prompt)
- [Write a customer change notice](#write-customer-change-notice) (prompt)
- [Write a decision memo](#write-decision-memo) (prompt)
- [Write a formal letter](#write-formal-letter) (prompt)
- [Write a handover document](#write-handover-document) (prompt)
- [Write a letter of support](#write-letter-of-support) (prompt)
- [Write a letter to an elected official](#write-letter-to-elected-official) (prompt)
- [Write a one-page job aid](#write-job-aid) (prompt)
- [Write a professional bio](#write-professional-bio) (prompt)
- [Write a project close-out report](#write-project-closeout-report) (prompt)
- [Write a project proposal or business case](#write-project-proposal) (prompt)
- [Write a project status report](#write-status-report) (prompt)
- [Write a public consultation response](#write-public-consultation-response) (prompt)
- [Write a recognition message](#write-recognition-message) (prompt)
- [Write a report to a charity board](#write-trustee-board-report) (prompt)
- [Write a site visit report](#write-site-visit-report) (prompt)
- [Write a user manual](#write-user-manual) (prompt)
- [Write a white paper](#write-white-paper) (prompt)
- [Write a workplace incident report](#write-workplace-incident-report) (prompt)
- [Write a workplace safety alert](#write-safety-alert-bulletin) (prompt)
- [Write an annual report letter](#write-annual-report-letter) (prompt)
- [Write an award nomination](#write-award-nomination) (prompt)
- [Write an executive summary](#write-executive-summary) (prompt)
- [Write an FAQ from source documents](#write-faq-from-documents) (prompt)
- [Write an internal announcement](#write-internal-announcement) (prompt)
- [Write an internal team newsletter](#write-team-newsletter) (prompt)
- [Write manager talking points for a change](#write-manager-talking-points) (prompt)
- [كتابة خطاب رسمي](#write-formal-arabic-letter) (prompt)
- [प्रार्थना पत्र लिखना](#write-hindi-application-letter) (prompt)
- [年终总结与述职报告](#write-year-end-work-summary) (prompt)
---
## Ask for help in team chat
`ask-for-help-in-team-chat` · prompt · Business writing · https://hermes-ide.com/prompts/ask-for-help-in-team-chat
Writes a question for a team chat channel that gets answered, with context, what was tried, the specific ask, urgency and where to reply. Use as a new hire or remote worker.
````markdown
Questions in busy team channels get answered when a helper can understand them in one read and answer without a round of follow-ups. They go unanswered when they ask to ask ("anyone know about the VPN?"), describe an attempted fix instead of the goal (the "XY problem": asking how to do X when the real need is Y), leave out the error message or what was tried, or hide the urgency. A good question states the goal, what happened versus what was expected, what was tried, the specific question, and how urgent it is, in a short first message, with longer details in the thread. Posting the answer back afterwards turns the thread into documentation for the next person.
Write a team chat question. Urgency: today.
[PROBLEM]
1. If you cannot tell what the person is trying to achieve, ask one question about the goal and stop.
2. Check for the XY problem: if the problem describes a workaround or a means, state the underlying goal first so helpers can suggest a better route.
3. Remove any secrets or sensitive data in the problem (passwords, API keys, tokens, customer personal data, financial account numbers) from the message, replace them with placeholders, and say so under Tips.
4. Main message, at most about five short lines:
- The goal and the problem in one sentence.
- Expected versus what actually happens, with the exact error text in a code span if there is one.
- The specific question.
- Urgency stated honestly: for "blocking", say what is blocked and since when; for "low", say it can wait.
- Where to reply ("in thread, please").
5. Thread details: what was tried, environment or context (device, system, account, document link placeholders), and screenshots to attach, as a short list. Omit if there is nothing beyond the main message.
6. Tips: whether to tag a specific owner or team (only if the channel audience suggests one, and never tag a whole channel for a non-urgent question), and one line on searching the channel history first if that was not tried.
7. After it is answered: a one-line follow-up template that posts the solution and thanks the helper.
- Use only the facts given; never invent error messages, system names or steps tried. Use `[need: …]` where an error message or link would help.
- No "anyone around?", "quick question" or apology for asking.
- Do not inflate urgency; "blocking" only when the input says work cannot continue.
- Keep the tone friendly and matter-of-fact; suitable for a new joiner who does not know people yet.
## Main message
The message, ready to paste.
## Thread details
The thread reply, or "Not needed".
## Tips
Two or three bullets.
## After it is answered
One line.
Weak: "Hey, does anyone know about the VPN?"
Strong: "I can't reach the staging dashboard from home: the VPN connects, but the page times out (`ERR_CONNECTION_TIMED_OUT`). Is there an extra step for staging access for new starters? Blocking my onboarding tasks since this morning. Details in thread 🧵"
````
---
## Ata de assembleia de condomínio
`write-condo-meeting-minutes` · prompt · Business writing · https://hermes-ide.com/prompts/write-condo-meeting-minutes
Redige a ata de uma assembleia de condomínio a partir das anotações, com presença, quórum, ordem do dia, votações e deliberações no formato esperado, e aponta o que precisa ser confirmado.
````markdown
Você é secretária de assembleias experiente e trabalhou anos com administradoras de condomínio. A ata é o registro oficial do que foi decidido: vai para todos os condôminos, pode ser registrada em cartório e pode ser usada para cobrar uma taxa extra ou contestar uma obra. Por isso ela registra fatos, não opiniões: quem estava presente, se havia quórum, o que estava na pauta, como cada item foi votado e o que ficou decidido. As regras de convocação e de quórum vêm da convenção do condomínio e do Código Civil, e a ata não deve afirmar algo que as anotações não sustentam.
Condomínio: [CONDOMINIO]
Tipo: assembleia geral ordinaria
[ANOTACOES]
1. Se faltarem a data ou os itens da pauta com seus resultados, peça esses dados em uma mensagem curta e pare. Outros dados ausentes vão como [a confirmar].
2. Redija a ata em texto corrido, impessoal, no passado, com os itens da pauta numerados:
- abertura: “Ata da Assembleia Geral [Ordinária/Extraordinária] do [CONDOMINIO]”, data, horário, local (ou plataforma, se virtual ou híbrida), chamada (primeira ou segunda convocação) e referência ao edital de convocação.
- presença: número de unidades presentes e representadas por procuração, com a lista de presença como anexo; quórum de instalação conforme as anotações.
- mesa: eleição do presidente e do secretário.
- ordem do dia: cada item com um resumo neutro da discussão, o resultado da votação (votos a favor, contra e abstenções, ou “aprovado por unanimidade” / “por maioria”, como nas anotações) e a deliberação exata (valores, parcelas, prazos, responsáveis).
- assuntos gerais: apenas registro de comunicados e sugestões.
- encerramento: horário, a frase de que nada mais havendo a tratar a ata foi lavrada pelo(a) secretário(a) e assinada pelo presidente e pelo secretário.
3. Linguagem neutra: identifique condôminos pela unidade (“o condômino da unidade 302”); discussões acaloradas viram “houve manifestações contrárias”, sem reproduzir ofensas.
4. Em “Pontos a confirmar”, liste tudo marcado como [a confirmar].
5. Em “Alertas”, aponte, sem dar parecer jurídico, situações que a administração deve checar na convenção e na lei antes de divulgar a ata, por exemplo: votação de assunto que não estava na pauta do edital; deliberação que parece exigir quórum qualificado (alteração de convenção, obras voluptuárias, mudança de destinação) sem que as anotações mostrem esse quórum; procurações sem registro de conferência; voto de condômino inadimplente (o Código Civil condiciona o direito de votar a estar quite com as contribuições).
6. Antes de responder, confira que cada número (votos, valores, parcelas, datas) da ata está nas anotações e que nenhuma deliberação foi acrescentada.
- Não invente votos, valores, nomes nem decisões. Use [a confirmar].
- Não afirme que o quórum foi atingido se as anotações não disserem isso.
- Não dê parecer jurídico sobre a validade da assembleia; em caso de dúvida séria, recomende consultar a administradora ou um advogado.
- Responda inteiramente em português do Brasil.
## Ata
O texto da ata, pronto para revisão e assinatura.
## Pontos a confirmar
## Alertas
Se não houver, “Nenhum alerta”.
````
---
## Dilekçe yazmak
`write-turkish-petition` · prompt · Business writing · https://hermes-ide.com/prompts/write-turkish-petition
Bir kuruma, okula veya işverene verilecek dilekçeyi doğru biçimde yazar: hitap satırı, tarih, konu, talep, saygı ifadesi, imza bloğu ve ekler listesi.
````markdown
Resmî yazışma ve dilekçe hazırlama konusunda deneyimli bir büro yazmanısın. Türkiye'de dilekçenin yerleşik bir biçimi vardır ve kurumlar biçime dikkat eder: makam adı ortada, büyük harfle ve yönelme hâli ekiyle (“KADIKÖY BELEDİYE BAŞKANLIĞINA”); altında şehir; sağ üstte tarih; kısa bir giriş, açık bir talep; “Gereğini saygılarımla arz ederim.” gibi bir kapanış; sağ altta ad soyad ve imza; sol altta adres ve iletişim; en altta “EKLER”. Biçimi doğru, talebi net bir dilekçe daha hızlı işleme alınır.
Makam: [KURUM]
[KONU]
Ekler: [EKLER]
1. Talep belli değilse kısa bir soru sor ve dur. Diğer eksik bilgiler [köşeli parantez] içinde kalsın.
2. Dilekçeyi şu düzende yaz:
- Sağ üstte tarih: [GG.AA.YYYY].
- Ortada makam adı, tamamı büyük harfle ve yönelme ekiyle: “… MÜDÜRLÜĞÜNE”, “… DEKANLIĞINA”, “… BAŞKANLIĞINA”. Büyük harfle yazımda “i” harfinin “İ” olmasına dikkat et.
- Altında, ortada veya sağda şehir (ve gerekiyorsa ilçe): “İSTANBUL” ya da “KADIKÖY/İSTANBUL”.
- İsteğe bağlı “Konu:” satırı (örneğin “Konu: Mazeret sınavı talebi”).
- Gövde: birinci tekil kişiyle, kendini tanıtan bir giriş (“Fakülteniz İşletme Bölümü 2. sınıf, 2023123456 numaralı öğrencisiyim.”), durumu anlatan bir veya iki cümle, açık talep (“… hususunda gereğinin yapılmasını …”).
- Kapanış: üst makama “Gereğini saygılarımla arz ederim.” veya “Bilgilerinize arz ederim.”; denk ya da daha resmî olmayan bir muhataba “Gereğini rica ederim.”.
- Sağ altta: imza için boşluk ve ad soyad.
- Sol altta: “Adres:”, “Telefon:”, gerekiyorsa “T.C. Kimlik No:” (değerleri [ ] içinde).
- En altta: “EKLER:” ve numaralı liste (“1- Sağlık raporu (1 sayfa)”). Ek yoksa bu bölümü yazma.
3. Dil: resmî ama sade; uzun ve devrik cümlelerden, “arz ve talep ederim” gibi yığılmalardan kaçın; yazım kurallarına (TDK) uy.
4. Göndermeden önce kontrol et: makam adı yönelme ekiyle bitiyor mu, tarih ve numaralar konudaki bilgilerle aynı mı, talep tek cümlede açıkça okunuyor mu, ekler gövdede anılanlarla uyuşuyor mu.
- T.C. kimlik numarası, öğrenci numarası, adres veya tarih uydurma; [ ] içinde bırak.
- Mahkeme, icra, itiraz gibi yasal süreli dilekçelerde dilekçeyi yazabilirsin, ama süre ve usul için bir avukata veya baronun adli yardım bürosuna danışmayı tek cümleyle öner.
- Kurum e-Devlet, CİMER veya kendi sistemi üzerinden başvuru kabul ediyorsa bunu “Vermeden önce” bölümünde bir seçenek olarak an.
- Yanıtın tamamını Türkçe yaz.
## Dilekçe
Basılmaya hazır metin; satır düzeni (sağ, orta, sol) parantez içinde belirtilmiş.
## Doldurulacak yerler
[ ] içindeki bilgiler.
## Vermeden önce
İki üç madde: imza, ek sayısı, nereye ve nasıl teslim edileceği.
````
---
## Menulis surat undangan resmi
`write-indonesian-formal-invitation` · prompt · Business writing · https://hermes-ide.com/prompts/write-indonesian-formal-invitation
Menulis surat undangan resmi berbahasa Indonesia untuk rapat, acara kantor, sekolah, atau kegiatan warga dengan struktur baku, bahasa santun, dan penulisan sesuai EYD.
````markdown
Anda adalah sekretaris berpengalaman yang terbiasa menyusun surat dinas untuk kantor, sekolah, dan pengurus RT/RW. Surat undangan resmi dinilai dari kelengkapan dan kerapiannya: kop surat, nomor, lampiran, perihal, alamat tujuan, salam pembuka, isi dengan rincian hari, tanggal, waktu, dan tempat yang mudah ditemukan, salam penutup, tanda tangan, serta nama terang. Kesalahan kecil seperti hari yang tidak cocok dengan tanggal, penulisan jam yang salah, atau “Kepada Yth.” yang berlebihan membuat surat terlihat kurang cermat.
Penerima: [PENERIMA]
Tanggal acara: [TANGGAL]
[ACARA]
1. Jika nama kegiatan, tempat, atau waktu tidak ada, ajukan pertanyaan singkat lalu berhenti. Data lain yang kurang ditulis dalam [kurung siku].
2. Susun surat dengan urutan baku:
- Kop surat: nama lembaga atau panitia dan alamat ([ ] jika tidak ada).
- Nomor surat ([nomor surat], jangan dikarang), Lampiran (“-” jika tidak ada), Perihal: Undangan.
- Tempat dan tanggal surat di kanan atas: “[Kota], [tanggal surat]”.
- Alamat tujuan: “Yth. Bapak/Ibu …” diikuti tempat jika perlu. Gunakan “Yth.” saja, tanpa “Kepada” di depannya.
- Salam pembuka: “Dengan hormat,”; untuk kegiatan warga atau lembaga keagamaan Islam dapat “Assalamu’alaikum warahmatullahi wabarakatuh,” sesuai kebiasaan pengundang.
- Paragraf pembuka: maksud undangan (“Sehubungan dengan …, kami mengundang Bapak/Ibu untuk hadir pada:”).
- Rincian dalam bentuk daftar rata titik dua: hari/tanggal, waktu, tempat, acara.
- Paragraf penutup: “Mengingat pentingnya acara tersebut, kami mengharapkan kehadiran Bapak/Ibu tepat waktu. Atas perhatian dan kehadiran Bapak/Ibu, kami mengucapkan terima kasih.” (sesuaikan dengan acaranya).
- Salam penutup: “Hormat kami,” atau “Wassalamu’alaikum warahmatullahi wabarakatuh,” jika dibuka dengan salam yang sama; jabatan; ruang tanda tangan; nama terang.
- Tembusan, hanya jika disebutkan dalam rincian.
3. Ikuti EYD: jam ditulis dengan titik dan zona waktu (“pukul 09.00 WIB”, “pukul 09.00–11.30 WIB”), nama hari dan bulan diawali huruf kapital, “Bapak/Ibu” dengan huruf kapital saat menyapa, tanpa singkatan tidak baku.
4. Hari dan tanggal: jika pengguna hanya memberi tanggal, jangan menebak harinya; tulis “[hari], [TANGGAL]” dan minta pengguna memastikan. Jika hari dan tanggal sama-sama diberikan, cantumkan apa adanya dan ingatkan untuk mencocokkannya dengan kalender.
5. Sebelum menjawab, pastikan semua rincian (waktu, tempat, nama, jabatan) sama dengan data pengguna dan tidak ada yang dikarang.
- Jangan mengarang nomor surat, nama, jabatan, alamat, atau susunan acara.
- Bahasa santun dan ringkas; satu halaman.
- Jawab seluruhnya dalam bahasa Indonesia.
## Surat undangan
Surat lengkap siap dicetak, dengan tata letak (kanan/kiri) ditandai dalam kurung bila perlu.
## Yang perlu dilengkapi
Daftar isian dalam [kurung siku].
## Pemeriksaan
Dua sampai tiga hal yang perlu dicek: kecocokan hari dan tanggal, tanda tangan dan stempel, cara pengiriman.
````
---
## Plan change communications
`plan-change-communications` · prompt · Business writing · https://hermes-ide.com/prompts/plan-change-communications
Plans the communications for an organisational change such as a new system, a reorg or a policy, by audience and phase, with key messages, channels, timing, managers' role and feedback loops.
````markdown
Change communication fails in predictable ways: one big announcement and silence afterwards, the same message for everyone regardless of how they are affected, managers hearing about it at the same time as their teams, no route for questions, and "communication" ending at go-live just when people need help. Change practitioners (Prosci's ADKAR model is a common reference) sequence communication to build awareness of why the change is happening, desire to take part, knowledge of how, ability in practice, and reinforcement afterwards. Their research consistently finds employees want to hear the business reasons from senior leaders and the personal impact from their direct manager, which makes a manager briefing and toolkit central. Messages need repeating several times through different channels before most people have absorbed them. Some changes also carry formal obligations first: in many countries, reorganisations, redundancies and new monitoring tools require consultation with employee representatives, such as a works council or union, before any announcement.
Plan the communications for this change.
[CHANGE]
[AUDIENCES]
1. If the change or the reason for it is unclear, ask up to three questions and stop. A missing go-live date becomes a placeholder, and the timeline uses relative weeks (T-6 weeks).
2. Check for obligations that must come before any announcement: employee representative consultation (reorgs, job losses, monitoring tools, working-time changes), legal or HR review, customer or regulator notice. List what applies under Risks and gaps as "check with HR or legal", without stating the law for a specific country.
3. Audience impact map: for each audience, what changes for them day to day, the degree of impact (high, medium, low), what they will most likely worry about, what they need to know or be able to do, and who they should hear it from.
4. Core messages: one core message (why, what, when, in two sentences), three supporting messages, and what is not changing. Then one line per audience on "what this means for you".
5. Timeline across phases: before announcement (leaders and managers briefed first), announcement, preparation and training, go-live, and reinforcement (at least four to six weeks after go-live). For each communication: date or relative week, audience, message, channel, sender, and owner. Leaders explain why; managers explain what it means for the team; training covers how.
6. Manager toolkit: what managers get and when (briefing session, talking points, FAQ, where to escalate questions they cannot answer), and what they are asked to do.
7. Feedback and measures: the channels for questions and concerns (Q&A sessions, a shared mailbox, pulse questions), how the FAQ is updated and how often, and adoption or understanding measures with targets where the input allows.
8. Address each known concern explicitly in messages, timing or support.
- Use only facts from the input; never invent dates, numbers, decisions or names. Use `[need: …]`.
- Honest messages: no promise that nobody is affected unless the input says so, no spin on reasons, and say what is not yet decided.
- No announcement to affected staff before their managers are briefed, and no all-staff announcement before required consultation is complete.
- Plans proportionate to the change: a small policy tweak gets a short plan; a reorg gets the full treatment.
- Plain language; no change-management jargon in the messages themselves.
## Summary
Three to five sentences: the change, the approach and the critical dates.
## Audience impact map
Table: audience, what changes, impact level, likely concerns, need to know or do, messenger.
## Core messages
Core message, supporting messages, what is not changing, then a line per audience.
## Timeline
Table: when, audience, message, channel, sender, owner.
## Manager toolkit
Bullets with dates.
## Feedback and measures
Bullets.
## Risks and gaps
Bullets: obligations to check, risks with mitigations, and `[need: …]` items.
````
---
## Report writing track
`report-writing-track` · workflow · Business writing · https://hermes-ide.com/prompts/report-writing-track
Takes a work report from purpose and audience to an answer-first outline, an evidence check, a full draft, an executive summary and a final edit, pausing for approval between steps.
````markdown
Writes a work report one approved step at a time, as an experienced report writer and editor would: brief, answer-first outline, evidence check, draft, executive summary, then a final edit.
[REPORT_PURPOSE]
[SOURCE_MATERIAL]
Each step produces one artifact and stops for approval or edits. Later steps build on the approved versions and do not reopen them unless the writer asks. If the source material is unlabelled, label the sources S1, S2, … in the order given and use those labels throughout. Use only facts, figures and quotes from the source material; mark anything missing as `[NEEDED: …]` instead of inventing data, results, quotes or names. If the writer asks to skip the approvals, confirm once that later steps will build on unreviewed choices; if they agree, run the remaining steps in one reply and state the choice made at each skipped gate.
## Steps
Work through these steps in order. Do not skip a gate.
1. brief (plan)
2. outline (design)
3. evidence (verify)
4. draft (build)
5. summary (build)
6. edit (review)
### Step 1: Purpose and audience brief
Pin down what the report must do before any structure exists.
1. Two things are essential: what the reader should decide, do or understand after reading, and enough source material to support it. If either is missing, ask for it in one message, with the audience, deadline, template or length and who signs off, then stop. Otherwise do not ask: write the brief and list your assumptions.
2. Write a brief of no more than one page:
- **Purpose:** "After reading this, [reader] will …", one sentence. If a decision is wanted, name it exactly.
- **Readers:** who acts, who is informed, what they know and care about, and how much they will read.
- **Key questions:** the three to five questions the report must answer, in the reader's words.
- **Scope:** what is in and out, and the period or population the data covers.
- **Constraints:** length, template, house style, deadline, confidentiality.
- **Material on hand:** the sources by label and what each can answer.
- **Assumptions to confirm:** each default you chose, one line each.
Stop and wait for approval or edits. Do not outline yet.
**Gate:** stop here and wait for the user's approval before step 2 (outline).
### Step 2: Answer-first outline
Build the argument before the prose, from the approved brief.
1. State the governing message: the one sentence that answers the purpose. If the material does not yet support one, give the most likely answer, mark it provisional and say what would confirm it.
2. Group the support pyramid-style: three to five key points, each a full sentence supporting the message, with the findings beneath each. Points at one level are of the same kind and do not overlap.
3. Choose the section order and say why: answer first for decision-makers; situation, complication, resolution when context is needed; chronological only for an account of events.
4. For each section, write the heading as a takeaway ("Repeat contacts drive half of support cost", not "Support analysis"), the source labels it draws on, any table or chart it needs, and a target word count.
5. Mark what goes in appendices (method, full tables) so the body stays lean.
Stop and wait for approval or edits. Do not check evidence or draft yet.
**Gate:** stop here and wait for the user's approval before step 3 (evidence).
### Step 3: Evidence check
Test every claim in the approved outline against the sources before writing.
1. Table every claim (message, key points, findings): Claim · Sources · What the source actually says · Strength · Issue.
2. Strength: **strong** (directly stated by a reliable source, figures match), **adequate** (indirect, small sample or one source), **weak** (inferred or anecdotal), **unsupported** (no source).
3. Recompute totals, percentages and changes from raw figures where given; check units and periods; flag any figure that differs between sources.
4. Flag conflicts between sources, overreach (correlation as cause, a sample generalised to everyone) and data too old for the decision.
5. For each weak or unsupported claim, recommend: soften it, find the evidence (say what and where), or drop it. If the governing message itself is weak, say so and propose a reframe.
Stop and wait for approval or edits. The draft will use only claims the writer keeps.
**Gate:** stop here and wait for the user's approval before step 4 (draft).
### Step 4: Draft
Write the body from the approved outline and evidence decisions.
1. Follow the approved order and takeaway headings. Open each section with its takeaway, then the support, then what it means for the reader.
2. State each claim at the strength the evidence check allowed, with its limits ("in the 40 stores surveyed"); leave out dropped claims.
3. Cite sources by label or in the writer's template format. Keep figures exactly as checked, with units and periods.
4. Build the planned tables and charts, each titled with its message.
5. End with conclusions and, if the purpose asks, recommendations: each a specific action with an owner role and timing, traced to its findings.
6. Keep to the word targets: short paragraphs, plain language, active voice, terms defined once. Method and long tables go in appendices.
7. Do not write the executive summary yet.
Stop and wait for approval or edits.
**Gate:** stop here and wait for the user's approval before step 5 (summary).
### Step 5: Executive summary
Write the summary from the approved draft, for a reader who reads nothing else.
1. About 10% of the body, at most one page.
2. Open with the governing message and, if a decision is wanted, the decision and the date it is needed.
3. Then the key points by importance, each with its strongest figure; the main recommendation or next steps; the main risk or limitation.
4. Add nothing that is not in the draft, and keep figures and certainty exactly as in the body. State findings; do not describe the report ("This report examines…").
Stop and wait for approval or edits.
**Gate:** stop here and wait for the user's approval before step 6 (edit).
### Step 6: Final edit
Edit the approved summary and draft into the final report.
1. **Consistency:** figures, names, dates and terms match across summary, body, tables and appendices.
2. **Clarity:** cut throat-clearing and stacked hedges, break sentences over about 30 words, replace jargon, and fix any sentence a reader could read two ways.
3. **Honesty:** no claim stronger than the evidence check allowed; limitations stated once, where they matter.
4. **Mechanics:** spelling, numbers, capitalisation and citations consistent with the house style if given.
5. Return the final report in full, a short change log by type, and the remaining `[NEEDED: …]` items to fill before sending.
This is the last step.
````
---
## Write a briefing note
`write-briefing-note` · prompt · Business writing · https://hermes-ide.com/prompts/write-briefing-note
Writes a public-sector style briefing note for a minister, director or board with purpose, background, considerations, options and a recommendation under the required headings.
````markdown
A briefing note lets a senior decision-maker, often reading between meetings, understand an issue and act on it in a few minutes. Government departments in Canada, the UK, Australia and elsewhere use similar shapes: a purpose line saying whether it is for decision or information, a short summary, background, the current status, considerations (financial, legal, policy, stakeholder, communications, equity, risk), options with honest pros and cons, a recommendation, and next steps. Public servants write them impartially: the facts and risks are set out even when they are unwelcome, the recommendation follows from the analysis, and nothing is shaped for party-political advantage. Notes fail when the ask is buried, when options are straw men, when the legal or financial risk is missing, when acronyms go unexplained, or when they run past the page limit and are not read.
Write a briefing note for [AUDIENCE], no longer than 2 pages (about 450 words per page).
[ISSUE]
[BACKGROUND]
1. If you cannot tell what the issue is or the background has no facts to analyse, ask up to three questions and stop.
2. Decide the type: for decision (a recommendation and a decision line are needed), for information, or for a meeting (add key messages and likely questions). Use the type the issue states; otherwise infer it and say so under Gaps and checks.
3. Use the required headings exactly and in order if given. Otherwise use: Purpose; Summary; Background; Current status; Considerations; Options; Recommendation; Next steps. Drop Options and Recommendation for an information note.
4. Write each part:
- Purpose: one sentence: "To seek your decision on…" or "To inform you of…", with the date a decision is needed and why.
- Summary: three to five bullets a reader could stop after.
- Background and Current status: only the facts needed to understand the options, with figures and dates from the input, in numbered paragraphs.
- Considerations: the financial, legal, policy, stakeholder, communications and equity points that apply, each in a sentence or two. Name who has been consulted and who has not.
- Options: two to four genuine options including the status quo if realistic, each with benefits, risks, cost and timing on the same basis. Do not weaken alternatives to favour the recommendation.
- Recommendation: the option and the deciding reason, and its main risk with mitigation.
- Next steps: what happens after the decision, by whom and when.
- For a decision note, end with a decision line: "Agreed / Not agreed / Discuss", with space for signature and date.
5. Spell out every acronym on first use. Use plain, neutral language.
- Stay within 2 pages; if the material cannot fit, keep the analysis and suggest an annex for detail under Gaps and checks.
- Use only the facts in the input. Never invent figures, legal positions, stakeholder views or consultation that did not happen; mark gaps `[NEEDED: …]`.
- Impartial: no party-political framing, no spin, no omission of a material risk even if the reader will not like it. If the input asks to leave out a material risk or to frame the note for political advantage, keep the risk and note why under Gaps and checks.
- No hedging chains; state uncertainty once, with what would resolve it.
## Briefing note
Header lines (To / From / Date / Subject / Type: for decision, information or meeting), then the note under its headings with numbered paragraphs.
## Gaps and checks
Bullets: `[NEEDED: …]` items with where to get them, assumptions made, who should clear the note (legal, finance, communications) before it goes up.
````
---
## Write a business requirements document
`write-business-requirements` · prompt · Business writing · https://hermes-ide.com/prompts/write-business-requirements
Writes a business requirements document for a process change or system purchase with goals, scope, current and future state, numbered requirements and acceptance criteria. Use as a business analyst.
````markdown
A business requirements document (BRD) says what the business needs and how it will know the need is met, before anyone chooses a vendor or designs a solution. It is the document procurement, suppliers and approvers read, so ambiguity in it becomes cost later: change requests, disputes about what was promised, and systems that pass a demo but fail on the warehouse floor. Business analysis practice (the BABOK guide is the common reference) asks for requirements that are tied to a business objective, solution-neutral (what, not which product), unambiguous, testable, prioritised and traceable to a stakeholder. Words like "user-friendly", "fast", "flexible" or "seamless" are not requirements until they carry a measure. This prompt covers business processes and system purchases outside software development: phone systems, outsourcing, facilities, fleet, finance processes.
Write a business requirements document for this initiative.
[INITIATIVE]
[CURRENT_PROCESS]
1. If the business problem or the current process is too thin to derive needs from (no steps, volumes or pain points), ask up to four specific questions and stop.
2. If the initiative names a solution as the goal ("buy product X"), restate the underlying business need, record the named product as a constraint or a candidate, and keep the requirements solution-neutral.
3. Write the BRD with these sections:
1. Purpose and background: the problem in two or three sentences, with figures from the input.
2. Business objectives: two to five objectives, each measurable (metric, baseline, target, date) where the input allows; otherwise `[NEEDED: target]`.
3. Scope: in scope and out of scope as bullet lists; out of scope is as important as in.
4. Stakeholders: a table with stakeholder, role (sponsor, approver, user, consulted, informed), interest and how they are affected.
5. Current state: the process as numbered steps with volumes and pain points.
6. Future state: the process as it should work, at the same level of detail, without naming a product.
7. Business requirements: a table with ID (BR-01…), requirement as a "The solution shall…" statement, priority (Must, Should, Could, Won't for now), source stakeholder, rationale linked to an objective, and acceptance criterion (a concrete, testable condition).
8. Non-functional and service requirements: availability and support hours, capacity and volumes, security and data protection, retention and audit, accessibility, training, transition and exit (data return, notice), each with a measure.
9. Assumptions, constraints and dependencies.
10. Risks: the main risks with likelihood, impact and mitigation.
11. Approval: who signs off.
4. Number every requirement once and keep each to one testable need; split compound ones.
- Use only facts given; never invent volumes, costs, dates, regulations or stakeholder positions. Mark gaps `[NEEDED: …]` and list them under Open questions.
- Requirements are solution-neutral: no product names, vendors or design choices inside requirement statements.
- Every requirement has a measurable or observable acceptance criterion; reject vague words (fast, easy, intuitive, robust) unless quantified.
- Where data protection, employment, accessibility or sector rules plausibly apply, add a requirement to confirm compliance with the named area and mark it for legal or compliance review, without stating what a specific law requires.
- Concise: tables over prose; no padding sections that have no content (write "None identified").
## Business requirements document
The BRD with the numbered sections above.
## Open questions
Numbered questions, each with who can answer it.
## Requirements quality check
A short list of any requirement that is still vague, compound, untestable or not traced to an objective, with the fix, or "All requirements pass".
````
---
## Write a customer change notice
`write-customer-change-notice` · prompt · Business writing · https://hermes-ide.com/prompts/write-customer-change-notice
Tells customers about a change such as new hours, a move, a temporary closure or a discontinued product - what changes, when, why and what to do - across email, signs, posts and listings.
````markdown
Customers accept most changes when they hear about them early, plainly and from the business itself, and when the notice answers their real questions: what exactly is different, from when, does it affect me, what do I need to do, and what happens to what I already paid for. They are annoyed by notices that bury the change under "exciting news", dress up a reduction as an improvement, or leave them to discover the change at a locked door. Small businesses also need the same message to work across very different channels: an email, a door sign read in five seconds, a 160-character text, a social post, and an updated listing on maps and booking sites. Some changes carry notice obligations from consumer law, contracts or subscription terms.
Write a customer change notice. Effective: [EFFECTIVE_DATE].
[CHANGE]
1. If it is unclear what is changing, ask and stop. For a move, also stop and ask if the new address or the dates are missing. If a date is uncertain (a reopening that depends on works, an inspection or a permit), write "we'll confirm the date" instead of guessing and plan a second notice.
2. If the change is a price increase, write the notice but add under Checklist that price changes are better planned with segment impact and grandfathering in mind, and keep the wording factual.
3. Email:
- Subject: the change and the date, plainly ("From 1 February we're closed on Mondays").
- First two sentences: what changes and from when, and whether customers need to do anything.
- What stays the same, as a short line or list.
- The reason in one or two honest sentences, if given. Do not invent one.
- What customers need to do, with deadlines, and what happens to existing bookings, credit, gift cards, subscriptions or orders, using only the facts given or `[need: …]`.
- Alternatives or replacements if offered, and where to ask questions.
- A sincere thank-you; one line acknowledging inconvenience if the change takes something away.
4. Other channels: for each channel listed (or website banner and door sign by default), a version fitted to it: a door sign of at most about 25 words in large-print style; a website banner of one line; an SMS under 160 characters including the business name; a social post of two to four sentences. Keep the date and the key fact identical across all versions. For a move or temporary closure, customers miss single posts, so write a short sequence instead of one post: the announcement, a reminder a week before, the last day, the first day at the new place or back open, and a "we've moved" post for the weeks after. Each leads with the change, not a story.
5. FAQ: three to five questions customers will actually ask, with answers from the input or `[need: …]`, short enough for staff to say at the counter or on the phone ("are my bookings still on?", "do my vouchers work?").
6. Checklist: when to send relative to the effective date (at least the notice period in any contract or terms, and generally the earlier the better), a reminder a few days before, briefing staff, every place the hours or address live (map listings such as Google Business Profile, website footer and contact page, booking system, delivery apps, social bios, email signature, voicemail, invoices) with the exact line to paste, and checking any notice obligations in the terms or consumer rules with an adviser if unsure. For a move, keep a sign at the old premises for some weeks afterwards.
7. Timeline: when each message goes out relative to the effective date.
- Email under about 180 words.
- Use only facts given; never invent reasons, dates, compensation, refunds or alternatives. Use `[need: …]`.
- Never present a reduction (fewer hours, a smaller product, a discontinued service, a higher price) as an improvement. If the input asks for that, write it honestly and note why under Checklist.
- Dates are written with weekday and date and are identical everywhere.
- Plain, warm language; no "exciting news" for a reduction, no corporate euphemisms.
- If the reason is personal (illness, bereavement, a dispute), keep it brief or leave it out unless the owner wants it shared.
- State accessibility of new premises only as supplied; if it is missing for a move, list it under FAQ as `[need: …]`, because customers will ask.
## Email
Subject line, then the body.
## Other channels
A sub-heading per channel with its version.
## FAQ
Questions and answers.
## Checklist
Bullets.
## Timeline
Table: When | Channel | Message.
````
---
## Write a decision memo
`write-decision-memo` · prompt · Business writing · https://hermes-ide.com/prompts/write-decision-memo
Writes a one-page decision memo with the decision needed and by when, context, options with honest trade-offs, a recommendation and next steps. Use when asking a manager to approve something.
````markdown
A decision memo exists to get a clear yes, no or choice from a busy person in a few minutes. It fails when the decision is buried under background, when the options are a straw man next to the favourite, when costs and risks are vague, or when the reader has to write back to ask what exactly they are approving. Good memos put the ask and the deadline in the first lines, compare real options on the same criteria, admit the downside of the recommendation, and say what happens next under each answer.
Write a one-page decision memo.
[SITUATION]
1. If you cannot tell what decision is needed or the situation gives no facts to weigh (only feelings or a general complaint), ask up to three short questions and stop. Missing options are not a reason to stop: propose them in step 4. A missing decision-maker is not either: address the memo to `[NEEDED: decision-maker]`, write for a busy senior reader who knows the business but not this issue, and say so under Gaps.
2. State the decision as one question with a yes, no or choice answer, and the date it is needed by (with the reason for that date, such as a notice period or a release date in the situation). If no date can be derived, mark `[NEEDED: decide-by date]`.
3. Write the context the decision-maker needs and nothing more: three to six sentences on what is happening, why it matters now, and the cost of not deciding. Fit it to what the decision-maker already knows and cares about.
4. Lay out two to four genuine options. Always include "do nothing" or "delay" if it is realistic. Compare them on the same criteria (cost, benefit, risk, time, reversibility, effect on people or customers), using only figures from the situation and marking unknowns.
5. Recommend one option and give the deciding reason in one or two sentences. Name its main downside and how it will be managed. If the facts do not support a clear recommendation, say what would settle it.
6. Write next steps if approved: who does what by when, and the first checkpoint where the decision could be revisited.
- One page: about 350 to 500 words for the memo itself.
- Use only the facts supplied. Never invent costs, dates, percentages or names; mark each gap `[NEEDED: …]` and list it.
- Present options fairly. Do not weaken the alternatives to make the recommendation look better; if an option is clearly not viable, say why in one line.
- Plain, neutral language. No hype, no hedging, no "synergies". Numbers in figures, with units.
- If the decision touches legal, HR, safety or regulatory obligations, note who must also sign off.
## Memo
**To / From / Date / Decision needed by** (names and dates from the situation, otherwise `[NEEDED: …]`)
**Decision needed:** one question.
**Recommendation:** one sentence.
**Context:** short paragraph.
**Options:** a table with options as rows and the criteria as columns, then one line per option on its main risk.
**Why this recommendation:** two to four sentences, including its downside.
**Next steps if approved:** numbered, each with owner and date.
## Gaps to fill
Each `[NEEDED: …]` with what it is and where to get it. "None" if none.
## Before you send
Two or three checks specific to this memo (for example "confirm the vendor price is still valid").
````
---
## Write a formal letter
`write-formal-letter` · prompt · Business writing · https://hermes-ide.com/prompts/write-formal-letter
Writes a formal letter to a bank, council, school, supplier or official body in the layout and conventions of the chosen country, with a clear purpose, references and a specific request.
````markdown
Official bodies, banks and suppliers process letters by reference number and by the request in the first paragraph. A formal letter works when the clerk who opens it can see in ten seconds who is writing, which file it concerns and what action is being asked for by when. Layout and etiquette signal care, and getting them wrong in another country (a comma after "Mit freundlichen Grüßen", "Yours sincerely" after "Dear Sir or Madam", a missing "Objet") makes the writer look careless.
Conventions to apply:
- **us:** block format; sender address (or letterhead), date as "October 3, 2026", inside address, optional "Re:" line, "Dear Ms. Rivera:" (colon), body, "Sincerely," then name; "Enclosures:" line if any.
- **uk:** sender address top right or letterhead, date as "3 October 2026", recipient address on the left, "Dear Ms Rivera," (no full stop after titles) closing "Yours sincerely,"; "Dear Sir or Madam," closing "Yours faithfully,"; optional bold subject line after the salutation.
- **de (DIN 5008):** sender line and recipient address field top left, information block or date on the right ("3. Oktober 2026" or "03.10.2026"), reference line ("Ihr Zeichen", "Kundennummer"), bold subject line without the word "Betreff", "Sehr geehrte Frau Müller," or "Sehr geehrte Damen und Herren," then the first sentence starting in lower case, closing "Mit freundlichen Grüßen" with no comma, "Anlagen" listed at the end.
- **fr:** sender block top left, recipient block on the right, "À Paris, le 3 octobre 2026", "Objet :" line, optional "Références :", salutation "Madame," / "Monsieur," / "Madame, Monsieur,", a full closing formula that repeats the salutation ("Je vous prie d'agréer, Madame, Monsieur, l'expression de mes salutations distinguées."), signature, "Pièces jointes :".
- **br:** place and date "São Paulo, 3 de outubro de 2026", recipient block, "Assunto:" line, "Prezado Senhor," / "Prezada Senhora," or "Prezados Senhores," (use "Ilustríssimo Senhor" only for very formal public bodies), closing "Atenciosamente," then name and CPF or CNPJ if relevant.
- **generic:** neutral international block format, date written out with the month as a word, subject line, "Dear …," and "Yours sincerely,".
Write a formal letter for this purpose, to [RECIPIENT], using the generic convention.
[PURPOSE]
1. If the purpose is unclear (you cannot tell what the recipient should do), ask one or two questions and stop.
2. Language: for de, fr and br, write the letter in German, French or Brazilian Portuguese unless the user asks otherwise, and give an English line-by-line gist under Translation notes so the sender knows what they are signing. For us, uk and generic, write in English unless the purpose is written in another language, in which case use that language.
3. Structure the body:
- Opening paragraph: who you are in relation to the recipient (customer, resident, parent, supplier) and the purpose in one or two sentences, with the reference numbers.
- Middle: the relevant facts in date order, short and verifiable, with amounts and dates exactly as supplied.
- Request: the exact action, the deadline for it and, if useful, how to reply (address, email, phone placeholder).
- Close: enclosures and one courteous line; no grovelling, no threats unless the user explicitly wants a firm notice, in which case state the next step calmly.
4. Fill the layout for the chosen convention. Use placeholders in square brackets (`[Your full name]`, `[Customer number]`) for anything not supplied. Never invent account numbers, names, addresses, dates or legal references.
5. Choose the salutation and closing correctly for whether a named person is known.
- One page: body under about 300 words.
- Formal but plain. Short sentences. No idioms that do not translate.
- If the letter cancels a contract, disputes a charge, responds to an official decision or has a legal deadline, say under Before you send that deadlines, notice periods and the right form of delivery (registered post, signature, online portal) should be checked, without asserting what they are.
- Do not cite laws, articles or regulations unless the user supplied them.
## Letter
The complete letter in a code block or as plain text with line breaks, laid out top to bottom as it should be printed.
## Translation notes
For de, fr and br: an English gist of each paragraph and any etiquette choice explained in one line. Otherwise "Not applicable".
## Before you send
Bullets: placeholders to fill, enclosures to attach, signature, delivery method to consider, and any deadline to check.
````
---
## Write a handover document
`write-handover-document` · prompt · Business writing · https://hermes-ide.com/prompts/write-handover-document
Writes a handover for leave or a role change covering responsibilities, open work status, contacts, access, recurring tasks, known risks and first-week priorities, with gaps listed as questions.
````markdown
A handover is read by someone covering work they did not build, often in a hurry, on the day something goes wrong. It fails when it is a diary of history instead of a guide to action, when "status" means "in progress" with no next step, when access and passwords are an afterthought, and when the knowledge that lives only in the leaver's head (the client who needs a call not an email, the report that breaks every quarter-end) never gets written down. A good handover is organised by what the reader must do, says who decides what, and is honest about what is unfinished.
Turn these notes into a handover document.
[ROLE_AND_WORK]
1. If the notes do not say what the role is or list any current work, ask for them and stop.
2. Sort everything in the notes into the sections below. Do not drop anything; if an item fits nowhere, put it under "Other notes".
3. For each open piece of work, state: what it is, current status in one line, the very next action, the owner from the handover date, the deadline, and where the files or tickets live. If any of these are missing, write `[ASK: …]` in that cell.
4. Separate decisions the cover person can make alone from ones that need someone else, and name that person or role.
5. Build a calendar of recurring tasks (daily, weekly, monthly, quarterly) with the date of the next occurrence if the handover date allows it.
6. Pull out the tacit knowledge: workarounds, quirks, sensitive relationships and "if X happens, do Y" rules, and write each as a short instruction.
7. Write the first-week priorities: the three to five things the cover person must do or check first.
- Never put passwords, keys, tokens or personal data in the document. Say where access is managed (password manager, IT ticket, admin) and who grants it; if the notes contain a secret, leave it out and warn about it in Questions before you go.
- Use only facts from the notes. Do not invent names, dates, systems or statuses.
- Keep it scannable: tables for open work, contacts and recurring tasks; short bullets elsewhere. Write for someone who has never seen this work.
- Be neutral and factual about colleagues and clients; describe working preferences, not personalities.
## Handover
**Summary:** role, handover period, cover person or `[ASK]`, and how to reach the leaver if at all (or "do not contact").
**First-week priorities:** numbered.
**Open work:** table: Work | Status | Next action | Owner | Deadline | Where it lives.
**Responsibilities:** bullets, marking which are delegated, paused or covered by whom.
**Decisions:** two lists: "You can decide" and "Escalate to …".
**Recurring tasks:** table: Task | Frequency | Next due | How | Where.
**Contacts:** table: Name or role | What for | Notes on working with them.
**Access and tools:** table: System | What it is used for | How to get access.
**Known risks and quirks:** bullets with "if this happens, do this".
**Other notes**
## Questions before you go
Every `[ASK: …]` gathered into one list for the leaver to answer, plus any warning about secrets found in the notes.
## Handover meeting agenda
A 30 to 45 minute agenda for walking the cover person through it.
````
---
## Write a letter of support
`write-letter-of-support` · prompt · Business writing · https://hermes-ide.com/prompts/write-letter-of-support
Writes a letter of support for a grant, planning application, partner organisation or community project with specific commitments and evidence of need, to be signed by an organisation or leader.
````markdown
Funders, panels and committees read many letters of support and discount the generic ones: "we fully support this excellent project" from a body that commits nothing and knows little. The letters that count show a real relationship, add evidence of need the applicant could not provide alone (the supporter's own waiting list, referral numbers or local knowledge), and make specific, quantified commitments. Panels also notice when several letters share the same wording, so each should read as the supporter's own. A letter of commitment, which binds the supporter to cash or resources, carries more weight and must be signed by someone with authority to commit. Planning committees can only weigh material planning considerations (such as design, amenity, traffic, community benefit), so support for a planning application should speak to those rather than to personal loyalty.
Write a letter of support to [RECIPIENT] from [SUPPORTER].
[PROJECT]
1. If the project or the supporter's relationship to it is unclear, ask up to two questions and stop.
2. Layout: the supporter's letterhead placeholder, date, the recipient's name and address placeholders, and a reference line with the project title and the funding call or application reference.
3. First paragraph: who the supporter is (one sentence of standing: what they do, scale, area) and the statement of support for the named project and applicant.
4. Relationship: how long and in what way the supporter has worked with the applicant, with one concrete example from the input.
5. Need: the evidence of need from the supporter's own vantage point, with figures from the input. If none is given, write `[need: one figure or observation from your own work, e.g. waiting list, referrals]` rather than inventing one.
6. Commitments: each commitment as a specific, quantified line (what, how much, when, for how long). If none is given, keep the letter to support only, do not imply resources, and suggest under Notes what commitments would strengthen it.
7. For a planning application, frame support around material considerations named in the input (community benefit, design, accessibility, local employment) and avoid irrelevant ones.
8. Close: the expected benefit in one or two sentences and a contact for verification, then a signature block with name, title and organisation placeholders as needed.
- One page: about 250 to 400 words.
- Use only facts given. Never invent statistics, history, outcomes or commitments, even if asked to make the case stronger; use `[need: …]` placeholders and explain under Notes.
- Write in the supporter's voice, specific to them; avoid stock phrases ("wholeheartedly support", "excellent initiative", "will make a real difference") unless backed by a fact in the next sentence.
- Do not overstate the supporter's authority or describe the letter as a binding commitment unless the input says it is one.
## Letter
The letter, ready for letterhead.
## For the signatory to confirm
Bullets: each commitment, figure and claim the signatory must check, and that they have authority to commit.
## Notes
Placeholders, suggestions to strengthen it, and anything left out on purpose. "None" if nothing.
````
---
## Write a letter to an elected official
`write-letter-to-elected-official` · prompt · Business writing · https://hermes-ide.com/prompts/write-letter-to-elected-official
Writes a letter or email to an elected representative about an issue with the ask, the local impact, a personal story and evidence, in a form constituent offices act on. Use as a citizen or advocate.
````markdown
Elected representatives' offices sort correspondence by whether the writer is a constituent, which issue it concerns and what is asked. Staff tally positions on bills and pass on stories that illustrate local impact; research on legislative offices (the Congressional Management Foundation's surveys of US congressional staff are the best known) consistently finds that individualised messages from constituents, with a specific ask and a personal story, influence offices far more than identical form letters. Many representatives only reply to their own constituents, so a full postal address matters. Letters work when they cover one issue, state the ask in the first lines (with a bill number or decision name if there is one), show the local effect, include a short true story and one or two pieces of evidence with sources, stay respectful, and ask for a reply. Casework, meaning help with a personal problem with a government agency, is a different request from a policy view and needs the case details and often a consent form.
Write a letter to [REPRESENTATIVE] about this issue, from a constituent in [LOCATION].
[ISSUE]
Ask: [ASK]
1. If the ask is unclear or covers several unrelated issues, ask which single issue and action matter most and stop.
2. If no representative is named, address the letter to `[Representative name and title]` and explain under Before sending how to find the right one from the location (the official parliament, congress, state or council "find your representative" lookup by postcode or ZIP code), and which level of government handles this issue.
3. Decide whether this is a policy letter or a casework request. For casework, structure it around the case: reference numbers, dates, what has been tried, the help needed, and a note that the office may ask for a signed consent form.
4. Write the letter:
- Salutation in the form used for that office in the country implied by the location (for example "Dear Senator Lopez", "Dear Jane Smith MP" or "Dear Ms Smith"), or a neutral placeholder if unsure.
- First paragraph: "As a constituent in [town, postcode]…", the issue, and the specific ask (with bill number or decision name).
- Local impact: how it affects people in the area, from the input.
- Personal story: a few sentences in the writer's voice, from the personal connection only. If none is given, write `[need: two or three sentences on how this affects you]` rather than inventing one.
- Evidence: one or two facts with their source, only if in the input, or `[need: one fact with source]`.
- Close: restate the ask, request a reply stating the representative's position or action, and thank them.
- Signature block with full name, postal address, email and phone placeholders.
5. Write a 30-second phone script for calling the office with the same ask.
- Under about 300 words for the letter; one issue only.
- Use only facts and stories from the input; never invent statistics, bill numbers, quotes or personal experiences.
- Respectful and firm, whatever the representative's party or record: no insults, threats, sarcasm or electoral ultimatums phrased as threats. A plain statement that the issue will matter to the writer's vote is acceptable. If the input asks for threatening or abusive wording, write a firm, respectful version and note why under Before sending.
- Non-partisan framing: argue from the issue and its impact, not from party identity.
## Letter
The letter with signature block.
## Phone script
About 75 words.
## Before sending
Bullets: how to verify the representative and the bill's current status, placeholders, the best channel (the office's web form or email often reaches staff faster than post), and anything changed on purpose.
````
---
## Write a one-page job aid
`write-job-aid` · prompt · Business writing · https://hermes-ide.com/prompts/write-job-aid
Writes a one-page job aid or quick-reference card for a frontline task with numbered steps, decision points, warnings placed where they matter and pictures to add, readable at a glance.
````markdown
A job aid is not a procedure. A procedure explains the whole process, why, and who is responsible; a job aid is the one page someone looks at in the middle of doing the task, often under time pressure, standing up, maybe in a second language. Good job aids show only what is needed at the moment of action: a clear title, what you need before you start, numbered steps with one action each, decisions written as "If ... then ...", warnings placed immediately before the step they apply to, and a "something went wrong" box with a name or number to call. Pictures carry a lot of the load for physical tasks.
Task: [TASK]
Users and conditions: [USERS]
[STEPS]
1. Read the steps and list anything ambiguous, missing or contradictory (an unclear order, an undefined term, a decision with no rule, no contact for problems). If the gaps make it impossible to write a safe aid, ask about them and stop; otherwise continue and mark each gap [CHECK] in place.
2. Write the job aid:
- Title: the task as a verb phrase.
- Use when: one line saying when this applies and when it does not.
- Before you start: the items, access or checks needed.
- Steps: numbered, one action per step, each starting with a verb, with the key word or button in bold. Aim for no more than about ten steps; if the task needs more, split it into phases with subheadings or suggest a second card.
- Decision points: write as "If ... then go to step N" or a two-column If / Then table.
- Warnings: CAUTION for risk of mistakes or damage and STOP for risk to people's safety, placed directly before the step they apply to, saying what to do instead.
- Done when: how the person knows the task is complete.
- Something went wrong: the most common problems and who to contact.
- Footer: owner, version and date, next review [X].
3. Adapt to the users and conditions: shorter words and sentences for second-language readers, larger type and fewer words if read from a distance or on a phone, and steps that make sense if the reader glances away.
4. Picture plan: for each step that would benefit, the photo or icon to add, what it must show, and where it goes.
5. Questions for the process owner: the gaps marked [CHECK] as direct questions.
6. Before answering, check the aid against the source steps: nothing added that was not in the source except formatting and clarifications marked [CHECK], every warning sits before its step, and it would fit one printed page.
- Do not invent steps, settings, values, part numbers or contacts. If the source does not give it, mark it [CHECK].
- Plain words. Avoid jargon unless the users use it, and then use it consistently.
- For tasks with safety, clinical, food-safety or legal consequences, add a line at the top that the aid must be checked by the responsible person before use.
- Keep the full procedure out; if important context does not fit, list it as something to put in training or the full procedure (write-sop) instead.
## Job aid
The card itself in Markdown, ready to paste into a document and print.
## Picture plan
Table: Step | Picture or icon | Must show.
## Questions for the process owner
Numbered.
````
---
## Write a professional bio
`write-professional-bio` · prompt · Business writing · https://hermes-ide.com/prompts/write-professional-bio
Writes the bio others read or say about you on speaker pages, programmes, proposals, author notes and team pages, at one-line to long lengths, angled to that reader and built only from your facts.
````markdown
A professional bio is usually read or spoken by someone else on your behalf: the conference programme, the host who introduces you, the proposal a client's board skims, the note at the back of a book. It answers one question for that reader: why should I listen to, hire or trust this person for this? Weak bios list job titles in date order, stack adjectives ("passionate, results-driven, visionary") and read the same for every audience. Strong ones lead with what the person does and for whom, give two or three proofs that matter to this reader (a result with a number, a body of work, a credential this audience respects), and end with one specific human detail or what the person is working on now. The same career yields different bios for a hospital board and a design meetup, because the proof each reader cares about differs. Character-limited social profiles (Instagram, X, LinkedIn headline) are a different job with platform limits; this prompt does not write them.
Write professional bios for: general professional audience. Point of view: third.
[BACKGROUND]
1. If the background lacks the person's name, current role, or anything concrete to prove it (a result, a body of work, a credential, years in a field), ask for what is missing in up to three short questions and stop. If the audience is a character-limited social profile, say that a platform bio written to that site's character limit fits better, then write only the one-liner and short bio.
2. Choose the angle: the one thing this reader most needs to know about the person, in one sentence. Pick the two or three proofs from the background that support it best for this reader, and leave the rest out rather than listing everything.
3. Write each length in the requested point of view. In third person, use the full name first, then the stated pronouns, or the surname or first name again (matching the register) if pronouns are not given:
- **One-liner:** up to 25 words, for a badge, byline or slide.
- **Short:** 50 to 70 words, for programmes and directories.
- **Medium:** 100 to 150 words, for speaker pages and proposals.
- **Long:** 200 to 250 words, for an about or team page, with a little more story and one personal detail if supplied.
4. Open every version with what the person does and for whom, not a date or a title list. End the medium and long versions with something specific and human from the background, or what the person is working on now.
5. Write a 20- to 30-second introduction (about 50 to 70 words) a host can read aloud: spoken rhythm, the name said last as the cue to walk on, nothing hard to pronounce without a marker.
- Use only facts in the background. Never invent clients, numbers, awards, publications, degrees or employers. Do not inflate: "contributed to" stays "contributed to", and "led" only when the background says so. If the person asks for claims the background does not support, leave them out and say why in Gaps.
- No empty adjectives (passionate, dynamic, visionary, results-driven, thought leader) unless a fact proves them, and then use the fact instead.
- Keep job titles and organisation names exactly as given.
- Do not include personal details the person did not offer, such as family, age, health or location.
- Match the register of the audience: formal for a board proposal, warmer for a community event. Hit each word range and show the count.
## Angle
One sentence, then the proofs chosen and why they matter to this reader.
## One-liner
## Short bio
With word count.
## Medium bio
With word count.
## Long bio
With word count.
(With `both`, give the third-person version, then the first-person version, under each heading.)
## Introduction to read aloud
The spoken introduction, with `[pronunciation?]` after any name the host should check.
## Facts used
Bullets mapping each claim to the part of the background it came from.
## Gaps
Unsupported requests left out, and details that would strengthen the bio (a number, a client type, a credential) as questions. "None" if none.
````
---
## Write a project close-out report
`write-project-closeout-report` · prompt · Business writing · https://hermes-ide.com/prompts/write-project-closeout-report
Writes a close-out report for a non-software project covering objectives against results, budget and schedule variance, lessons learned and a handover of every open item to a named owner.
````markdown
A close-out report lets the sponsor formally accept the project, release the team and budget, and know who now owns what is left. It is also the organisation's memory: the next similar project (an office move, an event, a building refurbishment, a process change, a marketing campaign) should start from its lessons. Close-out reports go wrong when they are a victory lap, when variance is hidden or computed wrongly, when lessons are generic ("communication could be better"), and when open items are listed with no receiving owner, so they quietly die once the team disbands.
Variance conventions to apply and show:
- Schedule variance: actual end date minus planned end date, in days or weeks, and as a percentage of planned duration.
- Budget variance: actual cost minus approved budget, in currency and as a percentage of the approved budget. State whether the budget figure is the original or the re-baselined one, and give both if both exist.
Write a project close-out report for sponsor.
[PROJECT_NOTES]
1. If neither the notes nor the original goals say what the project set out to achieve, ask for the objectives and approved budget and dates, then stop.
2. Compare each objective with the result: met, partly met or not met, with the evidence. If an objective can only be judged later (savings, satisfaction, adoption), mark it "to be measured", with when, how and who owns the measurement.
3. Report scope: delivered as planned, added, removed or deferred, each with the reason and who approved the change if known.
4. Compute schedule and budget variance using the conventions above. Show the arithmetic under Calculations. If figures are missing, use `[need: …]` and do not estimate.
5. Write lessons learned that the next project can act on. Each lesson states what happened, the effect, and a specific recommendation ("Book the venue's technical walkthrough four weeks before the event; this year it was three days before and the projector wiring had to be redone"). Include what worked well, not only problems. No blame on individuals.
6. List every open item (snags, warranty claims, outstanding invoices, documents, follow-up work, risks still live) with the receiving owner, due date and where the supporting information lives.
7. Write a summary the sponsor can read alone: overall outcome in one sentence, headline variance, the most important lesson, and what you need from the sponsor (acceptance, a decision on an open item, closing the budget code).
- Use only the supplied facts. Never invent figures, dates, approvals or feedback.
- State bad news plainly: an overrun is an overrun, with its cause, not "a reallocation".
- If the notes contradict each other (two different final costs), show both and ask which is right instead of picking one.
- Body under about 900 words; detail goes in tables.
## Close-out report
- **Summary**
- **Objectives and results:** table with Objective · Target · Result · Status · Evidence.
- **Scope:** table with Item · Change (delivered, added, removed, deferred) · Reason · Approved by.
- **Schedule and budget:** table with Measure · Planned · Actual · Variance · Variance % · Comment.
- **Benefits to be measured:** table with Benefit · Measure · When · Owner. Omit if none.
- **Lessons learned:** grouped under What worked and What to change, each with a recommendation.
- **Open items and handover:** table with Item · Receiving owner · Due · Where the information is.
- **Sign-off:** what is requested from sponsor and a line for acceptance.
## Calculations
The variance arithmetic, line by line.
## Missing information
Bullets: each `[need: …]` and each contradiction to resolve. "None" if complete.
````
---
## Write a project proposal or business case
`write-project-proposal` · prompt · Business writing · https://hermes-ide.com/prompts/write-project-proposal
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.
````markdown
A proposal is a request for a decision. Approvers ask the same questions every time: what problem, how big, what happens if we do nothing, what else could we do, what will it cost, what do we get and when, what could go wrong, and what exactly are you asking for. Proposals fail when they sell a single solution without alternatives, state benefits with no basis, hide the cost of people's time, or leave the ask vague. A credible business case shows its assumptions so the approver can challenge them.
Write a proposal for [AUDIENCE] based on this idea:
[IDEA]
1. If the idea does not say what problem it solves or what is being asked for, ask up to three short questions and stop.
2. State the problem in the approver's terms (money, time, risk, customers, staff), with evidence from the input, and the cost of doing nothing over a stated period.
3. Lay out at least three options, always including "do nothing" and one smaller or cheaper alternative. Compare them on cost, benefit, time to value, risk and effort from existing staff.
4. Recommend one option and give the deciding reason in one sentence.
5. Cost the recommendation: one-off and recurring costs, and people's time. Use figures from the input; where a figure is missing, write `[need: …]` and say who could supply it.
6. State benefits as measurable outcomes with a basis ("saves about 6 hours a week, based on the 120 tickets a month in the data"). Label anything without a basis as an estimate and record the assumption.
7. List the main risks with likelihood, impact and a mitigation for each, and name any dependency on other teams.
8. Define success: two or three measures, the current baseline and the target, and when you will report back.
9. End with the specific ask: what decision, how much money or how many people, by when, and the first step after a yes.
- Never invent numbers, quotes, vendors or results. Every figure is from the input, a calculation from input figures shown in Assumptions, or a `[need: …]` placeholder.
- Tailor emphasis to [AUDIENCE], but do not drop risks or costs to make the case look better.
- Keep the proposal to about two pages (roughly 800 to 1,000 words). Lead with a three-sentence summary: problem, recommendation, ask.
- Plain language and active voice; define any acronym the audience may not know.
## Proposal
Sections in this order: Summary · Problem and cost of inaction · Options considered (table: Option | Cost | Benefit | Time to value | Risk | Effort) · Recommendation · Cost and resources · Benefits · Risks and mitigations (table) · Success measures · The ask and next steps.
## Assumptions
Numbered: each assumption or calculation behind a figure, with the input it came from.
## Gaps to close before sending
Bullets: each `[need: …]` placeholder, plus the hardest question the approver is likely to ask that the proposal cannot yet answer.
````
---
## Write a project status report
`write-status-report` · prompt · Business writing · https://hermes-ide.com/prompts/write-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.
````markdown
A status report exists so that people outside the work can spot trouble early and make the decisions only they can make. The classic failure is the "watermelon" report: green on the outside, red inside, because the author reports activity instead of progress against the plan, or softens bad news. Readers want the status and the reason in one line, then what needs their attention.
RAG definitions to apply:
- **Green:** on track for the committed scope, date and budget; no help needed.
- **Amber:** at risk; the team has a credible recovery plan within its own control, or a decision is needed soon to stay on track.
- **Red:** will miss scope, date or budget without intervention, a decision or extra resources from outside the team.
Write a email status report for project stakeholders from these updates:
[UPDATES]
1. If the updates contain no information about progress against a goal or date, ask what the milestones and dates are and stop.
2. Set the overall RAG status from the evidence using the definitions above, not from the tone of the notes. If the notes imply green but contain a slipped milestone, an unresolved blocker past its date or a budget overrun, rate it accordingly and explain why in Status rationale.
3. Separate progress (outcomes delivered against plan) from activity (meetings held, work started). Report progress.
4. List risks and issues with impact, owner and the next action with its date. An issue is happening now; a risk might happen.
5. Pull out every decision or help needed from the readers, with who must decide and by when. If none, say "None this period".
6. List next steps for the coming period with owners.
7. Render for the format:
- email: a subject line in the form "[Project] status: – ", then in this order: one line with the status and the reason; Decisions needed; Progress (three to five bullets); Risks and issues; Next steps. A reader should absorb it in 60 seconds.
- doc: short headings in this order: Summary (status, reason, and the change since last period) · Decisions needed · Milestones (table: Milestone | Planned date | Forecast date | Status) · Progress · Risks and issues (table: Item | Risk or issue | Impact | Owner | Next action and date) · Next steps.
- slide: an assertion-style title that states the status and the reason (for example "Amber: content migration is 30 points behind; decision needed by Friday"), then at most six bullets, decisions first.
If the project name or reporting period is missing, use `[need: project name]` or `[need: period]` rather than guessing.
- Use only facts from the updates. Missing owners, dates or figures become `[need: …]`; never invent them.
- Lead with status and decisions; no "Hope everyone had a great week".
- Name problems plainly and without blame: describe what happened and its impact, not who failed.
- Keep it short: under 250 words for email and slide, under 500 for doc.
## Status report
The report in the chosen format.
## Status rationale
Two or three sentences: why this RAG status, citing the evidence, and whether it differs from what the notes implied.
## Missing information
Bullets: each `[need: …]` placeholder. "None" if complete.
````
---
## Write a public consultation response
`write-public-consultation-response` · prompt · Business writing · https://hermes-ide.com/prompts/write-public-consultation-response
Writes a response to a government or regulator public consultation that answers the published questions in order, states the respondent's position with evidence and proposes concrete changes.
````markdown
Officials who analyse consultation responses usually code them question by question, often in a spreadsheet, counting positions and extracting evidence and specific proposals. A response has influence when it is easy to code (it answers each numbered question under that number, with a clear position), when it brings evidence the officials do not already have (data, costs, real cases, the experience of the people the respondent represents), and when it proposes a specific, workable change to the text or design of the proposal. Responses that restate the respondent's general views, attack motives, ignore the questions, or overstate evidence are discounted, and identical campaign letters are typically counted once.
Draft a consultation response.
[CONSULTATION_QUESTIONS]
[RESPONDENT_POSITION]
1. If the questions are missing, or you cannot tell what the respondent wants, ask for them and stop.
2. Write a short respondent statement: who is responding, whom they represent and how many, their relevant experience, and any interest to declare. Use placeholders for details not supplied.
3. Write a summary of the response in four to six bullets: the overall position and the most important changes sought.
4. Answer every question under its own number and wording, in order:
- Start with a clear position where the question invites one (Agree, Disagree, Partly agree, Do not know, or the answer options the consultation gives).
- Give the reasons, most important first, each supported by evidence from the input with its source.
- Describe the practical impact on the people the respondent represents (costs, time, risks, unintended consequences), quantified where the evidence allows.
- Propose a specific change: revised wording, a threshold, a transition period, an exemption or an alternative mechanism. Say what problem the change solves.
- Acknowledge the policy aim and any trade-off honestly; officials discount responses that pretend there is none.
If the respondent has no view or evidence on a question, write "No response" rather than padding.
5. Respect word limits per question or overall; if the evidence will not fit, prioritise the questions most central to the respondent's position and say which were shortened.
- Use only the evidence supplied. Never invent statistics, studies, cases, quotes or legal references. Where a claim would need evidence that is not given, mark it `[evidence needed: …]`.
- Distinguish data from anecdote and from opinion in the wording ("in a survey of 212 members, 64% said…" versus "several members told us…").
- Respectful and precise; no attacks on officials or other stakeholders.
- Responses are often published. Flag anything in the input marked confidential or that identifies individuals, and keep it out of the main response unless the user says otherwise.
- This is drafting help, not legal advice. If the proposal has legal consequences for the respondent, note that a legal adviser should review the position before submission.
## Response
Respondent statement · Summary · Answers by question number (heading = number and question text).
## Evidence used
Table: Claim · Question number · Source from the input · Type (data, case, expert view, member experience).
## Gaps and risks
Bullets: `[evidence needed: …]` items, questions left unanswered, possible weaknesses officials may probe, confidentiality flags, and the deadline and submission route if given.
````
---
## Write a recognition message
`write-recognition-message` · prompt · Business writing · https://hermes-ide.com/prompts/write-recognition-message
Writes public recognition for a colleague or team, such as a channel shout-out or an all-hands mention, naming the specific contribution and its impact rather than generic praise.
````markdown
Recognition motivates when it is specific, timely and credible: it names what the person did, the effect it had, and what it says about how they work. "Great job, rockstar!" tells the person nothing and tells everyone else that recognition is a formality. Public recognition also has social risks the writer has to manage: leaving out quieter contributors, implicitly comparing people, praising heroics that came from poor planning in a way that encourages more of them, or putting someone who dislikes attention on the spot. The best messages are short, concrete and generous to everyone who helped.
Write a chat recognition message for [PERSON_OR_TEAM].
[CONTRIBUTION]
1. If the contribution is generic ("always great", "works hard"), ask for one specific thing they did and what it led to, and stop.
2. Structure the message as: who, what they did (specific actions, not traits), and the impact on customers, colleagues or the organisation. Add one line on what it shows about how they work only if the input supports it.
3. Credit everyone named as contributing. If the input suggests one person did most of the work in a team, recognise the team and name that person's specific part without ranking the others.
4. If the contribution involved working excessive hours or weekends, thank the effort without celebrating overwork as the norm (praise the outcome and the judgement, not the hours).
5. Fit the channel:
- chat: two to four sentences, with @mentions as placeholders, and one emoji at most.
- email: a short paragraph, suggest copying their manager, subject line included.
- all-hands: 30 to 45 seconds spoken (about 80 to 110 words), written for the ear, ending with an invitation to applaud or thank them.
- card: two or three warm, personal sentences.
6. Under Check before posting, remind the sender to confirm the person is comfortable with public recognition (if not, send it privately), and to check nobody who contributed is missing.
- Use only the facts given; never invent numbers, quotes or details of the work. If impact is unknown, describe the contribution and leave impact out rather than guessing.
- No clichés or superlatives: "rockstar", "ninja", "above and beyond", "crushing it", "the best team ever".
- No comparison with other people or teams ("unlike some…").
- Sincere, plain and short; the facts carry the praise.
## Message
The message, ready to post (with subject line for email).
## Check before posting
Two or three bullets.
Weak: "Huge shout-out to Priya for going above and beyond as always! You're a rockstar!"
Strong: "Thank you @Priya for rebuilding the returns process over two weekends after the warehouse flood. Because of it, no customer waited more than two days for a refund during the worst week of the year."
````
---
## Write a report to a charity board
`write-trustee-board-report` · prompt · Business writing · https://hermes-ide.com/prompts/write-trustee-board-report
Writes a report to a charity or nonprofit board with progress against plan, finances in brief, risks, safeguarding, decisions needed and papers to note, built only from the figures supplied.
````markdown
You write reports from a charity or nonprofit's staff lead to its board of trustees or directors. Trustees are volunteers who read board papers in an evening; they carry legal responsibility for the organisation and need to see quickly what has changed, whether the organisation is on track and solvent, what could go wrong, whether people are safe, and what the board must decide. Weak board reports are long operational diaries, hide bad news in the middle, give numbers without comparison to budget or plan, mix items for decision with items for information, and leave safeguarding as a line saying "nothing to report" without saying what was checked.
Period: [PERIOD]
From: chief executive
[UPDATES]
1. If the updates contain no information on progress or finances at all, ask for them and stop.
2. Cover sheet: report title, period, author, purpose (for decision, discussion or information), the decisions sought in one line each, and the main risks to the board's attention.
3. Summary: five bullets at most, leading with the most important change or concern, good or bad.
4. Progress against plan: each plan objective or project with a RAG status based only on evidence in the updates, one line on progress and one on next steps. If no evidence supports a status, mark it "not reported".
5. Finance in brief: income and expenditure against budget for the period and year to date, reserves and cash position, restricted funds issues and the forecast, using only supplied numbers, with variances explained. If figures are missing, show the table with gaps marked.
6. Risks: new or changed risks, with likelihood, impact, mitigation and owner.
7. Safeguarding: the number and type of concerns and incidents in the period with no identifying details, actions taken, any reports made to authorities or regulators, training and policy status. If no safeguarding information was supplied, flag it as a gap rather than writing "nothing to report".
8. People: staffing, vacancies, volunteers, wellbeing, any significant HR matters without identifying individuals.
9. Governance and compliance: regulator filings, policy reviews due, insurance, data protection and any serious incident that may need reporting to the regulator, as something for trustees to consider.
10. Decisions needed: each decision with background, options, recommendation, financial and risk implications, and the exact resolution wording for the minutes.
11. Papers to note: the supporting papers referenced in the updates.
12. Gaps to fill: every missing figure or fact the author should add before circulating.
- Use only facts and numbers in the inputs. Never invent figures, percentages, RAG statuses or outcomes; mark gaps as [to add].
- Lead with bad news when there is any. Trustees must not have to find it.
- Keep names of service users, staff in HR matters and people in safeguarding cases out of the report.
- Regulators and reporting duties differ by country and legal form. Mention them only as matters for trustees to check, not as legal conclusions.
- Keep each section short; detail belongs in appendices or papers to note.
- Before answering, check every number in the report against the updates and that decisions are separated from information.
Markdown with these headings:
## Cover sheet
## Summary
## Progress against plan
Table: Objective | RAG | Progress | Next steps.
## Finance in brief
Table: Line | Budget | Actual | Variance | Comment.
## Risks
Table: Risk | Likelihood | Impact | Mitigation | Owner.
## Safeguarding
## People
## Governance and compliance
## Decisions needed
## Papers to note
## Gaps to fill
````
---
## Write a site visit report
`write-site-visit-report` · prompt · Business writing · https://hermes-ide.com/prompts/write-site-visit-report
Turns field or site visit notes into a structured report with observations, evidence, issues rated by severity and owned follow-ups. For consultants, inspectors, auditors and area managers.
````markdown
A site visit report has two jobs: give someone who was not there an accurate picture of the site, and turn what the visitor found into actions that get done. Readers trust it when every finding is anchored in evidence (what was seen, measured, photographed or shown in a document) and when the report is honest about what was only heard from site staff. It loses value when findings are vague ("housekeeping could be better"), when minor and serious issues sit in one undifferentiated list, when good practice goes unrecorded, and when follow-ups have no owner or date.
Severity scale, applied consistently:
- **Critical:** immediate risk to people's safety, legal compliance or the core purpose of the site; act now.
- **Major:** a significant gap against the standard or objective that will cause harm, loss or failure if left; act within an agreed short period.
- **Minor:** an isolated lapse with limited impact; fix in normal course.
- **Observation:** not a breach; an improvement opportunity or something to watch.
Write a site visit report for client.
[SITE_AND_PURPOSE]
[VISIT_NOTES]
1. If the notes contain no findings at all, or you cannot tell which site or what the visit was for, ask in one short message and stop.
2. Group observations by area or topic in the order a reader would walk the site or follow the purpose of the visit.
3. For each observation, record the evidence type: seen, measured, photo (keep the visitor's photo references), document reviewed, or stated by site staff (by role). Keep statements by staff clearly attributed; do not present them as verified. If photos are attached, describe only what is visible in them, cite them by their number or file name, and do not infer readings, dates or causes the image does not show.
4. Turn problems into issues. Each issue states the condition found, the standard or expectation it falls short of (only if the notes or purpose name one; otherwise describe the expectation in plain terms and do not cite a regulation or clause that was not given), the impact, and a severity from the scale above. Explain any Critical rating in one line.
5. Record what is working well, with the same specificity. Good practice is a finding too and helps the site accept the rest.
6. Write follow-ups for every Critical and Major issue and any Minor issue the notes suggest acting on: the action, the owner (role), the due date and how completion will be shown. Use `[need: owner]` or `[need: date]` when the notes do not say.
7. Write a summary for a reader who reads nothing else: overall impression in one sentence, the number of issues by severity, the most important one or two actions, and any Critical item.
8. If anything in the notes points to immediate danger to people, put it first in the summary marked as Critical and say what should happen today.
- Use only what is in the notes. Never invent measurements, names, clause numbers, photos or conversations.
- Neutral, specific language: describe conditions and actions, not people's attitudes. "Two of six fire extinguishers had no inspection tag dated within the last 12 months" rather than "fire safety is sloppy".
- Do not rate an issue Critical or Major without evidence in the notes that supports it; if the severity depends on a fact you lack, give the likely rating and the question that would settle it.
- Match the register to client: a client report avoids internal shorthand; a report to the site itself can be more operational.
- Keep the body under about 900 words; put long lists of minor items in a table rather than prose.
## Visit report
- **Header:** site, date, visitor(s), people met (roles), purpose, scope (what was and was not covered).
- **Summary:** three to five sentences as described in step 7.
- **Observations by area:** short subsections with bullet findings, each ending with its evidence in brackets.
- **Issues:** table with # · Area · Issue · Evidence · Severity · Impact.
- **Good practice:** bullets.
- **Follow-ups:** table with # · Action · Owner · Due · Evidence of completion.
- **Next visit or review:** what to check next time, if the notes suggest it.
## Questions for the visitor
Bullets: facts you need to confirm, including each `[need: …]`, any severity that depends on a missing fact, and any finding where the notes were ambiguous. "None" if none.
````
---
## Write a user manual
`write-user-manual` · prompt · Business writing · https://hermes-ide.com/prompts/write-user-manual
Writes a task-based user manual for a physical product, appliance, office system or service, with safety notices, setup, everyday tasks, care and troubleshooting organised by symptom.
````markdown
People open a manual when they are trying to do something or something has gone wrong, not to read about features. Task-based manuals (the minimalist approach from technical communication research) organise content around what users want to do, start each task with the action, put one action in each step, show what should happen after a step, and let readers recover from errors. Manuals fail when they describe each button in turn, bury safety warnings in the middle of steps, use names that differ from the labels on the product, assume knowledge the reader lacks, or invent specifications the product does not have.
Safety notices follow the widely used signal-word hierarchy: **DANGER** (will cause death or serious injury), **WARNING** (could cause death or serious injury), **CAUTION** (could cause minor or moderate injury), **NOTICE** (property damage only, no injury). Each notice names the hazard, the consequence and how to avoid it, and sits before the step it applies to.
Write a user manual for a novice reader.
[PRODUCT_DESCRIPTION]
1. If you cannot tell what the product is, what its main controls are, or how it is used, ask for those details and stop.
2. List the user's tasks in the order they meet them: unpacking and checking the contents, setup, first use, everyday tasks, occasional tasks (settings, cleaning, refilling, replacing parts), and end of life (storage, disposal) where relevant.
3. Write each task as: a heading that names the goal ("Make a double espresso", "Add a new user"), any prerequisite, safety notices that apply, then numbered steps. One action per step, imperative mood, the control named exactly as labelled and in bold, and the expected result in italics after the steps where users need confirmation.
4. Pitch the detail to novice: novices get every step and a one-line explanation of unfamiliar terms; regular users get compact steps; experts get reference tables and shortcuts.
5. Write troubleshooting as a table organised by what the user notices (the symptom), not by internal cause: Symptom · Possible cause · What to do. Use known issues first, then obvious checks (power, connection, consumables). Escalation to support or a qualified technician goes last.
6. Add safety notices only for hazards that follow from the description (heat, electricity, moving parts, pressure, chemicals, weight, children, data loss) and mark any you inferred with `[confirm]`.
7. Keep a list of every fact you needed but did not have (dimensions, voltages, capacities, button names, temperatures, warranty terms, support contacts) and use `[confirm: …]` in the text rather than inventing them.
- Never invent specifications, settings, part numbers, certifications, warranty terms or contact details.
- Use the product's own names for controls and screens consistently; if the description uses two names for one thing, pick one and note it.
- Plain language: short sentences, active voice, second person, no marketing claims.
- For electrical, gas, pressure, children's, medical or vehicle products, note under Facts to confirm that legally required manual content and safety wording differ by market and must be checked against the applicable regulations before publication.
- Keep each task under about ten steps; split longer ones.
## Manual
Title, then: Safety information · What is in the box (or What you need) · Parts and controls (table: Part · What it does) · Setup · Everyday tasks · Occasional tasks · Care and maintenance · Troubleshooting (table) · Specifications (only supplied facts) · Getting help.
## Facts to confirm
Bullets: every `[confirm: …]` placeholder and inferred safety notice, grouped by section, plus any naming inconsistencies found.
````
---
## Write a white paper
`write-white-paper` · prompt · Business writing · https://hermes-ide.com/prompts/write-white-paper
Writes a B2B white paper that frames an industry problem with cited evidence and sets out a solution approach, citing a supplied source for every factual claim and flagging unsupported ones.
````markdown
A white paper earns trust by teaching before it sells. Its readers are evaluators, often sceptical specialists building a case internally, who will forward it only if it is accurate, specific and fair. White papers fail when they are brochures with footnotes: vague market claims, statistics without sources, a "solution" section that is just the product, and no acknowledgement of trade-offs or alternatives. The structure that works is problem, cost of the problem, why common approaches fall short, a principled approach (criteria a good solution must meet), how to apply it, and a short, honest note on how the author's organisation fits.
Write a white paper on:
[TOPIC]
Evidence you may cite (and nothing else):
[EVIDENCE]
1. If the evidence has fewer than three usable sourced items, or the sources are not identified, ask for more or for their origins and stop.
2. Identify the reader's core question and the paper's thesis in one sentence each. If no audience was given, infer the most likely evaluating reader from the topic, state that assumption above the paper, and pitch the depth to them.
3. Outline before writing: title, executive summary, the problem, its cost or consequences, why current approaches fall short, the recommended approach as a set of principles or criteria, implementation steps or a maturity path, a short section on the author's offering if the topic mentions one, and a conclusion with a next step.
4. Write the paper at 1,500 to 2,500 words, in confident, plain, specific prose for this audience. Use subheadings that state the point, short paragraphs, and a table or numbered list where it clarifies a comparison or process. Suggest one or two figures (what they show and which source they use).
5. Cite every factual claim (number, trend, study finding, quote, customer result) inline with a numbered reference [1] that maps to the evidence, and list references at the end in a consistent format. Any sentence that states a fact but has no source in the evidence must be rewritten as an opinion, removed, or marked `[SOURCE NEEDED]`.
6. Keep the solution vendor-neutral until the dedicated section; the principles should be useful even to a reader who never buys.
- Never invent statistics, studies, quotes, customer names or results, and never attribute a claim to a source that does not support it. Do not upgrade a claim beyond its source ("a survey of 200 firms" does not become "the industry").
- Distinguish clearly between evidence, the author's interpretation and recommendations.
- Acknowledge at least one limitation, trade-off or situation where the approach does not fit.
- Avoid hype words (revolutionary, game-changing, best-in-class, seamless) and unexplained jargon.
- Internal data is allowed but must be labelled as such, with its sample and period if given.
## White paper
Title, subtitle, executive summary (about 150 words), then the sections with stated-point subheadings, conclusion and next step, and a References list numbered to match the in-text citations.
## Claim and source check
A table: Claim (short) | Reference | Exact supporting detail from the evidence. Include every factual claim.
## Gaps
Each `[SOURCE NEEDED]` and any evidence that would strengthen a weak section. "None" if none.
## Repurposing notes
Three short ideas for reuse (a blog post, a slide, a sales email line), each pointing to the section it comes from.
````
---
## Write a workplace incident report
`write-workplace-incident-report` · prompt · Business writing · https://hermes-ide.com/prompts/write-workplace-incident-report
Writes a factual, blame-neutral report of a workplace accident, near miss, customer, property or security incident, separating observed facts from statements and listing actions with owners.
````markdown
A workplace incident report is a record that other people act on: a supervisor fixes the hazard, HR supports the people involved, facilities repairs the damage, an insurer or regulator may read it months later. It is useful only if it is accurate, dated, and written so that a reader who was not there can see what happened without being told whom to blame. The common failures are mixing opinion into facts ("he was being careless"), guessing at causes before anyone has looked, leaving out times and locations, recording more personal or medical detail than the reader needs, and listing actions with no owner.
Write as an experienced health and safety or operations coordinator would: neutral, specific, in the past tense, with every statement either observed, reported by a named role, or marked as unknown.
Write a other incident report for manager and HR from these notes:
[INCIDENT_NOTES]
1. If the notes do not say what happened, or give no indication of when or where, ask for those details in one short message and stop.
2. Check for urgency first. If the notes suggest someone may still be at risk, a hazard is still in place, a person needs medical attention, or a crime may be in progress, say so at the top under Urgent checks before anything else.
3. Sort every statement in the notes into one of three kinds and keep them apart in the report:
- **observed:** seen or measured directly by the person reporting;
- **reported:** told to the reporter by someone else, attributed by role ("the shift lead said…");
- **inferred:** someone's opinion or guess about cause. Move these to "Possible contributing factors (to be confirmed)" and word them as questions for the investigation, never as findings.
4. Rewrite blaming, emotional or judgemental language into neutral description of actions and conditions ("the floor was wet near bay 4; no sign was in place" instead of "the cleaner left it soaking wet as usual"). Record every change under Language changes.
5. Identify people by role or initials unless the audience needs full names, and record only the injury or health information the reader needs (body part, nature as described, first aid given, whether the person went to hospital). Do not diagnose or speculate about medical outcomes.
6. Propose immediate and follow-up actions that follow from the facts (make the area safe, preserve evidence, check similar equipment, support the person, review the procedure). Give each an owner and date if the notes supply them; otherwise use `[need: owner]` and `[need: date]`.
7. Under Notifications, list who has been told and when, and flag whether this type of incident may have to be reported to an external body (for example a workplace safety regulator, insurer, data protection authority or the police) so the reader can check the rules that apply. Do not state that it is or is not reportable.
- Use only the facts in the notes. Never invent times, names, witnesses, measurements, injuries or quotes; use `[need: …]`.
- No conclusions about fault, negligence, liability or disciplinary outcomes, even if the notes ask for them. A report that blames is less credible and can harm the people involved.
- Keep exact quotes only when they matter to what happened, attributed by role and in quotation marks.
- Use 24-hour or clearly marked times and a full date if given.
- Keep the report under about 600 words; a reader should grasp what happened from the Summary alone.
## Urgent checks
Anything that needs action before the report is filed, or "None identified".
## Incident report
- **Summary:** two or three sentences: what happened, when, where, outcome.
- **Details:** table with Date and time · Location · Incident type · People involved (role) · Reported by · Report date.
- **What happened:** numbered, chronological, factual steps, each marked (observed) or (reported by …).
- **Injuries, damage or loss:** as described, or "None reported".
- **Immediate actions taken:** what was done, by whom, when.
- **Witnesses:** role and a one-line summary of what each saw.
- **Possible contributing factors (to be confirmed):** conditions and questions for the investigation.
- **Actions:** table with Action · Owner · Due date · Status.
- **Notifications:** who has been told, and external reporting to check.
## Language changes
Bullets: original wording → neutral wording, with the reason. "None" if none.
## Missing information
Bullets: each `[need: …]`, with why it matters. "None" if complete.
````
---
## Write a workplace safety alert
`write-safety-alert-bulletin` · prompt · Business writing · https://hermes-ide.com/prompts/write-safety-alert-bulletin
Writes a workplace safety alert bulletin after an incident or near miss with what happened, the risk, immediate actions for staff and who to contact, readable at a glance on a noticeboard.
````markdown
You write safety alert bulletins: the one-page notice a workplace puts on noticeboards, in break rooms, on screens and in team chats after an incident or near miss, so everyone doing similar work changes what they do before it happens again. It is not the investigation report. People read it standing up, sometimes in a second language, often in a hurry. A good alert has a clear headline that names the hazard, a short factual account with no names and no blame, why it matters, three to five instructions written as commands, what is changing, and who to contact. Alerts fail when they bury the action under background, speculate about the cause, blame the person involved, use jargon, or contain instructions nobody has approved.
[INCIDENT]
Audience: [AUDIENCE]
Urgency: urgent
1. If the incident description does not say what the hazard was or what happened, ask what happened and what the hazard is, and stop.
2. Write the alert for [AUDIENCE]:
- a headline that names the hazard and the type of event, labelled "Safety alert" for urgent or "Safety lesson" for routine;
- what happened, in two or three short factual sentences: the task, the hazard, the outcome, no names, no blame;
- why it matters: the harm it could cause anyone doing this work;
- what you must do now: three to five numbered instructions starting with a verb, specific to the task;
- what is changing, if the incident text says (for example a guard being fitted or a new procedure), otherwise a line that the investigation is ongoing and updates will follow;
- who to contact and how to report a similar hazard;
- a reference, date and a review or removal date as placeholders.
3. Notes for the sender: which instructions come from the incident text and which are suggestions for a competent person to approve before issue, information still needed, a pictogram or photo to add, translation needs for the audience, and where to post or share it.
- No names, initials, job titles that identify one person, or injury details beyond what is needed to show the risk.
- Do not state a cause unless the incident text says it is confirmed. Otherwise write "under investigation".
- Mark any instruction not in the incident text as [suggested - approve before issue] in the alert, and list it in the notes.
- Use plain words and short sentences that work for readers with limited English; avoid acronyms or spell them out.
- Keep the alert to one page.
- Before answering, check that every instruction is a clear action, that nothing in the alert identifies the people involved, and that suggested instructions are marked.
## Safety alert
The bulletin, in this order: headline (bold, all key words), **What happened**, **Why it matters**, **What you must do now** (numbered), **What is changing**, **Questions or a similar hazard?**, then reference and dates.
## Notes for the sender
Bullets: approved vs suggested instructions, missing information, picture to add, translation, where to post.
````
---
## Write an annual report letter
`write-annual-report-letter` · prompt · Business writing · https://hermes-ide.com/prompts/write-annual-report-letter
Writes the chair's or CEO's letter for an annual report with the year's story, results with numbers, setbacks owned, thanks and the year ahead. Use for companies, nonprofits and associations.
````markdown
The chair's or CEO's letter is the most-read page of an annual report and the one most often written as boilerplate: "a year of challenges and opportunities", a list of activities, thanks to "all our stakeholders". The letters that are remembered and trusted (Warren Buffett's shareholder letters are the usual example) tell the year as a story with a point of view, give the results with numbers against the goals that were set, own the misses specifically and say what changed, thank people for specific things, and commit to measurable priorities. For nonprofits, the reader wants impact (people helped, outcomes) more than activity (events held). For listed companies and regulated bodies, every figure must match the audited accounts elsewhere in the report, and forward-looking statements need care and review.
Write the annual report letter for [ORGANISATION], signed by [SIGNATORY].
[YEAR_RESULTS]
1. If the results give no figures or concrete outcomes at all, ask for the three to five most important numbers and stop.
2. Find the year's story: one sentence that captures what the year was about (a turnaround, a hard year with lessons, growth that strained the organisation). Build the letter around it.
3. Write the letter in this order, with a few short sub-headings if it runs past about 600 words:
- Opening: the year's story in two or three sentences, from the signatory's point of view.
- Results: the most important three to five numbers, each compared with last year or with the goal where the input gives it, and what they mean for the people the organisation serves or its owners.
- Setbacks: what fell short, owned in the first person plural, with what was learned and changed. If no setbacks were given, add a `[need: the year's main setback or miss]` placeholder and say under Review why including one builds trust.
- People: specific thanks (staff, volunteers, members, donors, partners, customers) tied to things they did, from the input.
- The year ahead: the priorities, measurable where possible, and how progress will be reported.
- Close and signature block.
4. Match register to the organisation: a nonprofit letter leads with impact and the people served; a company letter speaks to owners and customers; an association letter speaks to members.
- About 600 to 900 words unless the input asks otherwise.
- Use only the figures and facts given; never invent numbers, quotes, names or achievements. Mark gaps `[need: …]`.
- Never describe a decline as growth or bury a miss in euphemism ("a year of consolidation" for falling revenue). If the input asks for spin, state the result accurately and say why under Review before publishing.
- No forecasts or guarantees of future financial performance; describe priorities and goals as goals.
- No clichés: "challenges and opportunities", "unprecedented", "journey", "stakeholders" as a catch-all.
## Letter
The letter with its signature block.
## Figure check
A table: each figure used, where it appears in the letter, and its source in the input. Readers check these against the accounts.
## Review before publishing
Bullets: figures to reconcile with the audited accounts, statements for legal or investor-relations review if applicable, placeholders, and anything rewritten for accuracy.
````
---
## Write an award nomination
`write-award-nomination` · prompt · Business writing · https://hermes-ide.com/prompts/write-award-nomination
Writes an award or recognition nomination that maps a colleague's specific achievements and evidence to each published criterion, within the word limit, and shows where the case is weak.
````markdown
Award panels read many nominations quickly, usually scoring each against a published criterion. Nominations lose not because the nominee is weaker but because the writer praised the person in general ("tireless, inspiring, always goes the extra mile") instead of proving each criterion with specific evidence, or skipped a criterion altogether. Strong nominations do three things: answer every criterion explicitly, in the panel's own words; prove claims with outcomes, numbers, scale and third-party voices; and show what was distinctive about this person's contribution, beyond doing their job well.
Write a nomination.
[AWARD_CRITERIA]
[NOMINEE_ACHIEVEMENTS]
1. If the criteria are missing, ask for them and stop; a nomination written without them usually misses what the panel scores.
2. Build a criteria map first: for each criterion, list the pieces of evidence that support it and rate the strength of the case (strong, adequate, thin) with a reason. Each piece of evidence goes where it scores best; reuse one only if it genuinely serves two criteria.
3. Write the nomination:
- An opening of one or two sentences that states who the nominee is and the single most impressive thing they did, with its result.
- One section per criterion, using the criterion's wording as the heading (or the form's section order). Lead each section with the strongest evidence. Use the pattern: situation in a clause, what the nominee specifically did, the measurable or observable result, and who benefited.
- Quotes from colleagues, customers or students, only if supplied, attributed by role.
- A short closing line on why this person and why now.
4. Fit the limits. If the evidence will not fit, cut weaker evidence rather than squeezing sentences until they are unreadable. Report the word count per section and in total.
5. Under Strengthen the case, list criteria rated thin and the evidence that would help (a figure, a testimonial, a before-and-after), so the nominator can gather it before the deadline.
- Every claim comes from the achievements supplied. Never invent figures, quotes, awards or outcomes. Use `[add: …]` only where a specific missing fact would clearly help.
- Concrete over adjectival: at most one adjective of praise per section, and only after the evidence.
- Credit the nominee's own contribution accurately when the work was a team effort: "led", "designed", "persuaded" only if the notes support it.
- Third person, present the nominee by name as given, past tense for achievements.
## Criteria map
Table: Criterion · Evidence used · Strength (strong, adequate, thin) · Note.
## Nomination
The text, with a heading per criterion or form section, then "Word count: N / limit" (per section where limits exist).
## Strengthen the case
Bullets: what to add or confirm, by criterion. "Nothing to add" if all criteria are strong.
Weak: "Maria is a passionate and dedicated leader who always puts customers first."
Strong: "When complaint volumes doubled after the 2025 price change, Maria set up a daily call-back rota and rewrote the five most-used reply templates. Within six weeks the average resolution time fell from 6 days to 2, and the team's satisfaction score rose from 71% to 88%."
````
---
## Write an executive summary
`write-executive-summary` · prompt · Business writing · https://hermes-ide.com/prompts/write-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.
````markdown
An executive summary is read instead of the document, not before it. Many readers stop after the first paragraph, so it must stand alone: what the document concludes, why that matters to this reader, and what the reader is being asked to do. Weak summaries describe the document ("This report examines…") instead of stating its findings, follow the document's chronology instead of its importance, bury the ask, or quietly change numbers and certainty while compressing.
Write an executive summary of the document below for [AUDIENCE], at most 250 words.
[DOCUMENT]
1. If the document is empty or is only a title or topic, ask for the full text and stop.
2. Find the governing thought: the single conclusion or recommendation the whole document supports. If the document has none, say so and summarise its main findings instead; do not invent a recommendation.
3. Find the ask: the decision, approval, money or action the reader is expected to give, with any deadline. If there is no ask in the document, state "No action requested" rather than making one up.
4. Pick the three to five points that most support the governing thought for this audience. Prefer points with numbers, consequences, costs or risks. Drop methodology and history unless the audience needs them to trust the result.
5. Order by importance, top-down: bottom line first, then the supporting points, then the ask and next steps.
6. Translate jargon the audience does not share into its consequence, and keep the document's level of certainty (an estimate stays an estimate, a pilot result stays a pilot result).
7. Count the words and cut until you are within the limit.
- Use only facts, figures and claims from the document. Copy numbers exactly; never round, recompute or combine them.
- Do not open with "This document", "This report" or a restatement of the title. The first sentence is the bottom line.
- Keep risks and caveats the document gives if they would change the reader's decision.
- If the document contradicts itself on a key figure, do not pick one: write "[CHECK: …]" and list the conflict under Left out.
- Plain, active sentences. No bullet longer than two lines.
## Executive summary
**Bottom line:** one or two sentences.
**Key points:** three to five bullets, most important first.
**The ask:** the decision or action needed, from whom and by when, or "No action requested".
Then the line "Word count: N / 250".
## Source check
A table: claim or number in the summary | where it appears in the document (section heading or a short quoted phrase).
## Left out
Bullets: material you cut that a reader might expect, and any conflicts or gaps you found. "None" if nothing material.
````
---
## Write an FAQ from source documents
`write-faq-from-documents` · prompt · Business writing · https://hermes-ide.com/prompts/write-faq-from-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.
````markdown
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: [AUDIENCE]. Include at most 15 questions.
[SOURCE_MATERIAL]
1. 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.
2. 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").
3. Rank them by how many readers will ask and how costly a wrong guess would be (money, deadlines, safety, eligibility). Keep the top 15; note the rest under Gaps as "not included".
4. 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.
5. 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.
6. 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.
7. 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]
````
---
## Write an internal announcement
`write-internal-announcement` · prompt · Business writing · https://hermes-ide.com/prompts/write-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.
````markdown
People read a change announcement asking four questions in order: what is changing, does it affect me, why, and what do I do now. Announcements fail when the change is buried under a preamble about values, when the reason is vague or spun ("to unlock synergies"), when they cheer about news that is bad for some readers, or when nobody knows where to ask. For changes that affect people's jobs, managers, roles or pay, the order of communication matters as much as the words: the people most affected should hear it directly, before a broadcast.
Write an announcement for [AUDIENCE] about this change:
[CHANGE]
1. If the input does not say what is changing or when, ask for that and stop.
2. Open with a subject line or headline that states the change itself, and a first paragraph that says what is changing and when it takes effect.
3. Explain why, using the actual reason from the input. If no reason is given, insert `[need: the reason]` rather than writing a generic one.
4. Explain the impact by group: who is affected and how, and say explicitly what is not changing.
5. List what readers need to do, with deadlines. If nothing, say "No action needed".
6. Say where to ask: a named channel, person, session or form from the input, or `[need: where to ask]`.
7. Match the tone to the news. A launch can be upbeat. A reorg, a cut or a policy that removes a benefit is plain and respectful: acknowledge that it is a real change for some people, without corporate euphemism and without over-apologising.
8. Draft an FAQ of five to eight questions readers will actually ask, including the uncomfortable ones (Is this a cost cut? Will there be more changes? What happens to my role?). Answer only from the input; where the answer is unknown, write the honest holding answer ("We don't know yet; we will tell you by [date]").
- Never invent reasons, numbers, dates, names or commitments.
- No euphemisms that hide what is happening ("rightsizing", "transitioning roles"). Say "roles will be eliminated" if that is the fact.
- Do not mention any individual's performance, health or personal circumstances.
- Keep the announcement under 350 words; detail goes in the FAQ.
- If the change involves job losses, pay or contract changes, or anything with legal implications, add to Before you send that HR or legal should review it, and that affected people must be told directly first.
## Announcement
Subject line, then the message with short sections: What is changing · Why · What it means for you · What you need to do · Questions.
## FAQ
Numbered questions with short answers.
## Before you send
A checklist: who must hear before this goes out, any `[need: …]` placeholders, reviews required, and the best channel and timing.
````
---
## Write an internal team newsletter
`write-team-newsletter` · prompt · Business writing · https://hermes-ide.com/prompts/write-team-newsletter
Writes an internal team or company newsletter from updates, wins and dates, with a lead story chosen for readers, short sections and recognition that names specific contributions.
````markdown
Internal newsletters compete with every other message in the inbox and usually lose. The ones people read lead with the item that matters most to the reader (not to the most senior person), keep each item short with a link for more, and make recognition specific enough that the person recognised feels seen and others learn what good looks like. "Thanks to the ops team for their hard work" is noise; "Priya rebuilt the returns process so refunds now take two days instead of nine" is news. Newsletters also go wrong by leaking things not yet announced, praising only the visible roles, or burying the one action people need to take.
Write a short newsletter for whole company from these updates:
[UPDATES]
1. If the updates are too thin to fill even a short issue (fewer than two real items), say what is missing and suggest the kinds of items to gather, then stop.
2. Choose the lead story by impact on the readers: what changes their work, what they will be asked about, or a win that affects many of them. Explain the choice in one line under Check before sending.
3. Write the lead in three to five sentences: what happened, why it matters to the reader, and what happens next or where to learn more.
4. Group the rest into short sections, using only those that have content: Updates · Wins and shout-outs · People news · Coming up (dates in date order) · One ask (the single action readers should take, if any).
5. For each shout-out, name who did what and the effect, using only details in the updates. If the updates thank someone without saying what they did, write `[add: what they did and the effect]` rather than generic praise.
6. Write three subject line options: specific, under 60 characters, no clickbait.
- Use only facts in the updates; never invent numbers, names, quotes or dates.
- Short: up to about 350 words for short, about 700 for standard. Each item two to four sentences.
- Warm and plain, like a well-written note from a colleague. No "exciting times ahead", no exclamation marks in every line.
- Flag anything that looks confidential or not yet announced (unreleased financials, unannounced departures or hires, customer names under NDA, personal health or family details) instead of publishing it.
- If recognition clusters on one team or role, note the imbalance under Check before sending.
## Subject lines
Three numbered options.
## Newsletter
The issue with a short title, the lead story, then the sections in order.
## Check before sending
Bullets: why this lead, items flagged as possibly confidential, `[add: …]` placeholders to fill, recognition balance, and links to add. "Nothing to check" if none.
````
---
## Write manager talking points for a change
`write-manager-talking-points` · prompt · Business writing · https://hermes-ide.com/prompts/write-manager-talking-points
Writes talking points, likely questions with honest answers and a do-not-say list so every manager can cascade an organisational change to their team consistently and truthfully.
````markdown
When a change is cascaded through managers, each team hears a slightly different version. Within a day the differences become rumours, and the most anxious version wins. Talking points exist so that every manager says the same true things, admits the same unknowns, and answers the predictable questions without improvising. The failures are predictable too: false reassurance ("nobody's job is affected") that later turns out wrong, corporate language that sounds evasive, managers speculating about undecided details, and managers distancing themselves ("I don't agree with this either, but…"), which destroys trust in both the change and the manager.
Write as an experienced internal communications lead who has run many cascades: plain words, honest about uncertainty, specific about what happens next.
Prepare a cascade pack for managers.
[CHANGE_SUMMARY]
[WHAT_IS_CONFIRMED]
1. If you cannot tell what is changing, for whom, or when, ask up to three questions and stop.
2. Separate confirmed facts from open questions. Every talking point must rest on a confirmed fact; open items become honest "not decided yet" answers with when people will hear more (or `[need: date of next update]`).
3. Write the core message: three sentences a manager could say from memory, covering what is changing, why, and what it means for the team.
4. Write talking points in the order a team meeting would go: what is changing; why now; what it means for this team (with a placeholder for the manager to add team-specific detail); what is not changing; timeline; what happens next and where to get help. Use short spoken sentences, not slide fragments.
5. Draft the questions people will actually ask, including the uncomfortable ones (job security, pay, workload, "was this decided already?", "why weren't we consulted?", "what happens to my project?"). For each, give an honest answer of two to four sentences. Where the answer is unknown, say so plainly and say when or how it will be answered.
6. Write a do-not-say list: phrases that would be false, speculative, legally risky, or that undermine the message, each with what to say instead. Include anything in the sensitive points that must not be shared yet.
7. Add notes for managers: how to open the conversation, how to respond to strong emotions, what to do with questions they cannot answer (write them down and send them to a named route), and when to escalate individual concerns to HR.
- Never state as fact anything not in what_is_confirmed. No false reassurance, no guesses about numbers, dates or individuals.
- If the change affects jobs, pay, contracts or working conditions, add a line advising that HR (and where relevant legal or employee representatives) review the pack before use, because consultation and disclosure rules may apply.
- Plain spoken language. Ban jargon such as "synergies", "right-sizing", "going forward we will leverage".
- The manager speaks for the organisation: no talking points that blame leadership or disown the decision, and no spin that hides real downsides.
## Core message
Three sentences.
## Talking points
Numbered sections as in step 4, with `[Manager: add …]` where team-specific detail belongs.
## Likely questions
`**Q:** …` then `**A:** …`, hardest questions first.
## Do not say
Table: Do not say · Why · Say instead.
## Notes for managers
Short bullets.
## Open items
Bullets: undecided points and missing facts, with who owns each. "None" if none.
````
---
## كتابة خطاب رسمي
`write-formal-arabic-letter` · prompt · Business writing · https://hermes-ide.com/prompts/write-formal-arabic-letter
يكتب خطابًا رسميًا بالعربية الفصحى إلى جهة عمل أو جامعة أو جهة حكومية، بالافتتاحية المعتادة وسطر الموضوع والمتن والخاتمة، مع مراعاة الألقاب وأعراف البلد.
````markdown
أنت كاتب مراسلات رسمية عمل سنوات في الدواوين الحكومية والجامعات والشركات في العالم العربي. الخطاب الرسمي بالعربية يُحكم عليه من شكله قبل مضمونه: اللقب المناسب للمنصب، والتحية المعتادة، وسطر الموضوع، ولغة فصيحة سليمة الإعراب، وطلب واضح في الفقرة الأولى أو الثانية، وخاتمة مألوفة. وتختلف الأعراف من بلد إلى آخر؛ ففي السعودية وبعض دول الخليج يُكتب التاريخ الهجري مع الميلادي غالبًا، وفي المغرب العربي يُستعمل الميلادي والأرقام الغربية، والبسملة شائعة في رأس الخطاب في كثير من الدول لكنها لا تُستعمل في كل السياقات.
المرسَل إليه: [RECIPIENT]
البلد: عام
[SUBJECT]
1. إذا لم يتضح ما يطلبه المرسل أو ما يبلّغ به، فاسأل سؤالًا قصيرًا وتوقف. وما سوى ذلك من بيانات ناقصة يوضع بين معقوفين [ ].
2. اكتب الخطاب بهذا الترتيب:
- البسملة في الأعلى إن كانت معتادة في البلد والجهة، وإلا فاذكر في الملاحظات أنها اختيارية.
- التاريخ: هجري وميلادي إن كان ذلك عرف البلد، وإلا فميلادي. لا تحسب التاريخ الهجري بنفسك؛ اتركه [التاريخ الهجري] ليكمله المرسل.
- المرسَل إليه: اللقب المناسب ثم المنصب ثم الاسم ثم «المحترم» أو «المحترمة»؛ مثل «معالي» للوزير ومن في حكمه، و«سعادة» للمدير والوكيل والسفير، و«فضيلة» للقاضي والعالم الديني، و«الأستاذ الدكتور» للأستاذ الجامعي. وإن لم تعرف اللقب المناسب فاستعمل «السيد / السيدة ... المحترم/المحترمة» ونبّه إلى ذلك.
- التحية: «السلام عليكم ورحمة الله وبركاته، وبعد:» أو «تحية طيبة وبعد،» بحسب الجهة.
- الموضوع: سطر مستقل، مثل «الموضوع: طلب إجازة دراسية».
- المتن: فقرة أولى تعرّف بالمرسل وتذكر الغرض («أتقدم إلى سعادتكم بطلب ...»)، وفقرة ثانية للتفاصيل والمسوغات، وفقرة ثالثة للطلب المحدد والمرفقات («لذا أرجو التكرم بالموافقة على ...»).
- الخاتمة: «وتفضلوا بقبول فائق الاحترام والتقدير،» أو «شاكرين لكم حسن تعاونكم،».
- التوقيع: «مقدّمه» ثم الاسم والصفة والتوقيع ووسيلة التواصل، والمرفقات مرقّمة إن وُجدت.
3. حافظ على صيغة الجمع للتعظيم في مخاطبة المرسَل إليه («سعادتكم»، «لكم»، «تفضلوا») من أول الخطاب إلى آخره، وطابق التذكير والتأنيث في الألقاب والصفات.
4. اكتب بفصحى معاصرة واضحة، بجمل متوسطة الطول، بعيدًا عن الحشو والمبالغة في المديح، وتجنب الألفاظ العامية.
5. وافق شكل الأرقام عرف البلد (الأرقام المشرقية ١٢٣ أو الغربية 123) واذكر ذلك في الملاحظات.
6. قبل الإجابة راجع الإعراب في المواضع الظاهرة (بعد «إنّ» و«كان»، والمثنى وجمع المذكر السالم)، واتساق صيغة المخاطبة، وتطابق التواريخ والأرقام مع ما قدّمه المرسل.
- لا تخترع أرقام معاملات أو أرقام هويات أو تواريخ أو أسماء؛ ضعها بين معقوفين.
- إذا كان الخطاب تظلّمًا أو اعتراضًا له مهلة نظامية، فاكتب الخطاب ونبّه في جملة واحدة إلى التحقق من المهلة لدى الجهة أو محامٍ.
- اكتب الإجابة كلها بالعربية الفصحى.
## الخطاب
نص الخطاب كاملًا جاهزًا للطباعة.
## ملاحظات على الألقاب والصيغ
نقطتان إلى أربع: لماذا اخترت هذا اللقب وهذه التحية والخاتمة، وما يتغير لو كانت الجهة في بلد آخر.
## يُستكمل قبل الإرسال
البيانات الموضوعة بين معقوفين والمرفقات.
````
---
## प्रार्थना पत्र लिखना
`write-hindi-application-letter` · prompt · Business writing · https://hermes-ide.com/prompts/write-hindi-application-letter
प्रधानाचार्य, प्रबंधक या किसी कार्यालय को अवकाश, प्रमाण पत्र या शिकायत जैसे विषयों पर औपचारिक हिंदी प्रार्थना पत्र सही प्रारूप में लिखता है।
````markdown
आप हिंदी के अनुभवी शिक्षक और कार्यालयी पत्राचार के जानकार हैं। प्रार्थना पत्र का एक तय प्रारूप होता है, और विद्यालय की परीक्षा से लेकर बैंक या नगर निगम तक, उसी प्रारूप से पत्र की गंभीरता आँकी जाती है: “सेवा में” के साथ पद और पता, साफ़ “विषय”, “महोदय/महोदया” संबोधन, “सविनय निवेदन है कि” से शुरुआत, “अतः” के साथ स्पष्ट प्रार्थना, और भेजने वाले के अनुसार सही समापन। हिंदी में क्रिया और समापन लिंग के अनुसार बदलते हैं (“भवदीय/भवदीया”, “आज्ञाकारी शिष्य/शिष्या”, “करता हूँ/करती हूँ”), इसलिए यह ग़लत होने पर पूरा पत्र अटपटा लगता है।
प्राप्तकर्ता: [RECIPIENT]
भेजने वाला: [SENDER]
[PURPOSE]
1. अगर उद्देश्य साफ़ नहीं है, या भेजने वाले का लिंग पता नहीं चलता (जिससे क्रिया और समापन तय होते हैं), तो एक छोटा प्रश्न पूछें और रुकें। बाकी अनुपलब्ध जानकारी [कोष्ठक] में छोड़ें।
2. प्राप्तकर्ता के अनुसार प्रारूप चुनें:
- विद्यालय या कॉलेज (विद्यार्थी की ओर से): “सेवा में, श्रीमान प्रधानाचार्य जी / श्रीमती प्रधानाचार्या जी, [संस्था], [शहर]” → “विषय: … हेतु प्रार्थना पत्र” → “महोदय/महोदया,” → “सविनय निवेदन है कि मैं आपके विद्यालय की कक्षा … का/की छात्र/छात्रा हूँ …” → “अतः आपसे विनम्र निवेदन है कि …” → “धन्यवाद।” → “आपका आज्ञाकारी शिष्य / आपकी आज्ञाकारी शिष्या”, नाम, कक्षा, अनुक्रमांक, दिनांक।
- कार्यालय, बैंक, नगर निगम, नियोक्ता: ऊपर “प्रेषक” (नाम, पता), फिर “सेवा में”, पद, कार्यालय, पता; “दिनांक”; “विषय”; “महोदय/महोदया,”; मुख्य भाग; “भवदीय / भवदीया”, हस्ताक्षर, नाम, संपर्क।
- शिकायत पत्र में समस्या, स्थान, कब से है और पहले की गई शिकायत (यदि हो) तथ्यों के साथ लिखें, भाषा विनम्र पर दृढ़ रखें।
3. मुख्य भाग दो-तीन छोटे अनुच्छेदों में: पहला, आप कौन हैं और किस बारे में लिख रहे हैं; दूसरा, कारण और तथ्य (तारीखें, अवधि); अंतिम, “अतः” से साफ़ प्रार्थना। संलग्नक हों तो अंत में “संलग्नक:” की सूची दें।
4. भाषा: शुद्ध, सरल मानक हिंदी; बोलचाल के अंग्रेज़ी शब्द केवल तब, जब कोई प्रचलित हिंदी शब्द न हो (जैसे “आधार कार्ड”)। पूरे पत्र में “आप” और आदरसूचक क्रियाएँ एक जैसी रखें।
5. उत्तर देने से पहले जाँचें: लिंग के अनुसार सभी क्रियाएँ और समापन सही हैं, तारीखें और अवधि तथ्यों से मेल खाती हैं, विषय पंक्ति पत्र के उद्देश्य से मेल खाती है, और कोई जानकारी गढ़ी नहीं गई।
- नाम, अनुक्रमांक, खाता संख्या, तारीख़ या कारण स्वयं न गढ़ें; [कोष्ठक] छोड़ें।
- बीमारी के कारण अवकाश में बीमारी का सामान्य उल्लेख पर्याप्त है; अनावश्यक निजी विवरण न जोड़ें।
- अगर उपयोगकर्ता परीक्षा के लिए पत्र माँगे, तो बोर्ड के प्रचलित प्रारूप का पालन करें और बताएँ कि अपने शिक्षक द्वारा बताया गया प्रारूप प्राथमिक है।
- पूरा उत्तर हिंदी में दें।
## पत्र
पूरा पत्र, प्रारूप के अनुसार पंक्तियाँ अलग-अलग।
## ध्यान दें
दो-तीन बिंदु: [कोष्ठक] में छोड़ी जानकारी, संलग्नक, और प्रारूप से जुड़ी कोई बात।
````
---
## 年终总结与述职报告
`write-year-end-work-summary` · prompt · Business writing · https://hermes-ide.com/prompts/write-year-end-work-summary
根据全年工作素材撰写年终总结或述职报告：成绩用数据量化，问题与反思具体可信，来年计划可衡量，语气符合职场规范，并按汇报对象调整详略。
````markdown
你是一位在大型企业人力资源和管理岗位工作多年的职场写作顾问，审阅过大量年终总结和述职报告。好的总结让领导在几分钟内看清三件事：你完成了什么（有数据、有对比）、你从问题中学到了什么（真实、具体、有改进措施）、明年你打算怎么做（目标可衡量）。常见的失败是堆砌工作流水账、满篇套话（“在领导的正确带领下”“学习还不够深入”）、只报喜不报忧，或者数字前后矛盾。
岗位与职责：[POSITION]
汇报对象：supervisor
[ACHIEVEMENTS]
1. 先检查素材。如果没有任何可量化的结果，也没有具体项目，就不要动笔，先用一条简短的消息列出需要补充的信息（例如关键指标的数值、年初目标、一两个代表性项目），然后停下等待回答。部分数据缺失时可以继续，用【待补充：……】标出。
2. 按汇报对象确定写法：
- supervisor：书面总结，结构完整，篇幅适中，重点是与年初目标的对照。
- all-hands：发言稿，三到五分钟，突出团队成果和感谢，少讲个人细节。
- review-panel：述职报告，对照岗位职责和考核标准逐项说明，体现能力和对团队的价值，结尾回应晋升或考核的要求。
3. 正文结构（all-hands 可压缩）：
- 标题和一句话概述全年。
- 工作完成情况：按目标或职责分为三到五类，每类写“做了什么—怎么做的—结果如何”，结果尽量用数据（完成率、同比或环比、节省的成本、缩短的周期）。
- 亮点：一到两个最有代表性的案例，讲清难点和个人贡献，不夸大团队成果为个人成果。
- 问题与不足：两到三条，具体到事情和原因，每条配一个改进措施；不写“态度还不够端正”之类的空话。
- 经验与思考：从这一年总结出的一两条可复用的方法。
- 明年计划：三到五个目标，可衡量、有时间节点，并说明需要的资源或支持。
4. 语言：书面语，客观、务实；适度使用“牵头”“推动”“落地”等职场常用词，避免堆砌口号和过多四字词；称呼领导和同事时得体。
5. review-panel 时另附三到五分钟的口述提纲；其他对象如需要也可附一个简短提纲。
6. 写完后自查：所有数字都来自素材且前后一致；问题部分有具体改进措施；计划与问题相呼应；没有编造的奖项、数据或评价。
- 只使用素材中的事实和数据，不编造。缺失的数字用【待补充：……】标出。
- 不贬低同事或其他部门；涉及失误时客观描述，说明已采取的补救措施。
- 涉及公司保密数据时，提醒用户按公司规定决定是否写入具体数字。
- 全部用简体中文作答。
## 正文
完整的总结或述职稿，带小标题。
## 数据核对清单
列出正文中出现的每个数字及其来源（素材原文），以及所有【待补充】项。
## 口述提纲
review-panel 必须提供；其他对象可写“无需”。
````