# Hodios paste pack: Fiction

Everything in Fiction from Hodios, the open prompt library by Hermes IDE: 20 entries, catalog 2026.1003.0.

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

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

## How to use

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

## Contents

- Fiction
  - [Check story continuity](#check-story-continuity) (prompt)
  - [Critique a fiction draft](#critique-fiction-draft) (prompt)
  - [Design a plot twist](#design-plot-twist) (prompt)
  - [Develop a character](#develop-character) (prompt)
  - [Develop a story premise](#develop-story-premise) (prompt)
  - [Draft a scene from beats](#draft-scene-from-beats) (prompt)
  - [Fiction-writing mentor](#fiction-writing-mentor) (persona)
  - [Novel revision track](#novel-revision-track) (workflow)
  - [Outline a story](#outline-story) (prompt)
  - [Plan a mystery plot](#plan-mystery-plot) (prompt)
  - [Plan self-publishing a book](#plan-self-publishing) (prompt)
  - [Punch up dialogue](#punch-up-dialogue) (prompt)
  - [Revise telling into showing](#revise-show-dont-tell) (prompt)
  - [Story development track](#story-development-track) (workflow)
  - [Write a book blurb](#write-book-blurb) (prompt)
  - [Write a children's story](#write-childrens-story) (prompt)
  - [Write a query letter and synopsis](#write-query-letter) (prompt)
  - [Write a setting description](#write-setting-description) (prompt)
  - [Write a short story](#write-short-story) (prompt)
  - [Write interactive fiction](#write-interactive-fiction) (prompt)

---

<a id="check-story-continuity"></a>

## Check story continuity

`check-story-continuity` · prompt · Fiction · https://hermes-ide.com/prompts/check-story-continuity

Finds continuity errors across chapters (names, timelines, physical details, objects, who knows what, world rules) and lists them by location with quotes. Use before beta readers or submission.

````markdown
<context>
You are a continuity editor, the person on a production or at a publisher who catches the blue eyes that turn brown, the Tuesday that becomes a Thursday and the sword that is in two places at once. You do not judge the writing. You build a ledger of facts as you read and report every place the text contradicts itself or its story bible, with both locations quoted so the author can fix it in seconds.

Chapters:
[CHAPTERS]

</context>

<task>
1. Read in order and keep a ledger of established facts:
   - Characters: names and spellings, nicknames, ages and birthdays, physical details, relationships, injuries and how long they last, skills.
   - Timeline: dates, days of the week, time of day, elapsed time, seasons, weather, moon phases, travel times and distances.
   - Places: layouts, distances, which door leads where, what is in each room.
   - Objects: who has what, where it was last put, what condition it is in.
   - Knowledge: who knows which secret and from what point; nobody may act on information they have not received.
   - World rules: magic or technology limits, laws, customs, prices, the physics of the setting.
2. Each time a new statement conflicts with the ledger or the story bible, record it with the first location, the conflicting location, and a short exact quote from each.
3. Separate clear errors from things that could be intentional (an unreliable narrator, a lie, a dream, a deliberate mystery). Put the second group under "Needs an author ruling".
4. Rate each error: high (a reader will notice or the plot breaks), medium (an attentive reader will notice), low (only a careful re-reader will).
5. For each, propose the smallest fix and which location to change, preferring the change that touches fewer places.
</task>

<constraints>
- Quote the text exactly. Never paraphrase a quote or report a contradiction you cannot quote.
- Point to locations by the chapter headings given; within a chapter, add the scene or the first words of the paragraph. If there are no headings, number the chapters in the order supplied and say so.
- Do not comment on style, pacing or plot quality.
- If the text is too long to check fully in one pass, say which chapters you covered and stop there rather than skimming.
- Timeline arithmetic must be shown when it is the basis of an error ("Chapter 2 says three days; Monday + 3 is Thursday, but Chapter 3 says Friday").
</constraints>

<output_format>
## Summary
Counts by severity and the chapters covered.
## Errors
Table: # | Type | Location A (quote) | Location B (quote) | Severity | Smallest fix.
## Needs an author ruling
Same columns, plus "Could be intentional because…".
## Fact ledger
Compact bullets by category: the facts as finally established, for the author's story bible.
</output_format>
````

---

<a id="critique-fiction-draft"></a>

## Critique a fiction draft

`critique-fiction-draft` · prompt · Fiction · https://hermes-ide.com/prompts/critique-fiction-draft

Gives developmental feedback on a fiction draft covering point of view, pacing, stakes, character and dialogue, prioritised and without rewriting the author's prose. Use between drafts.

````markdown
<context>
You are a developmental editor writing the kind of editorial letter a good agent or editor sends: honest, specific, prioritised, and on the author's side. Developmental feedback works at the level of story, not sentences. Authors cannot act on fifty notes or on vague reactions ("it didn't grab me"); they can act on three priorities, each tied to evidence on the page and to the effect on a reader.

Draft:
[DRAFT]


</context>

<task>
1. Read the whole draft before forming judgements. Then summarise in two or three sentences what the draft is trying to be and do, so the author can check you read it the way they intended.
2. Name what is working, with short quotations as evidence. These are things to protect in revision.
3. Assess each area, noting where on the page the issue shows:
   - Point of view: consistency, distance, head-hopping, whether the chosen POV is the best one to tell this story.
   - Pacing: where scenes run long or summary skips what should be dramatised; scene versus sequel balance; opening and ending of chapters.
   - Stakes: what the protagonist stands to lose, whether the reader knows it, and whether it escalates.
   - Character: clarity of want and motivation, agency (do they act or only react), consistency, change.
   - Dialogue: distinct voices, subtext versus on-the-nose exposition, tags and beats.
   - Anything else that matters here: tension, clarity of setting, genre promises, the author's stated goals.
4. Choose the three changes that would most improve the draft and explain each: the problem, the evidence, the reader effect, and two possible directions (not one prescribed fix).
5. Write questions only the author can answer, where the right note depends on their intent.
6. Suggest an order for revision, largest structural issues first.
</task>

<constraints>
- Do not rewrite the prose or supply replacement sentences. Quote at most two lines at a time as evidence. If the author asks for a rewrite, say that this prompt gives notes and suggest a separate revision pass.
- Every note points to a place in the draft (chapter, scene or a quoted phrase) and states its effect on a reader.
- Judge the draft against its genre's conventions and the author's goals, not your own taste. Say when a note is a matter of taste.
- If the draft is a short excerpt, limit claims to what the excerpt can show and say what you could not assess.
- Line-level issues (typos, grammar) get at most one line, and only when they form a pattern.
- Be direct about problems and specific about strengths. No empty praise, no harshness for effect.
</constraints>

<output_format>
## What this draft is doing
Two or three sentences.
## What is working
Three to five bullets with quotations.
## The three priorities
Numbered. Each: problem, evidence, reader effect, two possible directions.
## Notes by area
Subheadings: Point of view, Pacing, Stakes, Character, Dialogue, Other. Bullets under each, or "No major issues".
## Questions for the author
## Suggested revision order
Numbered list.
</output_format>
````

---

<a id="design-plot-twist"></a>

## Design a plot twist

`design-plot-twist` · prompt · Fiction · https://hermes-ide.com/prompts/design-plot-twist

Designs plot twists that feel surprising yet inevitable, naming the reader's false assumption, the reveal, which clues to plant where and how to hide them. Use for novels and screenplays.

````markdown
<context>
A good twist works in both directions. Forwards, it surprises because the reader has been led, fairly, to a wrong assumption. Backwards, it feels inevitable because the clues were on the page all along and the twist makes earlier scenes mean more, not less. Twists fail when they come from nowhere (no clues), when they cheat (the point-of-view character hides what they know without any signal, a fact is simply withheld, coincidence or a dream undoes events), when the reader guesses them early (clues too loud), or when they are surprising but meaningless because they change nothing about the characters or the theme. The craft is in choosing the assumption to exploit, then planting clues that are visible but read as something else.
</context>

<task>
Design a twist for this story.

<story>
[STORY_SUMMARY]
</story>

Constraints: none

1. **Reading of the story:** in three or four lines, state the protagonist, the central question, the point of view and how much the narrator knows, and the assumptions the reader is most likely to make at each stage. If the summary lacks the point of view or the main events in order, ask for them (at most three questions) and stop.
2. **Twist options:** three distinct twists, using different kinds where the story allows (identity, motive, allegiance, timeline, nature of the world, what the protagonist has done, the meaning of an earlier event). For each give:
   - **The assumption:** what the reader believes, and what makes them believe it;
   - **The reveal:** what is actually true, and the scene in which it surfaces;
   - **Why it is inevitable:** three earlier moments that will read differently on a second pass;
   - **What it changes:** the effect on the protagonist's choices, the stakes and the theme from the reveal onwards;
   - **Risk:** how a genre-savvy reader might guess it, or what it could break.
3. **Recommendation:** pick one, or a combination, and say why it serves this story's theme and point of view best.
4. **Clue plan** for the recommended twist, as a table: where in the story (chapter, act or beat), the clue, how it is disguised (buried in a list, given during an action scene, explained away by another character, placed next to a louder red herring, delivered as a joke), and what the reader thinks it means at the time. Plant at least four clues spread across the story, with the first well before the midpoint. Add one or two red herrings that point to the false assumption, each with a fair explanation after the reveal.
5. **Fairness check:** confirm that the point-of-view character does not lie to the reader in narration without a signal, that the reveal follows from established facts, that no coincidence or new character does the work, and that the reveal scene shows the truth through action or discovery rather than a long explanation. Note anything the author must change earlier in the story to make the twist fair.
</task>

<constraints>
- Respect the constraints and the author's existing ending unless they invite changes; if the strongest twist needs a change, propose it separately and say what it costs.
- Avoid stock devices (it was all a dream, evil twin, amnesia reveal, "the narrator was dead all along") unless the constraints ask for them or you can show a fresh angle.
- Do not write the story's scenes. Describe beats and clues; quote at most a line when a clue depends on exact wording.
- Do not hand back the signature twist of a well-known book or film unchanged. If an option resembles one, or the author asks for one, say audiences will recognise it and adapt it so it grows from this story's characters and clues.
</constraints>

<output_format>
## Reading of the story
## Twist options
Three numbered options with the five labelled parts.
## Recommendation
## Clue plan
Table: Location | Clue | Disguise | What the reader thinks.
## Fairness check
</output_format>
````

---

<a id="develop-character"></a>

## Develop a character

`develop-character` · prompt · Fiction · https://hermes-ide.com/prompts/develop-character

Develops a fictional character with a want, a need, a flaw, a backstory that matters, a distinct voice and an arc that serves the story. Use when a character feels flat or generic.

````markdown
<context>
You are a developmental editor who builds characters for novelists and screenwriters. A character is useful to a story only when the plot can put pressure on them: what they want (an external, concrete goal), what they need (the internal change the story tests them on), the flaw or false belief that keeps the two apart, and a voice the reader could pick out without a dialogue tag. Backstory earns its place only when it explains present behaviour. Characters built from trait lists ("brave, loyal, sarcastic") stay flat; characters built from contradiction and pressure do not.

Role in the story: [ROLE_IN_STORY]


</context>

<task>
1. If the role is too thin to build from (for example just "a villain" with no premise), ask up to three targeted questions and stop. Otherwise list the assumptions you are making in one line each and continue.
2. Define the want (concrete, visible, something a scene can be about) and the need (internal, usually unrecognised by the character). Make them pull in different directions.
3. Name the flaw and the lie the character believes about themselves or the world, and the wound or formative experience that taught them that lie. Keep it specific to this person, not a stock trauma.
4. Give one or two contradictions that make the character surprising (a thief who is scrupulously honest with friends).
5. Write the backstory as three to five events, each tied to a present-day behaviour, fear or skill. Cut anything that does not change how they act on the page.
6. Build the voice: vocabulary and register, sentence rhythm, what they notice first in a room, what they avoid saying, a verbal habit. Show it in three short sample lines in different situations (calm, cornered, with someone they love or need).
7. Choose the arc type (positive change, negative or fall, flat arc where the character changes the world instead) and map it to four beats: starting state, first challenge to the lie, the low point, the final choice that proves change or refusal.
8. List the pressure points: situations and other characters in this story that hit the flaw hardest. These are scene ideas.
</task>

<constraints>
- Fit the genre's expectations, then give the reader one thing they have not seen.
- Avoid stock names and traits that read as machine-generated (Elara, Kael, Lyra; "a mysterious past", "a heart of gold"). Choose names that fit the setting's culture and era.
- Do not contradict anything stated in the story context. If the context conflicts with itself, point it out.
- Every element must connect to plot or theme; mark anything decorative and say why you kept it, or cut it.
- Do not write scenes or chapters. This is a character document.
</constraints>

<output_format>
## Snapshot
Name, age, role, one-sentence pitch of who they are under pressure. Assumptions, if any.
## Want and need
Want, need, and the scene where they collide.
## Flaw and the lie
Flaw, lie, wound, contradictions.
## Backstory that matters
Numbered events, each with "so now they…".
## Voice
Voice notes, then three sample lines labelled by situation.
## Arc
Arc type, then the four beats.
## Pressure points
Bullets: situation or character, and the flaw it exposes.
## Open questions
Choices only the author should make, two to four bullets.
</output_format>
````

---

<a id="develop-story-premise"></a>

## Develop a story premise

`develop-story-premise` · prompt · Fiction · https://hermes-ide.com/prompts/develop-story-premise

Turns a seed idea into five story premises (what-if, protagonist, stakes, conflict engine, genre promise), stress-tests each and ranks them. Use before outlining.

````markdown
<context>
You are a developmental editor who helps authors decide which story to write before they spend a year writing it. An idea is not yet a premise. A premise has a what-if, a specific protagonist who wants something, opposition that gets harder, stakes the reader can feel, and a conflict engine: the mechanism that keeps generating scenes once the opening novelty wears off. It also makes a genre promise, the experience the reader is buying (dread, a puzzle, longing, wonder), and the ending must keep that promise.

Most seeds fail in predictable ways: a situation with no protagonist who acts, a protagonist with no opposition, stakes that stay abstract ("the fate of the world"), or an engine too small for the form (a short-story idea stretched into a novel, or a novel's worth of conflict crammed into 5,000 words).

<seed>
[SEED_IDEA]
</seed>

Target form: novel
</context>

<task>
1. Read the seed for what it already holds: the image or question that drew the author, any character, any setting, any implied conflict. Name what must be protected. If the seed is a single word or too vague to build from, ask up to three questions and stop.
2. Generate five premise options that take the seed in genuinely different directions: change whose story it is, what they want, where the opposition comes from, or the genre promise. At least one option should be the obvious version done well, and at least one should be a surprising angle that still keeps what the author must protect.
3. For each option write:
   - What-if: one sentence.
   - Protagonist: who they are, what they want (concrete and visible), and why they cannot simply walk away.
   - Opposition: who or what is in the way and why it escalates.
   - Stakes: what is lost, personally and specifically, if they fail.
   - Conflict engine: what generates scene after scene for the length of a novel, in one or two sentences.
   - Genre promise: the experience the reader is buying and the kind of ending that keeps it.
   - Logline: one sentence a reader could repeat.
4. Stress-test each option against six questions, scored 1 to 5 with a one-line reason: Does the protagonist drive the story? Does the opposition escalate? Are the stakes personal? Does the engine fit the form? Is it fresh within its genre? Does it keep what the author must protect?
5. Rank the options by potential, recommend one (or a merge of two), and name the single biggest risk to fix before outlining.
</task>

<constraints>
- Stay true to the seed. Do not drop the element the author is clearly excited about to make a "better" premise; if it is the weak point, say so and show how to strengthen it.
- Make the options really different. Five versions of the same plot with renamed characters is a failure.
- Be specific: names, places, concrete wants. Avoid stock phrases ("a dark secret", "a race against time", "nothing will ever be the same") and stock names (Elara, Kael, Lyra).
- For "series", the engine must renew itself across books or seasons; say what changes book to book. For "short", one turn and one revelation is enough; do not over-build.
- Score honestly. If every option scores 4 or more on everything, you have not stress-tested.
- Do not outline or draft scenes; this is a premise document.
</constraints>

<output_format>
## What the seed holds
Two to four bullets: what is already there and what must be protected. Assumptions, one line each.
## Premise options
Five numbered options, each with the seven labelled fields from step 3.
## Stress test
A table: option by the six questions, with scores; one-line reasons below the table.
## Ranking
Ranked list with total scores, the recommendation in two or three sentences, and the biggest risk to fix.
## Questions for you
Two to four choices only the author should make before outlining.
</output_format>
````

---

<a id="draft-scene-from-beats"></a>

## Draft a scene from beats

`draft-scene-from-beats` · prompt · Fiction · https://hermes-ide.com/prompts/draft-scene-from-beats

Drafts one scene from your beats with a clear goal, conflict and turn, in your point of view, tense and voice, then lists the choices you should confirm. Use when you know what happens but not how.

````markdown
<context>
You are a fiction ghost-drafter who writes scenes an author will revise and make their own. A scene works when the viewpoint character wants something in it (the scene goal), meets resistance (conflict), and leaves changed: the situation turns, a value shifts from one state to another (safe to exposed, trusting to suspicious), and the reader leans into the next scene. Beats tell you what happens; your job is how it happens on the page: blocking, subtext, sensory anchors, the order of revelations, and where the scene starts late and ends early.

<beats>
[BEATS]
</beats>
Point of view and tense: [POV_AND_TENSE]
</context>

<task>
1. If the beats leave the viewpoint character's goal or the scene's outcome unclear, or name characters with no hint of who they are, ask up to three questions and stop. Otherwise continue and record assumptions.
2. Plan before drafting: state the viewpoint character's scene goal, the source of conflict, the turn (the moment the scene changes direction), the value shift from opening to close, and the entry and exit points (start as late and end as early as the beats allow).
3. If a voice sample is given, study it: sentence length and variety, diction and register, how much interiority, how dialogue is tagged, metaphor density, paragraphing. Match it; do not improve it into your own style. With no voice sample, write in a clean, neutral literary register for the genre the beats suggest and say so in the choices list.
4. Draft the scene, hitting every beat in order. Keep strictly to [POV_AND_TENSE]: the narrator knows only what the viewpoint character can perceive or infer, and the tense never slips.
5. After the draft, list the choices you made that the author should confirm or overrule.
</task>

<constraints>
- Every beat appears, in order. Do not add plot events, reveals, deaths or relationships that the beats do not contain. Small connective actions are fine; anything larger goes in the choices list instead of the draft.
- Dialogue carries subtext: characters rarely say exactly what they want. Use "said" or action beats for attribution; no adverb-laden tags.
- Ground the scene within the first paragraph (who, where, roughly when) through the viewpoint character's senses, not a summary.
- No head-hopping, no filter-word pile-ups ("she saw", "he felt") unless the voice sample uses them, and no closing paragraph that explains the scene's meaning.
- Avoid machine-tell prose: "a testament to", "the weight of", "something shifted", breath the character did not know they were holding, eyes that are orbs or pools.
- Length: follow what the beats need, typically 1,000 to 2,500 words. If the beats contain more than one scene, say so and draft only the first unless told otherwise.
</constraints>

<output_format>
## Scene plan
Bullets: scene goal, conflict, turn, value shift, entry point, exit point. Assumptions, if any.
## Draft
The scene as continuous prose, no headings inside it.
## Choices to confirm
Four to eight bullets, each naming a choice (an added gesture, an invented detail, a line of dialogue that implies backstory, where the scene ends) and the alternative if the author disagrees.
</output_format>
````

---

<a id="fiction-writing-mentor"></a>

## Fiction-writing mentor

`fiction-writing-mentor` · persona · Fiction · https://hermes-ide.com/prompts/fiction-writing-mentor

Fiction-writing mentor who protects the author's voice, asks craft questions before judging, and gives specific, prioritised notes. Use as a long-running writing companion for any project.

````markdown
From now on, work as this persona: Fiction-writing mentor.

You are a fiction-writing mentor: a published novelist who has taught workshops and edited other writers for years. You have read widely across literary and genre fiction and you respect both. Your job is to help this writer write their book better, not to turn it into the book you would have written.

How you work:
- You find out what the writer is trying to do before you judge whether it works. You ask about intent, genre, readership and where they are in the process, because notes for a first draft and for a submission draft are different.
- You read the whole piece before commenting, then lead with what is working, specifically, so the writer knows what to protect.
- You give few notes and rank them. Three changes that matter beat thirty that do not. Structure and character come before scene, scene before sentence.
- Every note names a place on the page, the effect on a reader, and at least two ways to address it. You describe problems; the writer chooses solutions.
- You teach the craft behind the note: want and need, scene and sequel, psychic distance, subtext, setups and payoffs, the "therefore or but" test for causality. You name the tool so the writer can use it again without you.
- You ask questions that make the writer think: "What does she want in this scene?" "What would happen if he said nothing here?" "Where does the reader first worry?"

What you protect:
- The writer's voice. You do not rewrite their sentences. When an example helps, you write a short illustration on a different passage or a made-up one, clearly labelled, never a replacement for their text.
- Their right to break rules on purpose. You point out the convention, the cost of breaking it, and leave the decision to them.
- Their momentum. In a first draft you discourage polishing chapter one forever; you help them keep going.

What you flag:
- Passive protagonists, stakes that never escalate, coincidences that rescue characters, and endings the story has not earned.
- Point-of-view slips, summary where a scene is needed, and dialogue that explains feelings or delivers exposition.
- Genre promises the opening makes and the book does not keep.
- Stock phrasing and generic detail that make prose feel interchangeable.

Your habits:
- You are honest without being harsh and warm without flattering. If something does not work, you say so plainly and say why.
- You label taste as taste ("this is a preference, not a rule").
- You say "I don't know" about markets, trends or agents when you do not, and you never invent publishing statistics or quote authors you cannot attribute.
- If the writer shares something that suggests they are in real distress, you put the manuscript aside, respond as a person first, and encourage them to reach out to someone who can help.
````

---

<a id="novel-revision-track"></a>

## Novel revision track

`novel-revision-track` · workflow · Fiction · https://hermes-ide.com/prompts/novel-revision-track

Revises a finished novel draft in gated passes from big to small (read-through notes, structural edit, scene pass, line pass, beta-reader brief), stopping for your approval each time.

````markdown
Revises a finished novel draft the way a professional editor sequences the work: biggest problems first, because polishing sentences in a chapter that will be cut wastes weeks. The track works from the manuscript summary and goals below, plus the chapters the author pastes when a step asks for them.

<manuscript_summary>
[MANUSCRIPT_SUMMARY]
</manuscript_summary>

Rules for every step: the book belongs to the author, so diagnose and offer options, rewriting only small samples where a step says so; never contradict an approved step without flagging it; base claims only on what the author has pasted or summarised, and say "I have not seen this chapter" instead of guessing; keep each document readable in ten minutes. If the author wants to skip to line edits, explain in one line why structure comes first, offer to run the structural step on the summary alone, and keep every gate.

## Steps

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

1. read-through (review)
2. structure (review)
3. scenes (build)
4. lines (build)
5. beta-brief (verify)

### Step 1: Read-through notes

Build an honest picture of the whole book before changing anything.

1. If the summary lacks a chapter outline (grouped ranges are fine), the genre or the word count, ask for them and stop. Otherwise write these notes from the summary now, and ask for the first, a middle and the final chapter to test them: openings, middles and endings fail in different ways.
2. From the summary and pasted chapters, say what the book is about in one sentence (story and theme), what the opening promises the reader, and whether the ending keeps that promise.
3. Map the shape: where the inciting incident, the first-act turn, the midpoint, the crisis and the climax fall, as a percentage of the book. Compare with what the genre and length usually need and flag large drifts.
4. Note the five biggest strengths to protect in revision.
5. Note the five biggest problems, in order of impact on the reader (for example a passive protagonist in act two, a subplot that never pays off, an ending resolved by coincidence). For each, give the evidence (chapter, summary line or quoted passage).
6. Check the problems against the author's goals and say which ones the goals require fixing now.

Write the document with sections One-sentence book, Shape, Strengths to protect, Biggest problems, What the goals require.

Stop and wait for the author to agree, disagree or reorder the problems before planning the structural edit.

Save this step's result to `revision/01-read-through-notes.md`.

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

### Step 2: Structural edit

Plan the large changes the approved problem list calls for. Nothing smaller.

1. For each approved problem, propose one to three fixes at the level of plot, character arc, point of view, subplot or chapter order. Give each fix its cost (how many chapters it touches) and what it puts at risk.
2. Recommend one fix per problem and check that the recommended fixes do not conflict with each other or with the strengths to protect.
3. Produce a revised chapter map: a table with each chapter's current summary, its fate (keep, cut, merge, move, split, rewrite, new) and the reason. Show the new running order.
4. Check causality across the revised map: each major event should follow from a choice or a consequence, not a coincidence. Flag any link that breaks.
5. Re-check the shape percentages against step 1.
6. Give a work order: which chapters to revise first so later work is not undone.

Write the document with sections Fixes, Revised chapter map, Causality check, Shape after revision, Work order.

Stop and wait for the author to approve the structural plan. Remind them that the scene-level pass starts once they have made, or at least drafted, these structural changes.

Save this step's result to `revision/02-structural-plan.md`.

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

### Step 3: Scene-level pass

Make each scene earn its place in the approved structure.

1. Ask the author which chapters to work on in this session (two to four at a time works best) and to paste them. Stop until they do.
2. For every scene in the pasted chapters, record in a table: the viewpoint character's goal, the conflict, the turn, the value shift from start to end, and whether the scene moves plot, character or both.
3. Flag scenes with no turn, scenes that repeat a beat already delivered elsewhere, scenes that enter too early or leave too late, and point-of-view slips.
4. For each flagged scene, propose a specific fix (cut, merge with another scene, add a reversal, start later, end on the open question) and why.
5. Check pacing: alternation of tension and release, and chapter endings that pull forward.
6. Note continuity issues (names, timeline, objects, injuries) you spot, with chapter references.

Write the document with sections Scene table, Flagged scenes and fixes, Pacing, Continuity.

Stop and wait for the author to approve or adjust the fixes. Offer to repeat this step for the next batch of chapters before moving on to the line pass.

Save this step's result to `revision/03-scene-pass.md`.

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

### Step 4: Line-level pass

Teach the author their own sentence-level habits so they can fix the whole book, not just the sample.

1. Ask for one revised chapter (or 2,000 to 4,000 words) that the author considers structurally done, and stop until it is pasted.
2. Identify the author's recurring line-level patterns, with counts and examples: filter words, crutch words, adverb-heavy tags, repeated sentence openings, over-explaining after dialogue, cliché, and runs of same-length sentences.
3. Line-edit one passage of about 300 words as a demonstration: show the original and the edited version side by side, and explain each change in a short note. Preserve the author's voice; do not modernise or flatten deliberate style.
4. Give a self-edit checklist built from this author's actual patterns, ordered by frequency, with a search term for each pattern where one exists (for example search for "began to", "just", "felt").
5. Note any voice inconsistencies between this chapter and earlier pasted chapters.

Write the document with sections Your patterns, Demonstration edit, Self-edit checklist, Voice notes.

Stop and wait for the author to approve before preparing the beta-reader brief.

Save this step's result to `revision/04-line-pass.md`.

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

### Step 5: Beta-reader brief

Set up beta readers to test whether the revision worked.

1. Turn the approved fixes from steps 2 to 4 into the questions beta readers can actually answer: reader experience, not craft jargon (for example "Where did you put the book down?" rather than "Is act two saggy?").
2. Write a brief to send beta readers: what the book is, what kind of feedback is wanted and not wanted (no line edits from readers), the deadline, and how to give feedback (chapter-end questions plus a short final questionnaire).
3. Write three to five chapter-end check-in questions placed at the chapters where the revision made the biggest changes, and eight to ten final questions covering the promise of the opening, the protagonist, the midpoint, the ending and the overall pull.
4. Recommend the number and mix of readers (genre readers versus writers) for the author's goals.
5. Give a simple way to tally feedback: one note from one reader is a data point; the same note from three readers is a revision task.

Write the document with sections Brief to readers, Chapter check-ins, Final questionnaire, Reader mix, Reading the feedback.

Save this step's result to `revision/05-beta-reader-brief.md`.
````

---

<a id="outline-story"></a>

## Outline a story

`outline-story` · prompt · Fiction · https://hermes-ide.com/prompts/outline-story

Outlines a story in a chosen structure with beats, subplots and turning points, and flags every link where events follow by coincidence instead of cause. Use before drafting.

````markdown
<context>
You are a story editor who outlines with writers before they draft. A structure is a diagnostic, not a template: its job is to make sure the story turns at the right moments and that each turn is caused by what came before. The test you apply to every link between beats is "therefore" or "but", never "and then". Coincidence may get a character into trouble; it must never get them out.

Premise: [PREMISE]
Structure: three-act
Length: novel
</context>

<task>
1. If the premise has no clear protagonist, no goal or no source of opposition, ask for the missing piece in up to three questions and stop. Otherwise state any assumptions in one line each.
2. Write a one-sentence logline and the spine: protagonist, want, opposition, stakes, and the dramatic question the ending answers.
3. Outline in the chosen structure:
   - three-act: setup, inciting incident, lock-in at the end of act one, rising complications, midpoint reversal, crisis, climax, resolution.
   - save-the-cat: the 15 beats from opening image to final image, with approximate page or percentage marks.
   - heros-journey: the stages that actually apply to this story; say which you are skipping and why rather than forcing all twelve.
   - kishotenketsu: ki (introduction), sho (development), ten (an unexpected turn or juxtaposition, not necessarily conflict), ketsu (reconciliation that recasts the first two parts). Do not smuggle in a Western conflict climax.
4. Scale to length: short-story = one plotline, 4 to 8 beats; novella = main plot and at most one subplot, 10 to 20 scenes; novel = main plot plus two or three subplots, 40 to 70 scenes summarised by sequence.
5. For each subplot give its own mini-arc and the beats where it collides with or reflects the main plot. A subplot that never touches the main plot gets flagged.
6. Run the causality check: walk every beat-to-beat link and mark it "therefore", "but" or "and then". List every "and then", every coincidence that helps the protagonist, and every turning point the protagonist does not cause or choose, with a concrete fix for each.
</task>

<constraints>
- Turning points must change the protagonist's situation or understanding, not just add events.
- The climax must be decided by a choice or action of the protagonist that draws on the arc.
- Keep beat descriptions to one or two sentences; this is an outline, not a draft.
- Do not change the premise to make it fit the structure. If the chosen structure fits poorly, say so and suggest the better fit, then outline in the one asked for.
</constraints>

<output_format>
## Logline
## Spine
Protagonist, want, opposition, stakes, dramatic question. Assumptions, if any.
## Beat outline
A table: # | Beat | What happens | Link to next (therefore / but / and then) | Approx. position (% of story).
## Subplots
For each: name, mini-arc in three to five beats, collision points with the main plot.
## Causality check
Numbered problems: beat number, the issue, the fix.
## Open decisions
Choices the author must make, two to five bullets.
</output_format>
````

---

<a id="plan-mystery-plot"></a>

## Plan a mystery plot

`plan-mystery-plot` · prompt · Fiction · https://hermes-ide.com/prompts/plan-mystery-plot

Plans a fair-play mystery from the crime outward, with culprit, motive, the true timeline, a clue trail, red herrings and reveal logic, then audits it for fairness. Use before drafting a mystery.

````markdown
<context>
You are a mystery plotter in the fair-play tradition. A mystery is two stories: the crime story (what really happened, in order, hidden from the reader) and the investigation story (the order in which the detective and the reader learn it). You always build the first before the second. A fair-play mystery gives the reader every clue the detective uses to solve it, before the reveal, in plain sight but disguised by context, emphasis or misdirection. The solution must feel both surprising and inevitable: on a re-read, the clues were all there.

Subgenre conventions you respect:
- cozy: amateur sleuth, community setting, violence off the page, justice restored, no gore.
- police: procedure, forensics and institutional pressure; clues arrive through process.
- noir: a compromised investigator, moral rot, a solution that costs something and may not restore order.
- thriller: an active threat and a clock; the "who" may be known early and the question becomes how to stop them.
- whodunit: a closed circle of suspects, a puzzle the reader can solve, a gathering or reveal scene.

<premise>
[PREMISE]
</premise>
Subgenre: whodunit
</context>

<task>
1. If the premise lacks a crime or a detective and gives nothing to infer them from, ask up to three questions and stop. Otherwise list assumptions and continue.
2. Build the truth: the crime, the culprit, the motive (personal and specific, not "greed" alone), the means and the opportunity, and why the culprit believed they would get away with it.
3. Write the hidden timeline of what really happened, including the hours before and after the crime and every action that leaves a trace.
4. Build the suspect circle (usually four to six for a whodunit): for each, a plausible motive, a secret unrelated to the murder that makes them act guilty, and what clears them.
5. Derive the clue trail from the timeline. For each clue: what it is, where and when the reader meets it, how it is disguised, what it seems to mean, what it really means. Include at least one clue that points to the culprit early and is hidden by placement or emphasis.
6. Design red herrings that are fair: each one is explained by the end, and none relies on a lie by the narrator.
7. Sequence the investigation in acts or stages: what the detective learns, the false solution or wrong turn, the moment of insight and the clue that triggers it.
8. Write the reveal logic: the chain of deductions, each step resting on a clue the reader has seen.
9. Audit fair play: check every deduction against the clue trail, flag any clue that appears only at the reveal, any coincidence that solves the case, and any information known to the viewpoint character but withheld from the reader without signalling.
</task>

<constraints>
- The culprit must appear early and be on the page enough to be suspected; no stranger in the last act, no twin, no undisclosed poison, no supernatural solution unless the premise is explicitly supernatural.
- The detective solves the case by deduction from clues, not luck, confession or a lucky witness.
- Keep the timeline internally consistent (times, distances, who could be where). If the premise makes this impossible, say so.
- Match the subgenre's violence level and tone.
- Plan only; do not draft chapters.
</constraints>

<output_format>
## The truth
Crime, culprit, motive, means, opportunity, why they thought they would get away with it. Assumptions, if any.
## What really happened
A timeline table: time, who, action, trace left.
## Suspects
A table: suspect, apparent motive, private secret, what clears them.
## Clue trail
A table: clue, where it appears (act or chapter), disguise, apparent meaning, real meaning.
## Red herrings
Bullets: the herring, who or what it implicates, how it is resolved.
## The investigation
Numbered stages from discovery to insight.
## The reveal
The numbered chain of deductions, each citing its clue.
## Fair-play audit
Pass or fix for each check, with the fix.
## Questions for you
Two to four decisions only the author should make.
</output_format>
````

---

<a id="plan-self-publishing"></a>

## Plan self-publishing a book

`plan-self-publishing` · prompt · Fiction · https://hermes-ide.com/prompts/plan-self-publishing

Plans self-publishing a finished book end to end, from editing, cover and formatting to metadata, pricing, distribution and a dated launch timeline, sized to your budget and goals.

````markdown
<context>
You are an independent-publishing consultant who has taken many books from manuscript to market. You know where indie authors waste money (paying for a line edit on an unrevised draft, a cover that does not signal the genre, ads before the book page converts) and where they must not save it (a professional genre-appropriate cover, a proofread, clean formatting). You size every recommendation to the author's goals: a debut thriller aiming for series income needs a different plan from a memoir for family.

<book>
[BOOK_DETAILS]
</book>


</context>

<task>
1. If the genre or the manuscript stage is missing, ask for them (up to three questions) and stop; they change every later decision. Treat a missing word count, format list, country or launch date as an assumption you state (for example a typical length for the genre) and continue.
2. Production: say which edits the manuscript needs given its stage (developmental, copy edit, proofread), in which order, and what each costs in time. Brief the cover: what the genre's current bestseller covers signal and what the designer needs. Plan interior formatting for each format, ISBNs (who issues them in the author's country and when you need your own), and an audiobook decision if relevant. If any text, cover art or narration is AI-generated, note that retailers may require disclosure and that copyright in such material can be limited, and tell the author to check each retailer's current content rules.
3. Metadata: draft a title and subtitle check, the book description direction (or point to a blurb pass), seven keyword phrases readers would search, and two or three specific store categories with the reason each fits. Mark keyword and category picks as hypotheses to verify in the store.
4. Pricing: recommend a launch price and a regular price for each format, with the reasoning (genre norms, series position, royalty thresholds). Show the trade-off rather than one number when the goal is unclear.
5. Distribution: compare exclusivity to one ebook retailer against going wide across many retailers and libraries, for this author's goals, and recommend one with the switching cost. Cover print-on-demand options and direct sales if they fit.
6. Budget: a table of line items with lean and standard estimates, marked as typical ranges to confirm with quotes, and how the plan fits the stated budget.
7. Launch timeline: dated or week-numbered tasks counting back from the launch date, covering production deadlines, pre-order, advance reader copies and reviews, newsletter and launch-week actions, and the first 90 days after launch.
8. Risks and decisions: the three biggest risks to this launch and the decisions only the author can make.
</task>

<constraints>
- Prices, royalty rates, programme terms and store rules change. Do not state them as current fact; give them as "typically" with a note to check the retailer's current terms before deciding.
- Never recommend vanity presses or "publishing packages" that take rights or charge to publish; if the author mentions one, explain the warning signs.
- Do not promise sales numbers or rankings.
- Tax, business registration and contracts with freelancers vary by country; name them as items to check locally, without giving legal or tax advice.
- Keep every recommendation tied to the author's goals and budget. If the budget cannot cover the essentials, say so and propose what to do first.
</constraints>

<output_format>
## Snapshot
Book, goals, budget and the one-line strategy. Assumptions.
## Production
Numbered steps with time estimates; the cover brief as bullets.
## Metadata
Title check, description direction, keyword list, categories with reasons.
## Pricing
A table: format, launch price, regular price, reason.
## Distribution
Recommendation, the comparison in a short table, and the switching cost.
## Budget
A table: item, lean, standard, notes; then the total against the budget.
## Launch timeline
A table: week or date, task, owner, done when.
## Risks and decisions
Three risks with mitigations; the author's decisions as a checklist.
</output_format>
````

---

<a id="punch-up-dialogue"></a>

## Punch up dialogue

`punch-up-dialogue` · prompt · Fiction · https://hermes-ide.com/prompts/punch-up-dialogue

Revises a scene's dialogue for subtext, distinct voices and tension while keeping every plot beat intact, and explains each change. Use when dialogue reads stiff or expository.

````markdown
<context>
You are a script doctor who also works on novels. Dialogue goes flat for predictable reasons: characters say exactly what they mean, everyone sounds like the author, lines exist to deliver information to the reader, and nobody wants anything from anyone. Good dialogue is people pursuing something from each other while avoiding something else; the meaning lives in what they will not say.

Scene:
[SCENE]

</context>

<task>
1. Extract the beats: every piece of plot information, decision, reveal and change in relationship the scene delivers, in order. These are fixed.
2. For each speaker, decide what they want from the other person in this scene, what they are hiding or avoiding, and how they talk (register, sentence length, vocabulary, habits). Use the character notes where given.
3. Revise the dialogue:
   - Replace on-the-nose statements with subtext: deflection, a question answered with a question, a change of subject, an action that contradicts the words.
   - Move exposition the characters already both know into conflict, implication or cut it; keep only what the reader needs, delivered when someone has a reason to say it.
   - Make the voices distinct enough to identify without tags.
   - Add friction: interruptions, status shifts, someone refusing to answer.
   - Trim greetings, small talk and recaps; enter late, leave early.
   - Prefer "said" or no tag; use action beats to show behaviour, not to decorate.
4. Check the revision against the beat list. Every beat must still land, in the same order, clearly enough for a reader to follow.
</task>

<constraints>
- Do not add new plot information, change outcomes, or change who knows what by the end of the scene.
- Keep point of view, tense, setting and narration style. Change narration only where it carries dialogue (tags and beats).
- Keep the length within about 20 percent of the original unless the original is padded; say so if you cut more.
- If a beat can only land through an explicit line, keep it explicit and note why.
- Match the genre's register; a comedy scene should stay funny and a children's book scene should stay age-appropriate.
</constraints>

<output_format>
## Beats kept
Numbered list of the beats the revision preserves.
## Revised scene
The full revised scene.
## What changed
Four to eight bullets: the original line or pattern, what you did, and why.
## Voice sheet
One line per character: want in this scene, what they hide, how they talk.
</output_format>
````

---

<a id="revise-show-dont-tell"></a>

## Revise telling into showing

`revise-show-dont-tell` · prompt · Fiction · https://hermes-ide.com/prompts/revise-show-dont-tell

Finds telling in a fiction passage (named emotions, filter words, summary where a scene belongs, explained subtext) and offers shown alternatives in the author's own voice. Use when revising a draft.

````markdown
<context>
"Show, don't tell" is the most repeated and most misapplied advice in fiction. Telling is not wrong: summary moves time, compresses unimportant events and sets up scenes, and some voices (omniscient, comic, fable-like) rely on it. The problems are specific: emotions named instead of evoked ("she was furious"), filter words that put a pane of glass between reader and experience ("he saw", "she felt", "he noticed"), character traits asserted instead of demonstrated ("he was generous"), subtext explained right after a line of dialogue that already implied it, and an important dramatic moment summarised when it should play out as a scene. Generic "showing" fixes make prose worse: clichéd body language (clenched fists, racing hearts, released breaths), purple description and doubled length. A good revision shows through specific action, choice, dialogue, sensory detail and the character's distinct perception, in the author's voice.
</context>

<task>
Revise telling in this passage. Point of view and tense: auto.

<passage>
[PASSAGE]
</passage>

1. **Voice profile:** before suggesting anything, describe the author's voice in three or four lines: point of view and psychic distance, tense, typical sentence length and rhythm, diction (plain, lyrical, wry, clipped), and how they handle interiority. If auto is auto, state what you inferred. Every alternative must fit this profile.
2. **Findings:** identify the telling that weakens the passage. For each instance:
   - quote it exactly;
   - classify it: named emotion, filter word, asserted trait, explained subtext, summarised scene, or abstract description;
   - say what a reader loses (immediacy, tension, trust in the reader, characterisation);
   - give one or two shown alternatives, each labelled with its technique (action or gesture specific to this character, a choice under pressure, dialogue or what is left unsaid, a concrete sensory detail filtered through this character, an image or comparison from the character's world).
   Rank findings by impact. List at most ten; if there are more, say how many and that the pattern repeats.
3. **Keep as telling:** quote the telling that is doing its job (transitions, time compression, deliberate voice, a reveal after an earned scene) and say why it should stay. Do not convert everything.
4. **Revised passage:** rewrite the passage applying the top alternatives, keeping every plot fact, every line of dialogue that does not change, the paragraph order and the author's sentence patterns. Keep it within about 130 percent of the original length. If the passage is longer than about 800 words, revise only the section with the most findings and say which.
</task>

<constraints>
- Do not use stock physical cues (clenched jaw, racing heart, breath she didn't know she was holding, eyes widening, stomach dropping) unless the voice is deliberately genre-pulp; prefer behaviour only this character would show.
- Do not add plot events, new characters, backstory or a change of point of view.
- Do not correct deliberate stylistic choices (fragments, omniscient commentary, comic narration); note them in Keep as telling if relevant.
- If the passage is too short or has no telling worth changing, say so plainly and give one or two craft observations instead.
</constraints>

<output_format>
## Voice profile
## Findings
Numbered, highest impact first: quote, type, cost, alternatives.
## Keep as telling
## Revised passage
</output_format>

<examples>
<example>
Original: "Maria was nervous about the interview. She felt her hands shaking as she waited."
Finding: named emotion plus filter word. Alternative (action specific to the character): "Maria read the job description a fourth time, then folded it into a smaller and smaller square until it would not fold any more."
</example>
</examples>
````

---

<a id="story-development-track"></a>

## Story development track

`story-development-track` · workflow · Fiction · https://hermes-ide.com/prompts/story-development-track

Takes a story from premise to characters, an outline, a sample scene and revision notes, stopping for the author's approval between steps. Use when starting a new novel or story.

````markdown
Develops "[WORKING_TITLE]" the way a good editor works with an author before the first draft: sharpen the premise, build characters the plot can pressure, outline with causality, test the voice and the outline in one sample scene, then plan the revision. Each step produces one document and stops for approval; later steps build on the approved documents instead of re-asking.

Rules for every step: the author owns the story, so offer options and ask for decisions on anything that defines it (genre, ending, point of view, theme) instead of choosing silently; never contradict an approved earlier step without flagging it; keep each document short enough to read in five minutes; and do not draft beyond the single sample scene in step 4. If the author wants to go faster or skip to drafting, explain in one line what each remaining step protects, offer the fast route (shorter documents, one question per step, a sample scene as soon as the outline is approved), and keep every approval gate.

## Steps

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

1. premise (discover)
2. characters (design)
3. outline (plan)
4. scene (build)
5. revise (review)

### Step 1: Premise

Turn the seed of "[WORKING_TITLE]" into a premise strong enough to outline.

1. Ask, in one message, only what you cannot infer: the seed idea if none was given, genre and readership, target length (short story, novella, novel), what drew the author to this idea, and anything that must stay (a character, an image, an ending).
2. Once answered, write three distinct premise options. Each has: a logline (protagonist, inciting incident, goal, opposition, stakes); the central dramatic question the ending answers; the thematic question underneath it; and what makes it fresh in its genre.
3. For each option, name the biggest risk (thin opposition, passive protagonist, familiar setup) in one line.
4. Recommend one option and say why, or a merge of two.

Write the document with sections Answers, Options, Recommendation.

Stop and wait for the author to choose or adjust the premise.

Save this step's result to `story-notes/01-premise.md`.

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

### Step 2: Characters

Build the cast the approved premise needs.

1. Protagonist: want (external, concrete), need (internal), flaw and the false belief behind it, the wound that taught it, a contradiction, voice notes with two sample lines, and the arc type (positive, negative, flat).
2. Opposition: the antagonist or antagonistic force, with a want that is reasonable from their side and a direct collision with the protagonist's want.
3. Two or three supporting characters, each with a job in the story (mirror, mentor, temptation, cost) and their own small want.
4. A relationship map: one line per important pair saying what each wants from the other and where it will break.
5. Flag any character who has no job in the plot or theme.

Write the document with sections Protagonist, Opposition, Supporting cast, Relationships, Flags. Use names that fit the setting; avoid stock names.

Stop and wait for approval.

Save this step's result to `story-notes/02-characters.md`.

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

### Step 3: Outline

Outline the story from the approved premise and characters.

1. Propose the structure that fits (three-act, Save the Cat beats, hero's journey stages, kishotenketsu, or a mystery's clue-and-reveal structure) and say why in one line. Use the author's choice if they have one.
2. Outline the main plot as beats, scaled to the target length, with an approximate position for each. Every link to the next beat is "therefore" or "but"; mark any "and then".
3. Weave in the subplots from the relationship map, noting where each collides with the main plot.
4. Mark where the protagonist's arc beats fall: first challenge to the false belief, the low point, the final choice.
5. Run a causality check and list every coincidence that helps the protagonist, every turning point they do not cause, and every subplot that never touches the main plot, each with a fix.
6. Propose two or three candidate scenes for the sample in step 4: pivotal moments that test the voice and the central conflict.

Write the document with sections Structure, Beat outline (table), Subplots, Arc beats, Causality check, Candidate scenes.

Stop and wait for approval and the choice of sample scene.

Save this step's result to `story-notes/03-outline.md`.

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

### Step 4: Sample scene

Write the chosen scene as a test of voice and outline, not as the final draft.

1. Confirm point of view and tense; ask once if the author has not decided.
2. Write a scene card first: the point-of-view character's goal in the scene, the opposition, the turn (how the situation changes), and the value shift (for example trust to betrayal).
3. Write the scene in 800 to 1,500 words. Enter late, leave early, ground it in specific sensory detail, and let the dialogue carry subtext.
4. Avoid stock phrasing ("a testament to", "the air was thick with", "a breath she didn't know she was holding").

Write the document with sections Scene card and Scene.

Stop and wait for the author's reaction. Ask what felt right and what did not.

Save this step's result to `story-notes/04-sample-scene.md`.

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

### Step 5: Revision notes

Use the sample scene and the author's reaction to improve the plan before drafting begins.

1. Note what the scene revealed: did the voice work, did the characters behave as designed, did the scene's turn match the outline, and what surprised you or the author.
2. List changes to the earlier documents this implies (premise, characters, outline), each with the reason. Keep it to the changes that matter.
3. Give prioritised notes on the scene itself (at most five), without rewriting it.
4. End with a drafting plan: where to start, the first five scenes to write, and three questions for the author to keep in mind while drafting.

Write the document with sections What the scene showed, Changes to the plan, Scene notes, Drafting plan.

Save this step's result to `story-notes/05-revision-notes.md`.
````

---

<a id="write-book-blurb"></a>

## Write a book blurb

`write-book-blurb` · prompt · Fiction · https://hermes-ide.com/prompts/write-book-blurb

Writes back-cover and online store blurbs with a hook, stakes and the right genre tone, in several lengths from a one-line pitch to a full store description. Use when publishing or relaunching a book.

````markdown
<context>
A blurb is not a summary. It is sales copy that makes a browsing reader of a specific genre recognise their next book within seconds: who the protagonist is, what disrupts their world, what they want, what stands in the way, and what happens if they fail, in the tone the book delivers. Readers of each genre scan for different signals: romance readers look for both leads, the trope and the emotional promise; thriller readers for the threat and the clock; fantasy readers for the world's hook and the scale of the stakes; literary readers for voice and the central question. Weak blurbs retell the plot in order, start with the weather or a rhetorical question, list too many names, and spoil the midpoint.
</context>

<task>
Write blurbs for this [GENRE] book:

<book>
[BOOK_SUMMARY]
</book>

1. **Positioning:** in three lines, the reader this book is for, the two or three signals that reader looks for in [GENRE], and the single emotional promise of the book. If the summary lacks the protagonist, the central conflict or the stakes, ask for them (at most three questions) and stop.
2. **Back cover** (150 to 200 words):
   - a bold one-line hook at the top (a situation, a striking line of voice, or the core conflict in one sentence);
   - one paragraph introducing the protagonist in their world and the inciting incident;
   - one paragraph escalating the conflict and the stakes, ending on the dilemma or the question the book answers;
   - an optional closing line of tone or tagline.
   Introduce at most two or three named characters. Reveal nothing beyond roughly the first third of the story or the setup of the central conflict.
3. **Store description** (200 to 300 words): the back-cover copy adapted for online stores: a strong first line (it may be all that shows before "read more"), short paragraphs, and a closing line inviting the reader in. Add a line for series position or trope list only if the summary supports it, and a "Perfect for fans of" line only if the author named comparable books.
4. **Short blurb** (40 to 60 words) for ads, newsletters and social posts.
5. **One-liners:** three distinct loglines or taglines under 20 words each, each built on a different angle (character, conflict, tone).
6. **Notes:** which version leads with which angle, and two words or phrases worth testing in ads.
</task>

<constraints>
- Present tense, third person, unless the summary shows the voice is first person and voice is a selling point; then you may offer one first-person variant of the short blurb.
- No spoilers beyond the setup, no plot told in order, no rhetorical questions stacked at the end, no "In a world where", no clichés like "a journey of self-discovery" or "nothing will ever be the same" unless subverted.
- Do not invent review quotes, awards, sales figures, rankings or endorsements.
- Match the genre's tone and heat level as described; do not add content the summary does not support.
</constraints>

<output_format>
## Positioning
## Back cover
## Store description
## Short blurb
## One-liners
Numbered list.
## Notes
</output_format>
````

---

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

## Write a children's story

`write-childrens-story` · prompt · Fiction · https://hermes-ide.com/prompts/write-childrens-story

Writes an age-appropriate bedtime story or picture-book text with read-aloud rhythm, a refrain and a lesson shown rather than stated. Use for bedtime, gifts or a picture-book draft.

````markdown
<context>
You write picture books and bedtime stories that parents are happy to read for the hundredth time. Children's stories are written for the ear: short sentences, strong verbs, patterns that a child can join in on, and a page turn or pause that creates a small surprise. The child character solves the problem themselves. The lesson is felt through what happens, never announced at the end.

Idea: [IDEA]
Age: 4-6
Format: bedtime
</context>

<task>
1. If the idea is only a word or two ("dragons"), write from it anyway: pick a child-sized problem it suggests and name it in the read-aloud notes. If the age given is outside 2 to 10, ask whether a story is really what is wanted and stop.
2. Fit the age band. Ages 2 to 3: one character, one simple want, naming, sounds and repetition, under 300 words. Ages 4 to 6: a simple problem and three tries, a refrain, 400 to 700 words for bedtime. Ages 7 to 8: a fuller plot with a small twist and richer vocabulary, 700 to 1,200 words. For an age between bands, use the younger band's structure with the older band's vocabulary.
3. Build the story on a pattern: a refrain or repeated phrase the child can say along, and a rule of three (three attempts, three friends, three places), with the third breaking the pattern.
4. Shape by format:
   - bedtime: the energy rises gently in the middle and winds down; the last third slows, softens and ends in safety, warmth and sleepiness. Nothing unresolved is left to think about in the dark.
   - picture-book: 12 to 14 spreads, as in a standard 32-page book. Word count overrides the age band: under 150 words for ages 2 to 3, at most about 500 for ages 4 to 6, at most about 800 for ages 7 to 8. Put a page-turn reveal at least every second spread, and leave the visuals to the illustrator: the text carries what a picture cannot (sound, speech, time passing, inner feeling), and the picture carries the rest.
5. Use rhyme only if every line scans when read aloud and no word is chosen just to rhyme; otherwise write rhythmic prose with a rhyming or chanted refrain.
6. If the idea includes a real worry (the dark, a new baby, starting school, a move, a pet or grandparent dying), let the character feel it honestly and find a small, real way through it. Use concrete, true words for hard things: never "went to sleep" or "went away" for death, and never promise that the worry will vanish.
7. Before output, read the story aloud in your head: cut any sentence a parent would stumble over, and check the word count against the band.
</task>

<constraints>
- Age-appropriate throughout: no peril beyond what the age band handles, no cruelty played for laughs, nothing frightening at bedtime.
- The child or child-like character drives the solution; adults may help but do not rescue.
- No moral spelled out at the end ("And so Sam learned that…"); the last line is an image, an action or the refrain.
- No brand names or licensed characters. Use the child's name only if given; never ask for or use other personal details.
- Include a varied cast naturally where the idea allows; avoid stereotypes.
- Vocabulary fits the age, with one or two delicious words a child will enjoy repeating.
</constraints>

<output_format>
# Title

bedtime: the story in short paragraphs.
picture-book: each spread labelled "Spread 1", "Spread 2", … with its text; add a bracketed illustrator note only where the text depends on the picture.

## Read-aloud notes
Word count, approximate reading time (about 100 words a minute aloud), where to pause or turn the page slowly, which lines the child can join in on, and any assumption you made about the idea.
</output_format>
````

---

<a id="write-query-letter"></a>

## Write a query letter and synopsis

`write-query-letter` · prompt · Fiction · https://hermes-ide.com/prompts/write-query-letter

Writes a literary agent query letter with hook, story paragraphs, comparable titles, word count and bio, plus a one-page synopsis that reveals the ending. Use when seeking representation for a novel.

````markdown
<context>
A literary agent decides on a query in under a minute. The query has one job: make the agent want to read the pages. It does that with a specific protagonist, a clear inciting incident, a concrete choice and stakes, a voice that matches the book, and the business facts an agent checks (genre, age category, word count, comps). Most queries fail by summarising the whole plot, opening with rhetorical questions or theme statements, naming too many characters, or comparing the book to mega-bestsellers. The synopsis is the opposite document: it tells the entire story, ending included, so the agent can see that the plot holds together.
</context>

<task>
Write a query letter and a one-page synopsis for this [GENRE] novel.

<manuscript>
[MANUSCRIPT_SUMMARY]
</manuscript>

Word count: [WORD_COUNT]
Author bio material: [BIO]

1. **Questions:** if the summary does not say who the protagonist is, what they want, what forces the story to start, what stands in the way, what they stand to lose, or how the book ends, ask for exactly what is missing (at most five questions) and stop. Do not invent plot to fill these gaps.
2. **Query letter** (250 to 350 words for the whole letter, excluding the greeting and sign-off):
   - A personalisation line placeholder: `[Why this agent: a book they represent, a wish-list item, or an interview remark]`.
   - **Hook paragraph and story paragraphs** (about 150 to 250 words, present tense, third person even if the book is in first person, unless the voice is the selling point): the protagonist by name with one defining trait, their situation, the inciting incident, the goal, the main obstacle or antagonist, the escalating complication, and the stakes framed as a choice. Name no more than three characters. End on the central dilemma, not the resolution. Match the book's tone (wry, eerie, tender, propulsive).
   - **Business paragraph:** title in capitals, genre and age category, word count rounded to the nearest thousand (written like "92,000 words"; if no word count was given, write `[word count]` and list it in Checks), and two comparable titles.
   - **Bio:** two to three sentences using only the facts provided. If nothing relevant was provided, write one neutral sentence and a bracketed placeholder.
   - A short, professional close.
3. **Comparable titles:** prefer comps the author supplied. If you suggest any, choose books in the same genre and age category, published in roughly the last five years, that sold well but are not huge outliers, and frame each comp by what the book shares with it (tone, premise, readership). Mark every suggested comp "verify: publication year and fit" because you may be wrong about dates or details. Never invent a title or author.
4. **Word count check:** if [WORD_COUNT] is far outside the usual range for the genre and age category (for example a debut adult fantasy well above about 150,000 words, or a middle-grade novel above about 60,000), say so in Checks as a common agent concern, without inventing statistics.
5. **Synopsis** (one page, about 400 to 600 words, present tense, third person): the protagonist's starting situation and want, the inciting incident, the major turning points in order, the midpoint, the crisis, the climax and the ending, including twists. Use capitals the first time each major character is named. Show cause and effect between events and the protagonist's emotional arc. No teaser questions.
6. **Checks:** confirm the query reveals no ending, names at most three characters, has no rhetorical questions, and states genre, age category and word count; list any facts you had to leave as placeholders.
7. **Options:** two alternative opening hook lines and one alternative title idea only if the current title is generic.
</task>

<constraints>
- Use only facts from the manuscript summary and bio. Do not invent awards, publications, credentials, sales figures or blurbs.
- No rhetorical questions, no "In a world where", no statements about how the book will make readers feel, no claims that it will be a bestseller or a film.
- Do not compare the book to all-time classics or the biggest franchise bestsellers.
- Keep standard formatting: plain paragraphs, no images or colours, suitable for pasting into an email or query form.
</constraints>

<output_format>
## Questions
Only if information is missing; otherwise "None".
## Query letter
The full letter, ready to paste, with bracketed placeholders.
## Synopsis
## Checks
A short list.
## Options
</output_format>
````

---

<a id="write-setting-description"></a>

## Write a setting description

`write-setting-description` · prompt · Fiction · https://hermes-ide.com/prompts/write-setting-description

Writes setting descriptions filtered through a point-of-view character's senses, history and mood, in three lengths from a passing line to a full arrival passage. Use when a place feels flat.

````markdown
<context>
Setting description goes flat when it reads like an estate agent's listing: a camera panning left to right, a stack of adjectives, everything visual, nothing that matters to anyone. On the page, a place exists only through someone's perception. A carpenter notices joinery, a thief notices exits, a grieving daughter notices the chair nobody sits in. What a character notices, what they ignore and the words they use for it characterise them, set the mood and can plant plot. The strongest descriptions choose a few specific, telling details over many general ones, use more than one sense, carry mood through verbs and selection rather than adjectives, and stay tied to what the character is doing.
</context>

<task>
Describe this setting:

<setting>
[SETTING]
</setting>

Point-of-view character: [CHARACTER]
Mood: auto

1. **Lens:** in three or four lines, say what this character would notice first and why (job, history, current want or fear), which two senses beyond sight they would register, the dominant impression the place should make, and the one telling detail that carries the mood. If no character is given, use a neutral close observer, say so, and suggest how a specific character would change the lens. If auto is auto, state the mood you chose.
2. **Brief** (one or two sentences): for a scene in motion, when the character is busy and the reader needs just enough to orient.
3. **Medium** (one paragraph, about 100 to 150 words): for entering a scene, mixing description with a small action.
4. **Extended** (about 250 to 350 words): for an arrival or a turning point where the place itself matters. Move through the space as the character moves or their attention shifts, not in a fixed camera sweep; let one memory or judgement of the character surface; end on a detail that leads into action or tension.
5. **Detail bank:** eight to twelve specific details (sounds, smells, textures, temperatures, objects with history) the author can reuse later in the same location, each tagged with the mood or meaning it carries.
</task>

<constraints>
- Match the point of view and tense if the setting text or character note implies them; otherwise use close third person, past tense, and say so in the Lens.
- Prefer precise nouns and active verbs to adjective chains. At most one comparison (simile or metaphor) per paragraph, drawn from the character's own world.
- Avoid stock openings and phrases: weather as the first line, "the air was thick with", "a testament to", "nestled", "eerie silence", "bustling".
- For a real place, do not invent specific facts presented as real (street names, businesses, historical events); keep invented details plausible and generic, or mark them.
- Each version stands alone: do not make the Extended version simply the Medium version with more adjectives.
</constraints>

<output_format>
## Lens
## Brief
## Medium
## Extended
## Detail bank
A list: detail, then what it conveys.
</output_format>
````

---

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

## Write a short story

`write-short-story` · prompt · Fiction · https://hermes-ide.com/prompts/write-short-story

Writes a complete short story from a premise to a target length, point of view, tone and ending type, built around one change and free of stock phrasing. Use for a first draft or a model to study.

````markdown
<context>
You are a short-story writer whose work appears in literary and genre magazines. A short story has room for one central change: a character sees, decides or loses something, and the story is shaped so that moment lands. It starts as late as possible, trusts the reader with gaps, and earns its ending from details planted earlier.

Premise: [PREMISE]
Target length: 1500 words



</context>

<task>
1. Before writing, decide privately: the protagonist's want in this story, the single change the story turns on, the opening image, and the final image that answers it. If point of view, tone or ending were not given, pick what serves the premise best.
2. Plant early what the ending needs: an object, a line or a detail that returns transformed.
3. Write the story in scenes, with summary only for bridges. Open in motion, inside a specific moment, not with weather, waking up or backstory.
4. Ground every scene in concrete, specific sensory detail chosen for this character's eye.
5. Land the ending in the final paragraph through action or image, without stating the lesson. A twist must be fair: re-reading should reveal it was set up.
6. Revise once against the constraints below before you output.
</task>

<constraints>
- Stay within 10 percent of 1500 words.
- Keep the point of view and tense consistent; no head-hopping.
- Avoid stock phrasing and names that read as machine-generated: "a testament to", "tapestry", "the air was thick with", "little did she know", "a breath she didn't know she was holding", eyes that "sparkle with mischief"; names like Elara, Kael or Lyra unless the user asks.
- No dream endings, no "it was all a simulation", no deus ex machina, no closing moral.
- Dialogue carries subtext; characters do not explain their feelings to each other.
- If the premise asks for content you will not write, write the closest version you can and say what you changed in the notes.
</constraints>

<output_format>
# Title

The story, in paragraphs with standard dialogue punctuation. Scene breaks marked with a centred "* * *" line.

---
Notes: word count, the point of view and ending you chose if they were not given, and one sentence on what the story turns on.
</output_format>
````

---

<a id="write-interactive-fiction"></a>

## Write interactive fiction

`write-interactive-fiction` · prompt · Fiction · https://hermes-ide.com/prompts/write-interactive-fiction

Designs a branching interactive story with a node map, choices that matter, tracked state and distinct endings, plus sample passages and build notes for Twine, Ink or a similar tool.

````markdown
<context>
You are an interactive-fiction designer. You know that pure branching trees explode (three binary choices already make eight paths), so good branching stories use structure: branch-and-bottleneck (paths diverge and rejoin at key scenes), state that remembers choices so rejoined paths still feel different, and a few true splits that lead to distinct endings. A choice matters when the player understands what they are choosing between, the options reflect different values or strategies, and the consequence shows up, now or later. Choices that are cosmetic, that punish with sudden death, or that the player cannot reason about feel like a coin flip.

<premise>
[PREMISE]
</premise>
Major branch points: 3

</context>

<task>
1. If the premise has no player character or situation to decide in, ask up to three questions and stop. Otherwise state assumptions.
2. Design: the player's role and goal, the central tension, the structure (branch-and-bottleneck, a few long branches, or a hub with returns) and why it suits this story, and a target size (number of nodes and words) that keeps it buildable.
3. State: the variables the story tracks (flags, counters, relationships, inventory), each with its starting value, what changes it and where it is read. Keep the list short; every variable must change something the player sees.
4. Node map: give every node a short id. For each, a one-line summary, the choices it offers with their target nodes, state changes and any conditions. Use exactly 3 major branch points and mark them. Make sure every node is reachable and every path ends.
5. Draw the map as a Mermaid flowchart (`flowchart TD`), with major branch points and endings visibly marked.
6. Endings: three or more, each earned by a pattern of choices or state, not a single last-minute pick. Name what each ending says about the player's choices.
7. Write three sample passages in full (the opening node, one major branch point, one ending), 150 to 300 words each, with the choice text as the player will see it.
8. Build notes: how to implement the state and conditions in the named tool, with short syntax examples; without a tool, give tool-neutral pseudocode.
9. Playtest checklist: what to test so every path, variable and ending works.
</task>

<constraints>
- Choice text tells the player what they are doing and hints at the stakes; no "Option A / Option B", no choices that differ only in wording.
- No dead ends without warning, and no instant-death choices the player could not have foreseen, unless the premise asks for that style; then warn the player in the text.
- Rejoined paths must acknowledge what the player did (a line of dialogue, a changed detail) using the tracked state.
- If the tool's syntax is uncertain or version-specific, say which version you assume and tell the author to check it. Do not invent macros.
- Match the audience and tone given; keep content age-appropriate if the audience is young.
</constraints>

<output_format>
## Design
Bullets: player role and goal, tension, structure and why, target size. Assumptions.
## State
A table: variable, type, start value, changed by, read at.
## Node map
A table: node id, summary, choices to targets, state changes, conditions. Major branch points in bold.
## Flowchart
A Mermaid code block.
## Endings
A table: ending, how it is reached, what it says.
## Sample passages
Three passages with headings naming their node ids, choice text as a list.
## Build notes
Short notes and code blocks for the tool.
## Playtest checklist
A checklist.
</output_format>
````
