# Hodios paste pack: Email

Everything in Email from Hodios, the open prompt library by Hermes IDE: 38 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

- Email
  - [Ask for feedback by email](#ask-for-feedback-by-email) (prompt)
  - [Ask someone to be a reference](#request-reference) (prompt)
  - [Build a personal email template library](#build-email-templates) (prompt)
  - [Correct a mistake in an email](#correct-email-mistake) (prompt)
  - [Decline a request gracefully](#decline-request-gracefully) (prompt)
  - [E-mail corporativo](#write-corporate-email-brazil) (prompt)
  - [Invite a speaker](#invite-speaker) (prompt)
  - [Rédiger un e-mail formel](#write-french-formal-email) (prompt)
  - [Reject a vendor proposal](#reject-vendor-proposal) (prompt)
  - [Reply to an email](#reply-to-email) (prompt)
  - [Request approval by email](#request-approval-by-email) (prompt)
  - [Request information by email](#request-information-by-email) (prompt)
  - [Respond to an angry email](#respond-to-angry-email) (prompt)
  - [Rewrite an email bottom line first](#rewrite-email-bottom-line-first) (prompt)
  - [Scrivere una e-mail formale](#write-italian-formal-email) (prompt)
  - [Set up inbox filters](#set-up-inbox-filters) (prompt)
  - [Triage an inbox](#triage-inbox) (prompt)
  - [Write a bad news email](#write-bad-news-email) (prompt)
  - [Write a client apology](#write-client-apology) (prompt)
  - [Write a delay notification](#write-delay-notification) (prompt)
  - [Write a deliverable cover note](#write-deliverable-cover-note) (prompt)
  - [Write a farewell message](#write-farewell-message) (prompt)
  - [Write a follow-up to an unanswered email](#write-follow-up-email) (prompt)
  - [Write a meeting request email](#write-meeting-request-email) (prompt)
  - [Write a notice to your neighbours](#write-neighbourhood-notice) (prompt)
  - [Write a professional email](#write-professional-email) (prompt)
  - [Write a scope change email](#write-scope-change-email) (prompt)
  - [Write a weekly update to your manager](#write-weekly-update-to-manager) (prompt)
  - [Write an account handover email](#write-account-handover-email) (prompt)
  - [Write an email to a professor](#write-email-to-professor) (prompt)
  - [Write an escalation email](#write-escalation-email) (prompt)
  - [Write an event invitation](#write-event-invitation) (prompt)
  - [Write an introduction email](#write-introduction-email) (prompt)
  - [Write an out-of-office message](#write-out-of-office-message) (prompt)
  - [Write the next email in a negotiation](#write-negotiation-email) (prompt)
  - [비즈니스 이메일 작성](#write-korean-business-email) (prompt)
  - [ビジネスメールを敬語で書く](#write-japanese-business-email) (prompt)
  - [职场微信沟通](#write-workplace-wechat-message) (prompt)

---

<a id="ask-for-feedback-by-email"></a>

## Ask for feedback by email

`ask-for-feedback-by-email` · prompt · Email · https://hermes-ide.com/prompts/ask-for-feedback-by-email

Writes a request for feedback on a piece of work, a talk or your own performance, with two or three specific questions and an easy format, so people actually answer.

````markdown
<context>
"Any feedback?" gets "looks good" or silence. People give useful feedback when the request tells them what stage the work is in, what kind of feedback is wanted (direction, structure or line edits), asks two or three specific questions tied to decisions the sender is actually making, makes it safe to be critical ("the most useful thing is what you would cut"), takes a stated small amount of time, and has a deadline. Performance feedback works best with a narrow, behavioural question ("what is one thing I could do differently in planning meetings?") rather than "how am I doing?". Peers and people further down the hierarchy need explicit permission and sometimes anonymity to be candid.
</context>

<task>
Write a feedback request to [RECIPIENT_RELATIONSHIP] in the email-reply format.

<work_or_topic>
[WORK_OR_TOPIC]
</work_or_topic>

1. If you cannot tell what the feedback is about (for example "my stuff" or "everything"), ask what specifically and stop.
2. Identify the decisions or uncertainties the sender most likely has at this stage, from the work and its stage, and write two or three specific questions. At least one must invite criticism directly (what to cut, what is unclear, what they would do differently). Avoid yes/no questions and "did you like it".
3. State what kind of feedback is not needed now (for example "no need for typos; wording changes next week"), when the stage makes that clear.
4. Write the request:
   - Subject: "[Topic]: 3 quick questions, by [date]" or similar, with the time needed.
   - First line: what you are asking for and how long it takes ("10 minutes").
   - One or two lines of context and the stage.
   - The questions (numbered for email-reply; as an agenda for short-call; as a link placeholder with the questions listed for form).
   - Permission to be candid, fitted to the relationship: for a manager, ask directly; for peers or people more junior, make it clearly safe and offer the anonymous form option if the format allows.
   - Deadline and thanks; promise to share what you change, which makes people more likely to answer next time.
5. For performance feedback, keep questions behavioural and forward-looking, about specific situations named in the input.
</task>

<constraints>
- Under about 120 words in the body, excluding the questions.
- Two or three questions; never more than three in email-reply or short-call; a form may add one optional rating question.
- Use only the context given; never invent details of the work or past events. Use `[need: …]` for links and dates.
- No fishing for praise and no self-deprecation ("it's probably terrible").
- Plain, friendly and specific to the relationship; no HR jargon.
</constraints>

<output_format>
## Email
Subject line, then the body.
## Questions
The questions alone, ready to paste into a form or doc, each with a one-line note on what decision it informs.
## Notes
How to receive the feedback well (one or two lines), placeholders, and who else might be worth asking. "None" if nothing.
</output_format>

<examples>
Weak: "Would love any feedback you have on the deck!"
Strong: "1. Is the recommendation on slide 3 clear without me presenting it? 2. Which slide would you cut if we only had 10 minutes? 3. Is anything here likely to surprise the CFO?"
</examples>
````

---

<a id="request-reference"></a>

## Ask someone to be a reference

`request-reference` · prompt · Email · https://hermes-ide.com/prompts/request-reference

Asks a former manager, teacher or colleague to act as a reference, making it easy to say yes or no, with the role, the timeline and what they could speak to. Use when job hunting or applying.

````markdown
<context>
A reference request is a favour, and the person being asked is weighing two things: whether they can honestly say good things, and how much work it will be. The requests that get an enthusiastic yes remind the referee of the shared work with specific examples, say exactly what the opportunity is and when they might be contacted and how, name two or three things they could speak to, and give a genuine, face-saving way to decline ("if now is not a good time, or you feel someone else knows my recent work better, I completely understand"). A lukewarm reference from someone who felt obliged does more harm than none. The ask comes before the referee's name goes on any form, and it is separate from the later briefing once they have agreed.
</context>

<task>
Write a reference request to [REFEREE].

<relationship>
[RELATIONSHIP]
</relationship>

<opportunity>
[OPPORTUNITY]
</opportunity>

1. If the relationship gives no shared work or the opportunity is unclear, ask up to two questions and stop.
2. If the last contact was more than about a year ago, open with a short, genuine reconnection line (one sentence, from the input) before the ask.
3. Subject: "Would you be a reference for my application to [organisation]?"
4. Ask in the first or second sentence. Ask whether they would be comfortable giving a positive reference, not just "a reference".
5. Remind them of the shared work: when, the role, and two or three specific things they saw (only from the input).
6. Describe the opportunity in one or two sentences and why it fits.
7. Logistics: who will contact them, how (call, email, online form, letter), roughly when, and how long it usually takes, using placeholders where unknown.
8. Two or three things they could speak to, phrased as suggestions, never as a script.
9. The easy out, in one sentence, sincerely worded.
10. Offer to send the CV and the job description, and thank them.
11. Write a short version (under about 60 words) for LinkedIn or a text message, for referees who are more reachable that way.
12. Under "Once they say yes", list what to send them: CV, job description, the points to highlight, the expected contact date, and a promise to tell them the outcome.
</task>

<constraints>
- Email body under about 170 words.
- Use only the facts given. Never invent projects, results, titles or dates, and never suggest the referee say anything untrue or exaggerate the candidate's role; if the input asks for that, write an accurate version and explain why under Notes.
- Warm and direct; no grovelling, no pressure, no assuming a yes ("I've already listed you").
- For academic references or recommendation letters, allow more lead time and mention the submission method; suggest at least three weeks' notice if the deadline is close.
</constraints>

<output_format>
## Email
Subject line, then the body.
## Short message version
The short message.
## Once they say yes
Bullets.
## Notes
Placeholders and anything changed for accuracy. "None" if nothing.
</output_format>
````

---

<a id="build-email-templates"></a>

## Build a personal email template library

`build-email-templates` · prompt · Email · https://hermes-ide.com/prompts/build-email-templates

Builds a personal library of reusable email templates for the user's recurring situations, in their own voice from sent examples, with placeholders, subject lines and when-to-use notes.

````markdown
<context>
Templates save time only if the result does not read like a template. Recipients spot canned emails when the opening is generic, when a placeholder was left unfilled, or when the voice suddenly changes from the sender's usual style. A good personal template library sounds like its owner, has few placeholders and makes each one obvious, includes the one line that must be personalised every time, and tells the user when not to use it (when a phone call or a fully custom reply is better).
</context>

<task>
Build a template library in a warm professional tone for these situations:

<recurring_situations>
[RECURRING_SITUATIONS]
</recurring_situations>

1. If the situations are too vague to template (for example "work emails"), ask the user to list three to eight specific recurring situations and stop.
2. If samples are provided, extract the user's voice: greeting and sign-off habits, sentence length, formality, use of contractions, how they make requests and say no, phrases they use often, and things they never do (exclamation marks, emoji, "Hope this finds you well"). Apply it to every template. If samples conflict with the requested tone, follow the tone and say what you adjusted.
3. For each situation write one template with:
   - **Name** and **Use when** / **Don't use when** (one line each).
   - **Subject line** with placeholders.
   - **Body** with placeholders in `[SQUARE_CAPS]`, at most five per template; mark the one line that must be personalised every time with `[PERSONALISE: …]` and say what to put there.
   - **Short variant** for chat or a quick reply, if useful.
   - **Follow-up** line to send if there is no reply, where the situation calls for chasing.
4. Merge situations that are really the same email, and split one that needs different templates for different recipients (a first reminder versus a final notice). Explain merges and splits in one line.
5. Add a placeholder guide and a few reusable openers and closers in the user's voice.
</task>

<constraints>
- Each template must read naturally once placeholders are filled; read it with sample values to check.
- No invented facts about the user's business (prices, policies, payment terms, names); these become placeholders.
- Templates for sensitive situations (late payment, saying no, complaints) stay courteous and firm; final notices that mention legal steps carry a note to check what the user is entitled to do before sending.
- Keep each body under about 150 words.
</constraints>

<output_format>
## Voice notes
Bullets on the voice used and any adjustments made. If no samples, the tone choices made.
## Templates
`### Template name` per situation with the parts in step 3.
## Placeholder guide
Table: Placeholder · What to fill in · Example.
## Snippets
Three to five openers and three to five closers, in the user's voice.
</output_format>
````

---

<a id="correct-email-mistake"></a>

## Correct a mistake in an email

`correct-email-mistake` · prompt · Email · https://hermes-ide.com/prompts/correct-email-mistake

Writes a short correction to a previous email or document, such as a wrong date, figure, attachment or recipient, that states the fix first, without drama or over-apology.

````markdown
<context>
A good correction is boring: a subject that says "Correction", the right information in the first line, enough of the wrong version that readers know what to discard, and at most one short apology. Corrections go wrong in three ways. Over-apologising turns a typo into an incident and makes the sender look shaken. Burying the fix in a paragraph means half the readers still act on the wrong date. And not every mistake deserves a correction: a typo that changes no meaning creates more noise than it fixes. Some mistakes are not just errors but incidents: personal or confidential data sent to the wrong people usually has to be reported inside the organisation (often to a data protection or security contact) quickly, and the recipients asked to delete it. Email recall rarely works reliably and should not be relied on.
</context>

<task>
Write a correction for a small-group audience.

<original_message>
[ORIGINAL_MESSAGE]
</original_message>

<mistake>
[MISTAKE]
</mistake>

<correction>
[CORRECTION]
</correction>

1. Decide whether a correction is worth sending. Recommend not sending one when the mistake is a typo or wording slip that changes no fact, action, amount or date, and say why in one line. Otherwise continue.
2. Classify the mistake: wrong fact (date, time, amount, link, name), wrong or missing attachment, wrong recipient, or confidential or personal data exposed. Base the rest on the class.
3. Write the correction:
   - Subject: "Correction: [original subject]" (or "Updated attachment: …"). For a single recipient, a reply in the same thread is fine.
   - First line: the correct information, stated so it cannot be misread, with the wrong version named once so readers know what to discard ("The workshop is on Thursday 14 Nov, not Wednesday 13 Nov as I wrote earlier.").
   - Any action readers must take: update the calendar, use the new link, discard the old file.
   - Apology: none needed for a small factual slip to a large list beyond "apologies for the confusion"; one plain sentence otherwise. Never more than one.
   - For a wrong recipient or exposed data: ask the recipients not to open, forward or save the material and to delete it (and confirm they have, for sensitive data), without repeating the sensitive content.
4. For a large list, make the corrected fact bold or put it on its own line, and keep the email to three or four lines.
5. Under "Also do", list practical follow-ups: send an updated calendar invite, fix the source document or web page, tell people who might have acted on the wrong information, and for exposed personal or confidential data, report it to the organisation's data protection, privacy or security contact straight away because reporting deadlines can be short.
</task>

<constraints>
- Correction body under about 80 words (under about 50 for one-person corrections).
- Use only the facts given; never invent the right value if the correction is unclear, ask instead.
- No drama: no "huge apologies", "mortified", or explanations of how the mistake happened unless the reader needs it to act.
- Never repeat personal or confidential data in the correction itself.
- Do not claim the email was recalled.
</constraints>

<output_format>
## Send a correction?
One or two sentences with the recommendation.
## Correction
Subject line, then the body. Omit if not recommended.
## Also do
Bullets. "Nothing else" if none.
## Notes
Placeholders and assumptions. "None" if nothing.
</output_format>
````

---

<a id="decline-request-gracefully"></a>

## Decline a request gracefully

`decline-request-gracefully` · prompt · Email · https://hermes-ide.com/prompts/decline-request-gracefully

Declines a request or invitation clearly and kindly in the first lines, gives an honest brief reason if wanted, offers only real alternatives and preserves the relationship.

````markdown
<context>
A good "no" is clear early, brief and warm. People damage relationships less by declining than by declining badly: a vague reply that sounds like "maybe" and has to be chased, a long justification that invites negotiation, excessive apology that makes the other person comfort the decliner, or a counter-offer the decliner does not actually want to honour. A reason is optional; a clear answer is not.
</context>

<task>
Write a message declining this request:
<request>
[REQUEST]
</request>



1. If it is unclear what is being requested, ask and stop.
2. Infer the channel (email, chat, letter) and the relationship (boss, client, friend, stranger, organiser) from the request, and match its formality.
3. Open with brief, specific thanks or acknowledgement that shows you read the request, then decline clearly within the first two sentences. Use unambiguous words ("I won't be able to", "I'm going to say no to this"), not "I'm not sure I can" or "probably not".
4. Give the reason only if one was provided, in one sentence, without over-explaining. If none was provided, decline without a reason or with a neutral line such as "I can't take this on right now"; never invent one.
5. Offer the alternative only if one was provided, stated specifically. If none was provided, do not offer to help in some other way, and do not suggest asking again later unless the user said so.
6. End warmly and in a way that fits the relationship (wishing the event well, expressing interest in future work only if the user's input supports it).
</task>

<constraints>
- At most one apology, and only if the relationship calls for it.
- No invented reasons, commitments, referrals or future availability.
- Keep the main message under 120 words. The short version is under 40 words, suitable for chat.
- If the request is from a manager or client where saying no has consequences, keep the message respectful and note in Notes any part the user may want to discuss live instead of in writing.
</constraints>

<output_format>
## Message
Subject line if email, then the message.
## Short version
A shorter version for chat or text.
## Notes
One to three bullets: what to adjust (warmth, reason, door left open) and any risk in how it may land. "None" if none.
</output_format>

<examples>
Request: "Hi! Loved your talk last autumn. Would you speak at our 12 March meetup? 20 minutes on anything testing-related. Jordan" Reason: none given. Alternative: none.
Message: "Hi Jordan, thanks for thinking of me for the March meetup, and for the kind words about my last talk. I won't be able to speak this time. I hope the evening goes really well."
Why it works: the thanks uses only what Jordan wrote, the no is in the second sentence, and nothing is promised for later.
</examples>
````

---

<a id="write-corporate-email-brazil"></a>

## E-mail corporativo

`write-corporate-email-brazil` · prompt · Email · https://hermes-ide.com/prompts/write-corporate-email-brazil

Escreve e-mails corporativos em português do Brasil com tom profissional sem ser engessado: saudação adequada, pedidos e cobranças gentis, prazos claros e sem fórmulas ultrapassadas.

````markdown
<context>
Você é consultora de comunicação corporativa e já revisou milhares de e-mails em empresas brasileiras. O e-mail corporativo no Brasil equilibra cordialidade e objetividade: um “Olá, Marina, tudo bem?” costuma funcionar melhor do que “Prezada Senhora” com quem já se tem contato, mas o pedido precisa aparecer logo no início e com prazo. O que soa antiquado ou burocrático: “Venho por meio deste”, “Sem mais para o momento”, “Segue anexo” sem dizer o quê, gerundismo (“vou estar enviando”), “a nível de”. O que soa ríspido: cobranças secas, caixa alta, excesso de pontos de exclamação.

Objetivo: [OBJETIVO]
Destinatário: [DESTINATARIO]
<detalhes>
[DETALHES]
</detalhes>
</context>

<task>
1. Se faltar algo indispensável (um pedido sem o que exatamente se pede, uma cobrança sem o que foi enviado e quando), faça uma pergunta curta e pare. Para dados secundários, use [colchetes].
2. Assunto: específico e com prazo quando houver (“Aprovação do orçamento de novembro – retorno até 15/10”).
3. Saudação conforme a relação:
   - primeiro contato ou alta hierarquia: “Prezada Marina,” ou “Prezado Sr. Almeida,” (use “o senhor/a senhora” só se a cultura da empresa ou a idade pedir);
   - contato já estabelecido: “Olá, Marina, tudo bem?” ou “Bom dia, Marina,”;
   - colega próximo: “Oi, Pedro,”.
4. Corpo:
   - primeira frase: o motivo do e-mail; se for primeiro contato, uma linha de apresentação (nome, cargo, empresa, como chegou ao destinatário).
   - em seguida, o pedido concreto e o prazo; datas, valores e itens em lista quando houver mais de dois.
   - cobrança: retome com gentileza (“Retomo o e-mail abaixo sobre…”), ofereça ajuda ou uma alternativa, sem culpar.
   - recusa ou má notícia: agradeça, diga o “não” claramente, explique em uma frase, proponha alternativa.
   - fechamento: próxima etapa clara (“Fico no aguardo do seu retorno até sexta.”, “Fico à disposição para uma conversa rápida.”) e despedida conforme a relação: “Atenciosamente,” (formal), “Abraços,” ou “Um abraço,” (relação próxima).
   - assinatura: nome, cargo, empresa, telefone (em [colchetes] se não informados).
5. Use “você” como padrão; evite gerundismo, “a nível de”, “venho por meio deste”, “sem mais”; diga o que vai em anexo (“Segue em anexo a planilha com…”).
6. Antes de responder, confira datas, valores e nomes com os detalhes, e se o pedido e o prazo estão nas primeiras linhas.
</task>

<constraints>
- Não invente fatos, valores, prazos ou nomes.
- Não prometa descontos, multas ou compensações que não estejam nos detalhes.
- Mantenha o e-mail curto o suficiente para ser lido no celular: parágrafos de no máximo três ou quatro linhas.
- Responda inteiramente em português do Brasil.
</constraints>

<output_format>
## Assunto
## Corpo do e-mail
Pronto para enviar.
## Versão mais curta
Para quem lê pelo celular ou já conhece o assunto.
## Antes de enviar
Os [colchetes], anexos e quem colocar em cópia.
</output_format>
````

---

<a id="invite-speaker"></a>

## Invite a speaker

`invite-speaker` · prompt · Email · https://hermes-ide.com/prompts/invite-speaker

Writes an invitation to a speaker, guest expert or panelist with why them, the audience, the format, date options, what is offered and an easy reply path. Use for events, podcasts and classes.

````markdown
<context>
Speakers and guest experts receive many invitations and decide in seconds based on four things: is this for me specifically, is the audience worth my time, what exactly would I be doing and when, and what do I get. Invitations get ignored when they open with a long description of the organisation, flatter generically ("we love your work"), hide whether it is paid, leave out the time commitment (preparation, travel, the slot itself), or make replying hard. Strong invitations name the specific piece of the speaker's work that fits, describe the audience concretely, state the format, length and dates, are upfront about money and logistics, say what the organiser will handle, and close with a simple yes, no or "tell me more" path. For well-known people, the invitation often goes through an agent or assistant and must contain everything they need to put it in front of the speaker.
</context>

<task>
Write a speaker invitation to [SPEAKER].

<event>
[EVENT]
</event>
Audience: [AUDIENCE]

1. If the event's format or topic is unclear, or nothing is said about why this speaker, ask up to two questions and stop.
2. If the input suggests the speaker is booked through an agent, bureau or assistant, address it to them, keep it factual and complete, and make it easy to forward.
3. Subject: "[Invitation]: speak on [topic] at [event], [date or month]".
4. Opening: the invitation in one sentence, and why them in one or two sentences tied to their specific work as given. If the input gives no specific work, use `[need: their talk, article or project that fits]` rather than generic praise.
5. The audience: who, how many, and what they want to leave with.
6. The ask: format, length, topic or angle (with room for them to shape it), in person or remote, and the total time commitment including any prep call or rehearsal.
7. Dates: the options with time zone, and the date you need an answer by.
8. The offer: fee or honorarium, travel and accommodation, recording and how it will be used, promotion. If unpaid, say so plainly and state what is offered instead, without calling it "exposure".
9. What the organiser handles (AV, moderation, tech check, questions in advance) only as given or as placeholders.
10. Reply path: a one-line yes, no, or "happy to talk", plus a short call offer. An easy decline ("if the timing doesn't work, a recommendation of someone else would be welcome") is optional and short.
11. Write a short version (under about 70 words) for LinkedIn or a DM.
12. Under "Have ready", list what to send once they accept: event brief, speaker form, bio and headshot request with deadline, run of show, recording consent.
</task>

<constraints>
- Email body under about 200 words.
- Use only facts given; never invent audience figures, fees, past speakers, sponsors or the speaker's work. Use `[need: …]`.
- Specific, warm and professional; no gushing, no "huge fan", no pressure tactics or false scarcity.
- State money clearly in the first half of the email if it is unpaid or if the fee is a key detail.
- If a recording will be published or reused, say so in the invitation, not after acceptance.
</constraints>

<output_format>
## Email
Subject line, then the body.
## Short version
The short message.
## Have ready
Bullets.
## Notes
Placeholders and any facts to confirm. "None" if nothing.
</output_format>
````

---

<a id="write-french-formal-email"></a>

## Rédiger un e-mail formel

`write-french-formal-email` · prompt · Email · https://hermes-ide.com/prompts/write-french-formal-email

Rédige un e-mail formel en français avec la bonne formule d'appel, le bon registre et la formule de politesse adaptée au destinataire : supérieur, administration, professeur ou client.

````markdown
<context>
Vous êtes un rédacteur spécialisé dans la correspondance professionnelle et administrative en France. En français, la forme d'un e-mail formel est jugée autant que son contenu : une formule d'appel trop familière (« Cher Monsieur » à un inconnu), une formule finale incohérente avec l'appel, ou un objet vague suffisent à donner une mauvaise impression. À l'inverse, un e-mail qui respecte les codes, va droit au but dès le premier paragraphe et donne toutes les références utiles obtient une réponse plus vite.

Destinataire : [DESTINATAIRE]
Registre : formel
<objet>
[OBJET]
</objet>
</context>

<task>
1. Si une information indispensable manque (ce que vous demandez, ou le numéro de dossier pour une administration qui en exige un), posez une question brève et arrêtez-vous. Pour le reste, utilisez des [crochets].
2. Objet : précis et informatif (par exemple « Demande de report de rendez-vous – dossier n° [X] »).
3. Formule d'appel selon le destinataire et le registre :
   - personne inconnue ou service : « Madame, Monsieur, » ;
   - personne connue de nom : « Madame, » ou « Monsieur, », ou « Madame Lefèvre, » en courriel moins solennel ; « Bonjour Madame Lefèvre, » est acceptable en registre courtois ;
   - titre ou fonction : « Madame la Directrice, », « Monsieur le Professeur, », « Maître, » pour un avocat ou un notaire ; féminiser la fonction si la personne est une femme.
   Pas de « Cher Monsieur » sans relation établie.
4. Corps : premier paragraphe = qui vous êtes et l'objet de votre message ; deuxième = les faits et votre demande précise (avec délai si nécessaire) ; troisième, facultatif = pièces jointes et disponibilités. Vouvoiement constant, phrases courtes, pas de formules creuses (« Je me permets de vous contacter » une seule fois au maximum).
5. Formule finale cohérente avec le registre et qui reprend la formule d'appel quand c'est l'usage :
   - tres-formel : « Je vous prie d'agréer, Madame la Directrice, l'expression de mes salutations distinguées. » ;
   - formel : « Je vous prie de recevoir, Madame, Monsieur, mes salutations distinguées. » ou « Veuillez agréer, Madame, mes salutations respectueuses. » ;
   - courtois : « Bien cordialement, » ou « Cordialement, ».
   Ne pas mélanger un appel très formel et « Cordialement ». Éviter « exprimer mes sentiments » envers un destinataire qu'on connaît peu.
6. Signature : prénom, nom, qualité, coordonnées utiles (numéro d'allocataire, d'étudiant, téléphone), en [crochets] si inconnues.
7. Avant de répondre, vérifiez la cohérence appel / formule finale, les dates et numéros, et que la demande figure dans le premier ou le deuxième paragraphe.
</task>

<constraints>
- N'inventez ni faits, ni dates, ni numéros de dossier, ni noms.
- Pour une réclamation, restez factuel et courtois ; ne promettez pas de recours juridique au nom de l'utilisateur. Si l'enjeu est juridique (contestation avec délai, litige), mentionnez en une phrase qu'un conseiller (association de consommateurs, avocat, point-justice) peut aider.
- Répondez entièrement en français.
</constraints>

<output_format>
## Objet
## Corps du message
Prêt à envoyer, de la formule d'appel à la signature.
## Variantes de formule finale
Deux variantes, une plus formelle et une plus souple, avec le contexte où chacune convient.
## À vérifier avant l'envoi
Les [crochets] à compléter, les pièces jointes, le destinataire en copie éventuel.
</output_format>
````

---

<a id="reject-vendor-proposal"></a>

## Reject a vendor proposal

`reject-vendor-proposal` · prompt · Email · https://hermes-ide.com/prompts/reject-vendor-proposal

Tells vendors or bidders who were not selected, kindly and briefly, with optional useful feedback and no commitments that create exposure. Use after a tender, RFP or pitch.

````markdown
<context>
Vendors invest real time in proposals, and how they are told they lost shapes whether they bid again, how they talk about the buyer, and sometimes whether they challenge the decision. A good regret letter is prompt, states the outcome in the first lines, thanks them specifically, and closes cleanly. The risks are in what it adds: reasons that do not match the documented evaluation criteria, disclosure of a competitor's price or confidential details, hints of future work that read as a promise, or vague phrases ("at this time") that keep a door open that is actually shut. Public-sector buyers usually have formal duties on top of this, such as notifying all bidders at once, explaining scores against the published criteria, observing a standstill period before the contract is signed, and offering a debrief. Those rules vary by country and organisation.
</context>

<task>
Write a regret email to [VENDOR] for [PROJECT]. Include feedback: false.


1. If it is unclear which proposal or project this is, ask and stop.
2. Write the email:
   - Subject: "[Project/reference]: outcome of your proposal".
   - First two sentences: thanks for the proposal and the outcome, stated plainly ("we have decided not to take your proposal forward" or "we have awarded the contract to another supplier").
   - One sentence of genuine, specific appreciation if the input gives something specific; otherwise a plain thank-you.
   - If feedback is included: two or three factual points tied to the evaluation criteria (for example "your implementation plan scored lower than the selected bid on resourcing detail"), without naming or quoting other bidders or their prices. Or, if the reason is thin, offer a short debrief call instead.
   - If the vendor is an incumbent, state what happens to the current contract and the transition only as given, or with placeholders.
   - A neutral close. Mention future opportunities only as "we will consider you for future opportunities that fit" if the input says so; never promise or imply future work.
3. If the project is public sector or a formal tender, add placeholders for the required elements: the award decision, the scores against criteria, the standstill period end date, and the debrief offer, and flag under Before sending that the organisation's procurement rules decide the exact content.
4. Feedback notes (when feedback is included or offered): a short internal list of the points to cover in a debrief, each tied to a criterion, plus what not to discuss.
</task>

<constraints>
- Under about 150 words in the body when feedback is not included; under about 220 with feedback.
- Never disclose the winning bidder's price, proposal content, or any other bidder's confidential information. Relative statements tied to criteria are acceptable.
- Never give reasons that are not part of the evaluation (personal dislike, a friend's company, the vendor's size or location if those were not criteria), or anything discriminatory. If the input contains such a reason, leave it out and flag it under Before sending, including any conflict of interest it suggests.
- No commitments, apologies for the outcome, or language that could read as a reason to challenge ("it was very close", "we may revisit") unless true and documented.
- Use only facts given; mark gaps `[need: …]`.
</constraints>

<output_format>
## Email
Subject line, then the body.
## Feedback notes
Bullets for a debrief, or "Not included" when feedback is off and not offered.
## Before sending
Bullets: consistency with the evaluation record, procurement rules, timing relative to the award and the standstill period, and anything left out on purpose.
</output_format>
````

---

<a id="reply-to-email"></a>

## Reply to an email

`reply-to-email` · prompt · Email · https://hermes-ide.com/prompts/reply-to-email

Drafts a reply that answers every question and request in a received email from your stated position, matches its formality, proposes next steps and flags points you have not decided.

````markdown
<context>
The most common failure in a reply is answering the first question and missing the rest, which costs another round trip. The second is committing to more than the sender intended: a polite reply that accidentally agrees to a date, a price or a deliverable. A good reply answers each point in the order that is easiest to read, says clearly what happens next and who does it, and mirrors the sender's formality without copying their mood if they are upset.
</context>

<task>
Draft a reply to this email:
<email>
[EMAIL]
</email>

My position:
<position>
[MY_POSITION]
</position>

1. List every question, request, proposal and implied expectation in the email, numbered, including ones in postscripts and attachments mentioned.
2. Map my position to each item. Where my position does not cover an item, do not guess an answer: put a `[your answer on …]` placeholder in the reply and list it under Still to decide.
3. Match formality: mirror the sender's greeting, sign-off style, use of first names and length, adjusting up if they are senior or external. If the email is angry or upset, acknowledge the concern once, without matching the emotion, and move to substance.
4. Order the reply for the reader: lead with the answer they most need (usually the main yes or no, or a decision); answer the remaining points briefly, numbered if there are more than three.
5. Close with a concrete next step: who does what by when. Propose times or options when something needs scheduling.
6. Keep the original subject line with "Re:" unless the topic has changed; if so, suggest a new subject.
</task>

<constraints>
- Do not commit me to anything beyond my position: no dates, prices, deliverables, apologies or admissions of fault I did not state.
- Do not invent facts about earlier conversations, attachments or third parties.
- Keep it as short as the points allow; no filler openings or closings.
- If my position conflicts with something the sender said is fixed (for example a deadline), keep my position and flag the conflict under Still to decide.
- If my position contains a point the sender did not raise (for example "no refund" when they have not asked for one), do not volunteer it in the reply unless it is needed to answer them; list it under Still to decide as "held back" so I can choose.
</constraints>

<output_format>
## Points to answer
Numbered list of each point in their email, each marked "answered", "placeholder" or "declined".
## Reply
Subject: Re: …
The reply, ready to send apart from placeholders.
## Still to decide
Bullets: each placeholder or conflict and the decision you need to make. "None" if complete.
</output_format>
````

---

<a id="request-approval-by-email"></a>

## Request approval by email

`request-approval-by-email` · prompt · Email · https://hermes-ide.com/prompts/request-approval-by-email

Writes a bottom-line-first email asking a busy decision-maker to approve a budget, purchase, hire or exception, with options, cost, the risk of waiting and a one-line reply path.

````markdown
<context>
Approvers read approval requests on a phone between meetings. They say yes quickly when the first two lines tell them exactly what they are approving, how much it costs, and by when, and when the email shows the obvious objections have been handled: cheaper options, budget availability, policy, and what happens if they wait. Requests stall when the ask is buried after three paragraphs of background, when the approver has to reply with questions, or when the cost or the option being recommended is unclear. The bottom line up front (BLUF) pattern used in military and consulting writing exists for this reason.
</context>

<task>
Write an approval request email.

<request>
[REQUEST]
</request>

1. If you cannot tell what exactly is to be approved or roughly what it costs (money, headcount, time or risk), ask one or two questions and stop.
2. Write the subject line as "Approval needed by [date]: [what], [cost]". Use `[date]` if no deadline was given.
3. First two lines (the BLUF): the request in one sentence, including the amount and what it buys; and the reply you need ("Please reply 'Approved' or tell me which option you prefer by Thursday so we can place the order before the price rise").
4. Then, in short labelled blocks:
   - **Why:** the problem or opportunity in one or two sentences, with the business effect in numbers where the input gives them.
   - **Options:** two or three, including "do nothing" or a cheaper alternative, each with cost and main trade-off, and the recommended option marked. Skip if the input truly has a single option, and say why.
   - **Cost of waiting:** what happens if the decision slips (price, lost revenue, risk, missed deadline), only from the input.
   - **Already checked:** budget line, policy, quotes, who else agrees. Only what the input says.
5. Close with a one-line reply path ("Reply 'Approved' to go ahead with Option B") and an offer of a short call only if the request is complex.
6. Under Before sending, list attachments to include (quotes, the business case) and any `[need: …]` items.
</task>

<constraints>
- Under about 180 words in the body; it must fit on a phone screen with little scrolling.
- Use only facts in the input. Never invent costs, quotes, savings or approvals; use `[need: …]`.
- Confident, not pleading: no "sorry to bother you", no "if possible, at your convenience".
- Tailor the emphasis to the approver context if given (cost for finance, risk for legal, speed for operations), without changing the facts.
- If the request needs an exception to policy, say so plainly in the first lines rather than hoping it goes unnoticed.
</constraints>

<output_format>
## Email
Subject line, then the email body.
## Before sending
Bullets: attachments, `[need: …]` placeholders, and anyone who should be told or copied first. "Ready to send" if nothing.
</output_format>

<examples>
Weak opening: "Hi Anna, as you may know, the team has been discussing the challenges we've been having with the current laptops for some time…"
Strong opening: "Hi Anna, could you approve 9,600 EUR for 8 replacement laptops for the support team? Please reply 'Approved' by Thursday 6 Nov; the supplier's price rises 12% on 10 Nov."
</examples>
````

---

<a id="request-information-by-email"></a>

## Request information by email

`request-information-by-email` · prompt · Email · https://hermes-ide.com/prompts/request-information-by-email

Writes an email asking colleagues or vendors for specific information or documents as a numbered list with the format wanted, why it matters and a deadline, so it is easy to answer.

````markdown
<context>
Requests for information get slow, partial or wrong answers when the items are buried in a paragraph, when the format is unstated (which year, which file type, monthly or annual totals), when the reader cannot tell what is essential, and when they do not know why it is needed or by when. The fix is mechanical: a numbered list the reader can answer line by line, each item specific enough that two people would send the same thing, a clear priority, one line on purpose, a deadline with permission to send what they have, and a route for "I don't have this, ask X".
</context>

<task>
Write an email requesting information from [RECIPIENT].

<items_needed>
[ITEMS_NEEDED]
</items_needed>

1. Turn the notes into specific items. For each, settle what exactly, which period or version, the format (file type, units, level of detail), and where to send it (reply, shared folder placeholder, upload link). If an item is too vague to make specific ("the financials", "all the stuff for the audit"), ask up to three questions and stop, unless most items are clear, in which case draft and flag the vague ones under Notes.
2. Order by priority: must-have items first, marked as such; nice-to-have items last and labelled optional. If the notes do not say which matter most, keep the user's order and ask under Notes.
3. If there are more than about eight items, group them under short headings by topic or by who is likely to hold them, and suggest under Notes whether a shared checklist or folder would work better than email.
4. Write the email:
   - Subject: "[Request]: [what] for [purpose], by [date]".
   - First line: what is needed and by when, in one sentence.
   - One line on why it matters, from the purpose.
   - The numbered list.
   - How to reply: answer inline by number; partial answers welcome by the deadline; if something does not exist or someone else holds it, say so and name them.
   - Thanks in one line.
5. For vendors, reference the contract or PO if given; do not imply obligations the input does not mention.
6. Build a tracker table for the sender: item number, item, owner, status, date received.
7. Write a one-line polite follow-up to use if nothing arrives by the deadline, referencing the outstanding item numbers.
</task>

<constraints>
- Keep the prose around the list under about 90 words.
- Each item fits on one or two lines and is specific enough to be answered without a follow-up question.
- Use only the facts given; never invent reference numbers, dates, links or reasons. Use `[need: …]`.
- Neutral and courteous; no "per my last email" tone, no urgency the deadline does not justify.
- If an item could contain personal or sensitive data (salaries, health, ID documents, bank details), add a line asking for it through a secure channel rather than plain email, and say so under Notes.
</constraints>

<output_format>
## Email
Subject line, then the body with the numbered list.
## Tracker
Markdown table: #, Item, Owner, Status, Received.
## Follow-up line
One sentence.
## Notes
Vague items, placeholders, priority questions, secure-channel flags. "None" if nothing.
</output_format>

<examples>
Vague item: "Send me your sales data."
Specific item: "1. (Must-have) Monthly net sales by region for Jan 2024 to Sep 2025, as an Excel or CSV file, in EUR."
</examples>
````

---

<a id="respond-to-angry-email"></a>

## Respond to an angry email

`respond-to-angry-email` · prompt · Email · https://hermes-ide.com/prompts/respond-to-angry-email

Drafts a reply to an angry email that de-escalates, acknowledges what is valid, corrects facts without defensiveness and sets a clear next step, with a note on whether to call instead.

````markdown
<context>
An angry email usually contains three things mixed together: a legitimate grievance, some facts that are wrong or exaggerated, and emotion. Replies go wrong when they answer the emotion with emotion, defend line by line, open with corporate apology language ("We apologise for any inconvenience"), or concede things that are not true to make the anger stop. Replies that de-escalate acknowledge the person's experience specifically, own what is genuinely the sender's to own, correct facts once, calmly and with evidence, and move quickly to what happens next, often offering a call. Shorter is usually better.
</context>

<task>
Draft a reply to this email.

<email>
[EMAIL]
</email>


1. Read the email and separate: (a) the core grievance, (b) what they want, (c) claims that are valid according to the facts, (d) claims that are wrong or unclear, (e) tone issues such as insults or threats. If no facts were supplied, do not assume either side is right: write the reply so it acknowledges without conceding disputed points, and list what to check.
2. Decide the reply's single purpose, using the desired outcome if given.
3. Write the reply:
   - Open by acknowledging their experience in specific terms (what happened to them and its effect), without "I understand your frustration" boilerplate and without blaming them.
   - Own clearly anything that is genuinely the sender's fault, once, with a plain apology for that specific thing.
   - Correct wrong facts briefly and neutrally, with the evidence or reference, without "as I already said" or sarcasm.
   - State what you will do, what you cannot do and why in one line, and the next step with a date or a call offer.
   - Close courteously, without a lecture about their tone. If the email contained abuse or threats, set one calm, firm boundary.
4. Keep it under about 200 words unless the facts require more.
5. Advise whether this should be a call or meeting instead of email, and whether anyone else should be copied or consulted first.
</task>

<constraints>
- Never admit fault, liability or facts the sender did not confirm. Apologise for experience and for actual mistakes, not for things that did not happen.
- No defensiveness, sarcasm, passive aggression, or point-by-point rebuttal. No promises the facts do not show the sender can keep.
- If the email involves a legal threat, a safety issue, discrimination or harassment, say once that the sender should involve their manager, HR or legal before replying, and keep the draft neutral.
- If the email threatens violence or harm, tell the sender to keep it, not to reply alone, and to report it to their manager, security or the police as appropriate.
- Match the sender's role: a support agent follows company policy; an individual replying to a family member can be warmer.
</constraints>

<output_format>
## Read of the email
Bullets: grievance, what they want, valid points, points to correct or check, tone issues.
## Reply
Subject line and the full reply.
## Why it is written this way
Three to five bullets explaining the key choices.
## Before you send
Facts to verify, who to consult, whether to call first, and a reminder to wait a few minutes and reread before sending.
</output_format>
````

---

<a id="rewrite-email-bottom-line-first"></a>

## Rewrite an email bottom line first

`rewrite-email-bottom-line-first` · prompt · Email · https://hermes-ide.com/prompts/rewrite-email-bottom-line-first

Rewrites a long email or message bottom-line-first for a senior reader, with the ask and deadline up top and only the needed context, keeping every fact and listing what moved.

````markdown
<context>
Most long work emails are written in the order the writer thought: background, history, analysis, and finally the ask in the last paragraph. Senior readers read in the opposite order of importance and often stop after two lines. Bottom line up front (BLUF) puts the ask or the conclusion, with its deadline, in the first sentence, then the two or three reasons that support it, then only the context the reader needs to act. The risk in rewriting is losing information: a figure, a caveat or a name dropped while cutting changes the meaning. So a good rewrite also accounts for every fact in the original.
</context>

<task>
Rewrite this email bottom line first.

<email>
[EMAIL]
</email>

1. Find the bottom line: the ask (decision, approval, input, action) with its deadline, or, if the email is informational, the single most important conclusion. If an ask was supplied and it conflicts with the draft (a different amount, date or option), do not choose silently: use `[confirm: …]` in the rewrite and explain under What changed. If neither the draft nor the ask reveals any point, ask what the reader should do or know and stop.
2. Inventory the facts in the original: every figure, date, name, commitment, caveat, risk and attachment reference.
3. Write the rewrite:
   - Subject line with a tag and the bottom line: "Decision needed by Fri: …", "Action: …", or "FYI: …".
   - First sentence: the bottom line, with the deadline and its reason if the original gives one.
   - Then up to three short bullets or sentences with the reasons or key facts that support it.
   - Then a short "Background" or "Details" part for the remaining context the reader needs to act or that the original included and must not be lost.
   - Close with the reply path ("Reply 'yes' to proceed").
4. Keep the sender's relationship cues (greeting, thanks, a sensitive acknowledgement) but cut throat-clearing, repetition, hedging and narrative ("As you may recall…", "I just wanted to reach out…").
5. Fit emphasis to the reader if given (cost, risk, time, customers) without changing any fact.
</task>

<constraints>
- Keep every fact from the inventory unless it is pure filler; never add facts, figures or opinions that are not in the original or the ask.
- Aim for no more than about 60% of the original's length, unless the original is already short. Facts beat length: if keeping every substantive fact makes the rewrite longer, keep the facts, move them into Background, and say so under What changed.
- Plain words, active voice, figures as numerals.
- Do not change the meaning, the commitments or the level of certainty (a "probably" stays a probably).
</constraints>

<output_format>
## Rewrite
Subject line, then the email.
## Fact check
A table: fact from the original, where it is in the rewrite (first line, bullets, background), or "dropped: filler" with a reason. Nothing substantive may be dropped.
## What changed
Two to four bullets: what moved to the top, what was cut, any conflicts or placeholders.
</output_format>
````

---

<a id="write-italian-formal-email"></a>

## Scrivere una e-mail formale

`write-italian-formal-email` · prompt · Email · https://hermes-ide.com/prompts/write-italian-formal-email

Scrive una e-mail formale o un messaggio PEC in italiano per un ufficio, un'università o un'azienda, con registro adeguato, forme di cortesia con il Lei, formule di apertura e di chiusura corrette.

````markdown
<context>
Sei un consulente di comunicazione istituzionale con esperienza nella corrispondenza verso enti pubblici, università e aziende italiane. Una e-mail formale in italiano si giudica da pochi dettagli: il titolo giusto (Dott.ssa, Prof., Avv., Ing.), l'apertura (“Gentile” va bene per tutti, “Egregio” solo al maschile e più solenne, “Spett.le” per aziende ed enti), il Lei usato con coerenza, un oggetto preciso e una chiusura proporzionata. La PEC ha valore legale equiparabile a una raccomandata con ricevuta di ritorno: il testo va tenuto breve e preciso, e l'istanza vera e propria di solito va in un allegato PDF, firmato se richiesto.

Destinatario: [DESTINATARIO]
Invio tramite PEC: false
<oggetto>
[OGGETTO]
</oggetto>
</context>

<task>
1. Se manca un'informazione indispensabile (che cosa si chiede, oppure il numero di pratica o di matricola quando l'ufficio lo richiede chiaramente), fai una domanda breve e fermati. Per gli altri dati usa le [parentesi quadre].
2. Oggetto: preciso e riconoscibile da un ufficio (“Richiesta certificato di residenza storico – [Nome Cognome], C.F. [codice fiscale]”).
3. Apertura secondo il destinatario:
   - persona con titolo: “Gentile Prof.ssa Bianchi,”, “Gentile Dott. Ferri,”, “Egregio Avvocato,” (solo se maschile e registro solenne);
   - ufficio o ente: “Spett.le Ufficio [nome],” oppure “Alla cortese attenzione dell'Ufficio [nome],”;
   - azienda: “Spett.le [Ragione sociale],” e, se c'è un referente, “alla c.a. di [nome]”.
   Se il titolo non è noto, “Gentile Signora [Cognome]” / “Gentile Signor [Cognome]” o “Gentile [Nome Cognome]”.
4. Testo: primo paragrafo, chi scrive (nome, qualifica, matricola o riferimenti) e lo scopo; secondo paragrafo, i fatti e la richiesta precisa, con eventuale termine; terzo, gli allegati. Lei coerente (“La ringrazio”, “Le chiedo”; maiuscola di cortesia facoltativa ma uniforme), frasi brevi, niente burocratese superfluo (“con la presente” al massimo una volta).
5. Chiusura proporzionata: “Cordiali saluti” (standard), “Distinti saluti” (più distaccato, adatto a uffici), “In attesa di un Suo cortese riscontro, porgo distinti saluti.” quando si attende risposta. Firma con nome, cognome, qualifica e recapiti.
6. Se false è true:
   - testo ancora più asciutto, con riferimento esplicito all'istanza allegata (“Si trasmette in allegato l'istanza di …, firmata [digitalmente / con firma autografa scansionata e copia del documento d'identità]”);
   - nella sezione “Allegati e invio” ricorda di verificare l'indirizzo PEC ufficiale dell'ente (per le pubbliche amministrazioni, l'Indice dei domicili digitali IPA), di allegare in PDF, di conservare le ricevute di accettazione e consegna.
   Se è false, nella stessa sezione elenca solo gli allegati e un consiglio sul nome dei file.
7. Prima di rispondere verifica coerenza tra apertura, Lei e chiusura, e che date e numeri coincidano con quelli forniti.
</task>

<constraints>
- Non inventare fatti, numeri di pratica, codici fiscali, date o nomi.
- Per diffide, ricorsi o atti con scadenze di legge, scrivi il messaggio ma ricorda in una frase che conviene farlo verificare da un professionista o da un patronato/CAF secondo il caso.
- Rispondi interamente in italiano.
</constraints>

<output_format>
## Oggetto
## Testo
Pronto da inviare, dall'apertura alla firma.
## Allegati e invio
## Da verificare prima di inviare
Le [parentesi quadre] da completare e i punti da controllare.
</output_format>
````

---

<a id="set-up-inbox-filters"></a>

## Set up inbox filters

`set-up-inbox-filters` · prompt · Email · https://hermes-ide.com/prompts/set-up-inbox-filters

Designs an email label or folder scheme plus exact filter rules for Gmail, Outlook or Apple Mail from a sample of incoming mail, with a daily processing routine. Use for an overloaded inbox.

````markdown
<context>
Most overloaded inboxes are not a volume problem but a mixing problem: messages from people who need a reply sit between notifications, receipts, newsletters and CC-only threads, so everything gets the same attention. Filing systems with dozens of topic folders make it worse, because filing becomes a second job and search already finds old mail. What works is a small action-oriented scheme (five to eight labels at most), filters that pull machine-generated and low-priority mail out of the inbox automatically, a short list of senders that must always stay visible, unsubscribing instead of filtering where possible, and a fixed routine for processing what is left. Filters must never hide mail from people who need a reply, and auto-delete is almost never worth the risk.
</context>

<task>
Design an inbox filter setup for [EMAIL_CLIENT].

<sample>
[SAMPLE_SENDERS_AND_SUBJECTS]
</sample>

1. If the sample has fewer than about 15 messages or gives no senders, ask for a larger sample in "sender | subject" form and stop.
2. Classify the sample into groups: people needing a reply, people FYI or CC, automated notifications (tools, calendars, systems), transactional (receipts, invoices, shipping), newsletters and marketing, mailing lists or group mail, and possible phishing or spam. Count each group.
3. Propose a label or folder scheme of at most eight, named by what you do with the mail (for example "Read later", "Receipts", "Notifications", "Waiting on"), not by topic. Explain each in one line.
4. Write the filter rules, one per row, using only domains and addresses that appear in the sample (or the priorities). Rule 1 is always a "keep visible" rule for the priority senders (star, mark important, VIP or flag). How it protects them depends on the client, so follow the client's own logic:
   - For Gmail: give the exact search query using operators such as `from:`, `to:`, `list:`, `subject:`, `has:attachment`, `OR`, `-` and `{}`, followed by the actions (skip the inbox, apply label, mark as read, star, always mark as important, never send to spam). Gmail applies every matching filter, whatever their order, so a keep-visible filter does not stop a later filter from archiving the same message. Any filter that skips the inbox and could also match a priority sender (for example a whole-domain filter on the user's own company) must exclude that sender with `-from:` in its query; say this in one line under the rule.
   - For Outlook: the rule as conditions and actions in Outlook's terms (from, subject includes, sent only to me, my name in Cc; move to folder, categorise, mark as read). Rules run top to bottom, so put the keep-visible rule first with "stop processing more rules". Note that some conditions run only while the desktop app is open in classic Outlook.
   - For Apple Mail: the rule as conditions and actions; rules run in list order, so put the keep-visible rule first with the "Stop evaluating rules" action. Note that Mac Mail rules run only while Mail is open on that Mac, and that iCloud mail rules on the web run on the server but support fewer conditions.
   - For other: generic condition and action pairs, plus a line telling the user to check whether their client applies rules in order or all at once, and to exclude priority senders from archiving rules if it applies them all.
5. List senders to unsubscribe from or mute instead of filtering, drawn from the sample's newsletters and marketing.
6. Flag any sample items that look like phishing (lookalike domains, urgent payment or password requests) and recommend reporting them, never filtering them into a trusted label.
7. Write a daily routine: two or three set processing times, the order to work through labels, the two-minute rule for quick replies, and a weekly ten-minute review of the filters.
8. Setup notes: test each Gmail query in the search box before creating the filter, apply to existing mail only after checking the results, and which menus to look for (as general names; menu labels change between versions).
</task>

<constraints>
- Never suggest an auto-delete rule, or a rule that skips the inbox for mail from a person (as opposed to a system), unless the priorities ask for it, and then flag the risk.
- Never invent senders, domains or list ids that are not in the sample or priorities.
- At most eight labels and about twelve rules; merge rules that share an action using OR.
- Never rely on rule order alone to protect priority senders in a client that applies every matching rule.
- Mark anything you are unsure of in the client's current interface as "check in your version".
- Plain instructions a non-technical person can follow.
</constraints>

<output_format>
## Pattern summary
A short table: group, count, examples from the sample.
## Label scheme
Bullets: label and what it means.
## Filter rules
Numbered rules, rule 1 the keep-visible rule, each with the exact query or conditions, then the actions, and any exclusion it carries.
## Unsubscribe or mute
Bullets of senders.
## Daily routine
Short numbered steps.
## Setup notes
Bullets, including any phishing flags.
</output_format>

<examples>
Gmail rule: `from:(noreply@github.com OR notifications@atlassian.net)` → Skip the inbox, apply label "Notifications", mark as read.
</examples>
````

---

<a id="triage-inbox"></a>

## Triage an inbox

`triage-inbox` · prompt · Email · https://hermes-ide.com/prompts/triage-inbox

Sorts a batch of emails into reply, delegate, schedule and archive by your priorities, flags suspicious messages, and drafts the short replies and delegation notes.

````markdown
<context>
Inbox triage is a sequence of fast decisions, one per message: reply now if it takes a couple of minutes, delegate it if someone else should own it, schedule it if it needs real time or a later date, archive it if no action is needed. The value is in getting each decision right against what matters this week, catching the hidden deadline in a long thread, and not letting a phishing email or a vague "quick question" jump the queue.
</context>

<task>
Triage these emails:
<emails>
[EMAILS]
</emails>

1. If the input contains no recognisable emails, ask for them and stop.
2. For each email, identify the sender, what is being asked of me, any deadline stated in the email, and how it relates to my priorities.
3. Assign exactly one bucket:
   - **Reply:** needs my response and it can be written in about two minutes.
   - **Delegate:** someone else should own it. Name the delegate only if my priorities say who handles this; otherwise write `[who?]`.
   - **Schedule:** needs me but more than a few minutes of work or thought, or not until a later date. Estimate the time it needs and when to do it, before any deadline.
   - **Archive:** information only, newsletters, notifications, resolved threads or requests I have said to ignore.
4. Check each email for signs of phishing or fraud: urgency plus a link or attachment, requests for credentials, payment or gift cards, changed bank details, a sender name that does not match the address, or an unexpected invoice. Give these the bucket "Suspicious" in the triage table instead of one of the four, explain the signs in the Suspicious section and how to verify through a known channel (a number you already have, not one in the email); never draft a reply that complies. A routine invoice from a supplier I already use is not suspicious by itself; changed payment details or an unknown supplier are.
5. Order the triage table by urgency: hard deadlines first, then items tied to my priorities, then the rest.
6. Draft each Reply in under 80 words, and a one or two line forwarding note for each Delegate.
</task>

<constraints>
- Do not invent deadlines, facts or my decisions. Write deadlines as the email states them ("Friday", "5pm tomorrow"); do not convert them to calendar dates you cannot confirm. When a reply needs a decision I have not given, draft it with a `[decide: …]` placeholder.
- Drafts must not commit me to meetings, money or deliverables unless my priorities say so.
- If there are more than 30 emails, triage the 30 most urgent and list the rest by subject with a suggested bucket only.
</constraints>

<output_format>
## Triage
A table: # | From | Subject | Bucket | Why (one line) | Deadline.
## Draft replies
For each Reply item: "#n to <sender>", then the draft.
## Delegate
For each Delegate item: delegate, then the forwarding note.
## Schedule
For each Schedule item: what it needs, time estimate, suggested slot.
## Suspicious
Each flagged email with the warning signs and how to verify it. "None" if none.
</output_format>
````

---

<a id="write-bad-news-email"></a>

## Write a bad news email

`write-bad-news-email` · prompt · Email · https://hermes-ide.com/prompts/write-bad-news-email

Writes an email that delivers bad news, such as a cancelled project, a denied request or a missed target, with the news early, honest reasons, the impact on the reader and next steps.

````markdown
<context>
Readers of bad news want to know three things quickly: what happened, what it means for them, and what happens now. The classic "buffer" opening (praise first, news in paragraph three) now reads as manipulative, and readers skim for the "but" anyway. What preserves trust is the news in the first paragraph, reasons that are honest without being a defence brief, an acknowledgement of the reader's effort or loss that does not patronise, no false hope when the decision is final, and concrete next steps. Some news should not arrive by email first: anything that changes a person's job, pay or role, or ends a long relationship, deserves a conversation, with the email as the written follow-up.
</context>

<task>
Write a bad news email to [RECIPIENT] (internal relationship).

<news>
[NEWS]
</news>

1. If you cannot tell what the news is or who is affected, ask and stop.
2. Channel check: decide whether this should be said in person or on a call first. Recommend a conversation first when the news affects someone's job, pay, role or a long-standing relationship, or when the reader championed the work and would be blindsided. In that case still write the email, framed as the follow-up ("As we discussed this morning…").
3. Subject line: plain and specific ("Decision on the Atlas pilot"), never a disguise like "Quick update" and never alarming in caps.
4. First paragraph: the news in one or two sentences, including whether it is final. If it is not final, say what could change it and when.
5. Reasons: the main one or two, honestly, in plain words. Do not hide behind "the business has decided" when a clearer reason is available; do not list every factor. For clients and vendors, leave out internal politics and confidential numbers, and never blame a named colleague.
6. Impact on the reader: what changes for them, and an acknowledgement of their work or their loss that is specific, not generic ("the onboarding flow your team built will be reused in…" only if the input says so).
7. Next steps: what happens now, with dates, what is kept, what they need to do, and who they can talk to. For a vendor, cover outstanding work, invoices and notice per the contract if given; for a client, cover what is delivered and any commercial consequence only as stated.
8. Close with an offer to talk, with a specific way to do it.
9. List the three to five questions the reader is most likely to ask, with honest answers from the input or `[need: …]` where the answer is not known.
</task>

<constraints>
- Under about 220 words in the body.
- Use only the facts given; never invent reasons, alternatives, compensation or dates. Mark gaps `[need: …]`.
- No softening that changes the meaning: do not call a cancellation a "pause" or a denial "not right now" unless that is true.
- One sincere sentence of regret at most; no grovelling, no "unfortunately" in every paragraph, no corporate euphemisms ("right-sizing", "sunsetting the initiative").
- Do not make promises the input does not authorise (future work, guaranteed roles, refunds).
- If the news concerns redundancies, disciplinary matters or contract termination, add a line under Notes that HR or legal should review before sending.
</constraints>

<output_format>
## Channel check
One or two sentences: email is fine, or talk first and then send this.
## Email
Subject line, then the body.
## Likely questions
Numbered questions with short answers.
## Notes
Placeholders, reviewers to involve, anything deliberately left out. "None" if nothing.
</output_format>
````

---

<a id="write-client-apology"></a>

## Write a client apology

`write-client-apology` · prompt · Email · https://hermes-ide.com/prompts/write-client-apology

Writes a professional apology to a client for a service failure that owns the error, states the fix and what changes, and avoids admissions beyond the facts. Use in service businesses and freelancing.

````markdown
<context>
Clients forgive service failures more readily than they forgive the way a failure is handled. A recovery apology that keeps the client names the specific failure and its effect on them, takes responsibility in the active voice ("we sent the files late"), explains the cause briefly without excuses, shows what is already fixed and what will change, and offers a remedy only if one is authorised. It goes wrong when it is vague ("any inconvenience"), conditional ("if you were affected"), blames a subcontractor the client never chose, promises "this will never happen again", or volunteers legal conclusions. Owning the facts is different from admitting legal liability: words like "negligent", "breach of contract" or "we will cover all your losses" go beyond what happened and may conflict with contract terms or insurance conditions. For failures with significant financial loss, injury, data exposure or regulatory implications, a legal or insurance review before sending is common practice, and a phone call should come first.
</context>

<task>
Write a client apology for this service failure.

<what_happened>
[WHAT_HAPPENED]
</what_happened>

<impact_on_client>
[IMPACT_ON_CLIENT]
</impact_on_client>

<fix>
[FIX]
</fix>

1. If you cannot tell what failed or what was the sender's responsibility, ask and stop.
2. Talk first? Recommend a phone or video call before the email when the impact is significant (money, their customers, their reputation, a missed launch) or the relationship is long; the email then confirms the call in writing.
3. Write the email:
   - Subject: specific and calm ("The late delivery of your October payroll files").
   - First paragraph: the apology tied to the specific failure and its impact on the client, in the active voice, owning what was within the sender's control.
   - Cause in one or two sentences, factual. If the cause is not yet known, say so and when it will be. If a subcontractor or supplier was involved, the sender still owns it towards the client; name the supplier only if the client already knows about them and naming them helps.
   - What is fixed now, and what will change, using only the measures in the input. Concrete beats sweeping ("a second person now checks every file before sending" rather than "we have reviewed our processes").
   - Remedy only if authorised, stated plainly with any conditions.
   - Next step: a check-in date, a direct contact, or the call.
4. Under Before sending, list facts to verify, and flag when to involve legal, insurance or a data protection contact (money claimed, injury, data exposure, regulatory reporting, contract penalties).
</task>

<constraints>
- Under about 200 words in the body.
- One clear apology, early; no repeated apologies, no conditional or passive wording ("mistakes were made", "if this caused any inconvenience").
- Use only the facts given. Never invent causes, fixes, remedies or timelines; use `[need: …]`.
- Do not speculate about causes, characterise the failure in legal terms (negligence, breach, liability), quantify the client's losses, or promise to cover losses, unless the input explicitly authorises it. Say what happened; do not argue the legal consequences.
- Never promise that it will never happen again; describe what changes instead.
- This is a communication draft, not legal advice; when significant losses or obligations are involved, the Before sending section must say to have it reviewed.
</constraints>

<output_format>
## Talk first?
One or two sentences.
## Email
Subject line, then the body.
## Before sending
Bullets: facts to verify, reviewers to involve, and placeholders. "Ready to send" if nothing.
</output_format>
````

---

<a id="write-delay-notification"></a>

## Write a delay notification

`write-delay-notification` · prompt · Email · https://hermes-ide.com/prompts/write-delay-notification

Tells clients or stakeholders that a deliverable will be late, with the cause in one line, a credible new date or when it will be confirmed, the mitigation and any ask, without excuses or blame.

````markdown
<context>
A delay notice is judged on three things: how early it arrives, whether the new date is believable, and whether the reader can plan around it. People forgive one slip that is announced early with a credible plan; they stop trusting someone who sends a long excuse, blames others, or moves the date twice. The second slip usually comes from giving an optimistic date to soften the first message. Good delay notices lead with the facts, own what was in the sender's control, give a date with its dependencies, show what is being done to protect the reader, and ask for anything the reader can do to help.
</context>

<task>
Write a delay notification for a client audience.

<what_is_late>
[WHAT_IS_LATE]
</what_is_late>

<cause>
[CAUSE]
</cause>

New date: [NEW_DATE]

1. If you cannot tell what is late or the original date, ask and stop.
2. If there is no reliable new date yet, do not invent or guess one. Write the email so it commits instead to when the reader will get a confirmed date (use the date given, or `[need: date you will confirm by]`), and say what that date depends on. Sending this early beats waiting for certainty.
3. Otherwise, assess the new date before writing. Note what it depends on and anything in the cause that makes it optimistic (the same cause could recur, an external dependency is unconfirmed, no buffer). If the date looks risky, say so under Confidence check and suggest either a safer date or wording that states the dependency ("28 Nov, provided the parts arrive by 20 Nov; we will confirm on the 21st").
4. Write the email in this order:
   - Subject: "[Deliverable]: new date [date]", or "[Deliverable]: delayed, new date confirmed by [date]" when the date is not yet known.
   - First two sentences: what is late, the original date, and the new date or when it will be confirmed.
   - Cause in one sentence, factual. Own what was within the sender's control. For a client, do not blame named third parties or colleagues; describe the cause neutrally ("a component from our supplier arrived damaged").
   - Impact on the reader, if any, and what is being done to reduce it: partial delivery, a workaround, extra resource, a check-in date.
   - What is needed from the reader, if anything, with a date.
   - When they will next hear from the sender, even if nothing changes.
   - Apology matched to the audience: one sincere sentence for a client, a brief acknowledgement for internal colleagues, none or one line for executives, who want the facts and the plan.
5. For executive audiences, add one line on whether this affects any wider commitment (a launch, revenue, a contract) if the input says so.
</task>

<constraints>
- Use only the facts given. Never invent causes, mitigations, dates or compensation; use `[need: …]` where a fact would help.
- Under about 170 words for client and internal, under about 120 for executive.
- No excuse chains, no passive voice that hides the actor ("mistakes were made"), no minimising ("just a small delay") and no grovelling.
- Do not offer discounts, credits or penalties unless the input says the sender is authorised to.
</constraints>

<output_format>
## Email
Subject line, then the email.
## Confidence check
Two or three bullets: what the new date (or the confirmation date) depends on, how confident it looks, and a safer alternative if needed.
## Notes
Bullets: placeholders to fill and who else should hear before the reader does. "None" if nothing.
</output_format>
````

---

<a id="write-deliverable-cover-note"></a>

## Write a deliverable cover note

`write-deliverable-cover-note` · prompt · Email · https://hermes-ide.com/prompts/write-deliverable-cover-note

Writes the short note that accompanies a deliverable such as a report, design or analysis, saying what it is, the three things to know, what is needed from the reader and by when.

````markdown
<context>
The note that goes with a deliverable is often read more carefully than the deliverable itself, and sometimes instead of it. "Please find attached the report" wastes that moment. A strong cover note says in one line what is attached and which version, gives the three things the reader must know even if they never open it, flags any caveat honestly (data gaps, assumptions, open questions), says exactly what is needed from the reader and by when, and tells a short-on-time reader where to look first. It is not a summary of the whole document; that belongs in the document.
</context>

<task>
Write the cover note for this deliverable.

<deliverable>
[DELIVERABLE]
</deliverable>

<key_points>
[KEY_POINTS]
</key_points>

1. If you cannot tell what the deliverable is or what it found or contains, ask and stop.
2. Choose up to three points that matter most to the reader (three when the input has that many worth knowing; fewer when it does not): usually the headline finding or decision, the most consequential implication, and the most important caveat or change since the last version. If a caveat affects how the deliverable should be used (a data gap, an untested assumption, a figure still to be confirmed), it must be one of the three. Note which points you left out under Notes.
3. Write the note:
   - Subject: "[Deliverable] v[x]: [action] by [date]" or "[Deliverable] v[x] for your information".
   - First line: what is attached or linked, its version and format.
   - "Three things to know" (or "Two things to know" when there are only two), as numbered one-line points with figures where the input gives them.
   - What is needed: the specific action, the deadline and what depends on it. If no action is given, make it explicitly for information and say when the next step happens.
   - Where to start if short on time (a page, section or tab), if the input allows.
   - A one-line offer to walk through it, only if the deliverable is complex.
4. Keep the voice confident: findings stated as findings, caveats stated as caveats, without hedging every sentence.
</task>

<constraints>
- Under about 130 words.
- At most three key points: never pad with a weak point to reach three, and never squeeze in a fourth; points left out go under Notes.
- Use only the facts given; never invent findings, figures, page numbers or links. Use `[need: …]`.
- Never hide or soften a known problem with the deliverable, even if asked; state it plainly and briefly.
- No "please find attached", no "hope this helps", no "let me know if you have any questions" as filler.
</constraints>

<output_format>
## Note
Subject line, then the body.
## Notes
Points left out, placeholders, and any caveat the sender should double-check. "None" if nothing.
</output_format>

<examples>
Weak: "Hi Tom, please find attached the pricing report. Let me know if you have any questions."
Strong: "Hi Tom, attached is the pricing analysis v2 (PDF plus model). Three things to know: 1. A 6% list-price increase keeps churn under 3% in every scenario. 2. Enterprise discounts, not list price, drive most margin loss. 3. Churn assumptions use 2023 data only; 2024 data arrives next week. Needed from you: choose option A or B by Friday so sales can brief accounts on Monday. If short on time, read page 2."
</examples>
````

---

<a id="write-farewell-message"></a>

## Write a farewell message

`write-farewell-message` · prompt · Email · https://hermes-ide.com/prompts/write-farewell-message

Writes a goodbye message to colleagues, clients or a community when leaving a job or team, with specific thanks, handover pointers and a way to stay in touch, and nothing that burns bridges.

````markdown
<context>
A farewell message is read by everyone, remembered by some, and occasionally forwarded. The good ones are short, thank people for specific things, make it obvious who to contact now, and leave a door open. The bad ones list every project ever touched, thank everyone generically, hint at grievances, or (with clients) announce where the person is going in a way that breaches their contract or looks like poaching. Specific thanks ("Leo, for the night you stayed until 2 a.m. to get the Lisbon launch out") mean far more than a list of names, but naming a few people in a company-wide email can make others feel left out, so the specific thanks belong in team messages or separate notes.
</context>

<task>
Write a warm farewell message for team.

<leaving_details>
[CONTEXT]
</leaving_details>

1. If you cannot tell where the person is leaving from or roughly when, ask and stop.
2. Shape the message by audience:
   - **team:** personal; specific thanks to named people or moments from the leaving details; who takes over what; a way to stay in touch.
   - **company:** shorter; thanks to groups and the organisation rather than a long list of names; what you are proud of in one line; contact details.
   - **clients:** professional; thanks for the relationship; the date your involvement ends; the named successor and their contact; reassurance on continuity. Do not mention where you are going unless the leaving details say your employer has agreed.
   - **community:** what the community gave you, a nod to what continues, how to find you.
3. Include, in this order: the news and your last day; thanks with specifics from the leaving details; handover pointers (who to contact for what); how to stay in touch; a short warm close.
4. Match the tone: warm is personal and sincere; brief is three to five sentences; funny uses one or two light touches drawn from the leaving details, never jokes at someone's expense.
5. Write a subject line.
</task>

<constraints>
- Use only details from the leaving details. Never invent anecdotes, names, achievements or contact details; use `[your personal email]`, `[successor name]` and similar placeholders.
- No grievances, criticism or hints about why you are leaving, even if the leaving details mention a hard exit. If the person was made redundant or is leaving on difficult terms, keep it gracious and neutral, and say so under Before sending.
- No confidential information about projects, clients or the reasons for leaving.
- Under about 200 words for team and community, about 150 for company and clients.
</constraints>

<output_format>
## Message
Subject line, then the message.
## Before sending
Bullets: placeholders to fill, timing (usually on the last day or the day before, after your manager and close colleagues know), whether to send individual thank-you notes to people not named, and for clients, whether your employer must approve the message first.
</output_format>
````

---

<a id="write-follow-up-email"></a>

## Write a follow-up to an unanswered email

`write-follow-up-email` · prompt · Email · https://hermes-ide.com/prompts/write-follow-up-email

Writes a polite follow-up to an unanswered email that adds new context, makes the ask easier to answer and sets a gentle deadline, in three escalation levels from nudge to final note.

````markdown
<context>
Most unanswered emails are not refusals. The recipient was busy, the ask was unclear or too big to answer quickly, or it sank under newer mail. A follow-up that just says "Just checking in!" or "Bumping this to the top of your inbox" adds nothing and can read as passive-aggressive. Follow-ups that work restate the ask in one line, make it easier to say yes (a yes or no question, a choice of two options, a default the sender will act on), add something new (a fact, a deadline, a smaller version of the request), and get shorter and clearer with each round, while staying courteous.
</context>

<task>
Write follow-ups to this email, sent 5 days ago with no reply.


<original_email>
[ORIGINAL_EMAIL]
</original_email>

1. If the original email is missing or has no identifiable ask, say what is unclear and ask what the sender needs from the recipient, then stop.
2. Diagnose why it may have gone unanswered: was the ask buried, vague, too big, or missing a deadline? Name the one change that will help most.
3. Write three escalating follow-ups, each designed to be sent as a reply in the same thread so the original stays below:
   - **Follow-up 1 (gentle nudge):** two to four sentences. Restate the ask in one clear line, add one helpful element (new context, a link, a smaller ask or a yes-or-no version), and propose a soft date.
   - **Follow-up 2 (make it easy):** shorter. Offer a choice or a default ("If I don't hear by Thursday, I'll go ahead with option A"), or offer another route (a 10-minute call, the right person to ask instead).
   - **Follow-up 3 (close the loop):** a courteous final note that releases the recipient or states what the sender will do next, leaving the door open. Only include a default action the sender can genuinely take.
4. Keep the subject line of the thread; suggest a clearer subject only if the original was vague, as "Re: [original]" plus the ask.
5. Recommend when to send each one, adjusted for the relationship, any deadline in the original, and the 5 days already passed.
</task>

<constraints>
- Polite, warm and direct. No guilt ("I know you're busy, but…" repeated), no sarcasm, no "per my last email", no fake urgency or invented deadlines. A deadline must come from the original or be clearly the sender's own preference.
- Do not assume the recipient is ignoring the sender, and never threaten.
- Match the formality of the original email and the relationship. For a hiring manager or a senior person, keep it brief and deferential; for a supplier who owes a deliverable, it can be firmer.
- Do not invent facts, attachments or prior conversations.
- If more than one follow-up would be inappropriate (for example a job application after a final round, or a personal message), say so and recommend only what fits.
</constraints>

<output_format>
## Diagnosis
One or two sentences.
## Follow-up 1
Subject line, then the email.
## Follow-up 2
Subject line, then the email, or "Not recommended" and the reason when a second follow-up would not fit the situation.
## Follow-up 3
Subject line, then the email, or "Not recommended" and the reason.
## Timing
When to send each, and when to switch channel (call, chat, someone else) instead.
</output_format>
````

---

<a id="write-meeting-request-email"></a>

## Write a meeting request email

`write-meeting-request-email` · prompt · Email · https://hermes-ide.com/prompts/write-meeting-request-email

Writes an email asking a busy person for a meeting with the purpose, the length, proposed slots in their time zone and a pre-read. Use when booking time with stakeholders or clients.

````markdown
<context>
Busy people accept a meeting when the request shows, in the first two lines, what the meeting is for, what they get out of it, and how little time it takes. They decline or ignore requests that say "let's catch up" or "pick your brain", that ask them to do the scheduling work, or that offer slots in the sender's time zone at 6 a.m. theirs. The best requests name a concrete outcome ("agree the go-live date"), give a short agenda, offer two or three slots already converted to the recipient's time zone, attach or promise a pre-read with the minutes it takes to read, and make it easy to delegate or decline.
</context>

<task>
Write a meeting request for a 30-minute meeting.

<recipient>
[RECIPIENT_CONTEXT]
</recipient>

<purpose>
[PURPOSE]
</purpose>

1. If the purpose gives no outcome or reason for this person specifically (for example "just want to connect"), ask one question about what the meeting should achieve and stop.
2. Write a subject line that names the topic, the length and the timeframe, for example "30 min next week: agree pilot scope for Q1".
3. Open with the purpose and the outcome in one or two sentences, and why this person: their decision, expertise or stake, using only what the recipient context gives. If you have never met, add one line on who the sender is.
4. Give a two- or three-item agenda ending in the outcome.
5. Offer the times:
   - Convert each slot to the recipient's time zone and show it first, with the sender's time in brackets only when the zones differ ("Tue 11 Nov, 10:00 Chicago time (17:00 CET)"). Account for daylight-saving changes between the zones on those dates, and flag in Notes any date near a changeover.
   - Drop or flag slots that fall outside about 08:00 to 18:00 for the recipient.
   - If the recipient's time zone is unknown, keep the sender's zone, label it, and add `[confirm: recipient time zone]`.
   - If no times are given, ask for two or three slots that suit them or offer a booking link as `[booking link]`.
6. Mention the pre-read if there is one, with how long it takes to read, or say none is needed.
7. Close with an easy out: offer a shorter call, an async answer by email, or the right person on their team instead.
8. Write the calendar invite title and description (agenda plus pre-read link placeholder) to send once they accept.
</task>

<constraints>
- Under about 130 words in the email body.
- Never invent the recipient's interests, mutual contacts, deadlines or slots. Mark unknowns `[need: …]`.
- Do not flatter or apologise for asking ("I know you're incredibly busy, sorry to bother you"). One line of courtesy is enough.
- Times are always written with weekday, date and time zone, never "tomorrow" or "next Tuesday" alone.
- Keep the meeting length the user chose; if the agenda clearly cannot fit, say so under Notes rather than changing it silently.
</constraints>

<output_format>
## Email
Subject line, then the body.
## Calendar invite
Title, then a three-to-five line description.
## Notes
Time zone conversions used, placeholders to fill, and anything to check. "None" if nothing.
</output_format>
````

---

<a id="write-neighbourhood-notice"></a>

## Write a notice to your neighbours

`write-neighbourhood-notice` · prompt · Email · https://hermes-ide.com/prompts/write-neighbourhood-notice

Writes a clear notice or group message to neighbours or a building about an issue or event, such as building works, a lost pet or a street party, with the facts, the ask and a friendly tone.

````markdown
<context>
Notices to neighbours are read in passing: a glance at a lift wall, a notification preview, a flyer on a door. They work when the point is clear in the first line, the key facts (what, when, where, who to contact) are easy to find, the ask is specific, and the tone is friendly enough that people want to help. They backfire when they read as passive-aggressive, blame a neighbour in public, share more personal details than needed, or bury the date in a paragraph.

Purpose: [PURPOSE]
Channel: group-chat
<details>
[DETAILS]
</details>
</context>

<task>
1. Check the details for what this kind of notice needs and stop to ask (in one short message) if something essential is missing: for an event, date, time and place; for works, dates, daily hours and a contact; for a lost pet, name, description, where and when last seen, and a contact; for a request or complaint, what exactly you are asking people to do.
2. Write the notice for group-chat:
   - flyer: a large headline that says the point in a few words, the key facts as short lines (What, When, Where, Contact), one or two friendly sentences, and a note of where a photo, map or tear-off contact strip would go.
   - group-chat: the point in the first line so it shows in the notification preview, then two to five short lines with the facts and the ask, and a friendly sign-off with first name and flat or house number. At most one or two emoji, only if it suits the tone.
   - email: a subject line that states the point and date, then a short body with the facts in a list and the ask.
3. Tone: warm and neighbourly. For works or disruption, apologise once and say what you are doing to limit it. For a request or complaint, describe the problem and the ask without blaming anyone, assume good faith, and avoid capital letters and exclamation marks used as pressure.
4. Short reminder: a one- or two-line follow-up to post the day before or on the day (or, for a lost pet, a "still missing" or "found, thank you" update).
5. Before you post: a short checklist of privacy and practical points for this notice (share only a first name and a way to be contacted that you are comfortable with, do not name or picture a neighbour you are complaining about, check building or landlord rules on posting notices, add the photo for a lost pet, take down flyers afterwards).
6. Before answering, check the first line carries the point, every date and time from the details appears correctly, and the ask is specific.
</task>

<constraints>
- Use only the facts given; never invent dates, times, phone numbers or names. Use [X] for anything missing that is not essential.
- Keep it short enough to read at a glance; cut background that neighbours do not need.
- For disputes that have gone beyond a friendly notice (threats, harassment, legal claims, repeated serious noise), say once that a direct conversation, the landlord or building manager, mediation or the local council may be a better route.
- Do not write anything that shames, threatens or identifies a specific neighbour publicly.
</constraints>

<output_format>
## Notice
The ready-to-post text, formatted for group-chat.
## Short reminder
## Before you post
Three to five checklist items.
</output_format>

<examples>
Illustrative group-chat opening for building works: "Heads-up: kitchen works in Flat 4 from Mon 10 to Fri 14 March, 9:00 to 17:00."
</examples>
````

---

<a id="write-professional-email"></a>

## Write a professional email

`write-professional-email` · prompt · Email · https://hermes-ide.com/prompts/write-professional-email

Drafts an email from rough intent with a specific subject line, the ask in the first two sentences and the right tone for the relationship, marking any detail it would otherwise have to invent.

````markdown
<context>
Busy recipients decide from the subject line and the first two sentences whether to act now, later or never. Emails get ignored when the ask is in the last paragraph, when several unrelated requests share one message, when the reader must work out what is wanted or by when, or when the tone is wrong for the relationship (over-familiar with a stranger, stiff with a close colleague). A good work email is short, makes the next step obvious and easy, and gives just enough context to act.
</context>

<task>
Write an email to [RECIPIENT] in a neutral tone that achieves this:
<intent>
[INTENT]
</intent>

1. If the intent does not make clear what the recipient should do or know, ask one short question and stop.
2. Name the single outcome you want from the recipient (a reply, a decision, a meeting, a document, awareness). If the intent mixes unrelated requests, put the main one in this email and note in Placeholders that the others may deserve their own.
3. Write a subject line that states the topic and the action, with a date if there is a deadline, for example "Approval needed by 12 May: Q3 travel budget".
4. Put the ask, or the key information, in the first two sentences. Then give only the context the recipient needs to act.
5. Make the next step easy: specific options or times, the deadline and why it matters, what is attached, and who else is involved.
6. Fit the relationship: a stranger gets a one-line reason you are writing to them and how you got their name; a senior or formal recipient gets full greetings and no slang; a friendly colleague gets brevity and contractions.
7. Close with a clear line about what happens next, then a sign-off suited to the tone.
</task>

<constraints>
- Under 150 words in the body unless the intent truly needs more; if it does, use short paragraphs or a short list.
- Never invent facts: names, dates, times, numbers, attachments, prior conversations or titles not in the input become `[placeholders]`.
- No filler openings ("I hope this email finds you well") unless the tone is formal and the relationship is new, and never more than one such line.
- No over-apologising, guilt-tripping or false urgency.
</constraints>

<output_format>
## Email
Subject: …
The email body, ready to paste.
## Placeholders
Bullets: each `[placeholder]` with what to put there, plus any split-out requests. "None" if none.
## Alternative subject lines
Two alternatives, one shorter and one more specific.
</output_format>
````

---

<a id="write-scope-change-email"></a>

## Write a scope change email

`write-scope-change-email` · prompt · Email · https://hermes-ide.com/prompts/write-scope-change-email

Tells a client that a request is outside the agreed scope without friction, and offers options (a paid change, a swap or deferral) with cost and timeline. For freelancers, agencies and consultants.

````markdown
<context>
Most scope creep is not bad faith: clients do not remember the statement of work, and each request feels small. Freelancers and agencies lose money and goodwill in two ways: saying yes silently and resenting it, or saying no in a way that sounds like a contract lawyer. The professional middle path treats the request as a good idea worth doing properly, points neutrally to what was agreed, and offers clear choices with their cost and timeline, so the client decides. Starting work before the change is agreed in writing is the most common, most expensive mistake.
</context>

<task>
Write an email about this new request.

<original_scope>
[ORIGINAL_SCOPE]
</original_scope>

<new_request>
[NEW_REQUEST]
</new_request>

1. Check the scope first. Classify the request as in scope, out of scope, or ambiguous, quoting the part of the original scope that decides it. If it is in scope, say so and write a short, positive confirmation email instead. If ambiguous, say what makes it ambiguous and write the email as a friendly clarification that proposes your reading.
2. For an out-of-scope request, offer two or three options, choosing those that fit:
   - **Add it as a change:** price and timeline impact.
   - **Swap it:** replace an agreed item of similar effort, named specifically.
   - **Defer it:** to a later phase or a follow-on project, with when.
   - **Reduced version:** a smaller piece that fits within the current scope, if one exists.
   Recommend one if the input suggests which is best for the client.
3. Write the email:
   - Open positively about the idea or the client's goal behind it.
   - One or two sentences that state, neutrally, that it falls outside what was agreed, referring to the specific part of the agreement, without quoting the contract at them in full.
   - The options, each in one or two lines with cost and timeline.
   - The next step: which option they would like, and that work on it will start once they confirm in writing (a reply is enough, or a signed change order if the contract requires one).
4. Write a change summary table the client can approve.
</task>

<constraints>
- Use only the costs and timings supplied. If none are supplied, use `[price]` and `[+N days]` and list them under Notes; never invent rates.
- Friendly, confident and brief: under about 200 words. No apologising for having a scope, no passive-aggressive phrasing ("as clearly stated in the contract").
- Do not threaten to stop work or cite legal terms unless the user asks.
- If the request would affect a fixed deadline or other deliverables, say so in the options.
</constraints>

<output_format>
## Scope check
Classification, the deciding part of the original scope, and one line of reasoning.
## Email
Subject line, then the email.
## Change summary
Table: Option · What is included · Cost · Timeline impact · Status (to approve).
## Notes
Bullets: placeholders to fill, and advice on recording the agreement. "None" if nothing.
</output_format>
````

---

<a id="write-weekly-update-to-manager"></a>

## Write a weekly update to your manager

`write-weekly-update-to-manager` · prompt · Email · https://hermes-ide.com/prompts/write-weekly-update-to-manager

Turns a messy week of notes into a short update for one's manager, covering outcomes against priorities, blockers with specific asks, risks and next week's focus, as an email, chat message or bullets.

````markdown
<context>
A weekly update to a manager has one reader with three questions: is this person's work on track, does anything need me, and is there anything I should know before someone else tells me? Managers skim activity lists ("had 9 meetings, worked on the deck") and remember outcomes ("the pricing deck is approved by sales; Tuesday's customer call moved the pilot forward"). Good updates map the week to the agreed priorities, put asks where they cannot be missed, raise risks early while they are still small, and keep it short enough to read in a minute. They are also the record that makes performance reviews and promotion cases easier later.
</context>

<task>
Write a weekly update in email format.

<week_notes>
[WEEK_NOTES]
</week_notes>

1. If the notes are empty or contain nothing from this week, ask for the week's notes and stop.
2. Turn activity into outcomes: for each item, say what changed as a result (shipped, decided, unblocked, learned). Drop pure activity that led to nothing the manager needs to know, and list it under Left out.
3. If priorities are given, organise progress by priority and mark each on track, at risk or behind, with a reason. If a priority had no progress this week, say so honestly in one line. If no priorities are given, group by theme and add a line asking the manager to confirm priorities only if the notes suggest they are unclear.
4. Pull out asks: anything the manager needs to decide, approve, unblock or know, each with a "by when". Put them first if urgent.
5. Flag risks early: anything that could slip, a dependency on another team, a concern about workload or scope, phrased factually with what you plan to do about it.
6. Add next week's focus in two or three items.
7. Render for the format:
   - email: subject "Weekly update – [date or week]", then Needs from you · Progress · Risks · Next week. Under about 200 words.
   - chat: one short opening line, then up to eight bullets with the asks first. Under about 120 words.
   - bullets: headed sections with terse bullets for a 1:1 doc.
</task>

<constraints>
- Use only facts in the notes. Do not inflate results, invent numbers or add achievements; use `[need: …]` if an obvious figure is missing.
- Plain and direct. No "just wanted to quickly share", no apology for problems that are simply facts.
- Credit others where the notes show their contribution.
- Keep frustrations about colleagues factual and focused on the work and the ask; do not include judgements of people.
</constraints>

<output_format>
## Update
The update in the chosen format.
## Left out
Bullets: items from the notes deliberately left out and why (activity without outcome, too minor, better said in person). "Nothing" if nothing.
</output_format>
````

---

<a id="write-account-handover-email"></a>

## Write an account handover email

`write-account-handover-email` · prompt · Email · https://hermes-ide.com/prompts/write-account-handover-email

Introduces a new account owner to a client when responsibility changes, covering continuity, what stays the same, open items and a meeting offer. Use for account managers and freelancers.

````markdown
<context>
When an account owner changes, the client's first worry is not the person but the risk: will deadlines slip, will they have to explain everything again, will pricing or service change. Clients churn after handovers that arrive as a surprise, from someone they have never heard of, with no date and no word about open work. The handovers that keep clients come from the outgoing owner as a warm introduction, say when the change happens and how long the outgoing owner overlaps, name what stays the same, show the incoming owner already knows the open items, and offer a short joint call. A separate first note from the incoming owner then starts the new relationship.
</context>

<task>
Write an account handover email for [CLIENT], from [OUTGOING_OWNER] introducing [INCOMING_OWNER].


1. If it is unclear who takes over, ask and stop. Missing dates or details become placeholders.
2. Write the handover email from the outgoing owner, with the incoming owner in copy:
   - Subject: "[Client/project]: introducing [incoming owner] as your new account lead".
   - First two sentences: the change, the effective date (or `[need: effective date]`), and that the outgoing owner remains reachable until a stated date if given.
   - Reason in one neutral sentence if it is shareable (a move, a promotion, a team change). Leave out anything sensitive such as a performance issue, a dispute, health or a departure the company has not announced, and say so under Notes.
   - Why the incoming owner is a good fit, using only the experience given. If none is given, leave `[need: one line on relevant experience]` rather than inventing praise.
   - What stays the same: contract, pricing, team, service levels, tools and contact routes, only as stated or as placeholders to confirm.
   - Open items as a short list with status and dates, showing the incoming owner has been briefed.
   - A joint call offer with two or three slot placeholders or proposed times, 20 to 30 minutes.
   - Sincere thanks to the client for the relationship in one or two lines, specific to it if the input allows.
3. Write a short first note from the incoming owner to send after the introduction: thanks, one line on what they will do first (review the open items, confirm the call), and their direct contact details.
4. Under Notes, list what to confirm internally before sending (pricing, notice, any commitments the outgoing owner made verbally) and whether to phone the client first if the relationship is long or sensitive.
</task>

<constraints>
- Handover email under about 200 words; incoming note under about 80 words.
- Use only facts given; never invent experience, dates, commitments, pricing or names. Use `[need: …]`.
- Do not promise that nothing will change if the input suggests changes; state what is known.
- Warm and confident, not apologetic. The tone says "you are in good hands", supported by facts, not adjectives.
- Never disclose internal reasons the client does not need, and never criticise the outgoing or incoming owner.
</constraints>

<output_format>
## Handover email
Subject line, To/Cc line, then the body.
## Incoming owner follow-up
Subject line, then the body.
## Notes
Placeholders, internal checks, and whether to call first. "None" if nothing.
</output_format>
````

---

<a id="write-email-to-professor"></a>

## Write an email to a professor

`write-email-to-professor` · prompt · Email · https://hermes-ide.com/prompts/write-email-to-professor

Writes a student's email to a professor or adviser about an extension, a grade, research, a recommendation or an absence, with correct etiquette and one clear ask.

````markdown
<context>
Professors receive many student emails and answer the ones that are easy to act on: a subject line with the course, a correct title, the student identified, one clear request and the facts needed to decide. They tend to ignore or bristle at emails that start "Hey", ask a question the syllabus answers, ask "did I miss anything important?", argue for points, or arrive the night before a deadline with no plan. Each purpose has its own conventions:

- **Extension:** ask before the deadline, give the reason briefly (no medical detail; "documentation is available through student services" is enough), say what is done, and propose a specific new date.
- **Grade question:** ask to understand the marking against the rubric, not to negotiate points; check whether the course has a waiting period or regrade form; offer office hours.
- **Research inquiry:** show you read their recent work (name it), say what you bring (courses, skills, hours per week), ask a specific question (is there space in the lab this term?), attach a CV.
- **Recommendation:** ask at least three to four weeks ahead, ask whether they can write a strong letter, give an easy way to decline, and promise a packet (CV, statement, deadlines, submission links, courses and grades with them).
- **Absence:** inform rather than ask permission unless attendance rules require it, and ask how to catch up after checking the course site.
</context>

<task>
Write a [PURPOSE] email to a professor or adviser for [COURSE_OR_CONTEXT].

<key_facts>
[KEY_FACTS]
</key_facts>

1. If the facts lack something the ask cannot work without (for an extension: the assignment and its due date; for a recommendation: what the letter is for and its deadline; for a research inquiry: who the professor is or what their work is about), ask up to two questions and stop.
2. If the facts show the answer is probably in the syllabus or on the course site (late policy, regrade process, attendance rules), say so first under Before sending and still draft the email in case it is not.
3. Subject line: course code plus the request, for example "BIO 214 sec. 2: extension request for Lab Report 3 (due 14 Nov)".
4. Salutation: "Dear Professor [Surname]," or "Dear Dr [Surname]," using the name and title in the facts; if unknown, use `[Surname]`. Never first names unless the facts say the professor invited it.
5. First sentence: who the student is (name placeholder, course, section). Second sentence: the ask, specific and answerable with yes, no or a date.
6. Then the minimum supporting facts for the purpose, following the conventions above. Keep private matters private: name the category (medical, family emergency) only if the student wants to, never the details.
7. Close with what the student will do next or attach, thanks in one line, and a sign-off with full name and student number placeholder where the institution uses one.
</task>

<constraints>
- Under about 150 words in the body (a research inquiry may run to about 200).
- One ask per email. If the facts contain two requests, put the more urgent in the email and mention the other under Before sending.
- Use only the facts given. Never invent reasons, grades, papers, documentation or deadlines, and never write a false excuse even if asked; offer an honest version instead.
- Respectful and direct: no "Hey", no "Sorry to bother you", no pleading, no entitlement ("I deserve an A").
- Write in the conventions of the country in the facts if stated (for example "Dear Professor" in the US, "Dear Dr" for many UK academics); otherwise use "Professor".
</constraints>

<output_format>
## Email
Subject line, then the body.
## Before sending
Bullets: syllabus or policy checks, attachments, placeholders to fill, and when to follow up if there is no reply (usually after three to five working days).
</output_format>
````

---

<a id="write-escalation-email"></a>

## Write an escalation email

`write-escalation-email` · prompt · Email · https://hermes-ide.com/prompts/write-escalation-email

Writes an escalation to a manager, vendor or another team that states the issue, its impact, what was already tried and the specific decision or help needed by a date, without blame.

````markdown
<context>
An escalation asks someone with more authority or reach to unblock something you cannot unblock yourself. It works when the reader can act on it in two minutes: the ask and deadline are at the top, the impact is concrete, the history shows you made reasonable attempts, and the tone is factual rather than accusatory. It backfires when it is a complaint about a person, when it skips the people directly involved without warning them, when the ask is vague ("please help"), or when it arrives as a surprise to someone who will be embarrassed by it.
</context>

<task>
Write an escalation email.


<issue>
[ISSUE]
</issue>

1. If you cannot tell what is blocked, the impact, or what the recipient could do about it, ask up to three short questions and stop.
2. Check whether escalation is the right move now: has the direct owner been asked clearly, with a deadline, and told the matter would be escalated? If not, say so in "Check before escalating" and include a one-paragraph heads-up message to the direct owner first. Still write the escalation, ready for later.
3. Define the ask precisely: a decision (choose A or B), an action (assign an engineer, approve spend, call the vendor), or a priority call, with a date and the reason for that date.
4. Write the email:
   - Subject line: "[Decision/Help needed by date]: short issue".
   - First two lines: the ask, the deadline and the impact if nothing changes.
   - Context in three to five bullets: what is blocked, since when, impact in numbers where the facts allow, and who is affected.
   - What has been tried, as a short dated list, stated neutrally.
   - Options if helpful, with your recommendation.
   - A closing line offering a 15-minute call and stating what you will do in the meantime.
5. Recommend who to copy and who must be told before sending.
</task>

<constraints>
- Factual and neutral: describe actions and results, not people's character or motives. No sarcasm, no "per my last five emails".
- Use only facts from the input; mark missing figures or dates `[NEEDED: …]`.
- Keep the email under about 250 words; put long threads in an attachment or link, not in the body.
- For a vendor, refer to the contract or service level only if the input mentions it, and do not threaten legal action unless the user says that is the intent.
- If the issue involves harassment, discrimination, safety or a possible legal breach, say that the right channel may be HR, a safety officer or legal rather than a normal escalation.
</constraints>

<output_format>
## Check before escalating
Whether the direct owner has been given a fair chance, and the heads-up message if one is needed. "Ready to escalate" if so.
## Escalation email
Subject line and the email.
## Notes
Who to copy, who to tell first, `[NEEDED: …]` items, and when to follow up if there is no answer.
</output_format>
````

---

<a id="write-event-invitation"></a>

## Write an event invitation

`write-event-invitation` · prompt · Email · https://hermes-ide.com/prompts/write-event-invitation

Writes an invitation email for a work social, workshop, offsite or community event with why to come, logistics, RSVP mechanics and accessibility notes, plus a reminder. Use when organising an event.

````markdown
<context>
People decide whether to open an invitation from the subject line and whether to come from the first two lines: what it is, when, and why it is worth their evening or afternoon. Attendance then depends on removing friction: a single obvious way to RSVP, a deadline with a reason, a calendar hold, and logistics they do not have to ask about (end time, how to get there, cost, food). Organisers often forget the people who silently skip events: those who need step-free access, captions or a quiet space, those with dietary needs, carers who need an end time, and people who do not drink. A good invitation tells everyone what is already in place and invites them to ask for what they need, privately and without having to explain why.
</context>

<task>
Write a friendly invitation for [AUDIENCE].

<event_details>
[EVENT_DETAILS]
</event_details>

1. If the date, the start time, or the place (or link) is missing, ask for it and stop. Everything else can be a placeholder.
2. Subject line: event name, date and a hook, for example "Thu 4 Dec: support team winter social at the Boathouse".
3. Opening: what it is and why this audience should come, in two sentences. Base the "why" on the details (who will be there, what they will learn, decide or celebrate), not on generic enthusiasm.
4. Logistics block, as short labelled lines: date and time with start and end and the time zone for online or mixed audiences; place with address and how to get there, or the link and platform; cost and who pays; food and drink, including that non-alcoholic options are available if the details say so; dress code if any; what to bring or prepare.
5. RSVP: one action (reply, form placeholder, or calendar accept), the deadline and its reason, and what to include: dietary requirements and access needs. If there is no deadline, suggest one under Missing details.
6. Accessibility and inclusion: state only the arrangements given in the details (step-free access, captions, quiet room, parking, recordings). Where nothing is given, do not claim it; instead invite people to tell a named contact what they need, and list the unknowns under Missing details. If attendance is optional for a work social, say so plainly.
7. Write a calendar hold title and short description.
8. Write a three-to-four line reminder to send two or three days before, repeating the essentials and the RSVP or "see you there".
</task>

<constraints>
- Invitation body under about 180 words, with the logistics scannable on a phone.
- Never invent venue features, menus, speakers, prices or links; use `[need: …]` placeholders and list them.
- Match the tone: formal means no exclamation marks or emojis; friendly allows warmth; playful allows one or two light touches but the logistics stay plain.
- No pressure or guilt to attend ("everyone is expected") for socials, unless the details say attendance is required, in which case say so neutrally.
- Write dates with weekday and date, and times with start, end and time zone where readers may be in different zones.
</constraints>

<output_format>
## Invitation
Subject line, then the body.
## Calendar hold
Title, then two or three lines.
## Reminder
Subject line, then the body.
## Missing details
Bullets of placeholders and accessibility unknowns to confirm with the venue. "None" if nothing.
</output_format>
````

---

<a id="write-introduction-email"></a>

## Write an introduction email

`write-introduction-email` · prompt · Email · https://hermes-ide.com/prompts/write-introduction-email

Writes a double opt-in introduction, first the private ask to the person being introduced, then the intro email itself, with why the two should talk and an easy next step.

````markdown
<context>
A double opt-in introduction asks the busier or more senior person privately whether they want the intro before connecting them. It protects the connector's relationships and makes the eventual intro warmer, because both people have agreed. Good introductions are short and specific: who each person is in one line, why they in particular should talk, what is in it for the person being asked, and an easy next step that puts the burden on the person who asked. Weak ones are vague ("you two should connect!"), forward a long thread, or obligate a busy person in public.
</context>

<task>
Write a double opt-in introduction.

<person_a>
[PERSON_A]
</person_a>

<person_b>
[PERSON_B]
</person_b>

<reason>
[REASON]
</reason>

1. If it is unclear who is asking for what, or why person B would want this, ask one or two short questions and stop.
2. Decide who needs to opt in (usually the busier person, or whoever is being asked for something; both when the intro would reveal something sensitive about either, such as a confidential job search). Say which and why in Notes.
3. Write a private opt-in request to each person who needs to opt in: two to five sentences naming who the other person is, the specific reason they might want to talk, what is being asked of them (time, advice, a meeting), and an easy way to decline ("No worries at all if the timing isn't right"). Suggest the person who asked for the intro supplies a forwardable blurb.
4. Write the introduction email, to be sent once both agree: a subject line with both names, one line on each person (what they do and why relevant to the other), the specific reason for the intro, and a clear next step, usually that the person who asked will follow up with times. Suggest moving the connector to BCC.
5. Write a two-sentence forwardable blurb for each person in case either needs it.
</task>

<constraints>
- Specific and brief: each email under about 150 words. No gushing superlatives.
- Use only the facts given about each person; do not invent titles, companies or achievements.
- Never imply someone has already agreed when they have not.
- Do not share private details about one person with the other unless the brief says it is fine.
- Put the effort on the person who benefits most: they schedule, they follow up.
</constraints>

<output_format>
## Opt-in request
One per person who needs to opt in: To: [name]. Subject line and the message.
## Introduction email
Subject line and the message, to send once both agree.
## Blurbs
Person A: two sentences. Person B: two sentences.
## Notes
Who should opt in and why, and any detail to confirm before sending.
</output_format>
````

---

<a id="write-out-of-office-message"></a>

## Write an out-of-office message

`write-out-of-office-message` · prompt · Email · https://hermes-ide.com/prompts/write-out-of-office-message

Writes out-of-office auto-replies for leave, travel or parental leave with the return date, who to contact for what, and what happens to messages meanwhile. Use before going away.

````markdown
<context>
An out-of-office reply is read by someone who wanted something from you and now has to decide what to do. It works when it answers three questions in the first lines: when you are back, who can help with what in the meantime, and whether their message will be read or should be resent. It fails when it says "back Monday" with no date, routes everything to one overloaded colleague, or overshares. Auto-replies go to strangers, mailing lists and scammers too, so the external version should not reveal where you are, that a home is empty, private reasons such as health, or internal phone numbers and org details that help social engineering. The internal version can carry more detail: project links, channels and named owners.
</context>

<task>
Write out-of-office auto-replies for a both audience in a friendly tone.

Reason for absence (private context, not to be disclosed): [REASON]
First day back: [RETURN_DATE]

1. Decide how much of the reason to say. Default to a neutral "I am out of the office". Mention a reason only when it helps the reader and is not private: a conference or business trip may be named without the location for external readers; parental leave may be mentioned if the reason says so; medical, family, bereavement or other personal reasons are never named.
2. State the return date as a full date with weekday. If the return date is vague ("next week", "Monday"), use it but add `[confirm: full date]`. If it is uncertain, say "until [month]" or "for an extended period" and lean harder on the contacts.
3. Route by topic, not just by name: "For invoices, contact…; for urgent issues with live orders, contact…". Use only the contacts given. If none are given, say messages will be answered after the return date and suggest the reader resend anything urgent then; do not invent a colleague or a shared inbox.
4. Say what happens to messages: read on return, or (for absences of three weeks or more) not read and to be resent after the return date. Pick the one that fits the length of absence and say which you chose under Notes.
5. Write the external version (if needed) first, then the internal one (if needed). The internal version may add links, channels and the people covering specific projects, if given.
6. Write a one-line chat status (for Slack, Teams or similar) with the return date.
7. Write a short settings checklist for the absence: schedule start and end, separate internal and external replies, reply once per sender, avoid replying to mailing lists where the client allows it, decline or hand over meetings in the calendar, and tell the backup contacts before switching it on.
</task>

<constraints>
- Body under about 80 words per version; the first two lines must carry the return date and where to go instead.
- Never reveal private reasons, the travel destination, personal phone numbers or a home address in the external version. If the backup contacts include a personal mobile, keep it out of the external version and say why under Notes.
- Never promise a reply time you cannot keep ("I will reply within 24 hours of my return") unless the input says so.
- No jokes or emojis in the formal tone; in the friendly tone, warmth is fine but no puns about the beach.
- Use only the names, addresses and numbers given; never invent them.
</constraints>

<output_format>
## Auto-replies
For each audience: a subject line (for clients that allow one, such as "Out of office until Mon 17 Nov"), then the body.
## Chat status
One line.
## Settings checklist
Four to six bullets.
## Notes
Placeholders to fill, what you left out on purpose and why. "None" if nothing.
</output_format>

<examples>
Weak: "I'm currently out of the office with limited access to email. I'll respond as soon as possible upon my return."
Strong: "Thanks for your email. I'm away until Monday 17 November and won't be reading messages. For invoices, please contact Priya at finance@example.com; for anything else, I'll reply when I'm back."
</examples>
````

---

<a id="write-negotiation-email"></a>

## Write the next email in a negotiation

`write-negotiation-email` · prompt · Email · https://hermes-ide.com/prompts/write-negotiation-email

Drafts the next email in a negotiation with a client, vendor or landlord that anchors well, trades every concession for something and makes a clear proposal, while the walk-away point stays private.

````markdown
<context>
In a written negotiation each email is a move that is hard to take back. Principles from negotiation practice that hold up in email:
- **Anchor with a reason.** The first credible number shapes the range; an anchor backed by an objective standard (market rate, past price, cost, a published index) is harder to dismiss.
- **Never give a concession for free.** Trade it, conditionally: "If you can commit to 12 months, we can do 8% off." Unconditional concessions teach the other side to keep asking.
- **Concede in decreasing steps** so the pattern signals you are near your limit.
- **Package issues** (price, scope, timing, payment terms, volume, length of contract) so both sides can trade what they value differently.
- **Keep the walk-away point, alternatives and internal deadlines private.** Revealing them caps what you can get.
- **Separate the people from the problem**, especially in an ongoing relationship: firm on substance, warm in tone.
- Honesty matters: invented competing offers, fake deadlines or false claims about costs damage trust and can backfire badly when discovered.
</context>

<task>
Draft the next email in this ongoing negotiation.

<thread_or_situation>
[THREAD_OR_SITUATION]
</thread_or_situation>

<your_goal_and_limits>
[YOUR_GOAL_AND_LIMITS]
</your_goal_and_limits>

1. If you cannot tell what is being negotiated, what the other side's latest position is, or what the user wants, ask up to three questions and stop.
2. Read the situation (for the user only): the other side's likely interests and constraints behind their position, the issues on the table, where there is room to trade, who has more leverage and why, and the gap between the positions.
3. Choose the move for this email and explain it: open or counter with an anchor, trade a concession, add an issue to create value, ask a question to learn their constraint, hold firm, or propose to close. Name the objective standard the anchor rests on, if the input supplies one.
4. Write the email:
   - Acknowledge their position or a shared goal in one sentence.
   - State your proposal clearly with numbers and terms; if trading, use "if you…, we can…".
   - Give the reason briefly; do not over-justify.
   - Make it easy to say yes: a specific next step and, if real, a date.
   - Tone: warm and firm for ongoing relationships; courteous and businesslike for one-off deals.
5. Prepare the user for the reply: the next move if they accept, if they counter at a stated likely figure, and if they refuse; and the point at which to walk away (kept private).
</task>

<constraints>
- The email must never reveal the user's walk-away point, budget ceiling, alternatives they would accept, internal deadlines or eagerness, unless the user explicitly wants to disclose one as a tactic.
- No invented facts: no fictional competing offers, fake deadlines, invented market rates or claims about costs not in the input. If an objective standard would help and none was given, suggest the user find one and use `[benchmark: …]`.
- No threats or ultimatums unless the user's limits make walking away real and they want to signal it; then state it calmly as a fact, not a threat.
- Email under about 200 words.
- If the negotiation involves employment terms, legal claims, a lease dispute or settlement of a debt, note that terms with legal effect should be checked before agreeing.
</constraints>

<output_format>
## Read of the situation
Short bullets for the user only.
## Strategy for this email
The chosen move, the anchor or trade and why, and what is deliberately left unsaid.
## Email
Subject line if needed, then the email.
## If they reply
Bullets: if they accept, if they counter, if they refuse, and the private walk-away point.
</output_format>
````

---

<a id="write-korean-business-email"></a>

## 비즈니스 이메일 작성

`write-korean-business-email` · prompt · Email · https://hermes-ide.com/prompts/write-korean-business-email

요청, 보고, 사과 등 한국어 업무 이메일을 올바른 높임법, 표준적인 인사와 맺음말, 결론부터 쓰는 구조로 작성한다. 사내외 호칭과 자주 틀리는 높임 표현을 점검한다.

````markdown
<context>
당신은 국내 기업에서 오래 일하며 신입 사원의 업무 메일을 첨삭해 온 비즈니스 글쓰기 전문가입니다. 한국어 업무 메일은 내용만큼 형식과 높임이 평가됩니다. 제목만 보고 용건을 알 수 있어야 하고, 첫 문단에 결론이 있어야 하며, 호칭과 높임이 정확해야 합니다. 흔한 실수는 사물에 높임을 붙이는 것(“자료가 나오셨습니다”), “~하실게요”, 윗사람에게 “수고하세요”, 사내 메일에서 압존법을 과하게 쓰는 것(국립국어원 『표준 언어 예절』은 직장에서는 압존법을 쓰지 않는 것을 권합니다), 그리고 용건을 메일 끝에 숨기는 것입니다.

목적：[PURPOSE]
받는 사람：[RECIPIENT]
<details>
[DETAILS]
</details>
</context>

<task>
1. 목적을 이루는 데 꼭 필요한 정보가 없으면(요청인데 기한이 없음, 사과인데 무슨 일이 있었는지 없음, 보고인데 현재 상태가 없음) 메일을 쓰지 말고 짧은 질문으로 묻고 멈춘다. 보내는 사람 정보가 없으면 [회사명] [이름]으로 둔다.
2. 제목: 말머리와 핵심 내용, 필요하면 기한(예: “[요청] 11월 납품분 견적서 송부 요청 (10/15까지)”, “[보고] A 프로젝트 3분기 진행 현황”).
3. 본문 순서:
   - 호칭: “김민수 과장님”, 부서 전체에는 “구매팀 담당자님께” 등. 직함 뒤에 “님”을 붙이고 “과장님님”처럼 겹치지 않게 한다.
   - 인사와 소개: 사외는 “안녕하십니까, (주)○○ △△팀 □□□입니다.”, 첫 연락이면 연락하게 된 경위 한 문장, 사내는 “안녕하세요, △△팀 □□□입니다.”.
   - 결론(두괄식): 첫 문단에 용건과 요청 사항.
   - 세부 내용: 일정, 수량, 금액, 첨부 파일은 번호 목록으로.
   - 맺음: 목적에 맞게(“검토 부탁드립니다.”, “회신 주시면 감사하겠습니다.”, “다시 한번 불편을 드려 죄송합니다.”) 후 “감사합니다.”
   - 서명: 이름, 부서·직함, 회사, 연락처(모르면 []).
4. 목적별 요령:
   - 요청: 이유와 기한을 밝히고, 상대의 수고를 인정하는 말(“바쁘신 와중에 번거로우시겠지만”)은 한 번만.
   - 보고: 현재 상태(정상/지연/위험) → 근거 수치 → 이슈와 대응 → 필요한 결정.
   - 사과: 사실 → 사과 → 원인 → 조치 → 재발 방지. 변명으로 시작하지 않는다.
   - 독촉: 상대를 탓하지 않고 이전 메일 날짜를 언급하며 확인을 부탁한다.
5. 보내기 전에 높임 수준이 일관한지, 사물 높임·잘못된 “-시-” 사용이 없는지, 날짜·수치가 내용과 같은지, 맞춤법(“되/돼”, “안/않”, “-ㄹ게요/-ㄹ께요”)을 점검한다.
</task>

<constraints>
- 내용에 없는 사실, 날짜, 금액, 이름을 지어내지 않는다. 모르는 것은 []로 표시한다.
- 사과 메일에서 보상이나 법적 책임을 약속하는 문장은 사용자가 그렇게 정한 경우에만 쓴다.
- 문장은 짧게, 한 문단은 서너 줄 이내로 쓴다.
- 모든 답변은 한국어로 쓴다.
</constraints>

<output_format>
## 제목
한 줄, 필요하면 대안 하나.
## 본문
그대로 보낼 수 있는 메일.
## 높임 표현 점검
헷갈리기 쉬운 표현 두세 개와 그렇게 쓴 이유.
## 보내기 전 확인
[]로 남긴 항목, 첨부, 참조(CC) 대상 등.
</output_format>
````

---

<a id="write-japanese-business-email"></a>

## ビジネスメールを敬語で書く

`write-japanese-business-email` · prompt · Email · https://hermes-ide.com/prompts/write-japanese-business-email

依頼・お詫び・催促・お礼・お断りの日本語ビジネスメールを、正しい敬語、定型の挨拶と結び、クッション言葉、読みやすい構成で作成する。社外・社内どちらにも使える。

````markdown
<context>
あなたは日本企業の社内外コミュニケーションに長く携わってきたビジネス文書の専門家です。日本語のビジネスメールは、敬語の正しさだけでなく「型」で評価されます。宛名、挨拶、名乗り、要旨、詳細、結び、署名という順番が崩れていたり、二重敬語やバイト敬語が混じっていたりすると、内容が正しくても相手に不安を与えます。逆に、型を守りつつ要件が一目で分かるメールは信頼を生みます。

目的：request
宛先と関係：[RECIPIENT]
<details>
[DETAILS]
</details>
</context>

<task>
1. 内容を確認し、目的に欠かせない情報がなければ、メールを書かずに短い質問をまとめて送り、回答を待つ。
   - request：何を、いつまでに、どうしてほしいか。
   - apology：何が起きたか、相手への影響、原因（分かる範囲）、対応と再発防止策。
   - follow-up：最初に送った日付と内容、改めて必要な期限。
   - thanks：何に対するお礼か（具体的な出来事）。
   - refusal：何を断るか、理由として伝えてよい範囲、代案の有無。
   差出人の会社名・氏名が不明な場合は［会社名］［氏名］のまま進めてよい。
2. 件名：内容と用件が一目で分かるようにする（例：「【ご依頼】10月分見積書ご送付のお願い（10/15まで）」）。follow-up は、元のメールに返信して件名を残す案と、「【再送】」「【ご確認のお願い】」を付けた新しい件名の案を示す。
3. 本文を次の順で書く。
   - 宛名：社外は「株式会社〇〇 部署名 役職 氏名様」。役職と「様」は重ねず「部長 山田様」とし、「山田部長様」としない。組織宛ては「御中」。社内は「〇〇部長」「〇〇さん」など社風に合わせる。
   - 挨拶と名乗り：社外は「いつもお世話になっております。株式会社〇〇の△△でございます。」、初めての相手は「突然のご連絡失礼いたします。」、社内は「お疲れ様です。」。
   - 要旨：用件を最初の一、二文で述べる。
   - 詳細：日時、数量、期限などは箇条書きにする。
   - 結び：目的に合った結びの言葉で締める（「何卒よろしくお願い申し上げます。」など）。
   - 署名：会社名、部署、氏名、連絡先（不明なら［］のまま）。
4. 目的別の書き方：
   - request：クッション言葉（「お忙しいところ恐れ入りますが」「お手数をおかけしますが」）を一度だけ使い、期限と理由を明記する。
   - apology：言い訳から始めない。事実→お詫び→原因→対応→再発防止の順。お詫びは冒頭と結びの二回程度に抑える。
   - follow-up：相手を責めず、「行き違いでしたら何卒ご容赦ください」などで逃げ道を残す。
   - thanks：具体的に何が助かったかを書く。
   - refusal：感謝→お断り（曖昧にしない）→理由→代案や今後への期待。
5. 誤用を避ける：二重敬語（「おっしゃられる」「お伺いさせていただく」）、「させていただく」の多用、尊敬語と謙譲語の取り違え（「拝見なさる」）、社外に対して自社の人を高める表現（「弊社の山田部長がおっしゃいました」→「弊社の山田が申しておりました」）、「了解しました」「ご苦労様です」の目上への使用。
6. 送る前に、宛名の敬称、日付と期限、数字が詳細と一致しているか、要旨が冒頭にあるかを自分で確認する。
</task>

<constraints>
- 詳細にない事実、日付、金額、人名を作らない。不足は［］で示す。
- 一文を長くしすぎず、一段落は三、四行までにする。
- 謝罪で法的責任や補償を約束する表現（「全額補償いたします」など）は、詳細にその判断が書かれている場合だけ使う。
- 社内チャットで十分な軽い用件でも、依頼された場合はメールとして書く。
- 回答はすべて日本語で書く。
</constraints>

<output_format>
## 件名
件名を一行。必要なら別案を一つ。
## 本文
そのまま送れる本文。
## 敬語と言い回しのポイント
使った表現のうち迷いやすいもの二〜四点と、その理由。
## 送信前の確認
［］で残した項目と、添付や期限など送る前に確かめること。
</output_format>

<examples>
request の要旨の例：「さて、10月分のお見積書につきまして、10月15日（木）までにご送付いただけますでしょうか。」
</examples>
````

---

<a id="write-workplace-wechat-message"></a>

## 职场微信沟通

`write-workplace-wechat-message` · prompt · Email · https://hermes-ide.com/prompts/write-workplace-wechat-message

为微信、企业微信或钉钉撰写简洁得体的工作消息，如向领导汇报进度、请示、提醒同事、婉拒请求，按上下级关系调整称呼和语气，并给出跟进话术。

````markdown
<context>
你是一位熟悉国内职场沟通的写作教练。工作消息是在手机上被扫一眼就决定回不回的：开头只发“在吗”、一件事拆成五条、发长语音、对领导用太随意的语气词，或者对同事的提醒写得像催债，都会让事情变慢、关系变僵。好的工作消息结论先行、一条说清、对方知道要做什么和什么时候做，语气符合双方的关系。

目的：[PURPOSE]
对象：[RECIPIENT]
<details>
[DETAILS]
</details>
</context>

<task>
1. 如果缺少对方完成这件事所必需的信息（例如请示却没有可选方案或截止时间，提醒却没有具体事项和时间），先用一句话问清楚再写；次要信息可用【】占位。
2. 推荐版本：
   - 开头直接称呼加正事，不单发“在吗”“在不在”。称呼按关系：领导用“王总”“李经理”或公司惯用的称呼；平级同事用名字或“X老师”等公司习惯；群聊需要特定的人处理时用 @。
   - 按目的组织内容：
     - 汇报进度：结论（按计划／有风险）—关键进展（数字）—风险和应对—需要的支持。
     - 请示：一句话背景—方案 A／B 及利弊—我的建议—需要对方在什么时间前决定。
     - 提醒：先给台阶（“可能消息太多被刷下去了”），再说具体事项和时间，不用感叹号施压。
     - 婉拒：先表示理解或感谢—简短说明原因（手头的优先事项）—给替代方案（时间、人或部分帮助）。
     - 请假或调休：时间、工作交接安排、紧急联系方式。
   - 长度控制在手机一屏内；多项内容用 1. 2. 3. 分行。
   - 对领导少用“哈”“呢”“~”和表情；对熟悉的平级同事可以适当轻松，一个表情即可。
3. 更简短的版本：两三句话的版本，适合对方很忙或群聊。
4. 跟进消息：如果对方一段时间没回，可以发的一条礼貌跟进。
5. 发送提示：两到四条，例如是否该私聊而不是群聊、是否附上文件或截图、敏感话题（绩效、离职、投诉、薪资）建议当面或电话沟通、避免对领导发长语音。
6. 发送前自查：时间、数字、人名与素材一致；对方读完知道要做什么、什么时候做。
</task>

<constraints>
- 只用素材中的事实，不编造进度、数据或理由。
- 不写阿谀奉承或贬低他人的话；群聊中不点名批评。
- 涉及考勤、薪资、劳动纠纷等情况时，只写沟通措辞，不判断谁对谁错，必要时建议查看公司制度或咨询 HR。
- 全部用简体中文作答。
</constraints>

<output_format>
## 推荐版本
可直接复制发送的消息。
## 更简短的版本
## 跟进消息
## 发送提示
</output_format>

<examples>
请示的开头示例：“王总，618 活动的主视觉有两个方案，需要您周三下班前定一下：……”
</examples>
````
