The method · fiction and non-fiction

FROM IDEATO KDP

Separate the writing from the editing. Everything else follows from that.

Write it yourself or let the AI draft it — either way the framework keeps the structure and the layout under watch. Markdown, Pandoc, and a crew of AI editors that review blind and then get verified.

How it worksThe pipeline
FROM IDEA TO KDP coverFree · book + template
Scroll
The short version

How I write books with AI

A book is a series of documents, each of which has to be right before the next one becomes useful: premise, voice, outline, chapters, review, revision.

The trick that makes AI useful is to separate the writing from the editing. I draft with one process and one voice. I review with a crew of agents that each check exactly one thing — tension, pacing, voice, logic, mechanics, copyedit — and never read each other’s reports. Mixing the two produces mush: prose that gets “improved” into a blender, and reviews nobody can act on.

Write the prose yourself, or ask the AI to draft it. Both work, and you can switch per chapter. What the framework guarantees is not the sentences — it is that the structure and the layout stay watched: the outline holds, the voice guide is enforced, the facts are checked, and the build produces a book-shaped object every time.

The reviewers are the other half. They find what I cannot see in my own draft, and then I verify every countable claim against the text before acting on it. In this book’s last full orbit, six independent agents raised 31 findings and 2 of the 29 countable ones were simply wrong. That ratio is the reason verification is a step and not a nicety.

The same pipeline runs for fiction and non-fiction. The difference is three files in the bible: a novel starts from a story premise, characters, and a timeline; a non-fiction book swaps those for a book premise, a reader-and-promise file, and a verified-facts file that holds every asserted claim. The build, the voice guide, the review orbit, and the publishing path are identical.

Everything is plain text in git. The manuscript, the canon, and the full review archive are reviewable the same way code is.

The loop, one document at a time
  1. 01PremiseThe promise, the reader, the ending — before any prose exists.
  2. 02VoiceExtracted from your own published writing, then used as a spec.
  3. 03OutlineChapter by chapter: what changes, and what it costs.
  4. 04ChaptersDrafted against the outline and the voice guide, never freehand.
  5. 05ReviewSix blind agents, one concern each, then reconciled.
  6. 06RevisionEvery finding applied, declined with a reason, or proven wrong.

Each revision feeds back into the premise. The book is done when the gate checklist is green, not when the draft ends.

The pipeline

Six stages, one loop

Each stage produces a file that the next stage depends on. The whole thing is a Makefile, a bible directory, and a set of agent definitions — copy-ready in the template.

Before a word of prose

Three documents decide whether the book is worth writing. Skipping them is how drafts die at chapter twelve.

The premise that kills bad ideas

One file that has to state the promise, the reader, and the ending before drafting starts. Most ideas do not survive being written down this plainly, which is the point — it is cheaper to lose an idea here than at 40,000 words.

template/bible/story-premise.md
A voice guide from your own corpus

Extract the voice from writing you already published: sentence patterns, paragraph length, the words you never use. It becomes a spec an agent can check against, and a banned-tell list that catches generated prose. This costs nothing and it is the entire battle.

template/bible/voice.md
The outline as a contract

Chapter by chapter, what changes and what it costs. Once it exists, the outline pins the spine so that each chapter improves the book instead of pulling it a degree off course.

template/bible/master-outline.md

The review orbit

One agent per concern, each blind to the others, then a reconciler that verifies every countable claim before anything reaches the manuscript.

Six blind reviewers

Tension, pacing, voice, logic, mechanics, copyedit — each a separate agent with one job and no sight of the other reports. Blindness is what makes agreement meaningful: when three of them independently flag the same paragraph, that is signal rather than echo.

template/agents/
Isolation beats one long context

Running the six passes inside one context produced 24 findings, 2 blocking, and zero detectable consensus. Six isolated agents produced 31 findings, 9 blocking, 3 independent consensus items — and were wrong far less often on verification: 2 of 29 against 6 of 23.

Reconcile, then disposition

A reconciler reads every report, checks the countable claims against the text, merges the overlaps, and writes a response file. Every finding ends up applied, declined with a reason, or verified as wrong. If you cannot write down why you declined a blocking finding, you have not made the decision.

template/agents/review-reconciler.md
The instrument nobody opened

A photograph of a printed page found what six agents and four builds missed: an ASCII diagram had wrapped mid-token. The LaTeX log held 30 overfull boxes and no agent had ever read it. The diagram is an SVG now and the count is zero. Agents check what you point them at; some defects only exist in the artifact.

Build and publish

One source, four outputs. Markdown and Pandoc rather than a word processor, so the manuscript stays diffable and the build stays repeatable.

Four files from one make

A single make target produces the KDP paperback interior, the Kindle EPUB, both cover files, and a validation pass over the lot. The A4 proof is a separate target for reading on screen and annotating.

template/Makefile
The whole KDP dashboard, written down

Trim size, bleed, spine width, tax setup, categories, the gate checklist before you call it done. Two chapters of the book cover the part no blog post covers properly, because it is tedious rather than interesting.

template/bible/kdp-publishing.md
The whole loop as one skill

The pipeline is compressed into an installable book-writer skill — one standard SKILL.md, the same file in Claude Code, Codex, and opencode. Point it at a premise and it holds the loop from blank page to publish gate.

skill/book-writer/SKILL.md

What this does not do

The failure modes are more useful than the wins, and they are all mine rather than hypothetical.

It does not decide the sentences

Whether you type the prose or the AI drafts it against the outline and the voice spec, the words are your call. What the framework watches is the scaffolding around them — structure, continuity, layout — not whose hand produced the paragraph.

It does not replace a cold read

One gate line in this book’s review archive is still red, and it is the one no agent can close: no human has read chapter one cold. Everything an agent tells you about a first page is a prediction, not a reaction.

The measuring instruments lie too

The public review archive records five separate occasions where a tool or an agent was confidently wrong. Writing the book found four real bugs in this repository’s own template; they became chapters instead of quiet fixes.

the full review archive
Read it

From Idea to KDP

17 chapters in five parts, 18,398 prose words, 109 printed pages. Every command in it was run on the machine that wrote it, and where a command misbehaved, the misbehaviour is in the text. Free, in every format it builds.

EPUBKindle · 1.1 MBPDF · A4read on screen · 226 KBPDF · 5.5×8.5paperback trim · 252 KBHTMLone page, in browserThe repotemplate + skill + review archive
AI-generated content label

Transparency note

AI-assisted creation

AI tools helped create and edit this book, including parts of the text and cover artwork. Jacob Verhoeks directed the work, reviewed and revised the manuscript, and is responsible for the final published edition.