I wrote a book as one Markdown file and needed two different interiors for Amazon KDP: a reflowable EPUB for Kindle and a fixed-size PDF for paperback.
I built an open-source Claude skill that creates both from the same manuscript. I used the workflow for my own book, then separated it into a reusable build script, templates, and instructions.
The outputs still need to be checked in KDP’s preview tools. The skill removes repeated formatting work; it does not make every manuscript ready for publication without review.
One source produces two layouts
An ebook and a printed book use different layout rules.
Kindle readers can change the font, size, and screen orientation. Page numbers and fixed headers do not behave like they do on paper. A paperback has a fixed trim size, inside margin, page count, and page breaks.
The workflow treats them as two outputs:
Markdown manuscript
├── EPUB: reflowable chapters and navigation
└── PDF: fixed trim size, margins, and page numbersTrying to make one file serve both formats usually creates compromises in both.
What the skill asks for
The manuscript can be a .md or .txt file. Markdown headings identify the chapters. Optional front matter can supply the title, author, language, publisher, rights statement, description, and cover image.
When the skill runs, it also needs:
- the trim size for the paperback;
- whether the book uses bleed;
- the body font size;
- optional publisher metadata;
- an optional ebook cover image.
The paperback cover is a separate file. Its spine width depends on the final page count and paper choice, so the interior must be finished before the full cover can be sized correctly.
The build uses standard publishing tools
The current version uses Pandoc to parse the Markdown and build the EPUB. Pandoc and XeLaTeX produce the print PDF from a template.
The pipeline:
- reads the manuscript and metadata;
- converts top-level headings into chapters;
- builds the ebook navigation and styles;
- applies the selected paperback trim size;
- calculates the minimum inside margin from the page count;
- generates the EPUB and PDF in one output folder.
Amazon changes its specifications, so the margin table should be checked against the current KDP paperback submission guidelines. KDP currently varies the minimum inside margin by page-count range. The old version of this article gave an incorrect margin for a 300-page book; the official table, not the article, is the source to follow.
What still needs manual review
Automation works best for text-heavy books with a simple structure.
Check the output carefully when the manuscript contains:
- tables wider than the page;
- footnotes or endnotes;
- many images;
- full-bleed illustrations;
- code blocks;
- unusual fonts or languages;
- complex front matter;
- custom running headers.
For the EPUB, test navigation, chapter order, links, images, and the reading start position. For the PDF, inspect page breaks, blank pages, widows and orphans, margins, font embedding, and image resolution.
KDP’s Print Previewer may find problems that are not obvious in a normal PDF viewer. A successful local build is therefore the start of quality control, not the end.
Why I packaged it as a Claude skill
The writing and editing already happened in Claude. Packaging the build instructions as a skill lets the same workspace ask for missing metadata, run the script, inspect errors, and rebuild after a correction.
The core script can also run outside Claude from a command line. It requires Python, Pandoc, and XeLaTeX. Keeping that standalone path matters because the publishing workflow should not depend entirely on one chat interface.
Use the repository as the source
The kindle-book-skill repository contains the skill, build script, templates, supported trim sizes, and installation instructions. It is released under the MIT license.
Before using it for a full manuscript, build a small sample with the same headings, images, notes, and trim size as the real book. Upload that sample to KDP’s preview tools and fix the template once. Then build the complete book.
That test catches more problems than running a 300-page manuscript through an untested layout and reviewing every page afterward.