# Hodios paste pack: Email

Everything in Email from Hodios, the open prompt library by Hermes IDE: 15 entries, catalog 2026.1003.0.

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
  - [Build a personal email template library](#build-email-templates) (prompt)
  - [Decline a request gracefully](#decline-request-gracefully) (prompt)
  - [Reply to an email](#reply-to-email) (prompt)
  - [Request approval by email](#request-approval-by-email) (prompt)
  - [Respond to an angry email](#respond-to-angry-email) (prompt)
  - [Triage an inbox](#triage-inbox) (prompt)
  - [Write a delay notification](#write-delay-notification) (prompt)
  - [Write a farewell message](#write-farewell-message) (prompt)
  - [Write a follow-up to an unanswered email](#write-follow-up-email) (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 escalation email](#write-escalation-email) (prompt)
  - [Write an introduction email](#write-introduction-email) (prompt)
  - [Write the next email in a negotiation](#write-negotiation-email) (prompt)

---

<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="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="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="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="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-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-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-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-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-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-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>
````
