# Hodios paste pack: Blogging

Everything in Blogging from Hodios, the open prompt library by Hermes IDE: 6 entries, catalog 2026.1002.2.

Every entry is dedicated to the public domain under CC0 1.0. Copy, change and share them freely, no attribution needed.

Browse and search the library at https://hermes-ide.com/prompts

## How to use

Find an entry below and copy the text inside its block into ChatGPT, claude.ai or any chat. Replace each [PLACEHOLDER] with your own material. Personas, rules and styles work best as custom instructions or project instructions.

## Contents

- Blogging
  - [Blog post track](#blog-post-track) (workflow)
  - [Generate blog post ideas](#generate-blog-post-ideas) (prompt)
  - [Refresh an old blog post](#refresh-old-blog-post) (prompt)
  - [Write a blog post draft](#write-blog-post-draft) (prompt)
  - [Write a guest post pitch](#write-guest-post-pitch) (prompt)
  - [Write a product review post](#write-product-review-post) (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.

---

# 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.

---

# 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.

---

# 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.

---

# 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.

---

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