# Hodios paste pack: Developer writing
Everything in Developer writing from Hodios, the open prompt library by Hermes IDE: 5 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
- Developer writing
- [Explain a technical issue to executives](#explain-tech-to-executives) (prompt)
- [Rewrite for clarity](#rewrite-for-clarity) (prompt)
- [Write a conference talk proposal](#write-conference-talk-proposal) (prompt)
- [Write a technical blog post](#write-tech-blog-post) (prompt)
- [Write an API deprecation notice](#write-api-deprecation-notice) (prompt)
---
## Explain a technical issue to executives
`explain-tech-to-executives` · prompt · Developer writing · https://hermes-ide.com/prompts/explain-tech-to-executives
Translates a technical issue or decision into a one-page executive brief with business impact, options, cost, risk and the specific ask. Use when leadership must decide or fund something technical.
````markdown
Executives decide among options under constraints of money, time, risk and customers. They do not need to understand the mechanism, but they do need to trust that the engineer understands it and has framed the choice honestly. Technical briefs fail when the ask is buried at the end, when impact is expressed in technical units (CPU, latency, story points) instead of customers, revenue, risk or dates, when only one option is offered, or when uncertainty is either hidden or so heavily hedged that no decision is possible.
Write a brief for executive team about:
[TECHNICAL_DETAIL]
If what you need from them is not stated and cannot be inferred, ask; a brief without an ask is a status update, so say so if that is what it is.
1. Lead with the ask: the decision, by when, and the recommended answer, in two sentences.
2. Explain the situation in business terms: who or what is affected (customers, revenue, compliance, delivery dates, team capacity), how much, and what happens if nothing is done, with a time frame. Use an analogy only if it is accurate.
3. Give two or three options, including doing nothing. For each: what it costs (money, people, time), what it delivers, what it puts at risk, and what it gives up.
4. Give the recommendation and the main reason, plus the signal that would tell them it is working.
5. Translate every technical term into its consequence, or drop it. Keep one technical sentence at most, for credibility, in plain words.
6. Separate known facts from estimates. Express uncertainty as a range or a confidence level, once.
- At most one page (about 300 to 400 words) for the brief.
- Use only numbers from the input. Where a number the audience will expect is missing (cost, customers affected, date), mark it `[need: …]` rather than inventing it.
- Neutral, factual tone: no alarmism, no reassurance the facts do not support, no blame.
- Lead with the answer. Add reasoning only where it changes what the reader will do.
- No preamble, no restating the request and no closing summary on a short answer.
## Brief
Subject line, then sections: The ask, What is happening, Options (a short table: Option | Cost | Time | Risk | What we give up), Recommendation, What we will report back and when.
## Glossary removed
Bullets: technical terms from the input you translated or dropped, and what replaced them, so the author can check nothing was lost.
## Gaps
Bullets: each `[need: …]` placeholder and the question an executive is likely to ask that the brief cannot yet answer.
````
---
## Rewrite for clarity
`rewrite-for-clarity` · prompt · Developer writing · https://hermes-ide.com/prompts/rewrite-for-clarity
Rewrites technical prose so the main point comes first and every sentence is plain and specific, while keeping every fact, number and caveat. Use on design notes, emails, RFC drafts and docs.
````markdown
Technical writing is usually unclear for a few repeatable reasons: the conclusion is buried at the end, sentences hide the actor ("it was decided"), abstract nouns replace verbs ("perform an investigation of"), hedges pile up, and terms are used before they are defined. The fix is structural and line-level editing. Changing the meaning is not a fix: a clear sentence that says something the author did not mean is worse than the original.
Rewrite the text below for an engineer who knows the field but not this project. Length: shorter.
[TEXT]
1. Find the main point: the decision, request or finding the reader must take away. Put it in the first sentence or two.
2. Order the rest by what the reader needs next: context and reasons after the point, details after the reasons.
3. Edit line by line:
- one idea per sentence; split sentences over about 25 words;
- name the actor and use active verbs ("the cache drops stale entries", not "stale entries are dropped");
- turn nominalisations back into verbs ("decide", not "make a decision");
- replace vague words with the specific fact from the text ("in 3 of 40 runs", not "sometimes");
- cut filler and stacked hedges, but keep a hedge that carries real uncertainty;
- define or replace jargon the audience may not know; keep terms of art they do know;
- use a list when items are parallel, and prose when they are connected by reasoning.
4. Keep the author's voice and register. Do not make an informal note formal or the reverse.
- Preserve every fact, number, name, code snippet, link, commitment and caveat. Do not add claims, examples or opinions that are not in the original.
- If a sentence is ambiguous and the meaning matters, do not choose silently: pick the most likely reading and list the ambiguity under Check.
- If the text is already clear, say so and make only the edits that help. Do not rewrite for the sake of it.
- Code, commands and quoted error messages stay exactly as written.
## Rewrite
The rewritten text, ready to paste, in the original format (Markdown, plain text or email).
## What changed
At most five bullets naming the main kinds of edits.
## Check
Ambiguities you resolved and facts the author should confirm, or "None".
````
---
## Write a conference talk proposal
`write-conference-talk-proposal` · prompt · Developer writing · https://hermes-ide.com/prompts/write-conference-talk-proposal
Writes a CFP submission with title options, abstract, timed outline, takeaways and notes for reviewers, aimed at the event's audience and selection criteria. Use for engineers and developer advocates.
````markdown
Programme committees read hundreds of proposals and decide on most of them within the first few sentences. They accept talks that promise something specific and earned (a real system, a real failure, a number), fit the audience and track, and are clearly not a product pitch. They reject vague titles, abstracts that describe a topic instead of a talk, takeaways nobody could act on, and proposals that oversell what a 30-minute slot can deliver. Many CFPs review the abstract anonymously and use a separate private field for "why you" and the details that prove the talk is real.
Write a talk proposal for this idea:
[TALK_IDEA]
1. Find the core: the one problem the audience has, the insight or experience that answers it, and the evidence (a production story, a measured result, a built thing). If the idea has no concrete experience or evidence behind it, say so and ask for it before writing; do not invent results, numbers, companies or anecdotes.
2. Write three title options: specific and searchable, saying what the talk delivers, under about ten words; one may be playful if the event suits it. Avoid clickbait and unexplained acronyms.
3. Write the abstract, within the CFP's word limit if given (otherwise 120 to 200 words for a talk, 60 to 100 for a lightning talk, 150 to 250 for a workshop). Open with the audience's problem or a concrete situation, then what the talk covers and the evidence, then what attendees will leave with. Write in the third person or neutral voice, and keep the speaker's name and employer out of it so it works for anonymous review.
4. Write the outline with timings that add up to the slot, including a short opening, the main sections, any demo (with a fallback if the demo fails) and time for questions. For a workshop, add prerequisites, setup to do before the session, the exercises and what each one teaches.
5. List three takeaways, each something an attendee can do or decide differently on Monday.
6. State the audience and level: who will get the most out of it, what they need to know already, and what the talk will not cover.
7. Write the notes for reviewers (the private field): why this speaker, where the story comes from, what is new compared with existing talks on the topic, whether it has been given before and what changed, links to supporting material (as placeholders), and that it is not a sales pitch if a vendor is involved.
8. Write a short speaker bio from the background given, in the third person, under 80 words. Skip it if no background was given and say so.
9. Check fit against the conference's audience, track and stated criteria, and list anything that may count against the proposal.
- Use only facts from the input. Placeholders such as [NUMBER] or [LINK] mark anything the speaker must fill in.
- No hype words ("revolutionary", "game-changing", "deep dive into everything") and no promises the timing cannot deliver.
- Match the conference's language conventions and limits if the CFP text is provided.
- Lead with the answer. Add reasoning only where it changes what the reader will do.
- No preamble, no restating the request and no closing summary on a short answer.
## Title options
Three numbered titles, the recommended one first.
## Abstract
The abstract, then its word count.
## Outline
Table: minutes | section | content. Timings sum to the slot.
## Takeaways
Three bullets.
## Audience and level
Two or three sentences.
## Notes for reviewers
A short paragraph or bullets.
## Speaker bio
The bio, or a note that background is needed.
## Fit check
Bullets: strengths for this event, and risks with a fix for each.
````
---
## Write a technical blog post
`write-tech-blog-post` · prompt · Developer writing · https://hermes-ide.com/prompts/write-tech-blog-post
Turns engineering notes, code and results into a technical blog post with one clear takeaway, real numbers and working code, and no hype. Use for engineering blogs and write-ups of a project.
````markdown
Engineers read technical posts to learn something they can use: a technique, a trade-off, a mistake to avoid. They leave at the first sign of marketing or vagueness, and they distrust numbers without a method. The best posts follow one concrete problem from symptom to solution, show the dead ends honestly and end with a takeaway the reader can apply elsewhere.
Write a post about: [TOPIC]
For: working software engineers who do not know this codebase. Target length: about 1200 words.
[NOTES]
1. Decide the one takeaway a reader should leave with, in one sentence. Every section must serve it; cut material that does not.
2. Open with the concrete problem or surprising result in the first two sentences: a symptom, a number, a failure. No scene-setting about the industry.
3. Give only the context needed to follow along.
4. Walk through what was tried, in order, including what did not work and why. Show code or config where it carries the explanation, trimmed to the lines that matter.
5. Present the result with the numbers from the notes and how they were measured.
6. Name the trade-offs and when this approach is the wrong choice.
7. Close with the takeaway, phrased so it applies beyond this codebase.
- Use only facts, numbers, quotes and code from the notes. If a claim needs a figure that is not there, write `[needs number: ...]` instead of estimating.
- Code must be consistent with the notes and minimal; do not invent APIs or library features.
- No hype or filler: avoid "in today's fast-paced world", "game-changer", "seamless", "unlock", "delve", "robust" and rhetorical questions as openers.
- Use "we" for the team's work and "you" for the reader. Short paragraphs; descriptive subheadings.
- Do not name customers, colleagues or internal systems unless the notes say they can be named.
## Titles
Three title options: one plain and descriptive, one leading with the result, one leading with the problem. No clickbait.
## Post
The full post in Markdown with subheadings.
## Facts to verify
Every number, quote and factual claim in the post, each with where it came from in the notes, plus any `[needs number]` gaps.
````
---
## Write an API deprecation notice
`write-api-deprecation-notice` · prompt · Developer writing · https://hermes-ide.com/prompts/write-api-deprecation-notice
Writes the notice to API consumers for a deprecation or breaking change, covering what changes, the timeline, migration steps and where to get help. Use before announcing an API change.
````markdown
A deprecation notice is read by a busy developer who maintains an integration they wrote a year ago. They need to answer three questions in under a minute: does this affect me, what exactly must I change, and by when. Notices fail when they lead with the company's reasons, bury the date, say "some endpoints" instead of naming them, or promise a migration path that is not documented yet. A good notice is specific, scannable and calm, and every date and step in it can be acted on.
Write the consumer notice for this change:
[CHANGE]
Dates: [DATES]
Channel: all
1. Extract the facts: what is affected (exact endpoints, fields, parameters, SDK or API versions, auth methods), what replaces each, the behaviour after the removal date (error code, ignored field, redirect), and every date. If an essential fact is missing (what is removed, the replacement, or the removal date), list it under "Missing information" and use a clearly marked placeholder such as `[REMOVAL DATE]` rather than inventing it.
2. Write the full notice in this order:
- A subject or headline that names the API and the action and date, for example "Action required by 2027-03-31: Orders API v1 is being retired".
- Who is affected, and how a consumer can tell whether they are (a request header, a dashboard filter, a log query, an SDK version check).
- What changes, as a before and after table for each affected item.
- The timeline as a dated list: announcement, deprecation (still works, now marked deprecated with Deprecation and Sunset headers if the API uses them), any brownouts, removal. State the exact behaviour after removal.
- Migration steps, numbered, each one concrete, with a short request or code snippet where the change is mechanical and a link placeholder to the full migration guide.
- Why, in two sentences at most, after the steps.
- Where to get help and how to request an extension, if extensions are possible.
3. Produce the short versions for all: "email" gets an email of at most 150 words with the date in the subject line; "changelog-post" gets a changelog entry that links to the full notice; "docs-banner" gets a one-sentence banner for the affected reference pages; "all" gets all three.
4. Add a sender checklist of what must exist before the notice goes out.
- Lead with the action and date, not the backstory. No marketing language and no "we're excited".
- Name every affected item exactly as it appears in the API; never say "some endpoints" or "certain fields".
- Write dates in an unambiguous format (2027-03-31, or 31 March 2027) with a time zone when a time is given.
- Do not promise extensions, credits, SDK releases or support that the input does not mention.
- If the timeline gives consumers less than 90 days for a breaking change to a public API, say so in the sender checklist as a risk, without changing the dates.
- Keep the tone respectful of the consumer's time: acknowledge the work you are asking for once, without apologising repeatedly.
## Missing information
Bullets of facts you could not find and the placeholders used, or "None".
## Notice
The full notice in Markdown, ready to publish.
## Short versions
The email, changelog entry and docs banner required by the channel, each under its own bold label.
## Sender checklist
Checkboxes: migration guide published, replacement live and documented, deprecation headers or SDK warnings shipped, affected consumers identified and contacted directly, support staffed, brownout and removal dates in the team calendar, plus any risks.
````