# Amazon Kdp Publishing

> Use this skill whenever the user wants to format, prepare, verify, or publish ANY book or print-on-demand product for Amazon KDP (Kindle Direct Publishing) — novels, non-fiction, children's picture books, coloring books, notebooks, journals, planners, log books, sketchbooks, or any other "low-content" product, in paperback, hardcover, and/or Kindle eBook form. Trigger this any time the user mentions KDP, Amazon self-publishing, paperback/hardcover formatting, trim size, bleed, gutter margin, spine width, cover calculator, ISBN for a book, EPUB for Kindle, or asks "is this ready for Amazon" / "will KDP accept this" / "check my formatting" — even if they don't say "KDP" by name. Also use this skill's QA workflow whenever asked to proofread, fact-check, or check consistency in a long manuscript (novel-length fiction), since that workflow is bundled here alongside the formatting specs.

- Skill: `moeeza3/amazon-kdp-publishing` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add moeeza3/amazon-kdp-publishing`
- Raw SKILL.md: https://api.skillmd.com/api/skills/moeeza3/amazon-kdp-publishing/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: moeeza3 (https://skillmd.com/u/moeeza3)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/moeeza3/amazon-kdp-publishing

---


# Amazon KDP Publishing

Complete reference for producing and verifying KDP-ready files across every KDP product type, plus a repeatable manuscript QA workflow for long fiction. Built from hands-on verification (real EPUBCheck runs, real page-size/font audits) — trust the numbers here over general knowledge, but re-verify anything price- or policy-related with a quick search, since KDP changes these periodically.

## Step 0 — Identify the product type first

Everything downstream (trim size, bleed decision, file format) depends on what's being made. Ask if it's not obvious:

| Product type | Typical trim | Bleed? | Interior file | Reference |
|---|---|---|---|---|
| Novel / non-fiction (paperback) | 6×9" | No | PDF (preferred) or DOCX | `references/paperback-hardcover.md` |
| Novel / non-fiction (hardcover) | 6×9", 6.14×9.21" | No | Same PDF as paperback, different cover | `references/paperback-hardcover.md` |
| Kindle eBook | n/a (reflowable) | n/a | EPUB (preferred) | `references/ebook-kindle.md` |
| Journal / notebook / planner / log book | 6×9" or 8.5×11" | Usually no (yes if full-page art) | PDF | `references/low-content-books.md` |
| Coloring book | 8.5×11" or 8.5×8.5" | Depends (see ref) | PDF, single-sided | `references/coloring-and-childrens.md` |
| Children's picture book | 8×10" or 8.5×8.5" | Yes (illustrations) | PDF | `references/coloring-and-childrens.md` |

A single title can need up to three separate files: a print interior PDF, an ebook EPUB, and a print cover PDF — each with **different rules**. Never assume one file satisfies two formats.

## Step 1 — Build to the right specs the first time

Read the relevant reference file(s) above before generating anything — margins, page-count math, and bleed decisions are cheap to get right up front and expensive to redo after a rejection. `references/paperback-hardcover.md` has the exact spine-width and full-cover-size formulas; use `scripts/spine_calculator.py` to compute them rather than doing the arithmetic by hand.

For the actual document build (docx/epub/pdf mechanics — reference-doc styles, page breaks, footers, gutter/mirror-margins XML, EPUB CSS, pandoc invocations), use the `docx`, `pdf`, and general markdown→pandoc techniques already in your toolkit; this skill tells you *what values to plug in*, not how to drive pandoc. The one KDP-specific gotcha worth restating: **LibreOffice's docx→pdf export can drift the page size by ~1pt from what you specified** (a twips-to-points rounding artifact) — always verify the exported PDF's exact page size with `pdfinfo` and hard-correct the MediaBox with `pikepdf` if it doesn't match the trim size exactly (see `scripts/fix_pdf_pagesize.py`).

## Step 2 — Run the compliance checklist before telling the user it's ready

Don't just assert a file is compliant — verify it, the way you'd verify code by running it. For each file type:

**Print interior PDF:**
1. `pdfinfo file.pdf | grep "Page size"` — must exactly match trim size × 72 (e.g. 6×9" = 432×648pt). Fix with `scripts/fix_pdf_pagesize.py` if off by any amount.
2. `pdffonts file.pdf` — every font row should show `emb: yes`. If a font isn't embedded, KDP may substitute unpredictably.
3. Page count: `pdfinfo file.pdf | grep Pages`. Confirm ≥ 24 (paperback minimum), and pad to an even number with a blank page for clean binding (not a hard requirement — KDP auto-rounds — but best practice).
4. No encryption: `pikepdf` → `pdf.is_encrypted` must be `False`.
5. No crop marks, no bleed unless the product actually needs it (see Step 0 table).
6. Margins/gutter meet the minimums in `references/paperback-hardcover.md` for the actual page count.

**Kindle EPUB:**
1. Run real EPUBCheck, not just an XML well-formedness check — download it if not present (`references/ebook-kindle.md` has the exact command). A file can be valid XML and still fail EPUBCheck's structural rules.
2. Confirm `nav.xhtml` (HTML TOC) and `toc.ncx` both exist.
3. Confirm `dc:title`, `dc:creator`, `dc:language` are set correctly in `content.opf`.
4. Confirm the cover is registered with `properties="cover-image"`.
5. No page numbers/headers baked into the CSS — Kindle is reflowable, those don't belong.

**Print cover PDF (wraparound):**
1. Dimensions must match the **exact** output of the spine calculator for the **final** page count, paper color, and binding (paperback vs hardcover) — recompute if the interior page count changes after the cover was built. This is the single most common rejection cause.
2. 0.125" bleed on all outer edges, all text/logos inside the 0.25" safe zone from trim.
3. CMYK color space, 300 DPI.
4. No crop marks/color bars in the delivered file.

Report results as a table (spec vs. actual, pass/fail) the way you would code review output — don't just say "looks good."

## Step 3 — Manuscript QA workflow (for novels / long fiction)

Independent of file formatting, a long manuscript needs a **content consistency pass** before it's truly ready to publish. This is a distinct skill from formatting — do this on the text itself, in phases, before final file generation. Full method, phase breakdown, and the categories of errors most worth checking → `references/manuscript-qa-workflow.md`.

Quick summary: build a "story bible" of names/ages/dates/rules as you write or before you check; then re-read the manuscript in 2–4 chunks (never all at once) cross-referencing every number and relationship claim against it; log every finding before fixing anything; fix in small verified batches; rebuild and re-render deliverables only after all fixes land. This process caught (and fixed) real timeline and genealogy errors in prior work — it's worth the extra pass on anything over ~20,000 words.

## Step 4 — ISBN, categories, rights

Quick reference only — verify current numbers before quoting a price. Full detail → `references/isbn-and-metadata.md`.

- KDP gives a **free ISBN** for paperback/hardcover only (not ebook, not required for low-content). It lists "Independently published" as publisher and can't be used outside KDP.
- Each **format** (paperback, hardcover, ebook, audiobook) needs its own ISBN if using paid ISBNs (Bowker in the US, ~$125 single / ~$295 for 10).
- Low-content books (journals, planners, notebooks) get a "Low-content" checkbox during KDP setup that changes some requirements — flag this to the user if the product is low-content.

## Working notes / things this skill got right in practice

- The 6×9" gutter/margin XML for python-docx-generated files: `pgMar` with a separate `w:gutter` attribute, plus `<w:mirrorMargins/>` in `settings.xml` (not in `sectPr` — a common mistake, it belongs in settings, not the section properties).
- `w:titlePg` + two `footerReference` entries (`type="first"` blank, `type="default"` with a PAGE field) cleanly suppresses the folio on the title page without needing multiple sections.
- Pandoc's EPUB writer auto-wraps any pre-first-heading content (title page, copyright, dedication) into an implicit section titled after the doc's metadata title, which renders as an unwanted duplicate heading — hide it in CSS with `section#<slugified-title> > h1 { display: none; }`, not by hiding the whole section (that hides the front matter too).