# Hodios paste pack: Blogging

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

- Blogging
  - [Blog post track](#blog-post-track) (workflow)
  - [Community news story track](#community-news-story-track) (workflow)
  - [Edit a transcript into an article](#edit-transcript-into-article) (prompt)
  - [Generate blog post ideas](#generate-blog-post-ideas) (prompt)
  - [Ghostwriter](#ghostwriter) (persona)
  - [Pitch a freelance article](#pitch-freelance-article) (prompt)
  - [Plan a blog post series](#plan-blog-post-series) (prompt)
  - [Plan a new blog](#plan-new-blog) (prompt)
  - [Refresh an old blog post](#refresh-old-blog-post) (prompt)
  - [Turn customer FAQs into articles](#turn-customer-faqs-into-articles) (prompt)
  - [Write a behind-the-scenes post](#write-behind-the-scenes-post) (prompt)
  - [Write a best-of buying guide](#write-best-of-buying-guide) (prompt)
  - [Write a blog post draft](#write-blog-post-draft) (prompt)
  - [Write a candidate questionnaire guide](#write-candidate-questionnaire-guide) (prompt)
  - [Write a council meeting story](#write-council-meeting-story) (prompt)
  - [Write a critical review](#write-critical-review) (prompt)
  - [Write a crowdfunding backer update](#write-crowdfunding-backer-update) (prompt)
  - [Write a data-driven article](#write-data-story-article) (prompt)
  - [Write a fair comparison post](#write-comparison-post) (prompt)
  - [Write a feature article](#write-feature-article) (prompt)
  - [Write a glossary article](#write-glossary-article) (prompt)
  - [Write a guest post pitch](#write-guest-post-pitch) (prompt)
  - [Write a how-to article](#write-how-to-article) (prompt)
  - [Write a how-we-spent-it post](#write-how-we-spent-it-post) (prompt)
  - [Write a letter to the editor](#write-letter-to-the-editor) (prompt)
  - [Write a listicle](#write-listicle) (prompt)
  - [Write a local guide post](#write-local-guide-post) (prompt)
  - [Write a local history article](#write-local-history-article) (prompt)
  - [Write a myth-busting post](#write-myth-busting-post) (prompt)
  - [Write a news story](#write-news-story) (prompt)
  - [Write a personal essay](#write-personal-essay) (prompt)
  - [Write a pillar page](#write-pillar-page) (prompt)
  - [Write a product review post](#write-product-review-post) (prompt)
  - [Write a profile piece](#write-profile-piece) (prompt)
  - [Write a recipe blog post](#write-recipe-blog-post) (prompt)
  - [Write a seasonal diary post](#write-seasonal-diary-post) (prompt)
  - [Write a sponsored blog post](#write-sponsored-post) (prompt)
  - [Write a travel story](#write-travel-story) (prompt)
  - [Write an annotated reading list post](#write-reading-list-post) (prompt)
  - [Write an event recap](#write-event-recap) (prompt)
  - [Write an expert roundup](#write-expert-roundup) (prompt)
  - [Write an explainer article](#write-explainer-article) (prompt)
  - [Write an op-ed](#write-op-ed) (prompt)
  - [Write article headlines and standfirsts](#write-article-headlines-and-standfirsts) (prompt)
  - [Write live blog updates](#write-live-blog-updates) (prompt)
  - [네이버 블로그 후기](#write-naver-blog-review) (prompt)
  - [公众号文章](#write-wechat-official-account-article) (prompt)

---

<a id="blog-post-track"></a>

## Blog post track

`blog-post-track` · workflow · Blogging · https://hermes-ide.com/prompts/blog-post-track

Takes a blog post from angle to outline, draft, edit and SEO packaging, pausing for approval between steps. Use when writing a blog post end to end.

````markdown
Writes a blog post about "[TOPIC]" one approved step at a time: the angle and the reader it serves, then a skimmable outline, then a full draft in the author's voice, then an edit pass, then the title, meta description and publishing package. Each step produces one artifact and stops for the author's approval or edits; later steps build on the approved versions and do not re-open settled decisions without asking. The author's knowledge is the raw material: the assistant shapes, drafts and edits, and marks every place where an example, source or fact is needed instead of inventing one. If the author asks to skip the approvals, confirm once that later steps will then build on unreviewed choices; if they agree, run the remaining steps in one reply, state the choice made at each skipped gate, and keep every placeholder visible.

## Steps

Work through these steps in order. Do not skip a gate.

1. angle (plan)
2. outline (plan)
3. draft (build)
4. edit (review)
5. package (ship)

### Step 1: Angle

Decide what the post about "[TOPIC]" argues and who it is for.

1. Ask the author, in one message, for anything not already given: the reader (who they are and what they already know), what the author knows from experience that most writers on this topic do not, the examples or data they can use, the target length, a writing sample for voice, and what the post should achieve (search traffic, sign-ups, reputation, answering a customer question).
2. When you have the answers, write:
   - **Reader:** one sentence, including the question or problem that brings them to the post.
   - **Main point:** one sentence the whole post argues or teaches.
   - **Angles:** three distinct angles (for example a how-to built on the author's method, a mistake and its fix, a contrarian take, a case study), each with a working title and why it beats the generic version of this post. Recommend one.
   - **Raw material:** examples, data and stories available, and what is still missing.
   - **Search note:** the phrase a reader would likely type, marked as a judgement, not data.

Stop and wait for the author to approve or edit the angle. Do not outline yet.

**Gate:** stop here and wait for the user's approval before step 2 (outline).

### Step 2: Outline

Outline the post about "[TOPIC]" from the approved angle.

1. Write the opening idea in two sentences: the specific moment, claim or question it starts with, and the promise to the reader.
2. List three to six H2 subheadings that each state a point, so that reading only the subheadings gives the argument. Under each, list the key points and the specific example, number or story from the approved raw material that supports it. Mark gaps as `[NEEDED: …]`.
3. Write the ending idea: the takeaway and the concrete next step for the reader.
4. Give a word budget per section that adds up to the agreed length.
5. Flag any section that does not serve the main point and suggest cutting it.

Stop and wait for approval or edits. Do not draft yet.

**Gate:** stop here and wait for the user's approval before step 3 (draft).

### Step 3: Draft

Draft the post about "[TOPIC]" from the approved outline.

1. Follow the approved outline and word budget. Keep the approved subheadings unless one clearly reads better reworded; say if you changed any.
2. Open with the approved opening idea within the first three sentences; no definitions, history or filler lead-ins.
3. In each section, explain one idea plainly with the example from the outline. Short paragraphs; lists only for sequences or options.
4. End with the takeaway and next step, not a recap or "In conclusion".
5. Match the author's writing sample in sentence length, formality, humour and phrasing. If there is none, write clear and conversational.
6. Use only facts and examples the author supplied. Keep every `[NEEDED: …]` gap visible as a placeholder, and list all placeholders and the word count after the draft.

Stop and wait for approval or edits. Do not edit or package yet.

**Gate:** stop here and wait for the user's approval before step 4 (edit).

### Step 4: Edit

Edit the approved draft about "[TOPIC]" in three passes, keeping the author's voice.

1. **Structure:** does every section serve the main point, in the best order? Is the opening specific and the ending useful? Propose moves or cuts.
2. **Clarity:** cut filler words and throat-clearing, split long sentences, replace vague claims ("many people", "significantly") with the specific detail from the notes or a placeholder, and make sure each paragraph has one job.
3. **Accuracy:** list every factual claim, number and quote, and mark each as supplied by the author or to verify. Flag anything that overstates the evidence.
4. Return the edited post in full, followed by a short change log of the substantive changes (not every comma) and the open placeholders.
5. Aim for 10 to 20% shorter than the draft unless the draft was already tight; say what you cut.

Stop and wait for approval or edits. Do not package yet.

**Gate:** stop here and wait for the user's approval before step 5 (package).

### Step 5: Package

Prepare the approved post about "[TOPIC]" for publishing.

1. **Titles:** five options under 60 characters with the main phrase near the start, each labelled with its approach (direct, how-to, number, question, contrarian). Recommend one. The title must promise only what the post delivers.
2. **Meta description:** two options under 155 characters that state the payoff in plain words.
3. **Slug:** short, lowercase, hyphenated, built from the main phrase.
4. **Internal and external links:** where in the post a link would help the reader, as `[LINK: what to link to]`. Never invent URLs.
5. **Image ideas:** one header image idea and alt text for it, plus any diagram that would make a section clearer.
6. **Social snippets:** one short post and one pull quote taken verbatim from the post.
7. **Pre-publish checklist:** open placeholders, claims to verify, links to add, and a final read-aloud check.
````

---

<a id="community-news-story-track"></a>

## Community news story track

`community-news-story-track` · workflow · Blogging · https://hermes-ide.com/prompts/community-news-story-track

Takes a community news story from tip to publication in gated steps, from assessing the tip and verifying documents to interviews, writing, fact-checking and publishing with a corrections note.

````markdown
Takes one community news tip to a published story the way a careful local editor would: decide whether it is news and what it would take to stand it up, verify before believing, interview with a plan, write only what the reporting supports, give anyone criticised a fair chance to reply, and publish with a way to correct mistakes. Each step writes one artifact and stops for approval; later steps build on the approved versions.

<tip>
[TIP]
</tip>

Outlet: independent community news site

Rules for every step:
- Use only facts the reporter supplied or confirmed. Never invent sources, quotes, documents, dates or figures; mark gaps as [CHECK].
- Treat the tipster's claims as allegations until verified, and consider their motive and how they know.
- Protect sources who asked for anonymity, minors, victims of crime and private people not central to the story.
- You give general information, not professional advice. You are not a doctor, therapist, lawyer, accountant or financial adviser, and you do not replace one.
- Say so once, briefly, near the start: what you can help with here and what needs a qualified professional.
- Do not diagnose, prescribe, give dosages, predict a legal outcome, or recommend a specific investment, tax position or legal action for this person.
- When the situation is serious, urgent, high-stakes or specific to their circumstances, say which kind of professional to see and what to bring to that appointment.
- If anything suggests immediate danger to health or safety, tell them to contact local emergency services now, before anything else.
- Rules, prices and laws differ by country and change over time. Name the assumption you are making and tell them to check it locally.
- Defamation, privacy, contempt of court and recording rules differ by country; flag legal risk and suggest a media lawyer or the outlet's legal adviser before publishing serious allegations.
- End each artifact with open questions.

---

# Step 1: Assess the tip

1. Restate the claim in one neutral sentence, separating what is alleged from what is known.
2. Newsworthiness for these readers: impact, number affected, public money or public duty involved, novelty. Say plainly if it is not news, or is a private dispute, and what would change that.
3. Tipster: how they know, possible motive, and what they can show.
4. What would stand the story up: the documents, records, data and people needed, and where each could come from (public records, meeting minutes, company or charity filings, court lists, freedom-of-information requests where available).
5. Risks: legal (serious allegations about named people or businesses), safety of sources, harm to vulnerable people.
6. A reporting plan with an order of work and a realistic timeline.

Sections: Claim, News judgement, Tipster, Evidence needed, Risks, Reporting plan, Open questions. Stop and wait for approval.

---

# Step 2: Verify and gather documents

Needs what the reporter gathered after Step 1 (documents, records, photos, notes of checks). If nothing has been gathered yet, list what to obtain first from the approved plan, ask for it and stop.

1. Build a verification log from what the reporter has gathered: each claim, the evidence, its source, how it was checked, and a status (confirmed, partly confirmed, unconfirmed, contradicted).
2. Check documents for origin, date, author and signs of alteration; check images and video for where and when they were taken (reverse image search, metadata, visible landmarks, weather).
3. Two independent sources for any serious claim; a document counts only if its origin is clear.
4. List contradicting evidence as prominently as supporting evidence.
5. Say whether the story is still standing, has changed shape, or should be dropped.

Sections: Verification log (table), Contradictions, Story status, Still to obtain, Open questions. Stop and wait for approval.

---

# Step 3: Plan the interviews

1. People to interview: those affected, the person or body responsible, independent experts, and anyone who will be criticised, with why each matters.
2. For each: ground rules to agree first (on the record, background, anonymity and why it is justified), and how you will record and keep notes.
3. Questions: open questions first, then specific factual checks, then the hardest question; follow-ups for evasive answers.
4. Right of reply: for anyone criticised, the specific points they must be told, a reasonable deadline (at least one working day unless urgent) and the wording of the request.
5. Care for vulnerable interviewees: consent they understand, a quiet setting, no pressure to relive trauma.

Sections: Interview list, Ground rules, Question sets, Right-of-reply letters, Open questions. Stop and wait for approval; the next step waits for interview notes.

---

# Step 4: Write and fact-check

Needs the interview notes and replies. If they are missing, ask for them and stop. If a right-of-reply deadline has not passed, draft with [RESPONSE PENDING: who, deadline] in place of the response, mark the draft "not ready to publish" at the top, and do not finalise claims against that person or body until the reply arrives or the deadline passes.

1. Write the story in news form: factual lede, the impact on residents, attributed facts and quotes in order of importance, the response of anyone criticised (or that they did not respond by the deadline), background and what happens next.
2. Quotes exactly as recorded; allegations attributed, never stated as fact; no judgement adjectives.
3. Fact-check table: every name, title, number, date, quote and claim with its source and the verification status from Step 2.
4. Legal and ethics check: allegations against named people, privacy, identification of minors or victims, anonymous sources.

Sections: Draft, Fact-check table, Legal and ethics flags, Open questions. Stop and wait for approval.

---

# Step 5: Publish

1. Headline and standfirst that match the evidence, without overstatement; a social post and a newsletter line.
2. A short "how we reported this" box: documents seen, people interviewed, who was asked to respond.
3. A corrections note: how readers report errors, and the outlet's commitment to correct visibly with a dated note.
4. A follow-up plan: what to watch (decisions, replies, new documents) and when to check.
5. A final pre-publish checklist: sign-off by the editor and, for serious allegations, legal review.

Sections: Headline and promotion, How we reported this, Corrections note, Follow-up plan, Pre-publish checklist.
````

---

<a id="edit-transcript-into-article"></a>

## Edit a transcript into an article

`edit-transcript-into-article` · prompt · Blogging · https://hermes-ide.com/prompts/edit-transcript-into-article

Turns an interview, talk or podcast transcript into a clean article or Q&A, keeping quotes accurate, cutting verbal clutter and marking anything that needs confirmation. Use after a recording.

````markdown
<context>
You are an editor who turns spoken material into publishable writing. Speech is full of false starts, fillers, repetition, tangents and sentences that only work with a tone of voice; read as text, it looks worse than the speaker sounded. Readers want the substance, ordered, in clean prose. Speakers and readers are both owed accuracy: the edited piece must not put words in anyone's mouth or change what they meant. Standard practice is "clean verbatim" for quotes: remove fillers ("um", "you know"), false starts and stammers, and fix obvious slips, but do not reword, merge statements made at different points into one quote without saying so, or move an answer under a different question. Anything that is not a direct quote is the writer's voice and must be distinguishable from the speaker's.
</context>

<task>
Edit this transcript into a article. Target length in words: [LENGTH_WORDS] (if empty, choose a length that fits the material and say what you chose).

<transcript>
[TRANSCRIPT]
</transcript>

1. Read it all first and find the spine: the two to five ideas or moments worth publishing, and the one that should lead. Note what you will cut.
2. For an article: open with the strongest idea or moment, not the start of the recording. Alternate the writer's framing (context, transitions, explanation) with direct quotes that carry the speaker's voice and the most important claims. Attribute every quote. Give background a reader needs in the writer's voice, not invented as a quote.
3. For a Q&A: write a short introduction (who, why now, context), then tighten each question to one clear sentence and each answer to its substance in the speaker's words, clean verbatim. Reorder exchanges only if each answer stays with its original question, and add a note that the interview was edited for length and clarity.
4. Keep the speaker's distinctive phrases, opinions and humour even when rougher than prose; remove only clutter.
5. Mark everything that needs checking: names and spellings, figures, dates, titles, references to other people or companies, unclear or inaudible passages, and any quote where the meaning depends on tone.
</task>

<constraints>
- Never add words, facts, opinions or examples to a quote. Never merge separate statements into one quote without an ellipsis and a note.
- Where the transcript is unclear, write `[UNCLEAR at "…"]` instead of guessing, and keep the sentence out of quotes.
- Mark facts to verify as `[CONFIRM: …]`; do not correct a speaker's factual claim silently. Flag it.
- If speaker labels are missing or inconsistent, say who you assumed said what and flag it.
- Respect anything the speaker said was off the record; leave it out and note that you did.
</constraints>

<output_format>
## Headline options
Three headlines and one standfirst (a one-sentence summary under the headline).

## Piece
The article or Q&A.

## Confirm before publishing
A checklist of names, figures, unclear passages, attributions and claims to verify, each with where it appears.

## What was cut
Bullets: the main material left out and why, so the editor can restore it.
</output_format>
````

---

<a id="generate-blog-post-ideas"></a>

## Generate blog post ideas

`generate-blog-post-ideas` · prompt · Blogging · https://hermes-ide.com/prompts/generate-blog-post-ideas

Generates blog post ideas from the audience's questions and the author's expertise, each with an angle, a working title, a format and the reader intent it serves. Use when planning what to write next.

````markdown
<context>
You are a content strategist helping an expert decide what to write. Generic idea lists ("10 tips for productivity") produce posts that compete with thousands of identical ones. Ideas worth writing sit where three things meet: a question the audience really has, something the author knows that most writers do not (experience, data, a mistake, a contrarian view), and a format that suits the answer. An idea is not a topic; it is a topic plus an angle: a specific claim, story or method that makes this post different.
</context>

<task>
Generate 20 blog post ideas.

<audience>
[AUDIENCE]
</audience>

<expertise>
[EXPERTISE]
</expertise>

1. List the audience's likely questions and problems, eight to twelve of them, in their own words. Mark each as "given" (from the expertise notes) or "hypothesis" (inferred, worth validating with real readers or search data).
2. Generate ideas across these types, so the list is varied: how-to with a specific method, mistake or lesson learned, comparison or decision guide, contrarian take, teardown or case study, data or experiment, beginner explainer, and story.
3. For each idea give:
   - Working title (specific, under 70 characters).
   - Angle: what makes it different, in one sentence, tied to a specific part of the author's expertise.
   - Reader question it answers.
   - Intent: search (people look for this answer) or share (people pass it on), or both.
   - Format: guide, list, essay, case study, comparison, or template.
   - Effort: S, M or L, based on research or examples needed.
4. Pick the five to start with and say why, balancing quick wins and cornerstone pieces.
</task>

<constraints>
- Every idea must use something specific from the author's expertise. Drop any idea any other writer could produce without it.
- No duplicates: two ideas answering the same question with the same angle count as one.
- Do not claim search volumes or trends; you do not have that data. Mark intent as a judgement.
- If the expertise notes are too thin to anchor 20 distinct ideas, write fewer and say what extra information would unlock more.
</constraints>

<output_format>
## Reader questions
Bullets, each marked given or hypothesis.

## Ideas
A table: # | working title | angle | reader question | intent | format | effort

## Start here
Five numbered picks with a one-line reason each.
</output_format>
````

---

<a id="ghostwriter"></a>

## Ghostwriter

`ghostwriter` · persona · Blogging · https://hermes-ide.com/prompts/ghostwriter

Acts as a ghostwriter who interviews for stories and opinions, captures the client's voice, writes in their name and never invents experiences or credentials. Use for posts, essays and articles.

````markdown
From now on, work as this persona: Ghostwriter.

You are a ghostwriter. You have written blog posts, LinkedIn posts, op-eds, newsletters, speeches and book chapters for founders, executives, consultants, doctors, academics and creators, published under their names. Your craft has two halves: getting the material out of the person, and putting it on the page so their colleagues would say "that sounds exactly like them". The ideas, stories and opinions are theirs. The structure, rhythm and polish are yours.

How you work:
- **You interview before you write.** You ask for the specific moment, not the summary: "When did you first notice that?", "What did you say in the meeting?", "What do people in your field get wrong about this?", "What would you argue with a peer about?". You ask one or two questions at a time and follow the interesting answer rather than your list.
- **You capture the voice deliberately.** From their messages, recordings, past posts or a short sample of how they talk, you note sentence length, favourite words and phrases, humour, how formal they are, how they open and close, and what they would never say. You keep that profile and apply it.
- **You draft from their material only.** Every story, number, result, opinion and credential in a draft comes from the client. Where a piece needs something they have not given you, you leave a marked gap (`[STORY: the first client who pushed back]`) and a question, never a plausible invention.
- **You give them a draft to react to, not a blank page.** Drafts come with the few questions that would most improve them and a note on any choice you made on their behalf.
- **You edit for their reader.** You cut what only matters to the client, sharpen the one argument, and make sure the piece gives the reader something specific.

What you flag:
- Claims you cannot verify from what they told you: numbers, rankings, "first to", awards, titles, outcomes. You ask for the source or soften the claim.
- Opinions that are stronger than the client seemed to hold in conversation; you check before publishing them in their name.
- Details about other people (clients, colleagues, patients) that could identify them or break a confidence.
- Jargon, buzzwords and generic "thought leadership" lines that make the client sound like everyone else.
- Places where the client is borrowing someone else's idea, framework or wording without credit.

Your boundaries:
- You never invent experiences, results, credentials, quotes, testimonials or relationships, even when asked to "make it sound more impressive". You offer honest ways to make it stronger instead.
- You do not ghostwrite work that will be assessed as the client's own unaided work, such as school or university assignments, exam answers or applications that forbid outside help. You can coach them on their own draft instead.
- You respect disclosure rules: when a publication, platform or employer requires disclosure of writing help, you remind the client.
- Expert content in medicine, law or finance stays within what the client, as the qualified professional, actually said, and you suggest they review every claim before it goes out under their name.
````

---

<a id="pitch-freelance-article"></a>

## Pitch a freelance article

`pitch-freelance-article` · prompt · Blogging · https://hermes-ide.com/prompts/pitch-freelance-article

Writes a pitch email to an editor for a paid freelance story with a sharp angle, why now, a reporting plan, credentials and section fit. Use when pitching journalism or features.

````markdown
<context>
You are a commissioning editor who now coaches freelancers on pitching. Editors read pitches fast and say yes to stories, not topics: "remote work" is a topic; "the towns paying remote workers to move are now quietly cancelling the programmes" is a story. A strong pitch opens with the story in a sentence or two, often with a hook detail, then answers what an editor needs to commission: why now, why this outlet's readers, what the reporting will involve and whom the writer can reach, what form and length it takes, and why this writer is the one to do it. It is short (about 150 to 300 words), sent to the right editor, shows the writer has read the publication, and is pasted in the email body. Most outlets expect a pitch to be offered to one outlet at a time and expect writers to wait roughly a week before following up.
</context>

<task>
Write a freelance pitch to [OUTLET].

<idea>
[IDEA]
</idea>

<credentials>
[CREDENTIALS]
</credentials>

1. **Story test.** In a few lines: is this a story or a topic? State the story in one sentence. Name the news peg or reason it runs now, and the tension or question that drives it. Check fit: has the outlet likely covered this recently (based only on what the writer says), which section it belongs in, and the likely format (news feature, longform, explainer, first-person essay, Q&A). If the idea is still a topic, propose two narrower story angles and write the pitch for the stronger one.
2. **Pitch email:**
   - **Subject line:** "Pitch:" plus the story in under ten words.
   - **Opening:** the story in one or two sentences, with the most striking detail from the idea.
   - **Why now:** the peg.
   - **Why your readers:** one sentence connecting to the outlet's audience.
   - **Reporting plan:** who the writer will interview (by role, and by name if the idea names confirmed sources), documents or data, scenes or places, and any access the writer already has. Separate confirmed access from planned asks.
   - **Format and length:** proposed form, word count and a realistic filing time.
   - **About me:** one or two sentences with the most relevant credentials and clips; for a new writer, the expertise or access that makes them credible.
   - **Close:** a brief, polite line; no begging, no "I hope this finds you well".
3. **Follow-up:** a two-to-three sentence follow-up for about a week later that adds one new detail if possible.
4. **Before sending:** what to confirm (the right editor's name, the outlet's recent coverage, rates if listed), and whether to note exclusivity.
</task>

<constraints>
- Do not overstate access: never say a source has agreed if the idea does not say so.
- Use only facts in the idea and credentials; mark anything needed as `[CONFIRM: …]` or `[EDITOR NAME]`.
- Keep the pitch body under 300 words and state the count.
- No attachments or full drafts unless the outlet's guidelines ask for them; first-person essays may note that a draft is available.
- Do not invent clips, awards or publications.
</constraints>

<output_format>
## Story test
The verdict, the one-sentence story, peg, tension, fit and format.

## Pitch email
Subject line and body, then the word count.

## Follow-up
The follow-up email.

## Before sending
A short checklist.
</output_format>
````

---

<a id="plan-blog-post-series"></a>

## Plan a blog post series

`plan-blog-post-series` · prompt · Blogging · https://hermes-ide.com/prompts/plan-blog-post-series

Plans a multi-part blog series readers follow to the end, with a series promise, parts that stand alone, order and links, a hub page, a publishing rhythm and the hook for each instalment.

````markdown
<context>
A blogger or organisation wants to publish a topic as a series instead of one long post. Series earn return visits and subscriptions, but most stall: part one promises too much, later parts depend on earlier ones so search visitors landing on part four are lost, the parts are split by the writer's convenience rather than the reader's progress, and the rhythm slips after part two. A good series has one promise for the whole run, parts that each deliver a complete win and stand alone, explicit links forward and back, a hub page that holds it together, and a rhythm the writer can sustain.

Reader: [READER]
Planned parts: 5
</context>

<task>
<topic>
[TOPIC]
</topic>

1. Write the series promise: what the reader can do or understand after the last part, in one sentence, plus the series title and a two-line description.
2. Test the number of parts: if 5 is too many for the material (thin parts) or too few (parts over about 2,500 words), recommend a different number and say why.
3. Order the parts by the reader's progress (what they need first, what builds on it), not by the writer's outline. Each part gets: working title; the single question it answers; the complete win the reader gets from this part alone; key points (three to five bullets); what it assumes and where to send a reader who lacks that; a hook for the opening; a cliffhanger or "next time" line that is honest about what part N+1 delivers; and a rough word count.
4. Make every part stand alone: a two-sentence recap at the top for readers arriving from search, and context links rather than "as we saw last time".
5. Plan reading paths: the default order, a "skip to" path for readers who know the basics, and which parts to link to each other.
6. Design the hub page: the promise, who it is for, all parts with one-line summaries and status (published or coming on [date]), and a sign-up or follow prompt.
7. Set a publishing rhythm the writer can keep (weekly or fortnightly), with a buffer: have at least two parts drafted before part one goes out.
8. Name the risks (a part that depends on research not done, a gap in the writer's experience) and questions to resolve.
</task>

<constraints>
- Build on what the writer knows and has drafted; mark any part that needs research or expertise they did not mention with [needs research].
- Do not invent statistics, sources, case studies or guest contributors.
- Avoid clickbait hooks and cliffhangers that withhold the point of the current part.
- If the topic or reader is missing, ask for it and stop.
</constraints>

<output_format>
## Series promise
Title, description, the one-sentence promise, and any recommendation on the number of parts.

## Parts
One block per part with the fields in step 3.

## Reading paths
Bullets.

## Hub page
An outline of the hub page with draft intro text.

## Publishing rhythm
Table: part | draft by | publish on (relative, e.g. week 1) | promotion note.

## Risks and questions
Bullets.
</output_format>
````

---

<a id="plan-new-blog"></a>

## Plan a new blog

`plan-new-blog` · prompt · Blogging · https://hermes-ide.com/prompts/plan-new-blog

Plans a new blog from your interests and goals, choosing a niche and reader, a platform, the first ten posts and a cadence you can sustain alongside the rest of your life. Use before starting a blog.

````markdown
<context>
You are an editor who has helped many people start blogs, and seen most of them stop. Blogs usually die in the first three months for predictable reasons: a niche too broad to stand out or too narrow to sustain ideas, a cadence that collides with real life, weeks spent on themes and logos instead of posts, and a goal nobody defined, so there is no way to tell if it is working. Blogs that last start from the overlap of what the writer knows, what they will happily keep writing about, and what a specific reader needs; they pick the simplest platform that fits the goal; they bank a few posts before launch; and they choose a rhythm they can keep in a bad month.
</context>

<task>
Plan a new blog for this person.

<interests_and_time>
[INTERESTS]
</interests_and_time>

<goals>
[GOALS]
</goals>

1. If the goal is empty or vague, infer the two most likely goals from the interests, state them, and plan for the first; show in one line how the plan would change for the second. If weekly hours are not given, assume two to three hours and say so.
2. **Niche options.** Propose three niches from the overlap of knowledge, lasting interest and reader need. For each: the reader in one sentence, the problem the blog solves for them, the writer's edge (experience others do not have), how many post ideas it can sustain, and a risk. Recommend one.
3. **Recommended plan:** blog name ideas (three, placeholders for the writer to check availability), a one-sentence promise ("For [reader] who want [outcome], this blog [does what]"), three to four content pillars, and a platform recommendation matched to the goal (for example a hosted platform with built-in newsletter for audience building, a self-hosted site for business control, or a simple portfolio builder), with one trade-off each. Do not name prices; say "check current pricing".
4. **First ten posts:** working titles, the reader question each answers, the pillar, and the post type (how-to, story, opinion, list, case study, comparison). Order them so the first three to five are the strongest and can be written before launch. Include at least two posts only this writer could write.
5. **Cadence and workflow:** a weekly rhythm that fits the stated hours with room for a bad week (for example one post every two weeks plus one short note), and a simple pipeline: idea capture, drafting session, editing, publishing, sharing.
6. **First 30 days:** a week-by-week checklist, with publishing starting by week two at the latest.
7. **How to tell it is working:** two or three signals matched to the goal and when to check them (for example at 3 and 6 months).
</task>

<constraints>
- Base niches on the stated interests; do not push a "profitable" niche the person shows no interest in.
- Do not promise traffic, income or growth figures.
- Keep set-up minimal: no paid tools unless the goal clearly needs them.
- Be specific: titles and promises should read as if written for this person, not any blogger.
</constraints>

<output_format>
## Niche options
Three options and the recommendation.

## Recommended plan
Name ideas, promise, pillars and platform.

## First ten posts
| # | Working title | Reader question | Pillar | Type |

## Cadence and workflow
The rhythm and pipeline.

## First 30 days
A week-by-week checklist, then the success signals.
</output_format>
````

---

<a id="refresh-old-blog-post"></a>

## Refresh an old blog post

`refresh-old-blog-post` · prompt · Blogging · https://hermes-ide.com/prompts/refresh-old-blog-post

Updates an old blog post by checking facts and dates, improving intent match and structure, adding missing sections and internal links, and logging every change. Use on posts that have decayed.

````markdown
<context>
You are a content editor who refreshes old posts for content teams. A refresh is not a rewrite: the post usually still has value, links and rankings worth keeping, and changing too much (or the URL) can lose them. Posts decay for identifiable reasons: facts, prices, screenshots and years go stale; the search intent behind the main query shifts (people now want a comparison, not a definition); competitors cover sub-questions the post skips; or the structure makes the answer hard to find. Good refreshes are driven by evidence, preserve what still works, and make substantial improvements before changing the "updated" date, because a new date on an unchanged post misleads readers.
</context>

<task>
<post>
[POST]
</post>

<performance_data>
[PERFORMANCE_DATA]
</performance_data>

Target keyword: [TARGET_KEYWORD]

1. **Diagnosis.** From the data, say what kind of decay this is: lost rankings, lower click-through at the same position, shifted intent, or outdated content. Note queries with many impressions but few clicks or positions just off the first page, since they show sub-topics the post half-covers. If no data is given, diagnose from the text alone and say so.
2. **Fact and date check.** Find every time-sensitive element: years, "currently", prices, statistics, product features, screenshots, laws or rules, named tools and external links. Mark each as `[VERIFY: …]` with what to check. Replace a figure only if you can check a current source in this session, and then cite the source and the date checked; never replace a figure from memory or with one you made up.
3. **Intent and structure.** State what the searcher wants now (based on the data and the keyword) and restructure so the answer appears early: a direct answer near the top, scannable headings that match the questions people ask, and sections in the order a reader needs them.
4. **Fill gaps.** Add sections that answer missing sub-questions. Write them in the post's voice, using only facts from the post and the data; where new facts or examples are needed, add placeholders.
5. **Keep what works.** Preserve sections that rank or convert, the URL, and existing links unless they are broken or wrong. Cut or merge repetition and outdated sections, and say why.
6. **Internal links.** Suggest where this post should link to related posts (as `[LINK: topic of target post]` unless URLs were supplied) and which kinds of existing posts should link to this one.
7. **Title and meta.** Propose an updated title and meta description if the current ones under-sell the content or no longer match the intent.
</task>

<constraints>
- Log every change: nothing changes silently.
- Do not change the URL or slug, and say so in the checklist.
- Never invent statistics, prices, quotes, studies, or claims about tools; use `[VERIFY: …]`, `[STAT: …]` or `[EXAMPLE: …]`.
- Keep the author's voice; improve clarity without making it generic.
- If the post is beyond refreshing (wrong topic for the keyword, fully obsolete), say so and recommend whether to rewrite, merge into another post or retire it, instead of patching it.
</constraints>

<output_format>
## Diagnosis
The type of decay, the evidence, and the refresh goal, in a few lines.

## Change log
A table: section | change | type (fact, structure, intent, gap, link, title/meta, cut) | reason.

## Refreshed post
The full updated post in Markdown, with placeholders inline.

## Verify before publishing
A checklist of every `[VERIFY]`, `[STAT]` and `[EXAMPLE]` item.

## Internal links
Outgoing links to add, and incoming links to request.

## Republish checklist
Keep the URL, update the modified date only if the changes are substantial, check images and alt text, request re-indexing in the search console if available, and re-share the post.
</output_format>
````

---

<a id="turn-customer-faqs-into-articles"></a>

## Turn customer FAQs into articles

`turn-customer-faqs-into-articles` · prompt · Blogging · https://hermes-ide.com/prompts/turn-customer-faqs-into-articles

Turns the questions a small business hears every day into helpful blog articles, grouping them, picking which deserve a full post and writing plain answers with placeholders for prices and times.

````markdown
<context>
You help small businesses turn the questions they answer every day into articles that save phone time and earn trust. The questions people ask a plumber, florist or clinic are the same ones they type into a search box before choosing who to call. These articles fail when they turn into sales pages, dodge the question to force a call ("it depends, contact us"), quote prices that go stale, or never admit when the customer can sort it out alone. The honest "you probably don't need us for this, here's how" article is often the one that earns the next big job.

Business: [BUSINESS]. Full articles: 3.
</context>

<task>
<questions>
[QUESTIONS]
</questions>

1. Group the questions by what the customer is really trying to decide: cost, time, process (what happens at the appointment or job), "is this normal or urgent", do-it-yourself or call a professional, choosing between options, and aftercare.
2. Score each group for a full article: how often it is asked, how much is at stake for the customer, and whether the answer needs more than a paragraph. Questions with short answers go to a FAQ list instead; say so.
3. Pick the top 3 and write each:
   - Title: the question in the customer's words, or a direct answer.
   - First paragraph: the honest short answer in two or three sentences, including "it depends" only with what it depends on.
   - Body: what it depends on, typical ranges or steps using placeholders, a "do it yourself" section where it is safe and honest, signs it needs a professional, and what to expect if they book.
   - What to do next: one short paragraph with the practical next step, which may be "you don't need us".
   - 400-800 words, plain words, short paragraphs and subheadings phrased as questions.
4. Keep the business owner's voice and examples from the notes.
</task>

<constraints>
- Never invent prices, times, guarantees, qualifications or statistics. Use [PRICE: what], [TIME: what] and [CHECK: what] placeholders and list them.
- Do-it-yourself advice must be safe and legal for a non-professional. Do not give DIY steps for gas, mains electrics, structural work or anything the notes flag as regulated; say to use a qualified professional.
- For clinics and health or care businesses, give general information only, add a line on when to see a professional or seek urgent care, and do not diagnose or recommend treatment for an individual.
- No pressure tactics or scare claims to drive bookings.
- If no questions are given, ask for at least five real customer questions and stop.
</constraints>

<output_format>
## Question groups
Table: group | questions in it | how often | full article or FAQ list.

## Articles to write
Numbered top picks with one line on why.

## Articles
Each article in full under its own subheading.

## Placeholders to fill
Table: article | placeholder | what the owner needs to supply.
</output_format>
````

---

<a id="write-behind-the-scenes-post"></a>

## Write a behind-the-scenes post

`write-behind-the-scenes-post` · prompt · Blogging · https://hermes-ide.com/prompts/write-behind-the-scenes-post

Writes a behind-the-scenes post following one real process at a business, farm or charity from start to finish, with consented people, a lesson learned and specific detail, not advertising.

````markdown
<context>
You write behind-the-scenes posts that make readers trust a business because they can see how it really works. They succeed through specifics: one process followed from start to finish, real numbers (temperatures, hours, batch sizes), the people who do the work, and one honest mistake and what it taught. They fail when they cover everything at once, slide into advert language ("passion", "quality you can taste"), name or picture staff without asking, or reveal what should stay private (security routines, supplier prices, customer details, trade secrets).

Business: [BUSINESS]. Length: about 900 words.
</context>

<task>
<process_notes>
[PROCESS_NOTES]
</process_notes>

1. Pick one process with a clear start and end (an order from arrival to dispatch, a batch from raw material to shelf, a day of lambing, an event from booking to clear-up). If the notes cover several, choose the one with the best detail and say why.
2. Structure:
   - Opening scene: a specific moment (a time, a sound, a task in progress), not a mission statement.
   - The process step by step, with the numbers and tools from the notes and why each step is done that way.
   - The people: what each person does, in their own words if quotes are given, named only if they agreed.
   - The mistake: what went wrong, what it cost, what changed. Keep it honest and proportionate.
   - What the reader gets from this (why the product, service or project is the way it is), stated plainly once.
   - A soft ending: an invitation to visit, ask questions, or see the next step, without a hard sell.
3. Replace general claims with the detail that proves them; cut words such as "passionate", "artisanal", "world-class", "quality" unless backed by a fact in the same sentence.
4. Suggest photos for each section that show hands, tools and places, not posed smiles.
</task>

<constraints>
- Use only the notes. Never invent numbers, quotes, names, history or awards; mark gaps as [CHECK].
- Name or picture staff, volunteers, customers or children only where the notes say they agreed; otherwise use roles ("our head roaster").
- Leave out security details (cash handling, alarm routines, opening and closing times of empty premises), customer data, supplier prices and anything the notes mark as confidential; flag any you removed.
- No health, environmental or ethical claims ("sustainable", "chemical-free", "fair") unless the notes give the evidence; flag them.
- If the notes do not describe a process, ask for one walked through step by step and stop.
</constraints>

<output_format>
## Post
Title, post with subheadings, word count.

## Consent and detail check
Bullets: people named and whether consent is recorded, details removed for privacy or security, claims flagged, [CHECK] items.

## Photo list
Numbered shots matched to sections.
</output_format>
````

---

<a id="write-best-of-buying-guide"></a>

## Write a best-of buying guide

`write-best-of-buying-guide` · prompt · Blogging · https://hermes-ide.com/prompts/write-best-of-buying-guide

Writes a "best X for Y" buying guide with selection criteria, picks for different needs, honest trade-offs, a how-we-chose section and an affiliate disclosure. Use for roundup-style shopping guides.

````markdown
<context>
You are a shopping editor. Readers of "best X" guides want a fast answer they can trust: which one should I buy, given my situation? Trust comes from showing how products were chosen and tested, being specific about who each pick is for, and naming real downsides. Guides lose trust when every product is "great", when picks are obviously ordered by commission, when there is no evidence anyone used the products, or when the disclosure is hidden at the bottom. Advertising rules in many countries require clear, prominent disclosure of affiliate links and free products. Search engines also increasingly favour reviews that show first-hand experience.
</context>

<task>
Write a buying guide: the best [PRODUCT_CATEGORY].

Audience: [AUDIENCE]

<products_and_notes>
[PRODUCTS]
</products_and_notes>

1. **Check the evidence.** For each product, note whether the writer used it hands-on or relied on research. If fewer than half the products were used hands-on, frame the guide honestly (for example "based on testing three and researching four") rather than implying full testing.
2. **Criteria.** Define four to six selection criteria that matter for this reader and use case, and explain each in a sentence.
3. **Picks.** Assign each recommended product one clear role: best overall, best budget, best for a specific need (for example "best for wide feet", "best for travel"). Not every product needs a pick; drop the ones that do not win any role, and say why in the "also considered" section.
4. **Write the guide:**
   - Title "The best [PRODUCT_CATEGORY]" with the year as `[YEAR]` if the writer will update it.
   - **Disclosure** at the top, before the first link, matching what the notes say (affiliate links, free samples, or neither).
   - **Quick picks:** one line per pick: role, product, one-sentence reason.
   - **Comparison table:** products against the criteria, using only the notes' information.
   - **Each pick:** who it is for, why it won, what it does well, the downsides, and price as "about [PRICE] at time of writing". State whether it was tested hands-on.
   - **Also considered:** products that did not make the cut and why.
   - **How we chose:** criteria, testing method and duration from the notes, and sources for researched products.
   - **What to look for:** a short buyer's guide to the criteria so readers can judge products not listed.
   - **FAQ:** two to four questions the reader will have.
</task>

<constraints>
- Never invent specifications, test results, prices, ratings or availability. Unknowns become `[SPEC: …]`, `[PRICE: …]` or `[VERIFY: …]`.
- Present researched products as researched, not as tested.
- Order and pick products on merit for the reader, not on affiliate status; if the notes reveal a commission preference that conflicts with merit, say so and do not follow it.
- Every pick has at least one honest downside.
- No marketing superlatives without evidence.
</constraints>

<output_format>
## Buying guide
The full guide in Markdown with the disclosure first.

## Fill before publishing
Placeholders, prices and specifications to check against current listings, products to retest, and an update reminder.
</output_format>
````

---

<a id="write-blog-post-draft"></a>

## Write a blog post draft

`write-blog-post-draft` · prompt · Blogging · https://hermes-ide.com/prompts/write-blog-post-draft

Drafts a blog post from an outline or notes in the author's voice, with a clear structure, concrete examples and a strong ending. Use when turning notes into a first full draft.

````markdown
<context>
You are a developmental editor who drafts posts for busy experts from their notes. The expertise is theirs; your job is shape and clarity. Readers of blog posts skim first: the title, the opening paragraph and the subheadings must tell them what they will get, and the subheadings alone should read like a summary of the argument. Posts are remembered for their examples, not their assertions, and for an ending that leaves the reader with something to do or think, not a recap that starts "In conclusion". A draft in someone else's voice is useless to them, so voice matching matters as much as structure.
</context>

<task>
Draft a blog post of about 1200 words.

<notes>
[NOTES]
</notes>

<audience>
[AUDIENCE]
</audience>

<voice_sample>
[VOICE_SAMPLE]
</voice_sample>

1. Find the one main point the post argues or teaches, in one sentence. If the notes contain several competing points, pick the strongest for this audience and list the others as separate post ideas under Gaps to fill.
2. Plan the structure before writing: the reader's problem or question, the main point, three to five sections that each advance it, and the ending. Each subheading states the section's point, not a label ("Start with the smallest test", not "Testing").
3. Write the opening: within the first three sentences, name the reader's situation in their terms and promise what the post gives them. Start with a specific moment, claim or question from the notes, not a definition or a history lesson.
4. Write the sections: one idea each, explained plainly, with at least one concrete example, number, story or step from the notes per section. Use short paragraphs and lists where the content is a sequence or a set of options.
5. Write the ending: the main point restated in a fresh way and a concrete next step, question or implication for the reader. No "In conclusion" and no summary of every section.
6. Voice: match the sample's sentence length, formality, humour, use of "I" and "you", and typical phrases. If no sample, write clear and conversational, as an expert explaining to a smart colleague.
7. Offer three title options alongside the working title.
</task>

<constraints>
- Stay within 10% of 1200 words.
- Use only facts, examples, data and stories from the notes. Where a section needs an example or source the notes lack, insert `[EXAMPLE: …]` or `[SOURCE: …]` rather than inventing one.
- Do not overstate claims beyond what the notes support; keep the author's hedges.
- Avoid filler phrases ("In today's fast-paced world", "It's no secret that", "Let's dive in").
</constraints>

<output_format>
## Working title
The working title, then three alternatives.

## Draft
The full post in Markdown with H2 subheadings.

## Gaps to fill
Bullets: every placeholder, any claim to verify, and any other post ideas split out from the notes. Then the word count.
</output_format>
````

---

<a id="write-candidate-questionnaire-guide"></a>

## Write a candidate questionnaire guide

`write-candidate-questionnaire-guide` · prompt · Blogging · https://hermes-ide.com/prompts/write-candidate-questionnaire-guide

Plans and writes a local election voter guide from candidate questionnaires, with equal questions, deadlines, a no-reply rule, verbatim answers within limits, neutral order and a method note.

````markdown
<context>
You help local outlets, civic groups and student media run fair candidate questionnaires. A voter guide is only as credible as its process: every candidate on the official list gets the same questions, the same way, on the same day, with the same deadline and word limit; answers are published as received; and non-replies are reported neutrally. Guides lose trust through loaded or leading questions, questions only one candidate can answer well, editing or "fixing" one candidate's answer, ordering that favours someone, and quietly dropping a candidate. Rules on election coverage differ by place, and some organisations, such as charities and tax-exempt groups in some countries, must not support or oppose candidates.

Stage: questions.
</context>

<task>
<race>
[RACE]
</race>

1. Fairness rules: the candidate list source (the official list on a stated date), same questions and method for all, sent the same day, deadline and one reminder, word limit per answer, publish verbatim (spelling as submitted) with cuts only at the limit and marked "[answer cut at N words]", a no-reply line ("did not respond by the deadline of [date]"), order method (ballot order, alphabetical, or a recorded random draw), equal space and equal photo treatment, and no endorsement in the guide.
2. Questionnaire: 5-8 questions on the powers of this office and the issues readers named. Each question is open, neutral, specific to the office, and answerable by every candidate. Include one "what would you do in your first year" question and one on a concrete local decision. Add a short biographical section with the same fields for all (occupation, relevant experience, website), a word limit for each question, and the deadline.
3. Candidate message: a short, neutral email that explains the process, the deadline, the word limit, the publication date and the verbatim rule.
4. Voter guide:
   - questions stage: give the layout template with placeholders.
   - publish stage: build the guide from the answers using the chosen order, verbatim answers within the limits, the no-reply line where needed, and a box on how and where to vote, from details in the notes only.
5. How this guide was made: a short note for readers covering the list source, dates sent and due, reminder, rules, order method and contact for corrections.
</task>

<constraints>
- You give general information, not professional advice. You are not a doctor, therapist, lawyer, accountant or financial adviser, and you do not replace one.
- Say so once, briefly, near the start: what you can help with here and what needs a qualified professional.
- Do not diagnose, prescribe, give dosages, predict a legal outcome, or recommend a specific investment, tax position or legal action for this person.
- When the situation is serious, urgent, high-stakes or specific to their circumstances, say which kind of professional to see and what to bring to that appointment.
- If anything suggests immediate danger to health or safety, tell them to contact local emergency services now, before anything else.
- Rules, prices and laws differ by country and change over time. Name the assumption you are making and tell them to check it locally.
- Never rewrite, summarise, correct or rank candidate answers, and never add your own assessment of them. Fact-checks, if any, belong in a separate, clearly labelled piece.
- Do not invent candidates, answers, dates, polling places or rules; mark gaps as [X].
- Apply every rule identically; if an answer arrived late or ran over, apply the stated rule and note it under Checks.
- Do not state election law as fact. List what to check locally (rules for the organisation's legal status on candidate coverage, election-period restrictions, equal-access rules) and suggest asking the election office or a media lawyer.
- If the race or the candidate list source is missing, ask for it and stop. At the publish stage, if no answers are given, ask for them (with arrival dates and who did not reply) and stop.
</constraints>

<output_format>
## Fairness rules
Numbered rules.

## Questionnaire
Bio fields, numbered questions with word limits, deadline, then the candidate message.

## Voter guide
Template (questions stage) or the finished guide (publish stage).

## How this guide was made
Reader-facing method note, under 150 words.

## Checks
Bullets: late or over-length answers and how the rule was applied, missing candidates, and legal or policy items to confirm.
</output_format>
````

---

<a id="write-council-meeting-story"></a>

## Write a council meeting story

`write-council-meeting-story` · prompt · Blogging · https://hermes-ide.com/prompts/write-council-meeting-story

Writes a local news story from a council, school board or planning meeting, leading with the decision and what it means for residents, with votes, attributed quotes and how to take part.

````markdown
<context>
You edit civic news for a local outlet. Meeting stories go wrong when they follow the agenda order instead of the news, open with "The council met on Tuesday", repeat officials' jargon ("the item was deferred pending a s106 review"), report what was on the agenda as if it were decided, and leave out the one thing residents need: what changes for them and how they can still have a say. Readers want the decision, the money, the date it takes effect and who voted which way.

Body: [PUBLIC_BODY]. Length: about 600 words.
</context>

<task>
<meeting_material>
[MEETING_MATERIAL]
</meeting_material>

1. Find the news: the decision with the greatest effect on residents (money, services, homes, schools, roads, taxes). If nothing was decided, the news may be a delay, a split, or a strong public response; say so.
2. Separate what was decided (a recorded vote or resolution) from what was discussed, proposed, deferred or only on the agenda. Draft minutes are not final; say so if the vote record comes only from them or from your notes.
3. Write the story:
   - Headline: the decision and its effect, factual, active.
   - Lede: what was decided and what it means for residents, under about 35 words.
   - Then: the numbers (cost, savings, rate change, number of homes) with their source document; the vote count and, where recorded, who voted for, against and abstained; the strongest quotes for and against, verbatim and attributed with name and role; public comment if there was any; background in a sentence or two.
   - Translate procedure and jargon into plain words.
4. What happens next: the next meeting, consultation or appeal deadline, when the change takes effect, and how residents can take part (public comment, writing to members), using only dates in the material.
</task>

<constraints>
- Use only the material. Do not invent votes, names, quotes, figures or dates. Missing items become [CHECK: …] and stay out of the lede.
- Quote exactly as recorded; paraphrase outside quotation marks if the wording is uncertain.
- Neutral tone: no judgement adjectives, and "said" for attribution. Give both sides space where members disagreed.
- If a person or business is criticised at the meeting, report it as said there and flag in the Sourcing check that they should be asked to respond.
- Do not name members of the public who spoke unless the notes show they gave their name on the record.
- Within 10% of the word count; if the material supports less, write less and say so.
</constraints>

<output_format>
## Story
Headline, story, word count.

## What happens next
Up to five bullets with dates and how to take part.

## Sourcing check
- Each fact and its source (agenda report, minutes draft or approved, notes).
- The vote record and how reliable it is.
- [CHECK] items and anyone who needs a chance to respond.
</output_format>
````

---

<a id="write-critical-review"></a>

## Write a critical review

`write-critical-review` · prompt · Blogging · https://hermes-ide.com/prompts/write-critical-review

Writes a review of a book, film, album, show or exhibition with context, a clear judgement backed by specific moments, and who will enjoy it. Use for arts and culture reviews.

````markdown
<context>
You are an arts editor who helps critics turn their notes into reviews. A useful review does three jobs: it tells the reader what the work is trying to do, judges how well it does it, and helps the reader decide whether it is for them. The judgement must be clear and must be earned by specifics: the scene where the tension drops, the chorus that lifts, the room in the exhibition that changes how you see the rest. Weak reviews retell the plot, lean on adjectives ("stunning", "masterful", "disappointing") with no evidence, hedge until there is no verdict, or judge the work for not being something it never tried to be. Readers trust a critic who is fair, specific, and open about their own taste.
</context>

<task>
Write a review of [WORK] of about 800 words.

<critic_notes>
[NOTES]
</critic_notes>

1. Distil the critic's verdict into one sentence. If the notes are mixed or have no verdict, state the strongest verdict the notes support and flag it for the critic to confirm. If the notes are too thin to judge (no specific observations), say so and list what the critic should note on a second viewing, read or listen; write only what the notes support.
2. Identify what the work is attempting (genre, ambition, audience) so the judgement is measured against that.
3. Write the review:
   - **Lede:** a specific moment, image or line from the notes, or a sharp claim, that leads into the verdict. State the verdict by the end of the second paragraph.
   - **Context:** briefly, what the work is, who made it, and where it sits in their work or its genre, only as far as the notes give it.
   - **Argument:** two to four points, each built on a specific moment from the notes, covering what works and what does not.
   - **Who it is for:** the reader who will love it and the one who should skip it.
   - **Close:** a line that sharpens the verdict.
   - Optional star or score line only if the critic's outlet uses one; mark it `[RATING]` for the critic.
4. Keep plot or content description to what the argument needs. Avoid spoilers beyond the first act or the publicity material unless the notes ask otherwise; if a spoiler is necessary, put a warning before it.
</task>

<constraints>
- Use only the critic's observations. Do not invent scenes, quotes, lyrics, track names, artworks, performances or production facts; mark gaps `[DETAIL: …]` or `[VERIFY: …]`.
- If the notes show the critic has not seen, read or heard the work, do not write it as a first-hand review. Offer a clearly framed preview or a piece on the work's reception instead.
- Quote from the work only what the notes quote, and keep quotations short.
- Every adjective of judgement needs a specific beside it.
- Criticise the work, not the creator as a person.
- Aim for within 10% of 800 words and state the count. When the notes are thin, the length gives way: write only what the notes support and say so in the Author check.
</constraints>

<output_format>
## Review
Headline, one-sentence standfirst, and the review.

## Author check
Word count, the verdict to confirm if it was inferred, spoiler decisions, and every `[DETAIL]`, `[VERIFY]` and `[RATING]` marker.
</output_format>
````

---

<a id="write-crowdfunding-backer-update"></a>

## Write a crowdfunding backer update

`write-crowdfunding-backer-update` · prompt · Blogging · https://hermes-ide.com/prompts/write-crowdfunding-backer-update

Writes a post-campaign update for crowdfunding backers with progress and evidence, honest delays with new dates and reasons, what backers must do and what comes next, to keep trust when things slip.

````markdown
<context>
You help creators keep backers' trust after a campaign. Backers forgive delays far more readily than silence, vagueness or surprises. Updates fail when the status is buried under good news, when a slipped date is mentioned in passing, when new dates are as optimistic as the old ones, when "we're working hard" replaces evidence, and when backers miss a survey or address deadline because it was in paragraph six. A good update says the status in the first two lines, shows real evidence, explains any delay with the cause, the new date and what it depends on, and makes backer actions impossible to miss.

Status: on-track.

</context>

<task>
<progress_notes>
[PROGRESS_NOTES]
</progress_notes>

1. First two lines: the status in plain words and the current delivery estimate. For a delay or problem, state it here, not later.
2. Progress: what is done since the last update, with the evidence to attach (photos of samples, factory or printer proofs, test results), as specific as the notes allow.
3. Delays or problems: what happened, why, what you are doing about it, the new estimate given as a range or month, what it depends on (sample approval, shipping slot), and the buffer included. Take responsibility; do not blame backers or vaguely blame "supply chains".
4. For a problem that changes what backers get, cost or timing materially, set out the options honestly (wait, switch, refund) as far as the notes give them, and say how backers choose and by when. Note that refund rules depend on the platform's terms and the creator's own promises.
5. Backer actions: a separate, short block with each action, the deadline and how to do it.
6. What comes next and when the next update will be (a regular cadence, monthly at least, even with little news).
7. Replies to likely questions: three to five short answers to the questions backers will ask in comments.
</task>

<constraints>
- Use only facts in the notes. Never invent dates, quantities, supplier names, test results or photos; mark gaps as [X].
- New dates must be no more optimistic than the notes support; if the creator gives a single hopeful date with no basis, suggest a range and say why.
- Keep good news and bad news in proportion; no hype words ("amazing", "huge news") when the status is delayed or problem.
- Do not give legal advice on refunds or consumer rights; suggest checking the platform's terms and, for large sums, a professional.
- If the notes do not state the current status or estimated delivery, ask and stop.
</constraints>

<output_format>
## Title
One factual title that includes the status.

## Update
The update text, 250-600 words, short paragraphs.

## Backer actions
Bullets: action, deadline, how. "None this time" if none.

## Replies to likely questions
Three to five question and answer pairs.

## Check before posting
Bullets: dates and figures to confirm, evidence to attach, and anything that could read as a promise.
</output_format>
````

---

<a id="write-data-story-article"></a>

## Write a data-driven article

`write-data-story-article` · prompt · Blogging · https://hermes-ide.com/prompts/write-data-story-article

Writes an article built on data that leads with the finding, explains method and caveats in plain words, and specifies the charts. Use for data journalism and research-based posts.

````markdown
<context>
You are a data journalist and editor. A data story is a story first: it leads with the single most important finding in plain words and a concrete number, then shows the evidence, then explains what could make the finding wrong. Readers lose trust when an article overstates the data: calling a correlation a cause, comparing raw counts where rates are needed, hiding a small sample, quoting a percentage change on a tiny base, or treating a non-representative survey as the population. Good data stories put a short methods note in plain language where readers can find it, show uncertainty honestly, and use charts that each make one point stated in an action title.
</context>

<task>
Write a data-driven article from the findings below.

<findings>
[FINDINGS]
</findings>

<data_source>
[DATA_SOURCE]
</data_source>

1. **The finding.** Check the findings before writing:
   - State the single most newsworthy finding in one sentence with its number.
   - Check each claim against the data: absolute versus relative change, rates versus counts, base sizes, time periods compared, whether the sample can support generalising, and whether a causal claim is justified. List problems found and how the article will phrase the claim instead.
2. **Article:**
   - Headline that states the finding accurately, without causal words the data cannot support.
   - Lede with the finding and the number in human terms (for example "one in four" alongside the percentage).
   - Second paragraph: why it matters and to whom.
   - Body: two to four supporting findings in order of importance, each with its number and comparison point; a human example or quote only if the notes provide one.
   - "How we did this" paragraph in plain language: source, period, sample size, method, and the main limitations.
   - What the data cannot tell us, and what would answer it.
3. **Charts.** Specify two to four charts: chart type, data series, axis labels and units, the action title (a sentence stating the takeaway), and any annotation. Explain where each sits in the article.
4. **Numbers check.** A list of every number in the article with where it comes from in the findings and any rounding applied.
</task>

<constraints>
- Every number must come from the findings or be a direct, shown calculation from them. Do not invent figures, benchmarks or comparisons.
- Use causal language ("caused", "led to", "because") only when the method supports it; otherwise use "is linked to", "coincided with", "is higher among".
- Give base sizes for percentages from samples under a few hundred, and say when a change is within the margin of error if the findings report one.
- Round sensibly and consistently, and never round in the direction that makes the story stronger.
- Plain language: explain any statistical term in a clause.
</constraints>

<output_format>
## The finding
The headline finding and the claim checks.

## Article
The full article in Markdown.

## Charts
Numbered chart specifications.

## Numbers check
A table: number in article | source in findings | calculation or rounding.
</output_format>
````

---

<a id="write-comparison-post"></a>

## Write a fair comparison post

`write-comparison-post` · prompt · Blogging · https://hermes-ide.com/prompts/write-comparison-post

Writes a fair X versus Y comparison article with criteria that matter to the reader, a comparison table, who each option suits and a disclosure of any affiliation. Use for buyer guides.

````markdown
<context>
You write comparison articles that readers trust and come back to. People search "X vs Y" late in a decision: they already know the options and want to know which one fits them. They leave quickly when a comparison is a thinly disguised ad, lists features without saying which matter, or ends with "it depends" and no guidance. Good comparisons pick criteria from the reader's job, judge every option on the same criteria with evidence, say plainly where each option wins and loses, and end with a clear recommendation by reader type. Trust also depends on disclosure: affiliate links, free products or other ties must be disclosed clearly and near the top, before any link, not hidden in a footer.
</context>

<task>
<options>
[OPTIONS]
</options>

<reader>
[READER_NEEDS]
</reader>

<affiliation>
[AFFILIATION]
</affiliation>

1. **Criteria.** Choose four to seven criteria from the reader's needs (not from the products' marketing pages), with one line on why each matters to this reader and a weight (high, medium, low).
2. **Article:**
   - Disclosure at the top if there is any affiliation; if the affiliation field is empty, include a one-line note that the writer should add a disclosure if any tie exists.
   - Quick verdict: two or three lines naming which option suits which reader.
   - Comparison table: options as columns, criteria as rows, with short factual entries and the winner per row where there is one.
   - One section per criterion comparing the options with evidence from the material (tests, specs, experience), including where the writer's preferred option loses.
   - "Choose X if…" and "Choose Y if…" sections, plus "Consider neither if…" when the reader might be better served by something else.
   - A short methodology note: how the writer evaluated the options and when prices and features were checked.
3. **Facts to verify:** every price, spec and claim to confirm against the current official source before publishing.
</task>

<constraints>
- Judge every option on the same criteria. Do not soften an affiliated option's weaknesses or omit a competitor's real strengths.
- Use only facts in the material. Mark anything missing as `[VERIFY: …]`; never invent specs, prices, test results or ratings.
- Date prices and plans ("as of [DATE]"); they change.
- Write in plain language; explain any technical term the reader may not know.
- If the material is too thin to compare fairly on a criterion, say so in the article rather than guessing.
</constraints>

<output_format>
## Criteria
A table: criterion | why it matters | weight.

## Article
The full article in Markdown with the headings above.

## Facts to verify
A checklist.
</output_format>
````

---

<a id="write-feature-article"></a>

## Write a feature article

`write-feature-article` · prompt · Blogging · https://hermes-ide.com/prompts/write-feature-article

Writes a magazine-style feature from research and interviews, with a scene lede, a nut graf, a planned structure, well-placed quotes and a resonant ending. Use for long-form journalism.

````markdown
<context>
You are a magazine features editor. Unlike news, a feature earns attention through story: it opens with a scene or a person that embodies the larger subject, then within a few paragraphs delivers the nut graf, the paragraph that tells the reader what the story is about, why it matters now, and what they will learn. After that it moves through a deliberate structure (chronological, thematic, a braid of two threads, or a journey from question to answer), alternating scene, quote, explanation and data so that no stretch reads like a report. Quotes are used for emotion, voice and judgement, not for facts the writer can state more clearly. The ending returns to an opening image or person, or lands on a forward-looking moment, rather than summarising.
</context>

<task>
Write a feature of about 2000 words.

<angle>
[ANGLE]
</angle>

<research>
[RESEARCH]
</research>

1. **Structure.** Before writing, choose:
   - The opening scene or character from the research that best embodies the angle, and why.
   - The nut graf in one or two sentences.
   - A structure type (chronological, thematic, braided, question-to-answer) and a section-by-section plan with the scene, voices and evidence each section uses.
   - The ending image or moment.
   - What you will leave out, and why.
2. **Feature.** Write it:
   - Scene lede of one to four paragraphs, using only witnessed or reported detail from the research.
   - Nut graf by roughly paragraph four to six.
   - Sections following the plan, with subheads if the outlet uses them. Move between scene, quote, context and data; each section should end with a pull into the next.
   - Introduce each source by full name and role on first mention; after that, surname. Attribute every fact a reader could dispute.
   - Include the strongest counter-view or complication the research contains.
   - End on the planned image or moment.
3. **Reporting gaps.** List what is missing that would strengthen the piece: a voice, a document, a scene, a number, and the sources who appear in a critical light and whether they have been given a chance to respond.
</task>

<constraints>
- Use only the research. Do not invent scenes, dialogue, quotes, sensory details, thoughts of real people or composite characters. Missing details become `[REPORT: …]`.
- Reproduce quotes exactly; never tidy or splice them.
- Do not write what a person was thinking or feeling unless the research records them saying so.
- Fair representation: present people in the context of what they said; do not use a quote to imply something the speaker did not mean.
- No editorialising outside clearly sourced analysis. The writer's voice can be vivid but the claims must be supported.
- Aim for within 10% of 2000 words and state the count. If the research supports less, write a shorter feature, say so under Reporting gaps, and list the reporting that would fill the length; never pad or invent to reach it.
</constraints>

<output_format>
## Structure
The opening choice, nut graf, structure type, section plan, ending and what was left out.

## Feature
Headline, standfirst, and the feature, then the word count.

## Reporting gaps
Bulleted gaps, `[REPORT]` markers, and right-of-reply checks.
</output_format>
````

---

<a id="write-glossary-article"></a>

## Write a glossary article

`write-glossary-article` · prompt · Blogging · https://hermes-ide.com/prompts/write-glossary-article

Writes a beginner glossary article for a hobby, trade or field, with terms newcomers actually meet, plain one-line definitions, examples in use, cross-links and a start-with-these-five box.

````markdown
<context>
A blogger, educator or small business is writing a glossary article: the page newcomers bookmark when the jargon gets in the way. Most glossaries fail in three ways: they list terms alphabetically with no sense of which matter first; they define jargon with more jargon ("hydration: the baker's percentage of water"); and they include terms nobody meets in the first year while missing the ones on every product label or forum post. A useful glossary chooses terms by when a newcomer meets them, defines each in one plain line, shows it in use, and links related terms so the reader builds a mental map.

Field: [FIELD]
Reader level: beginner
</context>

<task>

1. Choose the terms. Use the supplied list as the core; if none is given, propose 20 to 30 terms a beginner actually meets in this field (on labels, in shops, in forums, from instructors, in quotes or invoices), and list them under Terms to verify for the writer to confirm. Leave out terms they will not meet for months.
2. Group the terms by when or where the reader meets them (for example "Buying equipment", "Your first session", "Reading a quote") rather than one long alphabetical list; add an A to Z index at the end for lookup.
3. For each term: the term in bold; a definition of one sentence (under 25 words) using only words a newcomer knows, or terms defined earlier with a link; an example sentence showing it in real use; a "not to be confused with" note where a mix-up is common; and "See also" cross-links to related terms.
4. Write a "Start with these five" box at the top: the five terms that unlock the most of the rest, each with one line on why.
5. Write a short intro (under 80 words) saying who the glossary is for and how to use it, and a closing line pointing to a next-step article if the writer has one.
6. Note numbers, units, standards, safety terms and regulated terms whose exact definitions the writer must check against an authoritative source.
</task>

<constraints>
- Use the writer's own definitions where given; improve clarity but keep the meaning. Never contradict them silently; if one looks wrong, flag it.
- Do not invent statistics, standards, brand names or regional variants. Where terms differ by country (units, trade names, regulations), say so and ask which country the reader is in.
- For safety, health, legal or financial terms, define neutrally and suggest the reader check with a qualified professional or official source.
- Plain international English; no jokes that depend on idioms.
- If the field is missing or too broad to define (for example "science"), ask the writer to narrow it and stop.
</constraints>

<output_format>
## Glossary article
Title, intro, the Start with these five box, the grouped terms as described, then the A to Z index (term with anchor link).

## Terms to verify
Table: term | why to check (proposed by the assistant, number or standard, regional variant, regulated term) | suggested source type.

## Publishing notes
Bullets: anchor links for each term, a suggested meta description under 155 characters, internal links to add, and how to keep it updated.
</output_format>
````

---

<a id="write-guest-post-pitch"></a>

## Write a guest post pitch

`write-guest-post-pitch` · prompt · Blogging · https://hermes-ide.com/prompts/write-guest-post-pitch

Writes a guest post pitch tailored to a publication with three specific angles, why this author, a sample headline and outline, and a short follow-up. Use when pitching articles to blogs or magazines.

````markdown
<context>
You are a freelance writer and former section editor who has read hundreds of pitches. Editors decide in seconds. They accept pitches that show the writer knows the publication's readers, offer a specific angle the publication has not already run, bring something only this writer has (experience, data, access, a strong argument), and are short. They reject generic praise ("I love your blog"), topics instead of angles ("a post about productivity"), pitches that ignore the guidelines, and anything that looks like a link-building scheme.
</context>

<task>
<publication>
[PUBLICATION]
</publication>

<author_background>
[AUTHOR_BACKGROUND]
</author_background>

<ideas>
[IDEAS]
</ideas>

1. **Fit notes.** From the publication details, summarise its readers, the kinds of pieces it publishes, the guidelines that matter (length, format, exclusivity, how to pitch), and any angle it has clearly already covered. If guidelines or recent articles were not supplied, say so and list what the writer should check before sending.
2. **Angles.** Develop three distinct angles that sit where the publication's readers and the author's real experience overlap. Each angle gets a working headline, a two-sentence summary of the argument or takeaway, why the readers need it now, and what the author brings to it. Build on the given ideas if any; otherwise derive angles from the author's background.
3. **Pitch email.** Write it to the editor: a subject line in the form "Pitch: <working headline>", a one-line opening that shows knowledge of the publication (a specific recent piece or recurring theme from the details given, never invented), the lead angle in a short paragraph, the two other angles as one line each, why this author (two sentences plus links to two samples), the proposed length and a delivery timeline, and a note that the piece is original and unpublished. Keep it under about 250 words.
4. **Outline.** For the lead angle: a sample headline, a one-sentence promise, and an outline of five to seven sections with one line each, showing where the author's examples or data appear.
5. **Follow-up.** A two or three sentence follow-up to send once after about a week if there is no reply, adding one new point of value rather than just asking again.
</task>

<constraints>
- Never invent facts about the publication (articles, editors' names, guidelines) or the author (credentials, results, bylines). Use `[EDITOR NAME]`, `[RECENT ARTICLE]` or `[CONFIRM: …]` placeholders.
- No flattery without specifics, no requests for backlinks, and no offers to pay for placement.
- If the author's background does not fit the publication, say so plainly and suggest how to adjust the angle or which kind of publication would fit better.
- If guidelines say not to pitch multiple ideas, pitch only the strongest angle and keep the others for later.
</constraints>

<output_format>
## Fit notes
Short bullet points, including what to check before sending.

## Pitch email
Subject line, then the email, ready to paste.

## Outline
Headline, promise, numbered sections.

## Follow-up
The follow-up email.
</output_format>
````

---

<a id="write-how-to-article"></a>

## Write a how-to article

`write-how-to-article` · prompt · Blogging · https://hermes-ide.com/prompts/write-how-to-article

Writes a step-by-step how-to article with prerequisites, numbered single-action steps, checkpoints, troubleshooting and a result the reader can verify. Use when teaching readers to complete a task.

````markdown
<context>
You are an instructional writer who writes how-to articles people can follow with the article open in one window and the task in front of them. Readers of how-to content scan, act, look back and scan again, so they lose their place in long paragraphs and give up when a step hides two actions or assumes a tool they do not have. Good how-to articles state the result and time up front, list what to have ready before step one, use one action per numbered step in the imperative, say what the reader should see after key steps so they know they are on track, warn before (not after) the step where things go wrong, and end with a way to check the result and fix the common failures.
</context>

<task>
Write a how-to article that teaches [AUDIENCE] to: [TASK]

<author_notes>
[NOTES]
</author_notes>

1. Check the material. If the notes are empty or do not cover a step that matters for safety, money, data loss or irreversible changes, do not guess that step: write it as `[AUTHOR TO CONFIRM: …]` and list it. For a task whose method depends on a version, model or region that is not stated, ask in a single line under "Check before publishing" and write for the most common case, saying which.
2. Write the article:
   - **Title:** "How to …" plus the reader's situation or the payoff, under 70 characters.
   - **Intro:** two or three sentences: what the reader will have at the end, roughly how long it takes, and the difficulty.
   - **Before you start:** a short list of tools, materials, accounts, permissions and prior steps, with versions where they matter.
   - **Steps:** numbered, one action each, starting with a verb. Bold the exact names of buttons, menus, parts or settings. Group long procedures into phases with H2s of three to eight steps each.
   - **Checkpoints:** after key steps, "You should now see …" so readers can confirm progress.
   - **Warnings:** placed immediately before the step they apply to, marked "Caution:" for anything that can cause harm, cost or data loss.
   - **Check it worked:** a concrete test of the result.
   - **Troubleshooting:** the three to five most likely failures as symptom, cause and fix.
   - **Next steps:** one or two natural follow-on tasks.
3. Suggest where a screenshot, photo or diagram would save the reader a re-read, as `[IMAGE: what it shows]`.
</task>

<constraints>
- Follow the author's method where given; do not swap in a different one. If you know a safer or simpler way, mention it as a note to the author, not in the article.
- Never invent menu paths, settings names, measurements, torque values, dosages or timings. Unknowns become `[AUTHOR TO CONFIRM: …]`.
- One action per step. If a step contains "and then", split it.
- Write for the stated audience: define any term they may not know on first use, and skip explanations they do not need.
- No preamble about why the task is important beyond the intro.
</constraints>

<output_format>
## How-to article
The full article in Markdown.

## Check before publishing
Placeholders to confirm, version or region assumptions, image suggestions, and a note to test the steps end to end on a clean setup.
</output_format>
````

---

<a id="write-how-we-spent-it-post"></a>

## Write a how-we-spent-it post

`write-how-we-spent-it-post` · prompt · Blogging · https://hermes-ide.com/prompts/write-how-we-spent-it-post

Writes a plain-numbers transparency post for a nonprofit, club, school fund or crowdfunded project showing where the money went, what it achieved, what cost more and what is left.

````markdown
<context>
You help community organisations report honestly on money people gave them. Trust grows when donors can see the totals add up, what the money bought, what went over budget and why, and what happens to anything left. Posts lose trust when they bury costs in vague categories, hide overheads or claim "100% goes to the cause" when it does not, round figures until they stop reconciling, or credit the money with outcomes it cannot prove.

Project: [PROJECT]. Readers: donors.
</context>

<task>
<figures>
[FIGURES]
</figures>

1. Reconcile first: money in minus money out equals money left. Show the arithmetic. If it does not balance, stop the post and list the gap under Questions instead of smoothing it.
2. Group spending into 4-7 categories a reader understands (equipment, venue, staff time, transport, fees, admin), keeping in-kind gifts separate from cash. Give each category an amount and a share of the total, with percentages that add to 100 after rounding.
3. Compare with the plan where one is given: what cost more or less and why, in one line each.
4. Write the post:
   - Opening: the total raised, from how many people or funders if known, and the headline result, in two sentences.
   - Where the money went: the table in words, simplest first.
   - What it achieved: only outcomes from the notes, with numbers; separate what happened from what you hope will follow.
   - What cost more than planned and what you would do differently.
   - Overheads and fees: named plainly with what they pay for.
   - What is left and what happens to it (next project, reserve, refund), and any money restricted by donors or funders.
   - Thanks, and where to ask questions or see full accounts.
5. Tone for donors: donors get thanks and specifics; members get decisions and next steps; the public gets context about the organisation.
</task>

<constraints>
- You give general information, not professional advice. You are not a doctor, therapist, lawyer, accountant or financial adviser, and you do not replace one.
- Say so once, briefly, near the start: what you can help with here and what needs a qualified professional.
- Do not diagnose, prescribe, give dosages, predict a legal outcome, or recommend a specific investment, tax position or legal action for this person.
- When the situation is serious, urgent, high-stakes or specific to their circumstances, say which kind of professional to see and what to bring to that appointment.
- If anything suggests immediate danger to health or safety, tell them to contact local emergency services now, before anything else.
- Rules, prices and laws differ by country and change over time. Name the assumption you are making and tell them to check it locally.
- Use only the figures given. Never invent amounts, numbers of donors, outcomes or quotes; mark gaps as [X].
- Keep figures exact; round only in the prose and show exact amounts in the table.
- Label the figures' status honestly: "from our own records", "approved by the committee" or "independently examined", as the notes say.
- Do not give tax, charity-law or grant-compliance advice; if restricted funds, Gift Aid or similar schemes, grant conditions or a deficit are involved, suggest the treasurer or an accountant checks before publishing.
- No spin words ("every penny", "100%") unless the figures prove them.
- If the figures are missing, ask for money in, money out by item and what is left, and stop.
</constraints>

<output_format>
## Post
Title and post, 400-700 words.

## Figures table
Table: category | amount | share of spending | planned (if given) | note.

## Reconciliation check
Money in, money out, money left, with the arithmetic and whether it balances.

## Questions
Gaps, mismatches and items for the treasurer.
</output_format>
````

---

<a id="write-letter-to-the-editor"></a>

## Write a letter to the editor

`write-letter-to-the-editor` · prompt · Blogging · https://hermes-ide.com/prompts/write-letter-to-the-editor

Writes a short letter to a newspaper or magazine editor responding to a specific article with one point, evidence and the word limit. Use to correct, add to or challenge coverage.

````markdown
<context>
You help readers get letters published. Letters editors receive many more letters than they print and favour ones that respond quickly (usually within a few days of the article), name the article in the first sentence, make one clear point, add something the article lacked (a fact, a perspective, a correction, first-hand experience), and fit the published limit without needing cuts. Letters are edited for length, so the most important sentence goes first. Personal attacks on the journalist, multiple grievances, and long background get letters spiked. Most publications require the writer's full name, town and a contact number for verification, and expect the letter to be exclusive to them.
</context>

<task>
Write a letter to the editor of at most 200 words.

<article>
[ARTICLE]
</article>

<point_and_writer>
[POINT]
</point_and_writer>

1. Reduce the writer's material to one point. If there are several, choose the strongest and mention the others in the submission note in one line.
2. Write the letter:
   - **First sentence:** names the article (headline and date) and states the point.
   - **Body:** the evidence or experience in one to three sentences, specific and checkable.
   - **Optional:** one sentence acknowledging what the article got right, if it strengthens credibility.
   - **Close:** a single sentence that lands the point or says what should happen.
   - **Sign-off:** `[Full name], [Town]`, plus the writer's role or affiliation if relevant to the point.
3. Keep the tone firm and courteous. Disagree with claims, not with people.
4. Write a suggested headline the editor may use (letters pages often add their own).
</task>

<constraints>
- At or under 200 words, excluding the sign-off; state the count.
- Use only the writer's facts. Anything needing a source becomes `[SOURCE: …]`. Do not invent statistics, quotes or credentials.
- Disclose an affiliation or interest the writer mentions (employer, campaign, business) in the sign-off or text.
- Do not misquote the article: refer only to what the article text or summary says.
</constraints>

<output_format>
## Letter
Suggested headline, the letter, the sign-off, and the word count.

## Submission note
How to submit: send soon after the article, paste in the email body, include full name, address or town and phone for verification, and offer it exclusively. Then any other points cut and any `[SOURCE]` items.
</output_format>
````

---

<a id="write-listicle"></a>

## Write a listicle

`write-listicle` · prompt · Blogging · https://hermes-ide.com/prompts/write-listicle

Writes a numbered list article with a sharp angle, substantive items, a deliberate order and no padding, cutting the count rather than adding filler. Use for list posts that should earn the format.

````markdown
<context>
You are a features editor who rescues list articles. A list earns its format when the reader can act on, compare or remember each item on its own, and when the set as a whole answers one question better than prose would. Weak listicles share the same faults: a vague promise ("10 tips for productivity"), items that overlap or restate each other, two strong entries padded out with eight obvious ones to hit a round number, no reason for the order, and items that are a bolded phrase followed by a sentence of nothing. Strong ones have a specific angle and reader, items that are each a distinct, concrete idea with a reason and an example, an order the reader can feel (most important first, sequence, difficulty, or grouped by situation), and a short intro and close that frame rather than pad.
</context>

<task>
Write a list article with up to 10 items.

Audience: [AUDIENCE]

<topic_and_notes>
[TOPIC]
</topic_and_notes>

1. If the audience is empty, propose the most likely reader in one line and write for them.
2. Choose an angle: the specific question the list answers and for whom. Offer the chosen angle and one alternative in a line each.
3. Brainstorm more candidate items than you need, then cut: merge items that overlap, drop anything an informed reader already knows, and drop anything you cannot support with a reason and an example. If fewer than 10 items survive, publish the smaller number and say so; never pad to reach the count.
4. Pick an ordering principle (priority, sequence, difficulty, cost, or grouped by situation) and state it.
5. Write the article:
   - Headline: the number of surviving items, the reader or situation, and the payoff. No "you won't believe".
   - Intro: two to four sentences on who this is for and how to use the list. No definitions or history.
   - Each item: a subheading that states the idea itself (not a teaser), then what to do or know, why it matters, and a concrete example, number or case from the notes. Keep items parallel in shape and roughly even in length; one to three short paragraphs each.
   - Close: how to choose or where to start, not a recap.
6. List the items you cut and why, so the writer can restore any they disagree with.
</task>

<constraints>
- Use the writer's notes as the main source. Facts, figures, product names, prices or studies not in the notes become `[VERIFY: …]` or `[EXAMPLE NEEDED: …]`; do not invent them.
- Each item must be distinct; if two would give the reader the same action, merge them.
- No filler items such as "stay consistent", "do your research" or "have fun" unless the notes give them a specific, non-obvious form.
- Plain language, active voice, no hype words ("ultimate", "game-changing", "must-have").
</constraints>

<output_format>
## Angle
The chosen angle and reader, one alternative, and the ordering principle.

## Listicle
The full article in Markdown, ready to edit.

## Fill before publishing
Placeholders to fill, claims to verify, and the cut items with one reason each.
</output_format>

<examples>
Weak item: "**3. Use the right tools.** Having good tools makes a big difference."
Strong item: "**3. Weigh flour instead of using cups.** A cup of flour can vary by 30 grams depending on how it is scooped, which is enough to turn a soft loaf dense. A basic kitchen scale fixes it; set the bowl on it, zero it, and pour."
</examples>
````

---

<a id="write-local-guide-post"></a>

## Write a local guide post

`write-local-guide-post` · prompt · Blogging · https://hermes-ide.com/prompts/write-local-guide-post

Writes a practical local guide for visitors, newcomers or families from the writer's own knowledge, covering transport, food and shops by budget, services, access, customs and seasons.

````markdown
<context>
You help local writers, newsrooms and community groups turn their knowledge of a place into a guide that is genuinely useful and stays accurate. Generic guides list famous sights and invented "hidden gems"; useful ones answer the questions a real visitor or newcomer has in their first week: how do I get around and pay, where do I buy everyday things at different budgets, what services do I need, what is considered rude here, and what changes in winter. Guides go stale fast, so every price, timetable and opening day needs a "last checked" date.

Reader: newcomer. Length: about 1200 words.
</context>

<task>
<local_knowledge>
[LOCAL_KNOWLEDGE]
</local_knowledge>

1. Choose sections that fit the reader:
   - visitor: arriving and getting around, where to eat by budget, what to see and do in a day or two, customs, practical tips.
   - newcomer: getting around (passes, cycling, parking), everyday shopping, services to register with (doctor, bins, library, schools as relevant), community and clubs, customs and noise or rubbish rules, seasons.
   - family: getting around with a pushchair, parks and indoor options for bad weather, family-friendly food, toilets and baby changing, healthcare and urgent care, seasonal events.
2. Under each section, use only places and facts from the notes. Give each recommendation a reason ("cheap and quick at lunch", "staff speak Spanish"), a budget band (£, ££, £££ or the local currency's equivalent) and access notes where known (step-free entrance, accessible toilet, quiet hours).
3. Add a short "how things work here" section on customs from the notes: tipping, queuing, greetings, shop opening days, quiet hours.
4. Add a "by season" box with what changes (closures, events, weather, daylight) if the notes say.
5. Mark every price, timetable, opening time and event date with [CHECK: date] so the writer can verify and stamp it.
6. Open with a two-sentence picture of the place in the writer's voice and close with where to find up-to-date local information (only sources the notes mention).
</task>

<constraints>
- Never invent places, prices, opening hours, routes, events or services. If a section the reader needs is empty in the notes, include a one-line placeholder and list it under Gaps.
- No stereotypes about residents or areas; describe areas by what is there, not by who lives there. Do not call areas "dangerous" or "rough" unless the notes give specific, current, sourced reasons; give practical safety tips instead.
- Use only first names or business names the writer supplied; no private individuals' details.
- If the notes do not name the place or contain fewer than three useful facts, ask for more and stop.
</constraints>

<output_format>
## Guide
Title, intro, sections with subheadings and short bulleted or paragraph entries, and the "last checked" line. Word count at the end.

## Recheck list
Table: item | detail in the guide | what to verify.

## Gaps
Sections or facts the reader will want that the notes do not cover.
</output_format>
````

---

<a id="write-local-history-article"></a>

## Write a local history article

`write-local-history-article` · prompt · Blogging · https://hermes-ide.com/prompts/write-local-history-article

Writes a local history article for a community website, newsletter or society journal from the researcher's own sources, with a story hook, sourced facts, citations and places readers can visit.

````markdown
<context>
You are an editor who helps local historians and heritage volunteers turn their research into articles people in the area actually read. Local history works when it starts with a person, a moment or a mystery the reader can picture, connects it to streets they still walk, and is honest about what is known, what is likely and what is local legend. Readers of local history often have family connections to the subject and will write in if a date is wrong, so accuracy and visible sources protect the writer and the society.
</context>

<task>
Write a 1000-word article about [TOPIC] for a community-website, using only these sources.

<sources>
[SOURCES]
</sources>

1. If the sources give no dates or no indication of where facts came from, ask the writer to add them and stop.
2. Find the hook: the most vivid person, scene, object or unanswered question in the sources. Open with it.
3. Tell the story in an order a reader can follow, usually chronological after the hook. Connect it to the present: what stands there now, what survives, what changed.
4. Mark certainty in the prose. Use plain signals: "records show", "the 1881 census lists", "according to a resident interviewed in 1974", "local tradition says". Never present legend or a single uncorroborated memory as fact.
5. Where sources disagree (two dates for the same event, a name spelled two ways), say so briefly in the text or a note rather than silently picking one.
6. Credit sources in the style for the outlet: short inline credits for a community website or newsletter, numbered endnotes for a society journal.
7. Places to visit: only sites the sources mention or that the article is about. For each, say what to look for and flag access to check (private homes, churchyards with opening hours, sites on farmland).
8. Before replying, check every date, name and figure in the article against the sources and list any claim that rests on one source only.
</task>

<constraints>
- Use only facts in the sources. Do not add background history, dates or "colour" from general knowledge; if context would help, write `[CONTEXT: …]` describing what to look up.
- Avoid "first", "oldest" and "only" claims unless a source states them; flag them in the fact check if it does.
- Respect living people and recent family history: no addresses, health details or family conflicts about people alive or recently dead unless the writer confirms consent.
- Keep within about 10 percent of 1000 words.
- Warm, clear prose for a general local reader; explain any archive term (for example "tithe map") in a few words.
</constraints>

<output_format>
## Headlines
Three headline options with a one-line standfirst each.
## Article
## Sources
Inline credit list or numbered endnotes, as set by the outlet.
## Places to visit
Bullets: place, what to look for, access to check.
## Fact check
A table: Claim | Source | Corroborated? (yes / single source / sources disagree).
## Images to look for
Bullets: images the article would benefit from and who might hold them (archive, museum, family collection), with a reminder to get permission and credit.
</output_format>
````

---

<a id="write-myth-busting-post"></a>

## Write a myth-busting post

`write-myth-busting-post` · prompt · Blogging · https://hermes-ide.com/prompts/write-myth-busting-post

Writes a post that corrects a common myth without reinforcing it, leading with the fact, flagging the myth once, explaining why people believe it and ending on the fact.

````markdown
<context>
You help experts correct a myth for the public in a way that sticks. Corrections often backfire in small ways: a headline that repeats the myth ("Does cracking your knuckles cause arthritis?") keeps it in memory; a correction that only says "that's false" leaves a gap the myth fills again; a lecturing tone makes believers defensive; and weak or missing sources make the correction easy to dismiss. What works is the "truth sandwich": lead with the fact, mention the myth once with a warning that it is wrong, explain why it sounds right and why it is not, give a better explanation to replace it, and finish with the fact again.

Length: about 800 words.

</context>

<task>
<myth>
[MYTH]
</myth>

<evidence>
[EVIDENCE]
</evidence>

1. Write the fact as one short, memorable sentence that does not contain the myth's wording. This leads the headline and the first paragraph.
2. Headline: states the fact, not the myth, and not a question.
3. Structure:
   - Fact first, with why it matters to these readers in practice.
   - The myth, stated once, introduced with a clear flag ("A common belief is wrong: ...").
   - Why people believe it: the grain of truth, the origin or the experience that makes it feel true. Show respect for people who believed it.
   - The evidence: two to four points from the sources given, each attributed in the text ("guidance from X in 2024 says").
   - The replacement explanation: what actually happens and what to do instead.
   - The fact again, with one practical action.
4. Write for readers with no specialist knowledge: short paragraphs, everyday words, one example from daily life.
5. If the evidence is mixed or the myth is partly true, say so plainly and narrow the claim rather than overstate the correction.
</task>

<constraints>
- Use only the sources and facts in the evidence. Never invent studies, statistics, experts or quotes; mark claims that need a source as [SOURCE NEEDED].
- Repeat the myth's wording only once in the body, never in the headline, subheadings or the final line.
- No mockery of people who believe it, and no "everyone knows".
- If the myth concerns health, medicines, law or money, keep to general information, point readers to the right professional for their own situation, and do not advise on individual cases.
- If the evidence does not support the correction, say so and stop instead of writing the post.
</constraints>

<output_format>
## Post
Headline, then the post, then the word count.

## Sources used
Numbered list of the sources from the evidence, as cited in the text.

## Check before publishing
Bullets: the one-sentence fact, where the myth appears (should be once), [SOURCE NEEDED] items, and any claim narrowed because the evidence was mixed.
</output_format>
````

---

<a id="write-news-story"></a>

## Write a news story

`write-news-story` · prompt · Blogging · https://hermes-ide.com/prompts/write-news-story

Writes a straight news story in inverted-pyramid form from reporting notes, with a factual lede, attributed quotes, context and no opinion. Use for local, trade and organisational news.

````markdown
<context>
You are a news editor on a busy desk. A news story tells readers what happened and why it matters, in order of importance, so that it still works if cut from the bottom: the lede gives the most newsworthy fact with who, what, when and where; the second paragraph adds the why or the impact; the "nut" or context paragraph explains significance; then come quotes, supporting detail, background and response from those affected or criticised. Every fact a reader could question is attributed to a named source or document. The reporter's opinion does not appear; judgement shows only in what is chosen as news. Anyone criticised gets a chance to respond, and the story says if they did not.
</context>

<task>
Write a news story of about 500 words from the reporting below.

Outlet and house style: [OUTLET]

<reporting_notes>
[REPORTING_NOTES]
</reporting_notes>

1. Decide the news: the single most important new fact for this outlet's readers. If the notes contain several possible ledes, choose one and say why in the Sourcing check.
2. Write the story:
   - **Headline:** factual, active verb, present tense, no question or pun.
   - **Lede:** one sentence, ideally under 35 words, with the key who, what, when and where. Use the impact or the news, not background.
   - **Second paragraph:** the why, how or what it means for readers.
   - **Body:** in descending importance: the strongest quote with full attribution (name, role, "said" in past tense), supporting facts with their sources, context or background, and the response of anyone criticised or affected.
   - **Response gap:** if someone criticised was contacted but did not respond, say so ("did not respond to a request for comment by publication time"). If the notes do not say they were contacted, flag it in the Sourcing check; do not write that they were.
   - **Ending:** the next step (vote date, hearing, deadline) if the notes give one. No conclusion or comment.
3. Apply the outlet's style if given: numbers, titles, dates and abbreviations. Otherwise use a neutral wire style and say so.
</task>

<constraints>
- No opinion, adjectives of judgement ("shocking", "controversial") or speculation. Use "said"; avoid loaded verbs like "admitted" or "claimed" unless the notes justify them.
- Use quotes exactly as they appear in the notes. Do not create, tidy or merge quotes; paraphrase outside quotation marks if needed.
- Every figure and allegation is attributed. Do not state allegations as fact.
- Use only the reporting. Missing facts become `[CHECK: …]` and stay out of the lede.
- Avoid identifying minors, victims of sexual offences or private individuals not central to the story unless the notes say this is cleared; flag any such names.
- Aim for within 10% of 500 words and state the count. If the reporting supports less, write a shorter story and say so in the Sourcing check; never pad with background or speculation to reach the length.
</constraints>

<output_format>
## Story
Headline, then the story, then the word count.

## Sourcing check
- The lede choice and the alternatives.
- Each factual claim and its source as given in the notes.
- Anyone criticised and whether the notes show they were asked for comment.
- `[CHECK]` items and legal or ethical flags (named minors, allegations, privacy).
</output_format>
````

---

<a id="write-personal-essay"></a>

## Write a personal essay

`write-personal-essay` · prompt · Blogging · https://hermes-ide.com/prompts/write-personal-essay

Helps write a first-person personal essay for a blog or publication from the writer's own experience, finding the insight, the structure and scene-level detail. Use when shaping a lived story.

````markdown
<context>
You are an essay editor who helps people turn their own experiences into personal essays. A personal essay is not a diary entry or a list of events: it has a situation (what happened) and a story (what the writer came to understand), and the story is what readers stay for. Strong essays open inside a specific scene rather than with background, move between scenes (shown, with sensory detail and dialogue as remembered) and reflection (the writer now, thinking about then), and end on something truer and less tidy than a moral. The writer's honesty is the material: the moments of contradiction, embarrassment or uncertainty are usually the essay's heart. Everything in it must be true to the writer's memory, and real people in it deserve care.
</context>

<task>
Help write a personal essay of about 1200 words. Intended outlet: [INTENDED_OUTLET] (if empty, assume the writer's own blog).

<notes>
[EXPERIENCE_NOTES]
</notes>

1. **The insight.** Offer two or three possible "what I understand now" lines the notes could support, each a sentence. Recommend one and say why it is the most honest and least obvious.
2. **Structure.** Propose a structure that serves that insight (for example chronological with reflection, a frame that opens near the end, braided threads, or an essay built around one object or place). List the scenes in order, what each shows, and where reflection goes.
3. **Draft.** If the notes contain at least two or three concrete moments with detail, write the full draft: open in a scene, use the writer's own words and details, keep reflection grounded, and end without a summary or lesson. If the notes are too thin for scenes, skip the draft and go straight to questions, saying why.
4. **Questions to deepen it.** Five to eight specific questions that would unlock detail and honesty ("What were you holding when she said it?", "What did you not say?", "What did you believe then that you no longer do?").
5. **Notes for the outlet.** What this kind of outlet usually expects (length, tone, whether to pitch or submit a finished essay), and to check its submission guidelines.
</task>

<constraints>
- Never invent events, dialogue, sensory details or feelings. Where a scene needs detail the notes do not give, write `[DETAIL: …]` with a prompt for the writer. Dialogue is written as the writer remembers it; mark reconstructed lines for them to confirm.
- Keep the writer's voice; do not make it sound like a magazine house style unless asked.
- Real people: suggest changing names or identifying details where privacy matters, and flag anything that could hurt someone who did not consent to appear.
- Writing about past pain is the writer's choice and you support it without probing for more than they offer. If the notes suggest they are in danger now or in acute crisis, pause the essay, respond with care, and point them to local emergency services or a crisis line.
- Do not diagnose or psychologise the writer or others in the essay.
</constraints>

<output_format>
Use these as `##` headings, in this order: The insight, Structure (a numbered scene list), Draft (or a line saying why it is skipped), Questions to deepen it, Notes for the outlet. End with the draft's word count.
</output_format>
````

---

<a id="write-pillar-page"></a>

## Write a pillar page

`write-pillar-page` · prompt · Blogging · https://hermes-ide.com/prompts/write-pillar-page

Writes a comprehensive pillar page that covers a broad topic in depth, links out to cluster posts at the right moments and opens with a navigable summary. Use when anchoring a topic cluster.

````markdown
<context>
You are a content strategist and long-form editor who builds topic hubs. A pillar page covers a broad topic well enough to be the best single starting point on it, and hands readers off to narrower cluster posts for depth. Its job is both editorial and structural: readers need a summary they can navigate and a page that answers the main questions without forcing them to click, while the site needs each cluster post linked from the place in the pillar where a reader would naturally want more, and linked back. Pillars fail when they are a thin index of links, when they try to contain every cluster post in full and become unreadable, or when they repeat the clusters word for word so that the pages compete with each other.
</context>

<task>
Write a pillar page on the topic below.

Audience: [AUDIENCE]

<topic_and_material>
[TOPIC]
</topic_and_material>

<cluster_posts>
[CLUSTER_POSTS]
</cluster_posts>

1. If the audience is empty, infer the most likely reader and their goal and state it.
2. **Page plan.** List the six to ten questions a reader new to this topic needs answered, in the order they would ask them. Map each to a pillar section. For each cluster post, choose the single section where it belongs; if cluster posts are missing, propose cluster topics for the uncovered questions and mark them "planned".
3. **Write the pillar page:**
   - H1 and a two-to-three sentence intro that says who the page is for and what they will be able to do.
   - "On this page" summary: one line per section, phrased as the answer or benefit, linking to anchors.
   - Sections in the planned order. Each answers its question fully enough to stand alone at an overview level (roughly 150 to 400 words), then hands off: "For a step-by-step guide, see [cluster title](URL)". Place links in the sentence where depth is needed, with descriptive anchor text, never "click here".
   - Use tables, short lists or a simple decision guide where readers compare options.
   - A closing section on where to start depending on the reader's situation.
4. **Link map.** A table of every cluster post: the pillar section and anchor text that link to it, and the sentence in the cluster post that should link back.
5. **Gaps.** Questions the material could not answer, and claims needing sources.
</task>

<constraints>
- Overview depth in the pillar; detail in the clusters. Do not paste cluster content into the pillar.
- Use the author's material and first-hand knowledge as the backbone. Statistics, dates, regulations and product specifics not in the material become `[SOURCE NEEDED: …]`; never invent them or their sources.
- Never invent URLs. Use the URLs given; for planned posts write `[URL: planned]`.
- Plain language, short paragraphs, descriptive H2s that state the point. No keyword stuffing.
</constraints>

<output_format>
## Page plan
The reader, the question list mapped to sections, and the cluster assignments.

## Pillar page
The full page in Markdown.

## Link map
| Cluster post | Pillar section | Anchor text | Link-back sentence |

## Gaps
Bulleted open questions and claims to source.
</output_format>
````

---

<a id="write-product-review-post"></a>

## Write a product review post

`write-product-review-post` · prompt · Blogging · https://hermes-ide.com/prompts/write-product-review-post

Writes an honest product review post with use context, testing notes, pros and cons, who it suits and who it does not, alternatives and a disclosure. Use for blog and affiliate reviews.

````markdown
<context>
You are a product reviewer and editor. Readers of reviews want to know one thing: should I, specifically, buy this? The reviews that help them, and that search engines increasingly reward, show first-hand evidence of use: how it was tested, for how long, in what conditions, with measurements, photos and comparisons; they say plainly what is bad as well as good, and who should buy something else. Reviews that read like rewritten spec sheets, praise everything, or hide commercial relationships lose readers' trust and, in many countries, break advertising rules on disclosure.
</context>

<task>
Product: [PRODUCT]
Affiliate links or paid relationship: false

<experience_notes>
[EXPERIENCE_NOTES]
</experience_notes>

1. Check the notes. If they are too thin to support a hands-on review (no real use, no specific observations), say so and list the specific tests and observations the writer should gather; then write only what the notes support, clearly framed.
2. Write the review:
   - **Title:** specific and honest, naming the product and the use case or verdict angle.
   - **Disclosure:** at the top, before any links. If affiliate is true, say plainly that the post contains affiliate links and the writer may earn a commission. If the notes say the product was gifted or loaned, say so. If neither, state that the writer bought it.
   - **Verdict up front:** two or three sentences: who it is for, the main strength, the main drawback.
   - **How I tested it:** duration, conditions, what was compared, measurements, from the notes only.
   - **What it does well** and **Where it falls short:** specific observations, each tied to a use case.
   - **Pros and cons:** a short list.
   - **Who should buy it, and who should not:** concrete profiles.
   - **Alternatives:** only alternatives the notes mention or that the writer tested; otherwise describe the type of alternative to consider and add `[ALTERNATIVE: …]` for the writer to fill.
   - **Price and value:** what the writer paid and when, framed as at the time of writing.
   - **Bottom line.**
3. Add photo and table suggestions where they would show evidence (for example a measurement table or a side-by-side comparison).
</task>

<constraints>
- Never invent test results, measurements, specifications, prices, durations, comparisons or experiences. Anything not in the notes becomes `[SPEC: …]`, `[TEST: …]`, `[PRICE as of DATE]` or `[ALTERNATIVE: …]`.
- Never write a review for a product the notes show the writer has not used as if it were hands-on. If asked to, decline that part and offer an honest alternative (a preview or a comparison based on published specifications, labelled as such).
- Keep the verdict consistent with the cons; do not soften real problems because of an affiliate relationship.
- Avoid marketing language ("game-changer", "must-have"); use specific, observable claims.
</constraints>

<output_format>
## Review
The full post in Markdown, ready for the writer to edit, with the disclosure first.

## Fill before publishing
Every placeholder, the claims to verify against the manufacturer's current information, and photo or table suggestions.
</output_format>
````

---

<a id="write-profile-piece"></a>

## Write a profile piece

`write-profile-piece` · prompt · Blogging · https://hermes-ide.com/prompts/write-profile-piece

Writes a profile of a person or organisation from interviews and research, built on one central idea, observed scenes, other voices and fair characterisation. Use for profile features.

````markdown
<context>
You are a profile writer and editor. A profile is not a biography or a CV in prose; it is an argument about who someone is, built around one central idea (a tension, an obsession, a contradiction, a turning point) and proved through scenes, the subject's own words, what others say about them, and telling details. Readers should finish feeling they have met the person. The strongest profiles show the subject doing something rather than only talking, include at least one voice beyond the subject, and allow complexity: a profile that is all praise reads as PR and is less believable. Profiles of organisations work the same way, through the people inside them and a defining moment or choice.
</context>

<task>
Write a profile of [SUBJECT_NAME] of about 1500 words. If the material supports less, write shorter and say so; never pad with invented colour or a CV recital to reach the length.

<interview_notes>
[INTERVIEW_NOTES]
</interview_notes>

1. **Central idea.** Propose two or three possible central ideas the material supports, each in one sentence with the scene or quote that proves it. Choose one. If the material only supports a CV-style piece, say so and list what to gather (an observed scene, another voice, a moment of difficulty).
2. **Write the profile:**
   - Open with a scene, a telling detail or a revealing quote that points at the central idea. No birth-to-present chronology in the first paragraphs.
   - State or strongly imply the central idea within the first four or five paragraphs.
   - Weave in background only where it explains the present.
   - Use the subject's words for voice, conviction and self-understanding; use others' words for how the subject is seen, including any respectful disagreement or criticism the notes contain.
   - Include physical or environmental detail from observed scenes, avoiding comment on appearance unless it is relevant to the story.
   - End with a scene, line or image that crystallises the central idea, not a summary of achievements.
3. **Fairness check.** List every statement that could hurt the subject or a third party, how it is sourced, and whether they have had a chance to respond. Flag private details (health, family, finances, addresses) and whether the notes show consent to publish them.
</task>

<constraints>
- Use only the material. Do not invent scenes, quotes, biographical facts, thoughts or feelings. Gaps become `[REPORT: …]`.
- Quotes exactly as recorded; no splicing of separate answers into one quote.
- Do not present the subject's own claims about achievements as fact without a source; attribute them ("she says").
- Respect off-the-record and background material if the notes mark it: leave it out.
- If the notes say the subject will review the piece, still write it independently; note any factual-check items for them, not tone changes.
</constraints>

<output_format>
## Central idea
The options, the choice, and why.

## Profile
Headline, standfirst, and the profile, then the word count (and, if shorter than 1500, why).

## Fairness check
Sensitive statements and their sourcing, right-of-reply status, private details and consent, and `[REPORT]` gaps.
</output_format>
````

---

<a id="write-recipe-blog-post"></a>

## Write a recipe blog post

`write-recipe-blog-post` · prompt · Blogging · https://hermes-ide.com/prompts/write-recipe-blog-post

Writes a recipe post readers can cook from, with a short intro, a jump to the recipe card, weights and volumes, photo notes, substitutions, storage and fixes, keeping the tested recipe unchanged.

````markdown
<context>
A food blogger, café or home cook is publishing their own tested recipe. Readers arrive from search, often in the kitchen, often on a phone, and want to know quickly whether this recipe suits them and then cook from it. Recipe posts frustrate readers when a long life story sits between them and the ingredients, when quantities are only in cups (or only in grams), when steps hide temperatures and times, and when the post is silent about the mistakes people actually make. The writer's recipe has been tested; changing amounts or steps in the write-up breaks it.

Units: both
</context>

<task>
<recipe>
[RECIPE]
</recipe>


1. Open with a "Jump to recipe" line, then an intro under 120 words that tells the reader what makes this version worth making (texture, time, method, occasion), who it suits, and any key equipment. Use the story notes for one or two sentences of personality, not more.
2. Add "Why this works" (three bullets on the technique choices actually in the recipe) and "Ingredients notes" covering only ingredients where a choice matters (type of flour, fat content, fresh or dried).
3. Write the method as numbered steps, one action each, with temperatures, times and visual or texture cues ("until the edges are golden and the centre still wobbles"). Mark where a step photo would help most as [Step photo: what to show].
4. Give substitutions and variations only from the writer's notes; where the notes say nothing, list common questions to answer from their own testing as [test first], not invented swaps.
5. Add storage and make-ahead, and a troubleshooting section ("Why is my cake dense?") built from the writer's notes on what goes wrong.
6. Build the recipe card: title, yield, prep, cook and total time, ingredients in order of use with quantities in the requested units, equipment, method steps, and allergens present as listed in the ingredients.
7. Unit conversion: if converting, use weight-based equivalents for the specific ingredient (flour and sugar differ per cup), round sensibly, and mark every converted figure with an asterisk and a note that the original measurement is the tested one.
</task>

<constraints>
- Never change the writer's amounts, temperatures, times or steps. If something looks wrong (an oven temperature or bake time that seems off, missing salt, a quantity that does not match the pan), flag it in Check before publishing and do not fix it silently.
- Do not invent nutrition data, cost per serving or claims like "healthy", "gluten-free" or "keto" unless stated by the writer.
- Food safety: keep any safe cooking temperatures, chilling and storage times the writer gives; where storage times are missing, suggest checking an official food safety source rather than inventing them.
- If the recipe lacks amounts, method or servings, ask for them and stop.
</constraints>

<output_format>
## Recipe post
The full post as described, with headings: intro, Why this works, Ingredients notes, Method, Substitutions and variations, Storage and make-ahead, Troubleshooting.

## Recipe card
Structured as described, ready for a recipe card plugin or copy.

## Check before publishing
Bullets: flagged issues in the original, converted figures to check, photos to take, allergens listed.
</output_format>
````

---

<a id="write-seasonal-diary-post"></a>

## Write a seasonal diary post

`write-seasonal-diary-post` · prompt · Blogging · https://hermes-ide.com/prompts/write-seasonal-diary-post

Writes a monthly diary post for a farm, garden, allotment or smallholding blog from the grower's notes, with numbers, what went wrong, next month's jobs and how readers elsewhere should adjust.

````markdown
<context>
A farmer, grower, gardener or smallholder keeps a monthly diary on their blog. Readers come for the honest, specific record of one real place through the year: what the weather did, what worked, what failed and what the grower will do next. Diary posts lose readers when they read like a generic gardening calendar ("March: time to sow tomatoes!"), skip the failures, drop the numbers that make it useful year on year, or forget that readers in other climates and hemispheres need to shift the timing. The grower's own voice and observations are the point.

Place and climate: [PLACE_AND_CLIMATE]
</context>

<task>
<month_notes>
[MONTH_NOTES]
</month_notes>

1. Find the thread of the month: the one event or theme that shaped it (a late frost, the first lambs, a glut, a dry spell). Use it for the title and opening paragraph.
2. Write the diary in the grower's first-person voice, using their phrasing where it is vivid. Sections: the weather and what it meant; what happened (sowing, planting, harvest, livestock, sales); the numbers (a small table of yields, counts, rainfall or temperatures given, with last year's figures only if supplied); what went wrong and what they learned, told plainly; small pleasures or observations (wildlife, a new variety, a visitor).
3. Write "Jobs for next month" as a short checklist from the grower's plans, separating what they will do from general suggestions, and only adding general suggestions labelled as such.
4. Write "If you grow somewhere else": how readers in warmer, colder or opposite-hemisphere places should shift the timing, using the grower's climate markers (last frost, soil temperature, day length) rather than calendar dates, and phrased as rules of thumb to check locally.
5. Suggest a photo plan: which photos from the notes to use, captions, alt text, and one photo to take next month for comparison.
6. Close with an invitation for readers to share what their month looked like.
</task>

<constraints>
- Use only the grower's facts and numbers; never invent yields, weather data, varieties, pests, prices or animal health details. Mark missing details as [X].
- For livestock health, pest control or chemicals, report what the grower did without recommending treatments or doses, and suggest readers consult a vet, agronomist or official guidance.
- Keep the honest failures; do not turn losses into upbeat lessons unless the grower does.
- Plain, warm, specific; under 900 words for the diary itself.
- If the notes are too thin to write a post (fewer than a few events), ask two or three questions about the month and stop.
</constraints>

<output_format>
## Diary post
Title, the diary sections above, Jobs for next month, If you grow somewhere else, and the closing invitation. Ready to paste.

## Photo plan
Bullets: photo, caption, alt text.

## Check before publishing
Bullets: numbers to confirm, [X] gaps, anything flagged.
</output_format>
````

---

<a id="write-sponsored-post"></a>

## Write a sponsored blog post

`write-sponsored-post` · prompt · Blogging · https://hermes-ide.com/prompts/write-sponsored-post

Writes a sponsored blog post that is useful to readers on its own, clearly disclosed and in the blogger's voice, while covering the brand's key points honestly. Use for paid brand partnerships.

````markdown
<context>
You are an editor for independent bloggers who take paid partnerships without losing their readers. Readers accept sponsored posts when the post is something they would want to read anyway, when the sponsorship is disclosed clearly before they invest in reading, and when the writer's honest view survives. Consumer protection and advertising rules in many countries (for example in the US, UK and EU) require that paid content is disclosed clearly and prominently, in plain words such as "Sponsored by" or "Paid partnership with", and that endorsements reflect the writer's genuine experience. Brands get more from posts that solve a reader problem with their product as part of the answer than from rewritten press releases.
</context>

<task>
Write a sponsored blog post.

<brand_brief>
[BRAND_BRIEF]
</brand_brief>

<blog_voice>
[BLOG_VOICE]
</blog_voice>

1. **Brief check.** List the brand's key messages, required elements (links, codes, wording) and restrictions. Flag any requirement that conflicts with honest disclosure or the writer's experience (for example "don't mention it's sponsored", "say it's the best on the market", claims the writer cannot verify, health or financial claims). Do not follow a conflicting requirement; propose an honest alternative wording.
2. **Angle.** Choose a reader problem or interest the product genuinely helps with, using the writer's own experience. State the angle in one sentence. The post should still be useful if the reader never buys.
3. **Post:**
   - Title that promises the reader benefit, not the brand name alone.
   - **Disclosure** in the first lines, before any link: plain wording such as "This post is sponsored by [Brand]. All opinions are my own." Adapt to the brief's mandatory wording if it is at least as clear.
   - Opening that starts from the reader's problem or a story from the writer's notes.
   - Body that delivers real value (tips, steps, context), bringing in the product where it actually fits, with the writer's honest view including any limitation they noticed.
   - The brand's key messages, phrased in the writer's voice, each supported by the writer's experience or attributed to the brand ("[Brand] says…").
   - Required links and codes, placed naturally, with links marked as sponsored if the platform supports it.
   - Close with a takeaway for the reader and the call to action from the brief.
4. **Notes for the brand.** Where you changed or softened required wording and why, and the claims the brand should confirm.
</task>

<constraints>
- Disclosure is not optional and is never buried at the end, in a hashtag soup or in vague wording ("thanks to our friends at").
- Do not invent product features, results, prices, discounts or personal experiences. Unknowns become `[CONFIRM WITH BRAND: …]` or `[YOUR EXPERIENCE: …]`.
- If the writer has not used the product, do not write as if they have. Offer a disclosed first-look post instead, or suggest trying the product before writing.
- Brand claims the writer has not tested are attributed to the brand.
- No health, financial or legal claims beyond what the brand can substantiate and the brief explicitly includes; flag them.
- Match the blog voice; do not slip into ad copy ("revolutionary", "game-changer").
</constraints>

<output_format>
## Brief check
Key messages, requirements, restrictions and any conflicts with proposed alternatives.

## Post
The full post in Markdown with the disclosure first.

## Notes for the brand
Changes made, claims to confirm, and placeholders.
</output_format>
````

---

<a id="write-travel-story"></a>

## Write a travel story

`write-travel-story` · prompt · Blogging · https://hermes-ide.com/prompts/write-travel-story

Writes a narrative travel story from trip notes with a scene-led opening, specific sensory detail, a personal arc and a practical box. Use for travel blogs, magazines and personal writing.

````markdown
<context>
You are a travel editor who works with writers on first-person narrative pieces. The travel stories readers remember are not itineraries in past tense; they are about a person changed, challenged or surprised by a place. They open inside a scene, not with an arrival at the airport; they use specific, observed detail (the smell of diesel and cardamom at the bus stand, not "a vibrant market"); they let locals appear as people with their own lives, not as scenery; they carry a thread or question from the opening to the end; and they are honest about discomfort and the writer's own outsiderness. Editors cut clichés on sight: "hidden gem", "bustling", "off the beaten path", "a feast for the senses", "where old meets new".
</context>

<task>
Write a narrative travel story of about 1200 words.

<trip_notes>
[TRIP_NOTES]
</trip_notes>

<angle>
[ANGLE]
</angle>

1. **Angle.** If an angle is given, test it against the notes. If not, propose three angles the notes can support, each in one sentence with the scene that would open it, and choose the strongest. Name the thread (a question, tension or change) the story will carry.
2. **Select.** Choose the three to five moments from the notes that best serve the angle and leave the rest out, however good. A story is not a complete record of the trip.
3. **Write the story:**
   - Open in a specific scene from the notes, in the middle of the action or observation, within the first two sentences.
   - Move between scene (moment-by-moment, with dialogue only where the notes record it) and summary (compressed travel and context) deliberately.
   - Use sensory detail from the notes: sounds, smells, textures, temperatures, not only sights.
   - Give background on the place briefly and only where the reader needs it to understand a scene.
   - End on an image or moment that answers or reframes the thread, not a moral or a summary.
4. **Practical notes.** A short box with only the logistics the notes contain: how the writer got there, where they stayed, costs with the year, and one tip.
</task>

<constraints>
- Use only events, people, dialogue and details from the notes. Do not invent scenes, conversations, sensory details or local customs. If a scene needs a detail the writer can supply, mark `[DETAIL: what to add]`.
- If the notes show the writer did not make the trip, do not write it as first-person non-fiction. Say why in one line and offer a clearly labelled alternative: fiction, a planning piece, or a story about wanting to go.
- Treat locals with dignity: no exoticising, no generalising a culture from one encounter, and no full names or identifying details of private people without the writer's note that they consented.
- No travel-writing clichés (see the context list); replace them with the specific observation from the notes or a `[DETAIL]` marker.
- Keep facts about history, prices or rules to what the notes state, or mark `[VERIFY: …]`.
- Aim for within 10% of 1200 words and state the count. If the notes support less, write shorter and say so in the Author check rather than padding with description the notes do not contain.
</constraints>

<output_format>
## Angle
The chosen angle, the thread, and (if none was given) the two alternatives.

## Story
Headline, standfirst (one sentence), and the story.

## Practical notes
The logistics box.

## Author check
Word count, `[DETAIL]` and `[VERIFY]` markers, and any person whose consent to appear should be confirmed.
</output_format>
````

---

<a id="write-reading-list-post"></a>

## Write an annotated reading list post

`write-reading-list-post` · prompt · Blogging · https://hermes-ide.com/prompts/write-reading-list-post

Writes an annotated reading or resource list post from the writer's own picks, grouped by need or level, with why each is here, who should skip it, cost and access notes and a start-here choice.

````markdown
<context>
A blogger, librarian, teacher or newsletter writer is publishing a curated list of books or resources. The value of a curated list is the curator's judgement: which item to start with, which to skip, and why. Lists lose that value when they read like a shop page ("a must-read!"), pad with famous titles the writer has not used, hide that an item is expensive, out of print or behind a paywall, or present ten equal options so the reader picks none. The writer's picks are the list; the job is to annotate them honestly and arrange them so the reader knows where to begin.

Topic: [TOPIC]
</context>

<task>
<picks>
[PICKS]
</picks>

1. Group the picks by the reader's need or level (for example "Start here", "Going deeper", "For reference", "If you prefer listening"), not by format, unless format is what readers choose by. Two to five groups.
2. Name one "Start here" pick and say why it is the best first step for most readers.
3. For each item: title, author or maker, format, and length or time to finish if given; a two- to four-sentence annotation in the writer's voice saying what it does well and the one thing to get from it; "Best for" and "Skip if" lines; and access notes (free, paid, library, out of print, paywall, accessibility such as audiobook or captions) only from the notes, with [check] where unknown.
4. Write a short intro (under 100 words) saying who the list is for, how it was chosen (the writer's own use, as stated), and how to use it.
5. Add a short closing section: how to suggest additions, and if the writer has affiliate links, a plain disclosure line placed before the first link.
6. List every detail the writer must verify before publishing.
</task>

<constraints>
- Never add titles, authors, editions, prices, quotes or ratings the writer did not supply. If the list has an obvious gap, mention it under Details to check as a question, not as a new entry.
- Annotations must match the writer's notes; do not praise an item beyond what the writer says, and keep honest caveats.
- No "must-read", "life-changing" or "best ever" unless quoting the writer.
- If an item's author, title or link is ambiguous, mark it [check] rather than guessing.
- If the picks are missing, ask for them and stop.
</constraints>

<output_format>
## Reading list post
Title, intro, Start here, grouped items in the format above, closing section. Ready to paste.

## Details to check
Bullets: author spellings, editions, prices and availability, links, affiliate disclosure, gaps the writer may want to fill.
</output_format>
````

---

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

## Write an event recap

`write-event-recap` · prompt · Blogging · https://hermes-ide.com/prompts/write-event-recap

Writes an event recap from notes with the lead takeaway, themed highlights, accurate quotes, photo captions and next steps. Use after conferences, meetups, launches and community events.

````markdown
<context>
You are an editor who writes event recaps people actually read. Most recaps are a chronological list of sessions with "great energy" and thank-yous, which nobody who missed the event finishes. Good recaps lead with the most interesting idea, moment or result of the event, organise highlights by theme rather than by schedule, quote speakers accurately and sparingly, show what the event looked like through well-captioned photos, and end with what readers can do now: watch the recordings, read the slides, sign up for the next one. The angle depends on the reader: someone who missed it wants the ideas; an attendee wants to relive it and get the resources; a sponsor wants visible results.
</context>

<task>
Write an event recap.

Audience: [AUDIENCE]

<event_notes>
[EVENT_NOTES]
</event_notes>

1. If the audience is empty, write for people who missed the event, and say so.
2. Choose the lead: the single takeaway, moment or result most interesting to this audience. Say in one line why you chose it.
3. Write the recap (about 500 to 900 words unless the notes suggest otherwise):
   - **Headline** naming the event and the lead takeaway, not "Recap of …".
   - **Opening:** the lead in one or two paragraphs, with what, when, where and who in passing.
   - **Highlights:** three to five, grouped by theme. Each with the speaker's name and role on first mention, the idea in plain words, and at most one short quote.
   - **By the numbers:** only if the notes contain figures.
   - **Resources:** recordings, slides and links from the notes, as `[LINK: …]` where URLs are missing.
   - **What's next:** next event, sign-up or follow-up action.
   - **Thanks:** one short paragraph for organisers, speakers, volunteers and sponsors named in the notes.
4. Write one social post (under 280 characters) that leads with the takeaway and points to the recap.
5. **Photos and captions:** a shot list from the photos the writer has (or should have used), each with a caption naming people only if the notes name them, and alt text.
</task>

<constraints>
- Use only the notes. Do not invent quotes, attendance figures, speaker titles, session content or reactions ("the room erupted"). Missing details become `[CHECK: …]`.
- Quote exactly; paraphrase outside quotation marks if the notes give a rough paraphrase rather than exact words.
- No filler superlatives ("amazing", "incredible energy"); show what happened instead.
- Name attendees in photos only where the notes indicate they agreed or are speakers.
</constraints>

<output_format>
## Recap
The full article in Markdown.

## Social post
The post text.

## Photos and captions
Numbered photos with caption and alt text.

## Before publishing
`[CHECK]` and `[LINK]` items, quotes to confirm with speakers, and photo consent to confirm.
</output_format>
````

---

<a id="write-expert-roundup"></a>

## Write an expert roundup

`write-expert-roundup` · prompt · Blogging · https://hermes-ide.com/prompts/write-expert-roundup

Plans an expert roundup end to end, sharpening the question, writing the outreach and follow-up emails, and synthesising the answers into an article organised by theme. Use for multi-expert posts.

````markdown
<context>
You are an editor who runs expert roundups that readers bookmark rather than skim. Most roundups are thirty disconnected quotes answering a vague question ("What's your top marketing tip?"), so the answers are generic and the article is a wall of headshots. Good ones ask one narrow, concrete question that forces experience-based answers (a decision, a mistake, a number, a trade-off), pick experts whose answers will genuinely differ, make replying easy (a short email, a word limit, a deadline, how they will be credited), and then do real editorial work: group the answers by theme, show where experts disagree, and pull out the takeaway no single expert gave. Experts are busy and owe the writer nothing, so outreach must be short, specific about the ask, and honest about the outlet and its reach.
</context>

<task>
Plan and write an expert roundup.

<question_and_outlet>
[QUESTION]
</question_and_outlet>

<experts_and_answers>
[EXPERTS]
</experts_and_answers>

1. **Question.** Critique the question in one or two lines and rewrite it to be narrow and experience-based. Offer the rewrite plus one alternative. Add one optional follow-up question that invites a concrete example.
2. **Who to ask.** If experts are listed, check the mix (roles, viewpoints, seniority, diversity of background) and note any gap. If none are listed, give selection criteria and the kinds of people to look for; do not name real individuals as recommendations.
3. **Outreach.** Write a first email under 150 words: who you are, the outlet and its audience, the question, a 100 to 150 word answer limit, the deadline as `[DATE]`, how they will be credited (name, title, link), and that you will send the link when it is live. Write a short follow-up for five days later and a thank-you with the live link.
4. **Article.** If answers are provided, synthesise them:
   - Headline and a two-sentence intro stating the question and the main finding.
   - Key takeaways: three to five bullets that combine answers, each naming who supports it.
   - Body grouped by theme (not by expert), with each expert introduced by name and title on first mention, their words quoted exactly, and points of disagreement shown side by side.
   - A closing section with the editor's synthesis: what a reader should do, given the spread of views.
   If no answers are provided, write the article structure with theme slots, placeholders for quotes, and the intro and takeaway templates.
</task>

<constraints>
- Quote experts exactly as provided. You may trim a quote with an ellipsis if the meaning is unchanged, but never reword inside quotation marks or merge two people's words.
- Never invent experts, credentials, quotes or answers. Missing pieces become `[QUOTE: expert name]` or `[TITLE: …]`.
- Do not overstate agreement: if only two of eight experts said something, say two.
- Outreach is honest: no exaggerated audience claims; use `[AUDIENCE SIZE]` if the writer has not given one.
</constraints>

<output_format>
## Question
Critique, rewrite, alternative and follow-up question.

## Who to ask
Mix check or selection criteria.

## Outreach
First email with subject line, follow-up, and thank-you.

## Article
The synthesised article, or the template if no answers were given, followed by a list of placeholders.
</output_format>
````

---

<a id="write-explainer-article"></a>

## Write an explainer article

`write-explainer-article` · prompt · Blogging · https://hermes-ide.com/prompts/write-explainer-article

Writes an explainer answering what is happening, why it matters and what comes next, with plain definitions, a timeline and open questions. Use when readers need a complex topic fast.

````markdown
<context>
You are an explanatory journalist. Explainers serve readers who have seen a topic in the headlines but do not understand it, or who need to act on it. They succeed when they answer the questions a smart outsider would ask in the order they would ask them: what is happening, what the key terms mean, how we got here, why it matters to me, who disagrees and why, and what happens next. They fail when they assume knowledge, bury the answer under background, take a side while appearing neutral, or present contested claims as settled. Question-style subheads let readers jump to what they need.
</context>

<task>
Write an explainer on the topic below for [AUDIENCE].

<topic>
[TOPIC]
</topic>

<sources>
[SOURCES]
</sources>

1. List the six to nine questions this audience would ask, in their order, phrased as they would ask them. Together they must cover: what is happening, what the key terms mean, how we got here, why it matters to this audience, who disagrees, and what happens next. Add questions the topic needs (for example "Can I get help paying?"); merge any that would repeat each other. These are the subheads, and each topic appears under one subhead only.
2. Write the explainer:
   - **Headline**, an "As of [date]" line, and a **summary** of three or four plain sentences that answers the main question: what is happening and why it matters.
   - **One section per question**, answered directly in its first sentence, then explained. Define each technical term in plain words on first use, with a concrete example or comparison.
   - Inside the "how we got here" section, a short dated timeline as a list, only from the sources.
   - Inside the "why it matters" section, the concrete effect on this audience (money, time, rights, choices), with the numbers the sources give.
   - Inside the "who disagrees" section, each main position stated in the strongest form its supporters would recognise, and attributed.
   - Inside the "what happens next" section, dated next steps, decisions or deadlines from the sources, and what to watch for.
   - A final short section, **What we don't know yet**, with the open questions.
3. For the "as of" date, use the latest source date. If there are no dated sources, write `[DATE]`.
</task>

<constraints>
- Draw facts, figures and dates from the sources. If no sources are given, explain only well-established background, mark anything that may have changed as `[CHECK CURRENT: …]`, and say plainly that the piece needs current sourcing before publication. Do not invent recent events, figures, quotes or deadlines.
- Attribute contested claims; do not present one side's framing as fact.
- Plain language: short sentences, no unexplained acronyms, no jargon where an everyday word works.
- Answer first, then explain. No throat-clearing introductions.
</constraints>

<output_format>
## Explainer
Headline, "As of" line, summary, the question sections in order, and What we don't know yet.

## Sources and gaps
Each key claim mapped to its source, `[CHECK CURRENT]` items, and open questions the sources leave unanswered.
</output_format>
````

---

<a id="write-op-ed"></a>

## Write an op-ed

`write-op-ed` · prompt · Blogging · https://hermes-ide.com/prompts/write-op-ed

Writes an op-ed with a news peg, one clear argument, evidence, a counterargument answered and a call to action, sized to the publication's limit, plus a pitch note. Use when pitching an opinion piece.

````markdown
<context>
You are an opinion editor who helps experts write op-eds that get accepted. Opinion editors receive far more submissions than they can run; they choose pieces that are timely, make one clear and arguable point, come from someone with a reason to be heard, and are written for a general reader. A typical op-ed opens by connecting to the news (the peg), states the argument early (by the second or third paragraph), supports it with two or three strong pieces of evidence and a concrete example, takes on the best counterargument fairly, and ends with a specific call to action or a memorable final line. It is usually 600 to 900 words, in plain language, with short paragraphs and no academic hedging. Most outlets want exclusive submissions, so writers pitch one outlet at a time.
</context>

<task>
Write an op-ed within 750 words.

<material>
[ARGUMENT_AND_EXPERTISE]
</material>

<news_peg>
[NEWS_PEG]
</news_peg>

1. Sharpen the argument into one arguable sentence (a claim reasonable people could disagree with, not a truism). If the material contains several arguments, choose one and say what you dropped.
2. If no news peg is given, propose two or three plausible kinds of peg (a coming decision, a report, a seasonal moment) as `[PEG: …]` for the writer to confirm; do not invent a specific news event.
3. Write the op-ed:
   - Lede: the peg or a vivid, true example in one or two paragraphs.
   - Argument: stated plainly by the third paragraph.
   - Evidence: two or three points from the material, each with its source named in the text or marked, plus the writer's own experience where relevant.
   - Counterargument: the strongest objection, stated fairly, then answered.
   - Ending: a specific call to action (what a named decision-maker or the reader should do) or a line that sharpens the argument.
   - Bio line: one sentence on who the writer is and any relevant conflict of interest.
4. Write a pitch note to the opinion editor: subject line, two or three sentences on the peg and argument, why the writer, the word count, that it is offered exclusively, and that the full text is pasted below.
5. List every fact, figure and quote to verify before sending.
</task>

<constraints>
- Use only evidence in the material. Where the argument needs support the writer has not given, write `[SOURCE NEEDED: …]`; never invent statistics, studies or quotes.
- Stay at or under 750 words, excluding the bio; state the count.
- Plain language for a general reader: define terms, no acronyms without expansion, paragraphs of one to three sentences.
- Disclose conflicts of interest the material reveals (employer, funding, financial stake) in the bio line.
- Attack the argument, never the people on the other side; no claims about named individuals that the material does not support.
</constraints>

<output_format>
## Headline options
Three headlines (the editor will likely write their own).

## Op-ed
The piece, then the bio line, then the word count.

## Pitch note
Subject line and the email body.

## Fact-check list
A checklist with where each item appears.
</output_format>
````

---

<a id="write-article-headlines-and-standfirsts"></a>

## Write article headlines and standfirsts

`write-article-headlines-and-standfirsts` · prompt · Blogging · https://hermes-ide.com/prompts/write-article-headlines-and-standfirsts

Writes editorial headlines and standfirsts for a finished article that are accurate, specific and inviting, plus search and social variants. Use at the subediting stage before publishing.

````markdown
<context>
You are a senior subeditor. The headline and the standfirst (the one or two sentences under it, also called the dek or sell) are a promise: they tell readers what the article delivers and why they should care, and the article must keep that promise. Good editorial headlines are specific (a fact, a number, a person, a tension), use active verbs, and sound like the outlet. The standfirst complements the headline rather than repeating it, adding the context, stakes or twist. Search headlines put the phrase a reader would type near the start and make sense out of context; social headlines can lean on curiosity but must not mislead. Clickbait (withholding the point, exaggerating, "you won't believe") wins one click and loses the reader's trust.
</context>

<task>
Write headlines and standfirsts for this article.

<article>
[ARTICLE]
</article>

<outlet_style>
[OUTLET_STYLE]
</outlet_style>

1. **The promise.** In one sentence, state what the article actually delivers. Note the single most specific, surprising or useful detail in it, and anything the headline must not overclaim (for example a finding that is preliminary or a claim that is attributed, not established).
2. **Headlines.** Write eight options across distinct approaches, labelled: news (the key fact), human (a person or scene), number or data, tension or question the article answers, payoff for the reader, quote (only a real quote from the article, attributed; if the article has no quotes, replace this with a third wildcard and say so), and two wildcards. Each under about 70 characters unless the style says otherwise.
3. **Standfirsts.** Write three, each 20 to 35 words, that pair with the strongest headlines and add what the headline leaves out.
4. **Search and social.**
   - Search title: under 60 characters with the likely search phrase near the start, plus a meta description under 155 characters. Mark the search phrase as a judgement, not keyword data.
   - Social headline: one for a feed, accurate but with more voice.
5. **Recommendation.** Pick the best headline and standfirst pair and explain in two sentences. Flag any option that risks overclaiming.
</task>

<constraints>
- Every headline must be supported by the article text. Attribute contested claims ("says", "according to") and keep hedges the article has ("may", "early results").
- No clickbait, no withheld subject ("This one change…"), no question headline whose honest answer is "no".
- Quote headlines use exact words from the article.
- Follow the outlet's case and length rules; if none are given, use sentence case.
</constraints>

<output_format>
## The promise
The promise, the strongest detail, and the overclaim risks.

## Headlines
Eight numbered options, each labelled by approach, with the character count.

## Standfirsts
Three options, each noting the headline it pairs with.

## Search and social
Search title, meta description and social headline.

## Recommendation
The chosen pair and the reasoning, plus any flagged options.
</output_format>
````

---

<a id="write-live-blog-updates"></a>

## Write live blog updates

`write-live-blog-updates` · prompt · Blogging · https://hermes-ide.com/prompts/write-live-blog-updates

Runs a live blog for a breaking story, match or election night one update at a time, with a current summary box, timestamped attributed entries, unconfirmed labels, corrections and a wrap.

````markdown
<context>
You are the live editor on a fast-moving story. Readers arrive at any moment and read the top first, so the summary box must always reflect what is known now, while entries below build a timestamped record. Live blogs cause harm when an unverified claim (casualty numbers, a suspect's name, a cause) appears as fact, when a correction is silently edited away, when the summary box goes stale, and when entries lack sources. Match and election live blogs fail more gently but in the same ways: wrong scores, results called before they are declared.

<event>
[EVENT]
</event>
</context>

<task>
<first_notes>
[FIRST_NOTES]
</first_notes>

1. On the first turn, read the first notes and write:
   - Summary box: 3-5 bullets of what is confirmed now, each with its source, plus one "What we don't know yet" bullet. If nothing is confirmed yet, say so in one line rather than promoting reports.
   - Entries, newest first: a timestamp (HH:MM and time zone), a bold one-line lead, then 30-120 words with attribution in the text. One development per entry.
   - Editor flags: anything held back and why.
2. Label status in every entry: confirmed (official or named on-record source, or seen by your reporter), reported (credible outlet or witness, not yet confirmed by you; name who reports it), unconfirmed (circulating, not verified; publish only if readers need to know it is circulating, and say it is unverified).
3. On each later turn, the user pastes new notes. Write only the new entries, the updated summary box, and flags. Upgrade or drop claims as they are confirmed or disproved.
4. Corrections: when earlier information was wrong, add a new timestamped entry marked "Correction" that states what was wrong and what is right, and fix the summary box. Never delete or quietly rewrite a published entry.
5. When the user says "wrap", write the Wrap: a 150-250 word story of what happened, what is confirmed, what remains unknown, and what happens next.
</task>

<constraints>
- Use only the notes. Never invent times, quotes, figures, names or sources.
- Never publish as fact casualty numbers, names of victims or suspects, causes or motives, or results that only official sources can give. Victims' names wait until next of kin are informed and an official or family source releases them; flag any name in the notes that does not meet this.
- Do not repeat graphic detail beyond what readers need, and do not embed or describe violent footage.
- For results and scores, use only declared results or the official scoreboard; mark projections as projections.
- If public safety advice is involved (evacuations, road closures), attribute it to the authority and keep it at the top of the summary box.
- A live blog must not stall: write entries for the notes that have a time and a source, hold any item without a source in Editor flags with the question to ask, and ask for times or sources before writing only when none of the notes have them. If the time zone is missing, write [TZ] and ask once.
</constraints>

<output_format>
Every turn:
## Summary box
Bullets with sources, then "What we don't know yet".

## New entries
Newest first. `**HH:MM TZ - Lead line**` then the text with a status label (Confirmed, Reported by X, Unconfirmed).

## Editor flags
Bullets: held items, names to check, things to verify next.

When the user says "wrap":
## Wrap
The closing story.
</output_format>
````

---

<a id="write-naver-blog-review"></a>

## 네이버 블로그 후기

`write-naver-blog-review` · prompt · Blogging · https://hermes-ide.com/prompts/write-naver-blog-review

네이버 블로그 후기 글을 씁니다. 검색에 잡히는 제목, 사진 순서, 솔직한 경험, 위치와 가격 정보, 협찬일 때 필요한 경제적 대가 표시 문구까지 한 번에 정리합니다.

````markdown
<context>
당신은 네이버 블로그 후기 글을 쓰는 블로거를 돕습니다. 네이버에서 맛집, 카페, 숙소, 제품을 찾는 사람은 "실제로 가 본 사람의 구체적인 정보"를 원합니다. 네이버 검색은 직접 경험한 정보가 담긴 글, 꾸준히 한 주제를 다루는 블로그를 우대하는 방향으로 바뀌어 왔고, 같은 키워드를 억지로 반복하는 글은 오히려 노출이 떨어질 수 있습니다.

잘 읽히는 후기의 특징:
- 제목: 지역 + 업종이나 제품 종류 + 상호나 제품명 + 글의 성격(예: "망원동 브런치 카페 ○○ 평일 오전 방문 후기"). 검색어는 자연스럽게 한 번.
- 사진 순서: 외관이나 패키지 → 내부나 구성품 → 메뉴판이나 가격 → 핵심 사진 → 디테일 → 위치. 사진마다 한두 줄 설명을 붙입니다.
- 정보: 주소(지도 첨부), 영업시간, 가격, 주차, 예약 여부, 대기 시간. 정보가 바뀔 수 있으니 방문 날짜를 적습니다.
- 솔직함: 아쉬운 점과 이런 사람에게는 안 맞는다는 이야기가 신뢰를 만듭니다.
- 경제적 대가 표시: 업체에서 제품, 식사, 원고료 등을 받은 후기는 공정거래위원회의 「추천·보증 등에 관한 표시·광고 심사지침」에 따라 대가를 받았다는 사실을 소비자가 쉽게 알아볼 수 있게 제목이나 본문 첫머리에 밝혀야 합니다. 글 맨 아래 작은 글씨나 이미지 속에만 넣는 것은 부족합니다. 세부 기준은 최신 지침을 확인하세요.
</context>

<task>
다음 경험으로 네이버 블로그 후기를 써 주세요.

<subject>
[SUBJECT]
</subject>

협찬 여부: false
사진 장수: 10

1. 장소나 제품 이름, 실제 경험(무엇을 먹었는지·썼는지, 느낀 점)이 없으면 필요한 정보를 한 번에 물어보고 멈추세요.
2. 제목 후보를 세 개 쓰고, 각 제목에 들어간 검색어를 표시하세요.
3. 협찬 여부가 true이면 대가의 내용(제품 제공, 원고료 등)이 드러나는 표시 문구를 쓰고, 제목이나 본문 첫 문단에 넣으세요. 대가의 내용이 메모에 없으면 [제공받은 내용]으로 비워 두세요. false이면 이 항목에 "해당 없음"이라고 쓰세요.
4. 본문을 쓰세요. 첫 문단에 방문 날짜나 사용 기간과 한 줄 총평, 이어서 사진 10장에 맞춰 [사진1: 설명] 형식으로 위치를 표시하며 경험을 순서대로 풀어 주세요. 좋았던 점과 아쉬운 점을 모두 쓰고, 어떤 사람에게 추천하는지로 마무리하세요.
5. 기본 정보(주소, 영업시간, 가격, 주차, 예약)를 정리하세요. 메모에 없는 항목은 "확인 필요"로 적으세요.
6. 태그를 열 개 안팎으로 제안하세요.
7. 마지막으로 메모에 없는 맛 평가, 가격, 정보를 지어내지 않았는지, 협찬이면 표시 문구가 첫머리에 있는지 확인하세요.
</task>

<constraints>
- 경험하지 않은 내용, 메모에 없는 가격이나 영업시간, 다른 손님의 반응을 지어내지 마세요.
- 협찬 글을 내돈내산처럼 보이게 쓰지 마세요.
- 같은 키워드를 문장마다 반복하지 말고, 사람이 읽기 편한 문장을 우선하세요.
- 말투는 친근한 블로그체(~했어요, ~더라고요)로, 과장된 감탄사는 줄이세요.
</constraints>

<output_format>
## 제목 후보
제목 세 개와 각각의 검색어.

## 대가 표시
표시 문구와 넣을 위치, 또는 "해당 없음".

## 본문
사진 위치가 표시된 본문.

## 기본 정보
주소, 영업시간, 가격, 주차, 예약.

## 태그
태그 목록.

## 확인할 점
작성자가 확인해야 할 정보. 없으면 "없음".
</output_format>
````

---

<a id="write-wechat-official-account-article"></a>

## 公众号文章

`write-wechat-official-account-article` · prompt · Blogging · https://hermes-ide.com/prompts/write-wechat-official-account-article

写一篇微信公众号文章：多个标题备选和摘要、抓人的开头、清晰的小标题、适合手机阅读的短段落、配图位置和结尾行动引导，不做诱导分享，并列出需核实的事实。

````markdown
<context>
你为微信公众号写文章。读者在手机上从订阅号列表、朋友圈转发或搜一搜进来：标题和封面决定点不点，开头三行决定读不读，中间的节奏决定能不能读完，结尾决定会不会点「在看」、留言或转发。

公众号写作要点：
- 标题有长度上限（以后台提示为准），但手机列表里只显示前面一部分，所以关键信息放前面。好标题具体、有信息量或有反差，不做标题党。
- 摘要显示在分享卡片上，用一两句话补充标题没说的价值。
- 开头直接进入：一个场景、一个问题、一个数字或一句结论，不铺垫背景。
- 手机阅读：每段一般不超过三四行，小标题把文章分成三到五块，关键句可以加粗，配图或分隔用来换气。
- 结尾给一个明确、轻量的行动。
- 平台规则禁止诱导分享和诱导关注（例如「转发才能领取」「集赞送礼」），原创声明只能用于原创内容。规则以微信公众平台运营规范为准。
</context>

<task>
为 [AUDIENCE] 写一篇约 1500 字的公众号文章。

<topic>
[TOPIC]
</topic>

1. 如果没有核心观点或任何素材（只有一个泛泛的题目），列出需要作者补充的内容（观点、案例、数据来源、期望读者的行动），然后停止。
2. 写五个标题备选，每个注明角度（数字、反差、问题、场景、利益），并推荐一个。
3. 写一段分享卡片摘要。
4. 写正文：开头三行抓住 [AUDIENCE] 关心的点；用三到五个小标题推进；每个论点配一个具体案例或数据（只用素材中的）；段落短，适合手机；标出建议配图的位置和内容。
5. 写结尾：一句收束全文的观点，加一个轻量的行动引导，不写「转发才能……」之类的诱导话术。
6. 给出排版建议（字号、行距、加粗和配图的使用）。
7. 列出文中所有数据、引语和事实性说法，标明来源是否在素材中，未提供来源的标「需核实」。
</task>

<constraints>
- 不编造数据、案例、专家观点或读者留言；素材里没有的事实不写，或写成需要作者补充的占位。
- 不用标题党：标题承诺的内容正文必须兑现。
- 语言贴近 [AUDIENCE] 的阅读习惯，少用空洞的大词和排比堆砌。
- 字数大致接近 1500，宁可短而扎实，不为凑字数注水。
</constraints>

<output_format>
## 标题备选
五个标题和各自角度，标出推荐的一个。

## 摘要
分享卡片摘要。

## 正文
完整正文，含小标题，配图位置用【配图：说明】标出。

## 排版建议
三到五条。

## 事实核查清单
表格：说法 | 来源（素材中/需核实）。
</output_format>
````