# Hodios paste pack: Developer writing
Everything in Developer writing from Hodios, the open prompt library by Hermes IDE: 15 entries, catalog 2026.1004.3.
Every entry is dedicated to the public domain under CC0 1.0. Copy, change and share them freely, no attribution needed.
Browse and search the library at https://hermes-ide.com/prompts
## How to use
Find an entry below and copy the text inside its block into ChatGPT, claude.ai or any chat. Replace each [PLACEHOLDER] with your own material. Personas, rules and styles work best as custom instructions or project instructions.
## Contents
- Developer writing
- [Announce a new open-source project](#write-open-source-announcement) (prompt)
- [Developer advocate](#developer-advocate) (persona)
- [Draft maintainer issue replies](#draft-maintainer-issue-replies) (prompt)
- [Explain a technical issue to executives](#explain-tech-to-executives) (prompt)
- [Outline a tech talk with a live demo](#outline-tech-talk-with-live-demo) (prompt)
- [Rewrite for clarity](#rewrite-for-clarity) (prompt)
- [Write a "how I built it" article for a project launch](#write-build-story-article) (prompt)
- [Write a conference talk proposal](#write-conference-talk-proposal) (prompt)
- [Write a public incident report](#write-public-incident-report) (prompt)
- [Write a release announcement kit](#write-release-announcement-kit) (prompt)
- [Write a technical blog post](#write-tech-blog-post) (prompt)
- [Write an API deprecation notice](#write-api-deprecation-notice) (prompt)
- [Write an engineering quarter review](#write-engineering-quarter-review) (prompt)
- [Write an open-source grant application](#write-open-source-grant-application) (prompt)
- [Write tech radar entries](#write-tech-radar-entries) (prompt)
---
## Announce a new open-source project
`write-open-source-announcement` · prompt · Developer writing · https://hermes-ide.com/prompts/write-open-source-announcement
Writes the launch post for a project going open source for the first time, new or released by a company, with a first-screen example, honest maturity, the maintainers' commitment and a readiness list.
````markdown
A launch post is the one long piece that introduces a project to strangers. Readers decide within the first screen whether to try it. Launch posts lose them in a few common ways. Some open with the author's journey. Some pile up adjectives instead of showing code. Some hide what is unstable until a reader runs into it, or compare unfairly with alternatives. Some never say who maintains the project or for how long, and some send readers to a repository that is not ready for visitors, with an empty README, no license file and no issue templates. A project released by a company faces harder questions: why release it now, what was removed, whether the company will keep investing, and who decides what gets merged. Release announcements for later versions and per-network social posts are separate jobs; this prompt writes the first introduction.
Write the launch post for this project, aimed at [AUDIENCE]. Origin: new-project.
[PROJECT]
1. Open with the problem as [AUDIENCE] experiences it, in one or two sentences. Follow with one sentence on what the project does about it.
2. Show it working within the first screen: the install command and the shortest real snippet that shows the core value, with its output where useful. Use only commands and APIs found in the project details. If there are none, put a clearly marked placeholder and list it under Facts to confirm.
3. Explain in a short paragraph how it works or what it does differently. Compare with named alternatives only where the details support it. Keep the comparison specific and fair, and say when an alternative is the better choice.
4. State maturity honestly: what is stable, what is experimental, known limits, supported versions or platforms, and the license in plain words (for example "MIT: use it commercially, keep the notice").
5. Say who maintains the project and what they can commit to, such as response times, release rhythm or "maintained in spare time". If the details do not say, add a placeholder and list it under Facts to confirm. A launch that implies support nobody will give does lasting damage.
6. Address what the origin raises:
- new-project: why it exists alongside what is already out there, and what feedback you most want.
- company-internal-tool: why the company is releasing it, what was removed or changed for the public version, how internal and public development stay in sync, and who reviews outside contributions.
- formerly-closed-product: exactly what is open and what stays proprietary, the license and whether contributions need a CLA or DCO, and what existing customers should expect. Do not call the project open source if the license in the details is not an open-source license. Say "source-available" and flag it.
7. End with how to take part: try it, report issues, good first issues or the contributing guide, and where discussion happens.
8. Write a reusable summary in two or three plain sentences. The author can reuse it in social or community posts.
9. Check launch readiness against the details: the README's first screen matches the post's example, a license file exists, contribution and conduct guidelines exist, issue templates and good-first-issue labels are set up, the discussion channel exists, and there is a security contact. Mark each item ready, missing or unknown.
10. Before answering, check every claim in the post against the project details. This covers numbers, benchmarks, compatibility, adopters and comparisons. Move anything unsupported to Facts to confirm and keep it out of the text.
- No hype adjectives or superlatives without evidence, and no emoji.
- Never invent benchmarks, adopters, quotes, stars, download numbers or maintainer commitments. If the author asks for them, leave them out and say why in Facts to confirm.
- The launch post should take about three to four minutes to read, roughly 600 to 900 words.
- Do not write per-network social posts or a changelog. Say in one line that they belong in separate pieces.
## Title options
Three titles: plain, problem-led and example-led. No clickbait.
## Launch post
The post in Markdown with short sections, ready to publish once the placeholders are filled.
## Reusable summary
Two or three sentences.
## Launch readiness
| Item | Status (ready, missing, unknown) | What to do |
## Facts to confirm
Claims, placeholders and requests the author must settle before publishing, or "None".
````
---
## Developer advocate
`developer-advocate` · persona · Developer writing · https://hermes-ide.com/prompts/developer-advocate
Acts as a developer advocate who earns attention by teaching, builds demos that work on the first try, carries user feedback back to maintainers and discloses affiliation every time.
````markdown
From now on, work as this persona: Developer advocate.
You are a developer advocate for a developer tool, often an open-source one. Your job has two directions: help developers succeed with the tool through teaching, demos and honest answers, and bring what you learn from them back to the people who build it. You are an engineer first; your credibility comes from things that work when someone copies them.
How you work:
- You teach the problem before the product. A talk, post or video should be useful to someone who never installs the tool; the tool appears where it genuinely helps.
- Every demo, snippet and quick start you publish runs on a clean machine, with versions pinned and prerequisites listed. You run it yourself before you publish and you say which platform you ran it on.
- You pick formats by what the audience needs: a 30-second GIF for "what is it", a quick start for "can I try it", a tutorial for "how do I do the real thing", a talk for "why should I care", a reference for "what exactly does it do".
- You reuse work deliberately: a talk becomes a post, the post becomes docs, the questions from the talk become an FAQ.
- You keep a feedback log of where users got stuck, quoted and counted, and you turn it into issues or docs fixes with the maintainers.
- You measure what you can see without tracking people: referrers and popular pages, downloads after a piece goes out, questions that stop being asked, issues that cite your content.
What you flag:
- Content that is a disguised ad: a "tutorial" that only works with a paid tier, a comparison written to win instead of to inform, a talk abstract that is a product pitch.
- Missing disclosure. When you post about the tool you work on, you say so, every time, including in community replies.
- Astroturfing in any form: sock puppets, coordinated upvotes, planting questions to answer yourself, paying for reviews.
- Demos that hide setup steps, use pre-baked state the viewer cannot reproduce, or show features that have not shipped without saying so.
- Commitments on the roadmap or timelines that the maintainers have not made.
Your habits:
- You open with what the reader will be able to do at the end.
- You show the exact command or code, then explain it, then show the output.
- You say what the tool is bad at and when an alternative fits better; it builds the trust that makes the rest believable.
- You answer questions in public, searchable places when you can, so the answer helps the next person.
- You write in the first person as yourself, never as a fake user.
````
---
## Draft maintainer issue replies
`draft-maintainer-issue-replies` · prompt · Developer writing · https://hermes-ide.com/prompts/draft-maintainer-issue-replies
Drafts kind but firm replies to the issues maintainers find hardest, such as support questions, out-of-scope requests, hostile reports, ETA demands and stale needs-info, with labels and next action.
````markdown
Maintainers burn out on the issues that are not bugs: usage questions in the bug tracker, feature requests outside the project's scope, "any update?" pings, demands for a release date, rude or entitled reports, and reports that never come back with the information asked for. Replies go wrong in two directions: too soft (the issue stays open forever and sets an expectation the maintainer cannot meet) or too curt (the person feels dismissed and the thread escalates). A good reply thanks once, says what will and will not happen, gives the person a useful next step, and closes or labels the issue so the tracker stays honest. Maintainers are volunteers or have limited time; replies should protect that time without apologising for it. This is for drafting the replies that are hard to write, one issue or a handful at a time; sorting and labelling a whole backlog is a triage job.
[ISSUES]
1. Classify each issue: usage question, duplicate, needs-info, stale needs-info, out-of-scope feature request, in-scope request without capacity, ETA or "+1" ping, hostile or entitled report, security report filed publicly, or a real bug hidden behind any of these.
2. Look for the real bug first: if a rude or vague report contains a reproducible defect, treat the defect seriously and the tone separately.
3. Decide the action: answer and close, redirect (to the discussion forum or support channel), close as duplicate (link the original), ask for specific information with a deadline, close as stale with an invitation to reopen, close as won't-do with the reason and an alternative (plugin, fork, another tool), keep open with "help wanted" and a pointer to where a contribution would start, or hide or lock under the code of conduct.
4. Draft each reply:
- at most about 120 words, plain and warm, no sarcasm, no apology for having limits;
- for questions: the answer or the link, then where such questions go next time;
- for needs-info: a numbered list of exactly what is needed (version, minimal reproduction, logs) and what happens if it does not arrive by a date;
- for out-of-scope requests: the scope reason in one sentence, an alternative, and no "maybe later" unless it is true;
- for ETA pings: what is known, that there is no date if there is none, and how the person can help (test a branch, fund, contribute);
- for hostile messages: acknowledge the frustration in one line, restate the facts, set the boundary with a link to the code of conduct, and do not mirror the tone; for abuse or repeated violations, recommend moderation instead of a reply;
- for a public security report: thank them, ask them to use the private channel, and suggest hiding the details.
5. Give each issue a label set and the next action for the maintainer.
- Do not promise fixes, dates or releases the maintainer has not confirmed.
- Use only policies, links and channels given; otherwise use placeholders such as [DISCUSSIONS LINK] and list them.
- Do not invent technical answers; if the answer is unknown, say what the maintainer needs to check.
- Never repeat personal data, tokens or exploit details from the issue in the reply.
## Replies
Per issue: a heading with the issue title, the type, then the reply in a quote block, then "Labels:" and "Action:".
## Summary table
Table: issue, type, action, labels, follow-up date if any.
````
---
## 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.
````
---
## Outline a tech talk with a live demo
`outline-tech-talk-with-live-demo` · prompt · Developer writing · https://hermes-ide.com/prompts/outline-tech-talk-with-live-demo
Outlines a conference or meetup talk built around a live demo, with the one idea, a timed structure, a demo script with checkpoints, slides versus editor, a recorded fallback and a failure plan.
````markdown
A live demo is the most memorable part of a technical talk and the most likely to fail. Demo talks go wrong when the demo is a tour of features instead of proof of one idea, when typing eats the time budget, when the audience cannot read the screen, when the demo depends on wifi or an account with rate limits, and when the speaker has no plan for the moment it breaks. The slot is 25 minutes.
[TOPIC]
1. Write the one idea: a single sentence the audience should repeat afterwards, and what they will be able to do or believe that they could not before. Cut anything that does not serve it.
2. Build a timed outline that fits the slot with about 10% slack and time for questions if the slot includes them: hook (the problem, shown not described), the idea, the demo in two to four acts, recap, call to action. Give minutes per section and a running clock.
3. Write the demo script, act by act: starting state (branch, terminal, open files, data loaded), each action, what the audience should see, the line you say while it runs, and a checkpoint (a git tag, a saved file or a prepared terminal) you can jump to if a step fails. Prefer pasting prepared snippets or using an editor snippet over typing anything longer than a line; never type secrets on screen.
4. Decide what goes on slides versus in the editor or terminal: slides for the problem, diagrams and the recap; live for the moment of proof. Specify font size (at least 20pt in the editor, larger terminal font, high-contrast theme), a clean desktop, notifications off and a separate presenter profile.
5. Write the failure plan: for each risk, the symptom, the 30-second recovery (jump to checkpoint, switch to the recorded fallback, use cached responses), and the line you say so the audience stays with you. Include a full screen recording of the demo as a fallback and when to switch to it (a failure that will not resolve in 30 seconds).
6. Write a rehearsal checklist: full run-throughs with a timer, a run on the venue setup or the projector resolution, an offline run, and what to set up 30 minutes before.
- Fit the slot: if the topic needs more time than the slot allows, say what to cut instead of compressing everything.
- Do not invent product features or commands; use what the topic describes and mark guesses as [X].
- Keep the demo deterministic: fixed data, pinned versions, no dependence on live third-party services unless there is a cached fallback.
- If the audience or event is missing, assume a mixed-level developer meetup and say so.
## The one idea
One sentence, plus one line on the audience takeaway.
## Timed outline
Table: section, minutes, running clock, what happens.
## Demo script
Per act: starting state, steps (action, what they see, what you say), checkpoint.
## Slides versus editor
Two short lists, then setup settings.
## Failure plan
Table: risk, symptom, recovery, line to say.
## Rehearsal checklist
Checkbox list.
````
---
## 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 "how I built it" article for a project launch
`write-build-story-article` · prompt · Developer writing · https://hermes-ide.com/prompts/write-build-story-article
Writes a build-story article for dev.to, Hashnode or a project blog that teaches one real technical lesson from making an open-source project. Use to support a launch.
````markdown
Launch announcements get skimmed; build stories get read and shared, because readers learn something they can use even if they never install the project. The strongest pieces pick one technical problem, show the dead ends honestly, include real code and real numbers, and mention the project as the place where the lesson happened. Developer platforms such as dev.to and Hashnode support a canonical URL, so the article can live on the project's own site and be republished without competing with itself in search. Community editors and readers on these platforms dislike thinly veiled ads, and many platforms ask authors to disclose AI assistance.
[PROJECT]
[BUILD_NOTES]
First published on: own-blog.
If the notes contain no concrete problem, decision or result, ask for one real story (a bug, a rewrite, a performance fix, a design trade-off) and stop.
1. **Choose the angle.** Propose three angles drawn from the notes, each a lesson a reader could apply ("Why we replaced X with Y and what it cost"). Pick the one with the most concrete evidence and say why.
2. **Write the article** (1,200 to 2,000 words):
- a title that names the lesson, not the product;
- an opening that states the problem and what the reader will learn, in under 80 words;
- the context: what the project is, in two sentences, with the link;
- the journey: what you tried first, why it failed (with numbers or errors), what you chose and the trade-off;
- code snippets that are complete enough to understand, taken only from the notes;
- results with the numbers from the notes, and what you would do differently;
- a short close: where the project is, what help or feedback you want, the link once more.
3. **Publishing notes:** front matter or tags for own-blog, a canonical URL plan if it will be cross-posted, a cover image idea, three suggested tags, a one-line AI-assistance disclosure if the platform expects one, and a two-sentence summary for sharing.
- Never invent numbers, benchmarks, errors or code; mark gaps as [NEED: ...].
- Keep the project mention to the context and the close; the body teaches.
- No superlatives about the project; let the evidence speak.
## Angle
Three options and the pick.
## Article
The full article in Markdown.
## Publishing notes
````
---
## 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 public incident report
`write-public-incident-report` · prompt · Developer writing · https://hermes-ide.com/prompts/write-public-incident-report
Writes a public, customer-facing incident report from the internal postmortem, explaining impact, cause and fixes honestly, without blame, speculation or sensitive internal details.
````markdown
A public incident report rebuilds trust only if it is specific and honest. Customers lose trust when a report minimises impact ("some users may have experienced"), hides behind passive voice, blames a vendor or a named employee, promises "this will never happen again", or is so vague that nothing seems to have been learned. It also must not leak what the internal postmortem legitimately contains: employee names, internal hostnames, IP addresses, security weaknesses that are not yet fixed, customer names, or details that legal and security have not cleared.
Turn this internal postmortem into a public incident report for the customers audience.
[POSTMORTEM]
1. Extract the facts customers need: what they experienced, which products, regions or features were affected, start and end times with time zone, duration, and the scale of impact (as precise as the postmortem allows: percentage of requests, number of accounts, data affected or not).
2. Explain the cause in plain language at the right depth for customers: a sentence or two for status pages, a short paragraph for customers, a technical but non-sensitive explanation for an engineering blog.
3. Say what was done to resolve it and what is changing to prevent a recurrence or reduce impact, drawn from the action items, with honest timing ("by the end of next month", "completed") rather than vague promises. Only include action items that are committed in the postmortem.
4. Take ownership: one plain apology in the company's voice, with no blame on individuals, and no blame shifted to a vendor even if a vendor was involved (state the vendor's role factually only if the postmortem says it is cleared to share).
5. If customers need to do anything (retry failed payments, rotate a key, check data), say exactly what, prominently, at the top.
6. Remove or generalise sensitive details: people's names, internal system names and hostnames, IP addresses, unfixed vulnerabilities, customer names, and anything marked internal. List each removal so the reviewer can check.
7. Before answering, check every number, time and claim against the postmortem, and make sure nothing in the report contradicts it or overstates the fixes.
If the postmortem does not state the customer impact or whether data was lost or exposed, do not guess: write the report with a clearly marked placeholder and put the question under Facts to confirm.
- No speculation, no "some users may have", no "never again". Use active voice: "We deployed a change that...".
- If any personal data was exposed, say so plainly and note under Facts to confirm that legal or privacy review is required before publishing.
- Length: status-page about 150 to 250 words; customers about 300 to 500; blog as long as the technical story needs.
## Report
The report in Markdown, with a title, a one-paragraph summary up top (including any customer action), then: What happened, Impact, Cause, Resolution, What we are changing, and a closing line with where to get help.
## Removed or generalised
| Internal detail | Treatment |
## Facts to confirm
Questions and placeholders for the reviewer, or "None".
````
---
## Write a release announcement kit
`write-release-announcement-kit` · prompt · Developer writing · https://hermes-ide.com/prompts/write-release-announcement-kit
Turns an open-source release's changes into a GitHub release body, a blog piece, social posts and an upgrade note, led by the change users care about and crediting contributors.
````markdown
For an open-source project, every release is a reason for past users to come back and for watchers to tell others. GitHub notifies people who watch releases, feeds and package managers surface new versions, and newsletters and aggregators pick up releases that state clearly what changed and why it matters. Most release notes waste this: they list commit titles, bury the one change people wanted, and forget the contributors who did the work. A good announcement leads with the user-visible outcome, is honest about breaking changes, and thanks contributors by name, which also encourages the next contribution. Studies of GitHub repositories found that stars rise in the week after a major release, a repeatable but small bump, so releases work best as a steady rhythm rather than one big moment. Keep a Changelog's convention groups changes as Added, Changed, Deprecated, Removed, Fixed and Security.
Release: [RELEASE]
[CHANGES]
If the changes are only internal (refactors, CI, dependency bumps) say that this is a maintenance release, write a short, honest GitHub release body, and skip the blog and social pieces.
1. **Headline.** Pick the single change most users will care about and write one sentence on what they can now do. Name two runner-up changes.
2. **GitHub release body.** The headline paragraph, then sections in the Keep a Changelog order (only those that apply), each item rewritten as a user-visible outcome with the PR or issue reference, then install or upgrade commands, then credits.
3. **Blog or newsletter piece** (250 to 450 words): the headline change with a short example or screenshot suggestion, the two runner-ups, breaking changes and how to upgrade, what is coming next only if the input says so, and how to give feedback.
4. **Social posts:** one short post for X or Bluesky and one for Mastodon (with CamelCase hashtags), each with the headline and the link.
5. **Upgrade note.** For breaking changes, numbered steps with before and after snippets taken from the input. If there are none, say "No breaking changes" explicitly.
6. **Credits.** Thank every contributor handle in the input, first-time contributors called out as such.
- Never invent features, fixes, numbers or contributor names. If a change is unclear, list it under "Needs a human description".
- Never hide or soften a breaking change; it goes near the top with migration steps.
- Use plain words; no "exciting", "game-changing" or "massive".
## Headline
## GitHub release
## Blog or newsletter piece
## Social posts
## Upgrade note
## Credits
````
---
## 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.
````
---
## Write an engineering quarter review
`write-engineering-quarter-review` · prompt · Developer writing · https://hermes-ide.com/prompts/write-engineering-quarter-review
Writes an engineering team's quarterly review for leadership, with outcomes against goals, what shipped and why it mattered, reliability, team health, tech debt, next-quarter bets and asks.
````markdown
A quarterly review is how an engineering team earns trust and resources. It goes wrong in familiar ways: a changelog of tickets instead of outcomes, vanity metrics without baselines, slipped goals buried or spun, platform and debt work described in terms leaders cannot value, and no clear ask, so nothing changes. Leaders reading it want to know: did we get what we planned, what did it change for users or the business, is the system healthy, is the team healthy, and what do you need from me. This review covers this quarter for a leadership audience.
[NOTES]
1. Summary: three to five sentences, bottom line first, including the most important miss if there is one.
2. Outcomes against goals: each goal set at the start of the quarter with its result as met, partly met or missed, the number against the target and baseline, and one line on why. Do not drop goals that were missed or abandoned; say so and why.
3. What shipped: group work into three to six themes; for each, the user or business effect (with the metric if given) rather than a ticket list. Translate platform and debt work into effects (deploy time cut from 40 to 12 minutes, so fixes reach users the same day).
4. Reliability and operations: SLO attainment, incidents by severity with one line on the main one and its follow-ups, on-call load and trend. Use only numbers given.
5. Team and tech health: headcount changes, hiring, attrition risk only at the level appropriate for the audience, tech debt paid and added, risks building up (single points of knowledge, unsupported dependencies).
6. Next quarter: two to four bets with the expected outcome and how it will be measured, plus what you will not do.
7. Asks: specific decisions, people, budget or help from other teams, each with the date it is needed and the impact if not.
8. Adapt to the audience: leadership gets business effects and asks first, about 600 words; engineering can include technical detail and metrics definitions; cross-functional emphasises user-facing changes and dependencies.
- Use only facts and numbers from the notes. Mark missing baselines or targets as [X] rather than presenting a number without context.
- Be candid about misses without blame; name causes as conditions (scope grew, dependency late), never individuals.
- Do not disclose personal matters (health, performance issues of named people) even if they are in the notes; describe capacity impact only.
- Keep to the claims the data supports; label estimates as estimates.
## Summary
Three to five sentences.
## Outcomes against goals
Table: goal, target, result, status (met, partly, missed), why.
## What shipped and why it matters
Three to six themed bullets, each effect first.
## Reliability and operations
Short table of metrics (metric, this quarter, last quarter, target) then two to four bullets.
## Team and tech health
Bullets.
## Next quarter
Table: bet, expected outcome, measure. Then "Not doing" bullets.
## Asks
Numbered: ask, from whom, by when, impact if not.
````
---
## Write an open-source grant application
`write-open-source-grant-application` · prompt · Developer writing · https://hermes-ide.com/prompts/write-open-source-grant-application
Drafts an open-source grant application with the problem and users, priced milestones, maintainer capacity, sustainability after the grant and measurable outcomes, fitted to the funder's questions.
````markdown
Funds for open-source work (public-interest technology funds, foundation programmes, security funds, company open-source programmes) receive many applications from projects that are useful but describe themselves badly. Applications fail when they explain the technology instead of who benefits, ask for "general maintenance" with no deliverables, give a budget that does not map to work, ignore the funder's stated priorities, and have no answer to "what happens when the money runs out". Reviewers score against the funder's own criteria, often quickly, so each answer must stand alone and fit its limit.
[PROJECT_DESCRIPTION]
[FUNDER_QUESTIONS]
1. Fit check: compare the project and the requested work with the funder's priorities and eligibility. Say where the fit is strong, where it is weak, and whether to apply, reframe or skip. Point out any eligibility rule the project may fail (entity type, licence, country, prior funding).
2. Frame the problem for the funder: who depends on the project (end users, downstream projects, public institutions), what breaks or stays insecure without the work, and evidence from the description (usage numbers, dependents, open issues, advisories).
3. Turn the work into three to six milestones, each a verifiable deliverable (a release, an audit fixed, a feature merged and documented), with the effort in person-days or weeks, the cost, and the dates. Make the budget add up exactly: hourly or daily rate times effort, plus any other costs the funder allows.
4. Capacity: who does the work, their track record on the project, and how review and continuity are handled if one person is unavailable.
5. Sustainability: what continues after the grant (maintenance by whom, other funding sources, reduced maintenance cost because of the work), stated honestly.
6. Outcomes: two to four measurable outcomes the funder can check, with baseline and target where possible.
7. Answer every funder question in their order, within its limit, reusing the material above and using the funder's own vocabulary where it fits.
8. Review as a sceptical reviewer would: the three weakest points and how to fix each before submitting.
- Use only facts and numbers from the description. Write [X] for missing figures (usage, rates, dates) and list them; never invent users, download counts, endorsements or prior grants.
- Respect every word or character limit; state the count after each answer.
- Do not overpromise: deliverables must fit the effort and the duration.
- Do not state eligibility, tax or legal rules as fact; tell the applicant what to confirm with the funder or a fiscal host.
## Fit check
Verdict (apply, reframe, skip) and four to six bullets.
## Answers
Each funder question as a heading, the answer, then "(N words)".
## Milestones and budget
Table: milestone, deliverable, effort, cost, due. Then the total and how it was calculated.
## Gaps to fill
Numbered [X] items.
## Reviewer's view
Three weaknesses with fixes.
````
---
## Write tech radar entries
`write-tech-radar-entries` · prompt · Developer writing · https://hermes-ide.com/prompts/write-tech-radar-entries
Writes tech radar blips for an engineering organisation from team notes and experience reports, each with a ring (adopt, trial, assess, hold), the evidence, where it fits, risks and an owner.
````markdown
A tech radar tells engineers in an organisation what to use by default, what to experiment with, what to keep an eye on and what to stop starting with. It loses credibility when rings follow hype or one enthusiast rather than evidence from production use here, when "hold" reads as a ban without saying what to use instead, when entries are vague ("great for scale"), and when nobody owns an entry. The usual meaning of the rings: Adopt (proven here in production, the sensible default), Trial (used successfully in at least one real project here, worth pursuing where it fits, with care), Assess (worth exploring to understand its effect; not for production yet), Hold (do not start new work with it; existing use may continue or migrate).
[TECHNOLOGIES_AND_NOTES]
1. For each item, choose the quadrant (techniques, tools, platforms, languages and frameworks) and the ring based on evidence in the notes: production use here, number of teams, incidents, operating cost, support and hiring, licence and vendor risk. Hype and external popularity alone never justify Adopt or Trial.
2. Apply ring rules: Adopt needs production use here by more than one team, or one team plus a clear support model; Trial needs at least one real project here; Assess needs only a credible reason to look; Hold needs a stated reason and an alternative. When a proposed ring is not supported, place it lower and explain.
3. Write each blip at about 80 to 150 words: what it is in one sentence, the decision and why, where it fits and where it does not, the risks or costs, the alternative (for Hold: what to use instead and the migration expectation), and the owner or contact.
4. Mark movement from the previous radar (new, moved in, moved out, no change) and give the reason for every move.
5. List contested placements where the notes show disagreement, with both arguments and the evidence that would settle it.
6. List items that cannot be placed honestly yet and what evidence is missing.
- Use only experiences and facts from the notes; do not import other organisations' radar placements as evidence.
- Do not state licence terms, prices or vendor roadmaps as fact unless given; mark them "to check".
- Keep the language neutral and specific: no "best", "modern" or "legacy" without a reason.
- If no owner is given for an entry, write [OWNER] rather than inventing one.
## Radar summary
Table: name, quadrant, ring, movement, owner.
## Blips
One subsection per item with the ring in the heading and the blip text.
## Contested placements
Bullets, or "None".
## Missing evidence
Bullets, or "None".
````