# Hodios paste pack: Business writing
Everything in Business writing from Hodios, the open prompt library by Hermes IDE: 8 entries, catalog 2026.1002.2.
Every entry is dedicated to the public domain under CC0 1.0. Copy, change and share them freely, no attribution needed.
Browse and search the library at https://hermes-ide.com/prompts
## How to use
Find an entry below and copy the text inside its block into ChatGPT, claude.ai or any chat. Replace each [PLACEHOLDER] with your own material. Personas, rules and styles work best as custom instructions or project instructions.
## Contents
- Business writing
- [Write a decision memo](#write-decision-memo) (prompt)
- [Write a handover document](#write-handover-document) (prompt)
- [Write a professional bio](#write-professional-bio) (prompt)
- [Write a project proposal or business case](#write-project-proposal) (prompt)
- [Write a project status report](#write-status-report) (prompt)
- [Write a white paper](#write-white-paper) (prompt)
- [Write an executive summary](#write-executive-summary) (prompt)
- [Write an internal announcement](#write-internal-announcement) (prompt)
---
## Write a decision memo
`write-decision-memo` · prompt · Business writing · https://hermes-ide.com/prompts/write-decision-memo
Writes a one-page decision memo with the decision needed and by when, context, options with honest trade-offs, a recommendation and next steps. Use when asking a manager to approve something.
````markdown
A decision memo exists to get a clear yes, no or choice from a busy person in a few minutes. It fails when the decision is buried under background, when the options are a straw man next to the favourite, when costs and risks are vague, or when the reader has to write back to ask what exactly they are approving. Good memos put the ask and the deadline in the first lines, compare real options on the same criteria, admit the downside of the recommendation, and say what happens next under each answer.
Write a one-page decision memo.
[SITUATION]
1. If you cannot tell what decision is needed or the situation gives no facts to weigh (only feelings or a general complaint), ask up to three short questions and stop. Missing options are not a reason to stop: propose them in step 4. A missing decision-maker is not either: address the memo to `[NEEDED: decision-maker]`, write for a busy senior reader who knows the business but not this issue, and say so under Gaps.
2. State the decision as one question with a yes, no or choice answer, and the date it is needed by (with the reason for that date, such as a notice period or a release date in the situation). If no date can be derived, mark `[NEEDED: decide-by date]`.
3. Write the context the decision-maker needs and nothing more: three to six sentences on what is happening, why it matters now, and the cost of not deciding. Fit it to what the decision-maker already knows and cares about.
4. Lay out two to four genuine options. Always include "do nothing" or "delay" if it is realistic. Compare them on the same criteria (cost, benefit, risk, time, reversibility, effect on people or customers), using only figures from the situation and marking unknowns.
5. Recommend one option and give the deciding reason in one or two sentences. Name its main downside and how it will be managed. If the facts do not support a clear recommendation, say what would settle it.
6. Write next steps if approved: who does what by when, and the first checkpoint where the decision could be revisited.
- One page: about 350 to 500 words for the memo itself.
- Use only the facts supplied. Never invent costs, dates, percentages or names; mark each gap `[NEEDED: …]` and list it.
- Present options fairly. Do not weaken the alternatives to make the recommendation look better; if an option is clearly not viable, say why in one line.
- Plain, neutral language. No hype, no hedging, no "synergies". Numbers in figures, with units.
- If the decision touches legal, HR, safety or regulatory obligations, note who must also sign off.
## Memo
**To / From / Date / Decision needed by** (names and dates from the situation, otherwise `[NEEDED: …]`)
**Decision needed:** one question.
**Recommendation:** one sentence.
**Context:** short paragraph.
**Options:** a table with options as rows and the criteria as columns, then one line per option on its main risk.
**Why this recommendation:** two to four sentences, including its downside.
**Next steps if approved:** numbered, each with owner and date.
## Gaps to fill
Each `[NEEDED: …]` with what it is and where to get it. "None" if none.
## Before you send
Two or three checks specific to this memo (for example "confirm the vendor price is still valid").
````
---
## Write a handover document
`write-handover-document` · prompt · Business writing · https://hermes-ide.com/prompts/write-handover-document
Writes a handover for leave or a role change covering responsibilities, open work status, contacts, access, recurring tasks, known risks and first-week priorities, with gaps listed as questions.
````markdown
A handover is read by someone covering work they did not build, often in a hurry, on the day something goes wrong. It fails when it is a diary of history instead of a guide to action, when "status" means "in progress" with no next step, when access and passwords are an afterthought, and when the knowledge that lives only in the leaver's head (the client who needs a call not an email, the report that breaks every quarter-end) never gets written down. A good handover is organised by what the reader must do, says who decides what, and is honest about what is unfinished.
Turn these notes into a handover document.
[ROLE_AND_WORK]
1. If the notes do not say what the role is or list any current work, ask for them and stop.
2. Sort everything in the notes into the sections below. Do not drop anything; if an item fits nowhere, put it under "Other notes".
3. For each open piece of work, state: what it is, current status in one line, the very next action, the owner from the handover date, the deadline, and where the files or tickets live. If any of these are missing, write `[ASK: …]` in that cell.
4. Separate decisions the cover person can make alone from ones that need someone else, and name that person or role.
5. Build a calendar of recurring tasks (daily, weekly, monthly, quarterly) with the date of the next occurrence if the handover date allows it.
6. Pull out the tacit knowledge: workarounds, quirks, sensitive relationships and "if X happens, do Y" rules, and write each as a short instruction.
7. Write the first-week priorities: the three to five things the cover person must do or check first.
- Never put passwords, keys, tokens or personal data in the document. Say where access is managed (password manager, IT ticket, admin) and who grants it; if the notes contain a secret, leave it out and warn about it in Questions before you go.
- Use only facts from the notes. Do not invent names, dates, systems or statuses.
- Keep it scannable: tables for open work, contacts and recurring tasks; short bullets elsewhere. Write for someone who has never seen this work.
- Be neutral and factual about colleagues and clients; describe working preferences, not personalities.
## Handover
**Summary:** role, handover period, cover person or `[ASK]`, and how to reach the leaver if at all (or "do not contact").
**First-week priorities:** numbered.
**Open work:** table: Work | Status | Next action | Owner | Deadline | Where it lives.
**Responsibilities:** bullets, marking which are delegated, paused or covered by whom.
**Decisions:** two lists: "You can decide" and "Escalate to …".
**Recurring tasks:** table: Task | Frequency | Next due | How | Where.
**Contacts:** table: Name or role | What for | Notes on working with them.
**Access and tools:** table: System | What it is used for | How to get access.
**Known risks and quirks:** bullets with "if this happens, do this".
**Other notes**
## Questions before you go
Every `[ASK: …]` gathered into one list for the leaver to answer, plus any warning about secrets found in the notes.
## Handover meeting agenda
A 30 to 45 minute agenda for walking the cover person through it.
````
---
## Write a professional bio
`write-professional-bio` · prompt · Business writing · https://hermes-ide.com/prompts/write-professional-bio
Writes the bio others read or say about you on speaker pages, programmes, proposals, author notes and team pages, at one-line to long lengths, angled to that reader and built only from your facts.
````markdown
A professional bio is usually read or spoken by someone else on your behalf: the conference programme, the host who introduces you, the proposal a client's board skims, the note at the back of a book. It answers one question for that reader: why should I listen to, hire or trust this person for this? Weak bios list job titles in date order, stack adjectives ("passionate, results-driven, visionary") and read the same for every audience. Strong ones lead with what the person does and for whom, give two or three proofs that matter to this reader (a result with a number, a body of work, a credential this audience respects), and end with one specific human detail or what the person is working on now. The same career yields different bios for a hospital board and a design meetup, because the proof each reader cares about differs. Character-limited social profiles (Instagram, X, LinkedIn headline) are a different job with platform limits; this prompt does not write them.
Write professional bios for: general professional audience. Point of view: third.
[BACKGROUND]
1. If the background lacks the person's name, current role, or anything concrete to prove it (a result, a body of work, a credential, years in a field), ask for what is missing in up to three short questions and stop. If the audience is a character-limited social profile, say that a platform bio written to that site's character limit fits better, then write only the one-liner and short bio.
2. Choose the angle: the one thing this reader most needs to know about the person, in one sentence. Pick the two or three proofs from the background that support it best for this reader, and leave the rest out rather than listing everything.
3. Write each length in the requested point of view. In third person, use the full name first, then the stated pronouns, or the surname or first name again (matching the register) if pronouns are not given:
- **One-liner:** up to 25 words, for a badge, byline or slide.
- **Short:** 50 to 70 words, for programmes and directories.
- **Medium:** 100 to 150 words, for speaker pages and proposals.
- **Long:** 200 to 250 words, for an about or team page, with a little more story and one personal detail if supplied.
4. Open every version with what the person does and for whom, not a date or a title list. End the medium and long versions with something specific and human from the background, or what the person is working on now.
5. Write a 20- to 30-second introduction (about 50 to 70 words) a host can read aloud: spoken rhythm, the name said last as the cue to walk on, nothing hard to pronounce without a marker.
- Use only facts in the background. Never invent clients, numbers, awards, publications, degrees or employers. Do not inflate: "contributed to" stays "contributed to", and "led" only when the background says so. If the person asks for claims the background does not support, leave them out and say why in Gaps.
- No empty adjectives (passionate, dynamic, visionary, results-driven, thought leader) unless a fact proves them, and then use the fact instead.
- Keep job titles and organisation names exactly as given.
- Do not include personal details the person did not offer, such as family, age, health or location.
- Match the register of the audience: formal for a board proposal, warmer for a community event. Hit each word range and show the count.
## Angle
One sentence, then the proofs chosen and why they matter to this reader.
## One-liner
## Short bio
With word count.
## Medium bio
With word count.
## Long bio
With word count.
(With `both`, give the third-person version, then the first-person version, under each heading.)
## Introduction to read aloud
The spoken introduction, with `[pronunciation?]` after any name the host should check.
## Facts used
Bullets mapping each claim to the part of the background it came from.
## Gaps
Unsupported requests left out, and details that would strengthen the bio (a number, a client type, a credential) as questions. "None" if none.
````
---
## Write a project proposal or business case
`write-project-proposal` · prompt · Business writing · https://hermes-ide.com/prompts/write-project-proposal
Writes an internal project proposal or business case covering the problem, options, recommendation, cost, benefits and risks, and marks every missing number instead of inventing it.
````markdown
A proposal is a request for a decision. Approvers ask the same questions every time: what problem, how big, what happens if we do nothing, what else could we do, what will it cost, what do we get and when, what could go wrong, and what exactly are you asking for. Proposals fail when they sell a single solution without alternatives, state benefits with no basis, hide the cost of people's time, or leave the ask vague. A credible business case shows its assumptions so the approver can challenge them.
Write a proposal for [AUDIENCE] based on this idea:
[IDEA]
1. If the idea does not say what problem it solves or what is being asked for, ask up to three short questions and stop.
2. State the problem in the approver's terms (money, time, risk, customers, staff), with evidence from the input, and the cost of doing nothing over a stated period.
3. Lay out at least three options, always including "do nothing" and one smaller or cheaper alternative. Compare them on cost, benefit, time to value, risk and effort from existing staff.
4. Recommend one option and give the deciding reason in one sentence.
5. Cost the recommendation: one-off and recurring costs, and people's time. Use figures from the input; where a figure is missing, write `[need: …]` and say who could supply it.
6. State benefits as measurable outcomes with a basis ("saves about 6 hours a week, based on the 120 tickets a month in the data"). Label anything without a basis as an estimate and record the assumption.
7. List the main risks with likelihood, impact and a mitigation for each, and name any dependency on other teams.
8. Define success: two or three measures, the current baseline and the target, and when you will report back.
9. End with the specific ask: what decision, how much money or how many people, by when, and the first step after a yes.
- Never invent numbers, quotes, vendors or results. Every figure is from the input, a calculation from input figures shown in Assumptions, or a `[need: …]` placeholder.
- Tailor emphasis to [AUDIENCE], but do not drop risks or costs to make the case look better.
- Keep the proposal to about two pages (roughly 800 to 1,000 words). Lead with a three-sentence summary: problem, recommendation, ask.
- Plain language and active voice; define any acronym the audience may not know.
## Proposal
Sections in this order: Summary · Problem and cost of inaction · Options considered (table: Option | Cost | Benefit | Time to value | Risk | Effort) · Recommendation · Cost and resources · Benefits · Risks and mitigations (table) · Success measures · The ask and next steps.
## Assumptions
Numbered: each assumption or calculation behind a figure, with the input it came from.
## Gaps to close before sending
Bullets: each `[need: …]` placeholder, plus the hardest question the approver is likely to ask that the proposal cannot yet answer.
````
---
## Write a project status report
`write-status-report` · prompt · Business writing · https://hermes-ide.com/prompts/write-status-report
Writes a project status report with an evidence-based RAG status, progress, risks, decisions needed and next steps, formatted as an email, a document or a single slide.
````markdown
A status report exists so that people outside the work can spot trouble early and make the decisions only they can make. The classic failure is the "watermelon" report: green on the outside, red inside, because the author reports activity instead of progress against the plan, or softens bad news. Readers want the status and the reason in one line, then what needs their attention.
RAG definitions to apply:
- **Green:** on track for the committed scope, date and budget; no help needed.
- **Amber:** at risk; the team has a credible recovery plan within its own control, or a decision is needed soon to stay on track.
- **Red:** will miss scope, date or budget without intervention, a decision or extra resources from outside the team.
Write a email status report for project stakeholders from these updates:
[UPDATES]
1. If the updates contain no information about progress against a goal or date, ask what the milestones and dates are and stop.
2. Set the overall RAG status from the evidence using the definitions above, not from the tone of the notes. If the notes imply green but contain a slipped milestone, an unresolved blocker past its date or a budget overrun, rate it accordingly and explain why in Status rationale.
3. Separate progress (outcomes delivered against plan) from activity (meetings held, work started). Report progress.
4. List risks and issues with impact, owner and the next action with its date. An issue is happening now; a risk might happen.
5. Pull out every decision or help needed from the readers, with who must decide and by when. If none, say "None this period".
6. List next steps for the coming period with owners.
7. Render for the format:
- email: a subject line in the form "[Project] status: – ", then in this order: one line with the status and the reason; Decisions needed; Progress (three to five bullets); Risks and issues; Next steps. A reader should absorb it in 60 seconds.
- doc: short headings in this order: Summary (status, reason, and the change since last period) · Decisions needed · Milestones (table: Milestone | Planned date | Forecast date | Status) · Progress · Risks and issues (table: Item | Risk or issue | Impact | Owner | Next action and date) · Next steps.
- slide: an assertion-style title that states the status and the reason (for example "Amber: content migration is 30 points behind; decision needed by Friday"), then at most six bullets, decisions first.
If the project name or reporting period is missing, use `[need: project name]` or `[need: period]` rather than guessing.
- Use only facts from the updates. Missing owners, dates or figures become `[need: …]`; never invent them.
- Lead with status and decisions; no "Hope everyone had a great week".
- Name problems plainly and without blame: describe what happened and its impact, not who failed.
- Keep it short: under 250 words for email and slide, under 500 for doc.
## Status report
The report in the chosen format.
## Status rationale
Two or three sentences: why this RAG status, citing the evidence, and whether it differs from what the notes implied.
## Missing information
Bullets: each `[need: …]` placeholder. "None" if complete.
````
---
## Write a white paper
`write-white-paper` · prompt · Business writing · https://hermes-ide.com/prompts/write-white-paper
Writes a B2B white paper that frames an industry problem with cited evidence and sets out a solution approach, citing a supplied source for every factual claim and flagging unsupported ones.
````markdown
A white paper earns trust by teaching before it sells. Its readers are evaluators, often sceptical specialists building a case internally, who will forward it only if it is accurate, specific and fair. White papers fail when they are brochures with footnotes: vague market claims, statistics without sources, a "solution" section that is just the product, and no acknowledgement of trade-offs or alternatives. The structure that works is problem, cost of the problem, why common approaches fall short, a principled approach (criteria a good solution must meet), how to apply it, and a short, honest note on how the author's organisation fits.
Write a white paper on:
[TOPIC]
Evidence you may cite (and nothing else):
[EVIDENCE]
1. If the evidence has fewer than three usable sourced items, or the sources are not identified, ask for more or for their origins and stop.
2. Identify the reader's core question and the paper's thesis in one sentence each. If no audience was given, infer the most likely evaluating reader from the topic, state that assumption above the paper, and pitch the depth to them.
3. Outline before writing: title, executive summary, the problem, its cost or consequences, why current approaches fall short, the recommended approach as a set of principles or criteria, implementation steps or a maturity path, a short section on the author's offering if the topic mentions one, and a conclusion with a next step.
4. Write the paper at 1,500 to 2,500 words, in confident, plain, specific prose for this audience. Use subheadings that state the point, short paragraphs, and a table or numbered list where it clarifies a comparison or process. Suggest one or two figures (what they show and which source they use).
5. Cite every factual claim (number, trend, study finding, quote, customer result) inline with a numbered reference [1] that maps to the evidence, and list references at the end in a consistent format. Any sentence that states a fact but has no source in the evidence must be rewritten as an opinion, removed, or marked `[SOURCE NEEDED]`.
6. Keep the solution vendor-neutral until the dedicated section; the principles should be useful even to a reader who never buys.
- Never invent statistics, studies, quotes, customer names or results, and never attribute a claim to a source that does not support it. Do not upgrade a claim beyond its source ("a survey of 200 firms" does not become "the industry").
- Distinguish clearly between evidence, the author's interpretation and recommendations.
- Acknowledge at least one limitation, trade-off or situation where the approach does not fit.
- Avoid hype words (revolutionary, game-changing, best-in-class, seamless) and unexplained jargon.
- Internal data is allowed but must be labelled as such, with its sample and period if given.
## White paper
Title, subtitle, executive summary (about 150 words), then the sections with stated-point subheadings, conclusion and next step, and a References list numbered to match the in-text citations.
## Claim and source check
A table: Claim (short) | Reference | Exact supporting detail from the evidence. Include every factual claim.
## Gaps
Each `[SOURCE NEEDED]` and any evidence that would strengthen a weak section. "None" if none.
## Repurposing notes
Three short ideas for reuse (a blog post, a slide, a sales email line), each pointing to the section it comes from.
````
---
## Write an executive summary
`write-executive-summary` · prompt · Business writing · https://hermes-ide.com/prompts/write-executive-summary
Writes an executive summary of a long document that leads with the bottom line, the key points and the ask, using only facts from the source. Use before sending a report to busy readers.
````markdown
An executive summary is read instead of the document, not before it. Many readers stop after the first paragraph, so it must stand alone: what the document concludes, why that matters to this reader, and what the reader is being asked to do. Weak summaries describe the document ("This report examines…") instead of stating its findings, follow the document's chronology instead of its importance, bury the ask, or quietly change numbers and certainty while compressing.
Write an executive summary of the document below for [AUDIENCE], at most 250 words.
[DOCUMENT]
1. If the document is empty or is only a title or topic, ask for the full text and stop.
2. Find the governing thought: the single conclusion or recommendation the whole document supports. If the document has none, say so and summarise its main findings instead; do not invent a recommendation.
3. Find the ask: the decision, approval, money or action the reader is expected to give, with any deadline. If there is no ask in the document, state "No action requested" rather than making one up.
4. Pick the three to five points that most support the governing thought for this audience. Prefer points with numbers, consequences, costs or risks. Drop methodology and history unless the audience needs them to trust the result.
5. Order by importance, top-down: bottom line first, then the supporting points, then the ask and next steps.
6. Translate jargon the audience does not share into its consequence, and keep the document's level of certainty (an estimate stays an estimate, a pilot result stays a pilot result).
7. Count the words and cut until you are within the limit.
- Use only facts, figures and claims from the document. Copy numbers exactly; never round, recompute or combine them.
- Do not open with "This document", "This report" or a restatement of the title. The first sentence is the bottom line.
- Keep risks and caveats the document gives if they would change the reader's decision.
- If the document contradicts itself on a key figure, do not pick one: write "[CHECK: …]" and list the conflict under Left out.
- Plain, active sentences. No bullet longer than two lines.
## Executive summary
**Bottom line:** one or two sentences.
**Key points:** three to five bullets, most important first.
**The ask:** the decision or action needed, from whom and by when, or "No action requested".
Then the line "Word count: N / 250".
## Source check
A table: claim or number in the summary | where it appears in the document (section heading or a short quoted phrase).
## Left out
Bullets: material you cut that a reader might expect, and any conflicts or gaps you found. "None" if nothing material.
````
---
## Write an internal announcement
`write-internal-announcement` · prompt · Business writing · https://hermes-ide.com/prompts/write-internal-announcement
Writes an internal announcement of a reorg, policy change or launch that explains what is changing, why, the impact on each group and where to ask, plus an FAQ and a pre-send check.
````markdown
People read a change announcement asking four questions in order: what is changing, does it affect me, why, and what do I do now. Announcements fail when the change is buried under a preamble about values, when the reason is vague or spun ("to unlock synergies"), when they cheer about news that is bad for some readers, or when nobody knows where to ask. For changes that affect people's jobs, managers, roles or pay, the order of communication matters as much as the words: the people most affected should hear it directly, before a broadcast.
Write an announcement for [AUDIENCE] about this change:
[CHANGE]
1. If the input does not say what is changing or when, ask for that and stop.
2. Open with a subject line or headline that states the change itself, and a first paragraph that says what is changing and when it takes effect.
3. Explain why, using the actual reason from the input. If no reason is given, insert `[need: the reason]` rather than writing a generic one.
4. Explain the impact by group: who is affected and how, and say explicitly what is not changing.
5. List what readers need to do, with deadlines. If nothing, say "No action needed".
6. Say where to ask: a named channel, person, session or form from the input, or `[need: where to ask]`.
7. Match the tone to the news. A launch can be upbeat. A reorg, a cut or a policy that removes a benefit is plain and respectful: acknowledge that it is a real change for some people, without corporate euphemism and without over-apologising.
8. Draft an FAQ of five to eight questions readers will actually ask, including the uncomfortable ones (Is this a cost cut? Will there be more changes? What happens to my role?). Answer only from the input; where the answer is unknown, write the honest holding answer ("We don't know yet; we will tell you by [date]").
- Never invent reasons, numbers, dates, names or commitments.
- No euphemisms that hide what is happening ("rightsizing", "transitioning roles"). Say "roles will be eliminated" if that is the fact.
- Do not mention any individual's performance, health or personal circumstances.
- Keep the announcement under 350 words; detail goes in the FAQ.
- If the change involves job losses, pay or contract changes, or anything with legal implications, add to Before you send that HR or legal should review it, and that affected people must be told directly first.
## Announcement
Subject line, then the message with short sections: What is changing · Why · What it means for you · What you need to do · Questions.
## FAQ
Numbered questions with short answers.
## Before you send
A checklist: who must hear before this goes out, any `[need: …]` placeholders, reviews required, and the best channel and timing.
````