Novelist

View saved version →

---
name: analytical-review
description: Review novel outlines, drafted chapters, full manuscripts, and prior revision findings as an independent analytical editor. Use when the author explicitly requests critique, developmental review, work examination, line editing, proofreading, whole-manuscript review, or regression verification, and when an explicitly fully autonomous workflow covers the complete novel lifecycle from initial planning through publication. Produce an intent-aware, evidence-backed report with Overall Assessment, Work Examination, and Line Editing or Proofreading sections while remaining read-only by default. Do not invoke this skill automatically for ordinary planning, drafting, revision, continuity validation, EPUB export, build, regeneration, packaging, validation, or publication requests.
---

# Analytical Review

Before running a bundled command, resolve `<skill-dir>` to the absolute
directory containing this `SKILL.md`. Keep `--project-root` pointed at the
active novel workspace, not at the skill or plugin installation.

## Operating Contract

Adopt an independent reviewer role. Diagnose the work without changing it.
Do not edit outlines, chapters, canon, the story ledger, or generated output
during a review-only request.

If the author requests both review and revision, finish and present the
diagnosis before applying selected findings. Use `novel-story-telling` for the
revision phase and preserve finding IDs across the handoff.

Write all internal instructions, temporary schemas, and script inputs in
English. Return the review in this order of precedence:

1. the language explicitly requested by the author;
2. `project.md` `language`;
3. `style/000.style-guide.md` `language`;
4. the dominant language of the reviewed source.

Localize report headings naturally while preserving the semantic section order
defined in [report-contract.md](references/report-contract.md). For Korean
output, use the canonical labels `작품 총평`, `작품 검토`, and `문면 교열`.

Treat the current manuscript and review response as private runtime material.
Use relative source anchors and only the shortest excerpt needed for evidence.
Do not copy manuscript prose or review output into the project, plugin,
examples, fixtures, or generated package. Save a report only when the author
explicitly requests a file and confirms its destination.

## 1. Confirm Authorization, Mode, And Scope

Read [review-modes.md](references/review-modes.md). Select exactly one mode:

- `outline`: planned story direction before prose exists;
- `chapter`: one or more explicitly named Drafts;
- `manuscript`: every numbered publishable chapter plus cross-chapter synthesis;
- `regression`: bounded verification of earlier findings after revision.

Invoke this skill only when:

- the author explicitly requests review, critique, line editing, proofreading,
  developmental feedback, or verification of prior findings; or
- the author explicitly delegates the complete autonomous lifecycle from
  initial planning through final publication.

Do not infer review authorization from an ordinary planning, drafting,
revision, validation, export, build, package, or publish request. `Review and
publish` authorizes review but not automatic revision. `Proofread and fix`
authorizes both phases; keep them distinct.

Confirm the requested source scope. For a chapter request, identify exact
chapter numbers or relative paths. For regression mode, require the prior
finding IDs, dispositions, and changed units.

## 2. Orient To The Work

Read:

- `AGENTS.md`;
- `project.md`;
- `style/000.style-guide.md`;
- `plot/000.master-plot.md`;
- `outlines/000.master-outline.md`;
- the sources in the declared review scope;
- only the linked character, world, material, MacGuffin, and plot files needed
  to establish intent or continuity.

Do not load every source file by default. Use author-side sources to understand
intent, rules, and hidden truth. Use only publishable `## Draft` text to claim
that a reader knows, sees, or can infer something.

Resolve conflicting evidence by the project authority order: explicit author
direction > `final` source > `revision` source > latest manuscript fact >
`draft` source > outline or seed. Keep unresolved conflicts visible.

## 3. Inventory The Review Scope

Use the bundled content-free inventory helper before reading findings into a
whole-work conclusion.

For outline review:

```bash
python3 "<skill-dir>/scripts/inventory_review.py" \
  --project-root . \
  --mode outline
```

Add one or more `--target outlines/<file>.md` or `--target plot/<file>.md`
options when the author selected a narrower plan.

For chapter review:

```bash
python3 "<skill-dir>/scripts/inventory_review.py" \
  --project-root . \
  --mode chapter \
  --chapter <number>
```

For manuscript review:

```bash
python3 "<skill-dir>/scripts/inventory_review.py" \
  --project-root . \
  --mode manuscript \
  --max-batch-tokens 12000
```

The command prints relative paths, metadata, line ranges, hashes, estimates,
and batches without copying prose. Prefer this non-persistent output. If an
external file is explicitly needed, pass a fresh, non-existing `--output`
path; the helper creates it exclusively with private permissions and refuses
collisions. Stop short of a complete-coverage claim when `coverage_complete`
is false. Do not omit a valid numbered chapter because it appears unlikely to
produce feedback.

## 4. Build The Review Charter

Read [review-method.md](references/review-method.md). Before producing findings,
record:

- mode, scope, form, genre, point of view, style, and completion stage;
- work promise, intended reader experience, and target-reader assumptions;
- project constraints;
- protected techniques and the boundary of each protection;
- work-specific review axes;
- limitations and unresolved premises;
- any external research required to avoid a material false positive.

Derive axes from this work rather than forcing a universal checklist. Protect
an intentional device from generic correction while still testing whether each
instance performs its intended function.

Use external research only when it can materially change a finding. Prefer
primary sources and separate external evidence from manuscript evidence. Do not
browse merely to decorate the report.

## 5. Review Bounded Units

Read each eligible inventory unit in order. For a full manuscript, use the
inventory batches, but keep one result per chapter or stable bounded span.
Track:

- reviewed unit and Draft line range;
- evidence-backed strengths;
- work findings and line findings;
- open questions and unresolved premises;
- candidate cross-unit patterns;
- active, revised, or withdrawn review axes.

Mark a unit reviewed even when it has no material finding. Complete all unit
passes before synthesizing whole-work tendencies.

Test patterns with deterministic search when useful. A global tendency requires
multiple independent evidence locations. Keep a single local issue local.
Withdraw or revise a hypothesis when the complete available work disproves it.

In outline mode, evaluate planned causality, unit function, motivation,
reader-model progression, setup/payoff, constraints, and direction. Do not
claim defects in unwritten dialogue, diction, rhythm, or scene prose.

In regression mode, verify prior material findings and affected dependencies.
Limit new findings to revision regressions or directly related blockers. Do not
reopen deferred or rejected findings without materially changed evidence, and
do not begin another unrestricted review.

## 6. Write The Report

Read [report-contract.md](references/report-contract.md). Lead with:

1. Overall Assessment;
2. Work Examination;
3. Line Editing / Proofreading.

Localize those headings in the output language. For Korean, use `작품 총평`,
`작품 검토`, and `문면 교열`. Keep their semantic order.

Distinguish observation, interpretation, confidence, reader effect, and
suggested direction. Use stable `W1` and `L1` style IDs. Present minimal
revision options rather than a replacement manuscript.

Do not force a finding count. State when no material finding exists. Put
structural dependencies before dependent line edits in the revision order.

For manuscript mode, append a compact coverage table and compare its reviewed
unit set with the inventory. Do not claim whole-manuscript completion unless
every eligible unit appears and the inventory has no blocking issue.

The optional method appendix may summarize the charter, sources, limitations,
and withdrawn axes. Do not expose hidden chain-of-thought.

## 7. Handle The Handoff

For a review-only request, stop after the report and wait for the author to
select findings or request revision.

For an explicit review-and-publish request that does not authorize revision,
present the report, leave all literary findings unapplied, and then hand the
unchanged manuscript to `publish-novel` for its existing structural and
continuity preflight plus deterministic packaging. Literary findings do not
become build failures.

For an explicitly authorized review-and-fix request:

1. preserve finding IDs and author dispositions;
2. apply only selected changes through `novel-story-telling`;
3. update canonical sources and the story ledger as required;
4. run one focused regression review unless the author requests broader work.

For a fully autonomous start-to-publication request, follow the bounded
handoff in [review-modes.md](references/review-modes.md): manuscript review,
`apply`/`defer`/`reject` disposition, story revision, one focused regression
pass, strict continuity validation, then deterministic `publish-novel`
packaging.

Never inject this loop into an ordinary publication request. Deferred or
rejected literary findings are handoff state, not EPUB validation errors.

## Completion Gate

Do not finish until:

- the mode and source scope are explicit;
- the charter records protected techniques, axes, limitations, and uncertainty;
- reader-effect claims use reader-visible Draft evidence;
- every unit in scope has been inspected;
- full-manuscript coverage matches the deterministic inventory;
- strengths and recurring tendencies have evidence;
- outline review defers unwritten prose judgments;
- observations, interpretations, and revision options remain distinguishable;
- the report contains the three localized semantic sections in order;
- structural dependencies precede dependent line edits;
- review-only work left source files unchanged;
- no manuscript or review output was persisted without explicit authorization.

Referenced files: 7

View saved version →

---
name: create-character
description: Create character source files for this novel project. Use when the user wants to invent, refine, name, or save a fictional character into characters/ as Markdown with YAML frontmatter, especially from role, personality, setting, era, region, language, relationships, motives, secrets, or plot function.
---

# Create Character

## Overview

Use this skill to turn a rough character brief into a complete `characters/*.md` source file for this novel project.

Always follow the project's `AGENTS.md` and `characters/_template.md`. Keep the process interactive: refine the character first, then run a naming loop, then write the file only after the user confirms the final direction.

Before running a bundled command, resolve `<skill-dir>` to the absolute directory
containing this `SKILL.md`. This keeps the same skill usable from either the
repository-local skill tree or the Novelist plugin.

## Workflow

### 1. Gather And Reflect The Brief

Read existing context before asking questions:

- `AGENTS.md`
- `project.md`
- `characters/_template.md`
- Existing files in `characters/`
- Relevant `plot/`, `outlines/`, `world/`, `materials/`, or `macguffins/` files when the user references them

Restate the supplied role, character traits, and setting in Korean. Include:

- story role
- social role or occupation
- personality and behavioral texture
- era, region, class, language, nationality, and cultural background
- gender, including whether the character is gender-neutral
- relationship or plot function
- secrets, desires, conflicts, or contradictions if present

Ask what the user wants to add, remove, or sharpen. Continue this prompt loop until the user says it is enough or gives enough detail to proceed.

Do not create the character file during this stage.

### 2. Recommend Names

After the brief is sufficiently refined, propose about 10 names with short reasons.

Naming rules:

- If the character is Korean or lives as a Korean character in South Korea, recommend plausible Korean names in Hangul with family name and given name.
- If the setting gives a specific Korean era, region, class, or dialect background, reflect that context in the name choice and explain the reasoning.
- If the character is not Korean, keep both the original-language name and the Korean reading for use in the novel.
- If the original script is relevant, include it. Example: `Aleksandr Mikhailov / 알렉산드르 미하일로프`.
- If only a romanized original is appropriate, still include a Korean reading.
- Avoid copying the exact identity of a real living person unless the user explicitly requests a real person.
- Avoid joke names, overly symbolic names, and famous-name collisions unless the user asks for them.

For each option, show:

- displayed Korean name or Korean reading
- original name when non-Korean
- name language or cultural context
- reason it fits the role, personality, and setting

Ask the user to choose a name, request revisions, or provide a new naming direction. Continue this prompt loop until one final name is selected.

### 3. Build The Character Sheet

Create a complete character sheet using the selected name and refined brief.

Required frontmatter keys:

```yaml
id: char-ascii-slug
type: character
name: "김하나"
original_name: "김하나"
korean_reading: "김하나"
name_language: ko
name_context: "현대 대한민국"
aliases: []
role: ""
status: seed
age: ""
gender: ""
pronouns: ""
first_appearance: ""
last_seen: ""
relationships: []
wants: []
needs: []
conflicts: []
secrets: []
related_materials: []
related_macguffins: []
plot_threads: []
created: YYYY-MM-DD
updated: YYYY-MM-DD
tags: []
```

Use an ASCII filesystem slug, such as `kim-hana`, `alexandr-mikhailov`, or `old-palace-guard`. The file path must be `characters/<slug>.md`, and `id` must be `char-<slug>`.

Set `gender` explicitly when the user provides or confirms it. If the character is gender-neutral, use `gender: "성별 중립"` and keep pronouns or honorific usage consistent with the setting. If gender is intentionally undecided, ask once before writing; only use `gender: "미정"` when the user wants it left undecided.

The Markdown body must include these sections:

- `# <name>`
- `## Function`
- `## Surface`
- `## Interior`
- `## Relationships`
- `## Continuity`

Keep unknown values as empty strings or empty arrays instead of inventing hard canon.

### 4. Write The File

Prefer the bundled script:

```bash
python3 "<skill-dir>/scripts/write_character.py" --input /path/to/character.json --project-root .
```

Use a temporary JSON file containing the final agreed character data. The script writes `characters/<slug>.md`, refuses invalid slugs, and refuses to overwrite existing files unless `--force` is passed.

If the script is unavailable, create the Markdown file manually with the same frontmatter and body shape.

### 5. Verify

After writing:

- Confirm the file starts and ends frontmatter with `---`.
- Confirm `type: character`.
- Confirm `id` matches the filename slug.
- Confirm non-Korean characters include both `original_name` and `korean_reading`.
- Run `git status --short` and report the changed files.

Do not commit unless the user asks.

Referenced files: 2

View saved version →

---
name: create-material
description: Create story material source files for this novel project. Use when the user wants to generate, refine, or save raw novel material such as motifs, objects, scene seeds, dialogue seeds, research notes, themes, images, conflicts, clues, or reusable ideas into materials/ as Markdown with YAML frontmatter.
---

# Create Material

## Overview

Use this skill to turn a rough story-material prompt into a complete `materials/*.md` source file.

Always follow `AGENTS.md` and `materials/_template.md`. Generate useful seed material from the prompt, ask for missing information and intended story use, revise from feedback, then write only after confirmation.

Before running a bundled command, resolve `<skill-dir>` to the absolute directory
containing this `SKILL.md`. This keeps the same skill usable from either the
repository-local skill tree or the Novelist plugin.

## Workflow

### 1. Read Context

Read:

- `AGENTS.md`
- `project.md`
- `materials/_template.md`
- Existing files in `materials/`
- Relevant `characters/`, `macguffins/`, `plot/`, `outlines/`, and `world/` files if referenced

### 2. Generate A Material Draft

From the user's prompt, infer a compact first-pass material note in Korean. Include:

- material category, such as `scene-seed`, `motif`, `object`, `line`, `research`, `theme`, `image`, `conflict`, or `clue`
- raw idea
- possible story use
- related characters, MacGuffins, plot threads, or settings
- whether it is canonical yet
- constraints, risks, or questions
- open decisions the user should make

Mark inferred items clearly. Keep uncertain ideas as `status: seed` and `canonical: false`.

### 3. Ask For Direction

Ask the user what role this material should play:

- background texture or major plot driver
- literal object or metaphor
- one-scene use or recurring motif
- clue, red herring, image system, dialogue seed, or research note
- canonical fact or scratch seed

Continue the feedback loop until the user says it is enough or gives enough detail to save.

### 4. Build The Material File

Use a filesystem-safe ASCII slug. Save to `materials/<slug>.md`; `id` must be `material-<slug>`.

Required frontmatter:

```yaml
id: material-ascii-slug
type: material
title: ""
category: scene-seed
status: seed
source: ""
canonical: false
related_characters: []
related_macguffins: []
plot_threads: []
used_in_chapters: []
created: YYYY-MM-DD
updated: YYYY-MM-DD
tags: []
```

The Markdown body must include:

- `# <title>`
- `## Idea`
- `## Story Use`
- `## Notes`

### 5. Write And Verify

Prefer the bundled script:

```bash
python3 "<skill-dir>/scripts/write_material.py" --input /path/to/material.json --project-root .
```

Use a temporary JSON file with final confirmed data. The script writes `materials/<slug>.md`, refuses invalid slugs, and refuses to overwrite existing files unless `--force` is passed.

After writing, verify frontmatter delimiters, `type: material`, matching `id`, and `git status --short`. Do not commit unless the user asks.

Referenced files: 2

View saved version →

---
name: create-novel-project
description: Initialize a safe, self-contained Markdown novel workspace from the Novelist plugin scaffold. Use when the user wants to start, scaffold, bootstrap, or create a new novel project with source directories, templates, continuity rules, visual guidance, and EPUB output conventions.
---

# Create Novel Project

## Operating Contract

Create a novel source workspace from the scaffold bundled with this plugin. The
scaffold includes source directories, YAML-frontmatter templates, manuscript
markup rules, visual direction, and generated-output boundaries. It does not
copy another set of Agent Skills into the project; the installed Novelist plugin
continues to provide them.

Before running the bundled command, resolve `<skill-dir>` to the absolute
directory containing this `SKILL.md`.

## Workflow

1. Resolve the destination from the user's explicit path. If no path was given,
   use the current directory only when it is clearly the intended workspace;
   otherwise ask for the destination.
2. Gather a working title and BCP 47-style language tag when the user supplied
   them. Both are optional: the defaults remain `Untitled Novel` and `ko`.
3. Inspect the destination before writing. Preserve unrelated existing files.
4. Run the bundled initializer:

```bash
python3 "<skill-dir>/scripts/create_novel_project.py" \
  --project-root /absolute/path/to/novel \
  --title "Working Title" \
  --language ko
```

5. Do not pass `--force` merely because the destination exists. The initializer
   performs a complete collision preflight and writes nothing when a scaffold
   file would be overwritten. Use `--force` only after the user explicitly asks
   to replace the plugin-managed scaffold files.
6. Verify `project.md`, `AGENTS.md`, the source directories and templates, and
   `published/.gitignore`. Run `git status --short` when the destination is
   inside a Git repository.
7. Summarize the created paths and suggest the next relevant plugin skill, such
   as `create-setting`, `create-character`, or `create-plot`. Let the host
   apply its own invocation syntax.

## Safety Rules

- Never initialize into the plugin installation itself.
- Never delete unrelated destination files.
- Never copy `.git`, `.codex`, generated EPUB output, or project-local skill
  duplicates into the new workspace.
- Treat the copied Markdown files as canonical source and `published/` as
  generated output.
- Do not commit unless the user asks.

Referenced files: 3

View saved version →

---
name: create-plot
description: Create whole-novel plot and plot-thread source files for this novel project. Use when the user wants to generate, refine, structure, or save a central plot, act structure, promise, pressure, reversals, turns, reveals, or payoffs into plot/ as Markdown with YAML frontmatter.
---

# Create Plot

## Overview

Use this skill to turn a rough plot prompt into a complete `plot/*.md` source file.

Always follow `AGENTS.md` and `plot/_template.md`. Generate a workable plot skeleton from the user's prompt, ask for missing information and desired direction, revise through feedback, then write only after confirmation.

Before running a bundled command, resolve `<skill-dir>` to the absolute directory
containing this `SKILL.md`. This keeps the same skill usable from either the
repository-local skill tree or the Novelist plugin.

## Workflow

### 1. Read Context

Read:

- `AGENTS.md`
- `project.md`
- `plot/_template.md`
- `plot/000.master-plot.md`
- Existing files in `plot/`
- Relevant `outlines/`, `world/`, `characters/`, `materials/`, and `macguffins/` files if referenced

### 2. Generate A Plot Draft

From the user's prompt, infer a compact first-pass plot in Korean. Include:

- story promise
- protagonist pressure and opposition
- inciting incident
- core conflict
- act or sequence shape
- midpoint reversal
- lowest point
- climax choice
- resolution shape
- setups, reveals, and payoffs
- open questions and missing decisions

Mark inferred items clearly. Do not lock major canon facts without user confirmation.

### 3. Ask For Direction

Ask the user what to strengthen, remove, or decide. Focus on plot decisions with real consequences:

- emotional ending vs ironic ending
- external conflict vs internal conflict
- mystery-first, thriller-first, romance-first, or literary-first structure
- single protagonist vs ensemble pressure
- reveal timing and whether the reader knows more than the characters

Continue the feedback loop until the user says it is enough or gives enough detail to save.

### 4. Build The Plot File

Use a filesystem-safe ASCII slug. Save to `plot/<slug>.md`; `id` must be `plot-<slug>`.

Required frontmatter:

```yaml
id: plot-ascii-slug
type: plot
title: ""
scope: novel
status: seed
starts_in: ""
turns_in: []
pays_off_in: ""
characters: []
materials: []
macguffins: []
created: YYYY-MM-DD
updated: YYYY-MM-DD
tags: []
```

Use `scope: novel` for the whole-book plot and `scope: thread` for a subplot or plot thread.

The Markdown body must include:

- `# <title>`
- `## Promise`
- `## Pressure`
- `## Turns`

### 5. Write And Verify

Prefer the bundled script:

```bash
python3 "<skill-dir>/scripts/write_plot.py" --input /path/to/plot.json --project-root .
```

Use a temporary JSON file with final confirmed data. The script writes `plot/<slug>.md`, refuses invalid slugs, and refuses to overwrite existing files unless `--force` is passed.

After writing, verify frontmatter delimiters, `type: plot`, matching `id`, and `git status --short`. Do not commit unless the user asks.

Referenced files: 2

View saved version →

---
name: create-setting
description: Create whole-novel setting and worldbuilding source files for this novel project. Use when the user wants to generate, refine, or save a novel setting, era, region, social order, locations, rules, atmosphere, constraints, or continuity facts into world/ as Markdown with YAML frontmatter.
---

# Create Setting

## Overview

Use this skill to turn a rough novel-setting prompt into a complete `world/*.md` source file.

Always follow `AGENTS.md` and `world/_template.md`. Generate useful defaults from the user's prompt, but keep the process interactive: reflect the inferred setting, ask for missing information and direction, revise from feedback, then write only after the user confirms.

Before running a bundled command, resolve `<skill-dir>` to the absolute directory
containing this `SKILL.md`. This keeps the same skill usable from either the
repository-local skill tree or the Novelist plugin.

## Workflow

### 1. Read Context

Read:

- `AGENTS.md`
- `project.md`
- `world/_template.md`
- Existing files in `world/`
- Relevant `plot/`, `outlines/`, `materials/`, `macguffins/`, and `characters/` files if the prompt references them

### 2. Generate A Setting Draft

From the user's prompt, infer a compact first-pass setting in Korean. Include:

- era and time scale
- primary region and key locations
- social order, institutions, class pressure, and power structure
- material culture and technology level
- atmosphere, sensory palette, and recurring visual motifs
- rules or constraints that affect plot
- continuity facts that should not drift
- open questions and missing decisions

Mark inferred items clearly. Do not present guesses as fixed canon.

### 3. Ask For Direction

Ask the user what to add, remove, sharpen, or decide. The question must focus on missing information and authorial direction, not on generic brainstorming.

Good prompts:

- "시대는 조선 후기 그대로 둘까요, 아니면 가상의 왕조로 비틀까요?"
- "이 세계의 핵심 압박을 정치, 가족, 종교, 경제 중 어디에 두면 좋을까요?"
- "현실 고증을 강하게 가져갈지, 분위기 우선으로 변형할지 선택해주세요."

Continue the feedback loop until the user says it is enough or gives enough detail to save.

### 4. Build The Setting File

Use a filesystem-safe ASCII slug. Save to `world/<slug>.md`; `id` must be `world-<slug>`.

Required frontmatter:

```yaml
id: world-ascii-slug
type: world
title: ""
category: setting
status: seed
time_period: ""
locations: []
rules: []
related_characters: []
related_materials: []
used_in_chapters: []
created: YYYY-MM-DD
updated: YYYY-MM-DD
tags: []
```

The Markdown body must include:

- `# <title>`
- `## Description`
- `## Story Pressure`
- `## Continuity`

### 5. Write And Verify

Prefer the bundled script:

```bash
python3 "<skill-dir>/scripts/write_setting.py" --input /path/to/setting.json --project-root .
```

Use a temporary JSON file with final confirmed data. The script writes `world/<slug>.md`, refuses invalid slugs, and refuses to overwrite existing files unless `--force` is passed.

After writing, verify frontmatter delimiters, `type: world`, matching `id`, and `git status --short`. Do not commit unless the user asks.

Referenced files: 2

View saved version →

---
name: create-visual-asset
description: Create cover and illustration image assets for this novel project with an available raster image provider. Use when the user wants to plan, generate, refine, or save a book cover, chapter illustration, spot illustration, visual motif, or image prompt while preserving a consistent visual style across assets.
---

# Create Visual Asset

## Overview

Use this skill to create project-bound cover and illustration assets for the novel.

Always preserve visual consistency by reading `style/visual-style-guide.md`
first. Detect the image-generation capabilities available in the current host,
then use the matching guide:

- Codex: `references/codex-image-generation.md`
- Claude Code: `references/claude-image-generation.md`
- Antigravity CLI: `references/antigravity-image-generation.md`
- External API or CLI provider: `references/external-image-provider.md`

Save final project-bound assets under `assets/cover/` or
`assets/illustrations/`; never leave a referenced asset only in a provider's
default output location.

## Required Context

Read before generating:

- `AGENTS.md`
- `project.md`
- `style/visual-style-guide.md`
- relevant `chapters/*.md`, `outlines/`, `plot/`, `world/`, `characters/`, `materials/`, and `macguffins/` files for the requested asset
- existing files in `assets/cover/` and `assets/illustrations/`

If `style/visual-style-guide.md` is incomplete, ask the user for missing visual direction before generating a final asset.

## Workflow

### 1. Identify Asset Type

Classify the request as one of:

- `cover`: front cover image for EPUB packaging
- `chapter-illustration`: full-width or full-page illustration tied to a chapter
- `spot-illustration`: smaller image embedded within a chapter
- `motif`: reusable visual symbol, object, or atmospheric plate
- `reference`: visual exploration not yet used in the manuscript

Confirm the intended destination and filename slug before saving.

### 2. Gather Direction

Summarize the likely image in Korean:

- subject
- narrative moment or symbolic function
- setting and time period
- characters shown or deliberately omitted
- composition and crop
- mood, lighting, palette, and texture
- continuity constraints from source files
- whether text should be included

Ask for missing direction when it affects the image. For covers, ask about tone, central image, and whether the title/author text should be left out for later typography. Prefer no generated text unless the user explicitly asks for it.

### 3. Build A Style-Locked Prompt

Use the visual style guide as the stable base. Keep the prompt concise but specific:

```text
Use case: illustration-story
Asset type: <cover|chapter-illustration|spot-illustration|motif|reference>
Primary request: <specific image>
Story context: <chapter/plot/world context>
Style/medium: <from style/visual-style-guide.md>
Composition/framing: <crop, subject placement, negative space>
Lighting/mood: <from style guide plus asset-specific mood>
Color palette: <from style guide>
Materials/textures: <paper, ink, grain, brush, lens, etc.>
Continuity constraints: <must match story facts>
Text: no text, no title, no watermark unless explicitly requested
Avoid: <style guide avoid list plus asset-specific avoid list>
```

### 4. Select And Invoke A Raster Provider

Inspect the tools actually available in the current agent host. Prefer, in
order:

1. a verified built-in raster image generator;
2. a configured image-generation MCP server or agent tool;
3. an author-approved external API or CLI adapter.

Do not infer image-generation capability from image input, image analysis, or
generic file tools. Do not substitute SVG, HTML, or placeholder art.

For project-bound assets:

1. Generate the image with the selected raster provider.
2. Inspect the result for style, subject, composition, and continuity.
3. Iterate only with targeted changes.
4. Move or copy the final selected image into the project:
   - cover: `assets/cover/<slug>.<ext>`
   - chapter illustration, spot illustration, motif, or reference: `assets/illustrations/<slug>.<ext>`
5. Report the saved path and final prompt.

If no raster provider is available:

1. say clearly that no image was generated;
2. return the complete style-locked prompt without shortening it;
3. link the relevant host guide and
   `references/external-image-provider.md`;
4. offer to continue after the author connects a provider;
5. do not create a fake asset or register a nonexistent image in Markdown.

### 5. Register In Markdown

For cover assets, store or update the cover path in `project.md` frontmatter when the user confirms it as the active cover:

```yaml
cover_image: assets/cover/cover.png
```

For chapter illustrations, add a normal Markdown image reference inside the target chapter when the user asks to insert it:

```markdown
![Alt text](../assets/illustrations/001-scene-slug.png)
```

Do not edit manuscript prose merely to place an image unless requested.

## Cover Missing During EPUB Build

If another workflow needs a cover and no usable cover exists, ask whether to generate one. Ask for the desired feeling, central image, and whether it should include text. If the user approves, use this skill to create the cover before building the EPUB.

## Verification

Before finishing:

- Confirm the final asset exists inside the workspace.
- Confirm the filename is filesystem-safe.
- Confirm project or chapter references use relative paths that the EPUB builder can resolve.
- Confirm the image follows `style/visual-style-guide.md`.
- Run `git status --short` and report changed files.

Referenced files: 7

View saved version →

---
name: novel-story-telling
description: Design and control whole-novel storytelling, reader mental-model progression, chapter-to-chapter flow, conflict escalation and resolution, reveals, foreshadowing, continuity, safe chapter-file creation, and next-chapter handoffs for this Markdown novel repository. Use when planning, drafting, or revising story structure, modeling what a target reader knows, infers, misreads, or still asks at each story turn, auditing cohesion or reader orientation, preparing or writing the next chapter from prior context, creating a template-conformant chapter under chapters/, checking contradictions, maintaining story-state summaries, selecting genre-specific narrative devices, or auditing character, timeline, world-rule, clue, MacGuffin, and plot-thread continuity.
---

# Novel Story Telling

Before running a bundled command, resolve `<skill-dir>` to the absolute directory
containing this `SKILL.md`. Keep `--project-root` pointed at the active novel
workspace, not at the skill or plugin installation.

## Operating Contract

Treat `chapters/` as manuscript canon and all other source directories as planning and continuity evidence. Follow `AGENTS.md`. Never edit `published/` as source.

Write all agent instructions, temporary prompts, schemas, and script inputs in English. Write manuscript prose and author-facing creative output in this order of precedence:

1. the language explicitly requested by the author;
2. `project.md` `language`;
3. `style/000.style-guide.md` `language`;
4. the dominant language of recent chapters.

Preserve names, honorifics, invented terms, and spelling from canonical files. Do not translate them unless requested.

Resolve conflicts by authority: explicit author direction > `final` source > `revision` source > latest manuscript fact > `draft` source > outline or seed. Report unresolved conflicts; do not silently choose or invent canon.

## Analytical Review Routing Boundary

Keep analytical review separate from ordinary planning, drafting, and revision.
Do not invoke `analytical-review` unless the author explicitly requests
critique/review or explicitly delegates the complete autonomous novel lifecycle
from initial planning through publication.

For that fully autonomous start-to-publication request only, after all chapters
are drafted and before calling `publish-novel`:

1. run whole-manuscript `analytical-review`;
2. record each material finding as `apply`, `defer`, or `reject` with a concise
   rationale;
3. apply selected findings through this storytelling workflow and update canon;
4. run one bounded analytical regression review;
5. complete strict continuity validation;
6. call `publish-novel` for deterministic packaging.

An ordinary request to finish remaining chapters, revise known material, or
publish an existing manuscript does not by itself authorize this loop. If the
author explicitly asks for review and revision together, keep diagnosis and
application distinct and preserve finding IDs through the handoff.

## Core Workflow

### 1. Orient

Read `AGENTS.md`, `project.md`, `style/000.style-guide.md`, `plot/000.master-plot.md`, and `outlines/000.master-outline.md`. Determine:

- output language and prose constraints;
- current story promise and governing question;
- target reader baseline, including genre literacy, prior reader-visible anchors, active questions, and unfamiliar terminology;
- target chapter and its irreversible change;
- active plot threads, promises, clues, and MacGuffins;
- current character knowledge, desire, condition, relationship, and location;
- hard world rules and timeline constraints.

Do not load every source file into context by default.

### 2. Build A Bounded Context Pack

Run:

```bash
python3 "<skill-dir>/scripts/build_story_context.py" \
  --project-root . \
  --chapter <number> \
  --query "<POV, location, entities, conflict, or theme>" \
  --max-tokens 6000 \
  --output-language auto \
  --output /tmp/story-context.md
```

Read the resulting pack. It prioritizes explicit links, active master sources, the target outline, recent chapters, the story ledger, and query matches. It includes source paths so every inferred constraint can be checked against canon.

Treat the context pack as author-side evidence, not proof that a reader has seen a fact. Reconstruct reader knowledge only from prior publishable `## Draft` text and explicitly recorded reader-facing evidence. Synopsis, Revision Notes, outlines, character sheets, hidden truth, and canon-fact ledger entries do not count as reader exposure. Treat recorded expected inferences as editorial hypotheses and spot-check them against Draft before relying on them.

Increase the budget only when the pack proves insufficient. Prefer linked fact cards and `Continuity` sections over full old chapters. Read a full source file only to resolve ambiguity or recover scene-level nuance.

### 3. Select Narrative Structure

Read [story-flow.md](references/story-flow.md) for whole-book and chapter-unit control. Read only the genre references needed for the current project:

- [wuxia.md](references/wuxia.md) for jianghu ethics, obligations, factions, techniques, and reputation;
- [science-fiction.md](references/science-fiction.md) for speculative premises, system consequences, and rule-bound solutions;
- [time-travel-and-loop.md](references/time-travel-and-loop.md) for temporal ontologies, causal state, and repeated-loop progression;
- [mystery.md](references/mystery.md) for fair clues, truth timelines, suspect logic, and reveal control;
- [drama.md](references/drama.md) for relationship pressure, recognition, reversal, and costly repair;
- [romantic-entanglement.md](references/romantic-entanglement.md) for jealousy, triangle dynamics, intimacy allocation, betrayal, and relational aftermath.

For hybrids, select one primary story engine and at most two secondary engines per chapter. Preserve each genre's reader contract. For example, a romantic subplot may intensify a mystery, but it must not excuse an unseeded solution.

### 4. Establish The Story-Control Frame

Before outlining or drafting, state compactly:

- **Promise:** the experience and central question owed to the reader.
- **Pressure source:** the person, system, relationship, scarcity, secret, or clock preventing an easy answer.
- **Change chain:** cause → decision → consequence → new constraint.
- **Thread states:** dormant, active, escalating, converging, paid, or intentionally deferred.
- **Information states:** what the reader, viewpoint character, allies, and opponents know or falsely believe.
- **Reader-model path:** entry model → recalled anchor → reader-visible cue → intended inference → confirmation, contradiction, or reframe → exit question or prediction.
- **Cost ladder:** what becomes harder, more public, more intimate, less reversible, or more morally expensive.
- **Resolution condition:** the decision and established mechanism capable of answering the promise.

Keep a distinction between facts, plans, and hypotheses. A plan in an outline is not yet an event in canon.

### 5. Design The Next-Chapter Contract

Give the chapter one primary job. Define:

- entry state and inherited emotional residue;
- viewpoint, location, world time, and elapsed time;
- immediate objective and opposition;
- active thread or promise being moved;
- reader entry model: what the target reader can recall, currently believes or suspects, and wants answered;
- information to expose, reinterpret, conceal legitimately, or pay off;
- reader update: the primary observation and inference the chapter enables, the textual prerequisite for it, and any ambiguity intentionally retained;
- one meaningful relationship or power shift;
- one irreversible or costly change;
- reader exit model: what picture has become clearer or been reframed, and what question or prediction now pulls the reader forward;
- exit state and hook into the following chapter;
- details that must not change.

Use the chapter motion `inherit → pressure → choice → consequence → handoff`. Vary scene rhythm and emotional temperature inside that motion. Do not force a twist when a decision, recognition, or cost produces the stronger turn.

### 6. Run Pre-Draft Continuity Gates

Run the structural audit:

```bash
python3 "<skill-dir>/scripts/check_continuity.py" --project-root .
```

Then perform the semantic gate using the context pack:

| Dimension | Entry fact | Proposed change | Evidence | Valid transition? |
| --- | --- | --- | --- | --- |
| Character knowledge |  |  |  |  |
| Physical state and possessions |  |  |  |  |
| Relationship and obligation |  |  |  |  |
| Location and elapsed time |  |  |  |  |
| World or genre rule |  |  |  |  |
| Clue, secret, or reveal |  |  |  |  |
| MacGuffin custody and meaning |  |  |  |  |
| Open thread and promised payoff |  |  |  |  |

Fix an invalid transition in the plan before drafting. If the author intends a retcon, identify every affected source file and obtain confirmation before changing established canon.

Then map the chapter's major beats with the reader-model table in [story-flow.md](references/story-flow.md). Every required inference must have reader-visible prerequisites. Preserve local orientation—who wants what, what changed, and why it matters—even when the larger truth remains hidden. Split or sequence a beat that requires several unrelated new names, rules, timelines, and causal claims at once unless overload is an intentional experience.

### 7. Draft Or Revise The Chapter

Follow the author-approved chapter contract and existing voice. Make every scene change at least one of: knowledge, leverage, relationship, objective, risk, resource, location, or commitment.

Preserve causal links. Use `therefore` or `but` transitions between major beats more often than unrelated `and then` transitions. Let relief expose consequences, deepen attachment, or reposition the next threat.

Compose information as a reader-state transition: anchor the current picture, present a perceivable cue, permit the intended inference, and let action or consequence use that update. The reader need not know the hidden truth, but must be able to understand the immediate situation and recover the intended causal bridge. Prefer reordering, dramatizing, bridging, or pruning information over repairing every gap with explanation. Preserve rewarding subtext and inference instead of explaining away all ambiguity.

Do not hide information that the viewpoint character is actively thinking merely to manufacture surprise. Hide significance, access, motive, or interpretation instead.

For a new chapter, prepare a reviewed UTF-8 JSON payload. Use English field names and write `title`, `synopsis`, `draft`, and creative notes in the manuscript language:

```json
{
  "number": 7,
  "title": "The Burned Index",
  "slug": "the-burned-index",
  "status": "draft",
  "pov": "char-protagonist",
  "timeline": "Day 12, after sunset",
  "setting": "world-royal-archive",
  "word_target": 2500,
  "characters": ["char-protagonist"],
  "materials": [],
  "macguffins": ["macguffin-burned-index"],
  "plot_threads": ["plot-main"],
  "outline": "outline-chapter-007",
  "published": false,
  "tags": [],
  "synopsis": "One or two paragraphs describing the chapter's change.",
  "draft": "Complete manuscript prose.",
  "revision_notes": "Optional reviewed notes."
}
```

Write it with the bundled guardrail:

```bash
python3 "<skill-dir>/scripts/write_chapter.py" \
  --project-root . \
  --input /tmp/chapter-007.json
```

The script must create exactly `chapters/NNN.lowercase-ascii-slug.md`, populate the repository chapter schema, and refuse any existing chapter number or path. Never bypass that refusal. If the number already exists, treat the task as a revision and edit that file minimally; do not regenerate or replace the whole file. Preserve its `created` date, set `updated` to the current ISO date, keep `number`, `id`, `title`, `slug`, filename, and H1 synchronized, and retain author text outside the requested revision.

Every chapter file must follow `chapters/_template.md` and contain exactly one H1 matching `title`, followed by exactly one each of `## Synopsis`, `## Draft`, and `## Revision Notes`. Put manuscript prose only in `## Draft`. Remove all template placeholder prose. Do not write a chapter outside `chapters/`, nest it in a subdirectory, omit YAML arrays, or invent non-ASCII filenames.

Treat the chapter file as an editorial container: only `## Draft` is
publishable. Keep Synopsis and Revision Notes useful to writers, but never
repeat their text as a preface, summary, or appendix inside Draft.

Use the Draft Markdown contract consistently:

- Use normal Markdown paragraph boundaries: only a blank line starts a new
  paragraph. Dialogue markup does not force a paragraph boundary.
- Keep narration as plain prose. Wrap every spoken range as exact `*“…”*`,
  whether it stands alone or shares a paragraph with narration, as in
  `*“Approved.”* Rhea said.` EPUB maps only that range to
  `<i class="dialog">` with serif italic styling.
- Do not allow 5 consecutive dialogue-only paragraphs. Before the fifth, add a
  speaker anchor, meaningful action, narration beat, or indirect response. Do
  not add an empty attribution merely to satisfy the gate; use a beat that also
  clarifies speaker, emotion, power, space, or changed information.
- Reserve unquoted `*…*` for interior thought. Use curly single quotes `‘…’`
  for cited wording, remembered phrasing, or a quotation nested inside speech.
  A curly double-quoted span anywhere outside exact `*“…”*` markers is an error
  because it cannot be styled or classified safely.
- Use `**…**` only for genuine strong emphasis. Keep every marker pair balanced
  on one line.
- Use inline backticks only for literal machine output, UI labels, filenames,
  code identifiers, or log text.
- Put `---` alone between blank lines for a scene or time break. Never use
  `* * *` or a decorative bullet sequence.
- Do not use lists, blockquotes, or fenced code blocks anywhere inside Draft.
  Reserve H3 through H6 for genuine subheadings and do not add another H2 inside
  Draft.

Immediately after creating or revising the file, run:

```bash
python3 "<skill-dir>/scripts/check_continuity.py" \
  --project-root . \
  --strict
```

Resolve every error. Review warnings and either fix them or report why they are intentional. Do not present a malformed chapter as completed.

After the structural gate, run the reader mental-model audit in [story-flow.md](references/story-flow.md) using only reader-visible Draft text. At each scene or major turn, state what the target reader can now describe, likely believes or suspects, still asks, and anticipates. Compare that reconstruction with the intended trajectory and repair accidental confusion, author-knowledge leakage, unsupported inference, cognitive overload, or inert repetition.

The strict gate must reject curly double-quoted speech without the surrounding
emphasis, straight ASCII dialogue quotes, and 5 consecutive dialogue-only
paragraphs without a readability break. It must accept narration before or
after a marked dialogue range in the same paragraph, shorter dialogue-only
runs, unquoted italic interior thought, and curly single-quoted cited wording.

### 8. Post-Draft State Update

After the author accepts or finalizes a chapter:

1. Update source files for newly canonical character, world, plot, MacGuffin, or style facts.
2. Prepare a reviewed JSON fact card in the manuscript language:

```json
{
  "chapter": 12,
  "title": "Chapter title",
  "summary": "Objective account of what changed.",
  "canon_facts": [],
  "state_changes": [],
  "timeline_changes": [],
  "knowledge_changes": [],
  "reader_model_changes": [
    {
      "id": "reader-model-change-id",
      "status": "expected",
      "evidence": "Reader-visible detail in Draft.",
      "expected_inference": "What the target reader can now infer.",
      "uncertainty": "Alternative interpretation or confidence limit."
    }
  ],
  "open_reader_questions": [],
  "macguffin_changes": [],
  "open_threads": [],
  "resolved_threads": [],
  "uncertainties": []
}
```

Keep `reader_model_changes` editorial rather than canonical. Use separate `evidence` and `expected_inference` fields, and record an `uncertainty` whenever another interpretation remains plausible. Record `open_reader_questions` only when the chapter intentionally keeps them alive; do not use this section for missing explanations or continuity gaps.

3. Preview the deterministic ledger change:

```bash
python3 "<skill-dir>/scripts/update_story_ledger.py" \
  --project-root . --input /tmp/chapter-state.json --dry-run
```

4. After verifying every item against the chapter, rerun without `--dry-run`.
5. Rebuild the next chapter's context pack and rerun the continuity audit.

Never record speculation as a fact. Put ambiguity in `uncertainties` with competing interpretations.

## Token Discipline

- Use the ledger for stable outcomes and recent chapter excerpts for voice and immediate physical continuity.
- Retrieve by explicit source links before lexical relevance.
- Keep hard invariants even when they appear unrelated to the current scene.
- Trim prose before trimming rules, obligations, clue states, or character knowledge.
- Recompute context after an accepted chapter rather than carrying a stale chat summary forward.
- Treat token estimates as conservative approximations; inspect the generated pack size before expanding it.

## Completion Gate

Do not finish a story-planning or chapter task until:

- the target change advances the story promise or intentionally complicates it;
- escalation changes kind or cost, not only volume;
- the chapter exit differs materially from its entry;
- the target reader's exit model differs intentionally from its entry model;
- every required reader inference has prior reader-visible evidence or a recoverable causal bridge;
- intended ambiguity preserves local orientation and is not accidental confusion;
- all used knowledge, rules, objects, and relationships have provenance;
- setups and payoffs remain tracked;
- the output language and prose style match the author's contract;
- structural audit errors are resolved;
- the chapter exists directly under `chapters/` with synchronized filename, frontmatter, H1, and required body sections;
- Draft prose follows the paragraph, dialogue, emphasis, literal-text, and
  scene-break Markdown contract;
- new canon is reflected in source files and the reviewed story ledger when applicable.

Referenced files: 15

View saved version →

---
name: publish-novel
description: Publish this Markdown novel project as a validated EPUB using the skill's bundled packaging script. Use when the author asks to publish, export, build, regenerate, package, or validate the novel or EPUB; when checking publication metadata, chapter readiness, covers, illustrations, generated output, or EPUB integrity; or when coordinating a missing cover before publication.
---

# Publish Novel

Before running a bundled command, resolve `<skill-dir>` to the absolute directory
containing this `SKILL.md`, and resolve `<skills-dir>` to its parent directory.
Keep `--project-root` pointed at the active novel workspace, not at the skill or
plugin installation.

## Operating Contract

Turn an author request such as "Publish this novel" into the complete EPUB workflow. Do not ask the author to type shell commands. Run the bundled script yourself, verify the result, and report the artifact path.

Treat Markdown and project assets as canonical source. Treat `published/epub/` and `.epub` files as generated output. Never repair a generated EPUB by hand; update source and republish.

Retain both outputs after a successful build. `published/epub/` is the
inspectable staging tree, while `published/*.epub` is the ZIP-based EPUB
container intended for reading software. Rebuilding may replace the contents of
the staging tree, but publication must not delete it after packaging.

Interpret `publish` as local EPUB generation only. Do not upload, distribute, email, release, or submit the book to a storefront or external service unless the author explicitly requests that separate action.

Do not invoke `analytical-review` merely because the author asks to publish,
export, build, regenerate, package, or validate an existing novel. Ordinary
publication retains the structural and continuity preflight below. When a
fully autonomous start-to-publication workflow was explicitly authorized, the
orchestrating storytelling workflow must complete analytical review,
finding disposition, revision, and bounded regression review before handing
the manuscript to this skill. Keep literary judgment out of `build_epub.py`.

## Workflow

### 1. Read Publication Context

Read:

- `AGENTS.md`
- `project.md`
- `published/README.md`
- publishable chapter filenames and frontmatter, plus image references needed for packaging
- `style/visual-style-guide.md`
- existing files under `assets/cover/` and `assets/illustrations/`

Preserve the manuscript language and project terminology.

Do not load the full prose of every chapter into model context. Let the bundled script stream chapter bodies during rendering. Read chapter prose only when diagnosing a rendering, image, or metadata problem.

### 2. Run Preflight

Confirm:

- at least one chapter matches `NNN.ascii-slug.md`;
- chapter numbers and filenames are in the intended order;
- every chapter's H2 sections are exactly `## Synopsis`, `## Draft`, and
  `## Revision Notes` in that order, with one non-empty, case-sensitive Draft
  outside fenced code;
- the requested manuscript is complete enough to publish;
- title, author or pen name, and language are known;
- all local Markdown image references inside Draft exist, and the selected
  cover exists;
- the output and staging paths remain under the intended project.

Run the story skill's strict structural audit before packaging:

```bash
python3 "<skills-dir>/novel-story-telling/scripts/check_continuity.py" \
  --project-root . \
  --strict
```

Stop on malformed dialogue markup or any other structural error. Canonical
dialogue is an exact `*“…”*` range that may stand alone or share a paragraph
with narration; interior thought is unquoted `*…*`, and cited wording uses
`‘…’`.

If any chapter is not `final`, list it and ask for confirmation before publishing unless the author explicitly requests a draft or proof EPUB.

If the title is empty or still a placeholder, ask for the publication title. If the author is missing, ask for the author or pen name; do not silently publish as `Unknown Author` without confirmation. Pass one-time metadata as script options. Update `project.md` only when the author asks to make it canonical.

### 3. Resolve The Cover

Find a cover in this order:

1. a path explicitly supplied by the author;
2. `cover_image` in `project.md` frontmatter;
3. `assets/cover/cover.png`, `.jpg`, `.jpeg`, or `.webp`.

If no cover exists, ask whether to create one or publish without one. When the
author wants a cover, use the `create-visual-asset` skill, save it under
`assets/cover/`, verify the final image, and resume publication. Do not block a
coverless publication after the author confirms that choice.

### 4. Publish

Run the bundled script from the repository root:

```bash
python3 "<skill-dir>/scripts/build_epub.py" \
  --project-root .
```

Add only the options needed for confirmed metadata or output choices:

```bash
python3 "<skill-dir>/scripts/build_epub.py" \
  --project-root . \
  --title "Publication Title" \
  --author "Author or Pen Name" \
  --language ko \
  --cover assets/cover/cover.png \
  --output published/novel.epub
```

The script must:

- render only each numbered chapter's `## Draft` content in filename order;
- fail before staging changes when the exact H2 sequence differs or Draft is
  missing, duplicated, or empty;
- exclude the title-container H1, Synopsis, and Revision Notes from manuscript
  rendering, while adding the canonical chapter title from frontmatter;
- render ordinary Markdown paragraphs as `p.prose` in a sans-serif stack and
  each canonical `*“…”*` speech range as `<i class="dialog">`, styled with a
  serif italic stack without forcing a paragraph boundary;
- render inline Markdown backtick ranges as fixed-width `<code>` text and use
  local CSS `::before` and `::after` content to show the opening and closing
  backtick glyphs to readers; these visible delimiters are a narrative marker
  for machine text that is evaluated literally, not disposable source syntax;
  place the complete inline code range on a subtle translucent background with
  a dark-mode override, while inheriting the reader's foreground color;
- render a standalone `---` or legacy Markdown thematic break as a semantic
  `<hr class="scene-break" />` paired with visible centered `* * *` text before
  list parsing;
- treat legacy thematic-break rendering as defensive compatibility only;
  canonical Draft source must use standalone `---` and pass the strict audit;
- use reader-compatible CSS with no external font or stylesheet dependency;
- ignore template files;
- package block and inline local images;
- include the selected cover when present;
- keep staging inside `published/epub/` by default;
- retain that staging tree after packaging;
- write `published/novel.epub` by default as a ZIP-compatible EPUB container;
- write `mimetype` as the archive's first, uncompressed member;
- validate the final archive automatically.

### 5. Verify And Report

Require the script's successful validation report. It checks:

- a non-empty ZIP-compatible EPUB;
- the first, uncompressed `mimetype` entry;
- required container, navigation, package, and stylesheet members;
- at least one rendered chapter;
- well-formed XML and XHTML;
- packaged targets for local `href` and `src` references.

Also inspect the generated chapter XHTML when changing the publisher or chapter
markup rules. Confirm that editorial headings and text from Synopsis or Revision
Notes are absent; every marked speech range becomes `<i class="dialog">` even
when narration follows in the same paragraph; unmarked thought remains `<em>`;
inline `<code>` uses a fixed-width stack and visibly retains both backtick
delimiters through CSS; and each scene break has a visible centered `* * *`
ornament instead of being emitted as a list.

To validate an existing artifact without rebuilding, run:

```bash
python3 "<skill-dir>/scripts/build_epub.py" \
  --project-root . \
  --validate-only published/novel.epub
```

Report:

- the absolute EPUB path;
- title, author, and language used;
- chapter and packaged-image counts;
- whether a cover was included;
- confirmation that the staging tree was retained alongside the final EPUB;
- any warnings or intentionally accepted draft conditions.

Run `git status --short` and separate generated ignored output from source changes. Do not commit `published/*.epub` or `published/epub/` unless the author explicitly asks.

## Failure Handling

- Stop when no publishable chapter exists.
- Stop when a chapter has no unique, non-empty `## Draft` section.
- Stop when a referenced local image is missing.
- Stop when the cover path is invalid.
- Stop when staging points outside a generated subdirectory of `published/`.
- Stop when the EPUB output points outside `published/` or inside its staging directory.
- Stop when EPUB validation fails; report the exact member or reference and repair the canonical source or bundled script before rebuilding.
- Never claim publication success from file existence alone.

Referenced files: 3