An employee handbook in Markdown, exported as a book

Keep the handbook as a folder of Markdown files, one per section, under version control, and publish it as a numbered, dated PDF each time it changes — with an EPUB for phones. The wiki can stay for day-to-day reading; the exported book is the thing HR can say a given person received on a given date.

Every company has a handbook and almost none can say what was in it on a particular Tuesday. It lives in a shared document, or a wiki, and it is edited in place by whoever noticed the parental-leave section was out of date. The result is a handbook with no editions — which is a handbook that cannot be relied on for the one thing a handbook exists for.

Why handbooks rot in Docs and wikis

A wiki is designed to be edited by many hands and to show the latest version. Those are virtues for a knowledge base and faults for a policy document. Three things go wrong, reliably.

  • There is no edition. Someone signed to say they had read the handbook. Which one? The version history exists but nobody can produce the page as it looked when they signed.
  • Structure drifts. Sections get added where they were easiest to add, headings get restyled by hand, and after two years the document has four different styles of policy heading and a section 3.1 that is not under section 3.
  • It is not portable. A handbook that only exists inside a tool is unavailable to the person who was offboarded from that tool last week, and unreadable to the lawyer who asked for a copy.

A plain-text source fixes the first two: text under version control has a history that can be reproduced, and the styling is applied by the renderer, not the editor. Exporting fixes the third.

One file per section, combined at export

Do not write the handbook as one long file. Write it as a folder, one Markdown file per section, named so they sort into reading order:

handbook/
  00-front-matter.md
  01-welcome.md
  02-how-we-work.md
  03-leave-and-time-off.md
  04-expenses.md
  05-security-and-devices.md
  06-conduct.md
  99-version-history.md

Each file starts with a ## heading — the section title — never a #, which is reserved for the book's title in the front matter file. A section's sub-policies are ###. Then combine the files in name order into one manuscript and typeset that. The person who owns expenses edits one small file; the export is the whole thing.

Number the sections in the headings themselves — ## 3. Leave and time off — so that a policy can be cited by number in an email, and keep the numbers stable: a new section goes at the end or takes a decimal, and a retired one leaves a heading that says it was retired. Renumbering a handbook breaks every reference to it that anyone ever wrote down.

Version it with git, publish it with a date

Put the folder in a git repository. That is the entire versioning system, and it is a better one than any document tool ships: every change has an author, a date and a reason, and any past state can be produced on demand. Non-technical editors can use a desktop client; the workflow is edit, describe the change, save.

Then decide what an *edition* is. A reasonable rule: the handbook is re-exported whenever a policy changes, the version number goes up, and the export is what gets sent out. Small wording fixes can accumulate into the next edition. The repository's history is for the editors; the numbered PDF is for everyone else.

ArtefactLives whereFor whom
The Markdown sourceGit repositoryThe people who edit the handbook
The dated PDFSent to staff, kept by HRThe record of what a person received
The EPUBShared drive or intranetReading on a phone or tablet
The wiki pageWherever it wasDay-to-day lookup, clearly marked as a copy

The version page

The last section of the book is a table of editions: version, date, what changed, who approved it. It is the page that answers the question the wiki could not, and it is also what turns the handbook from a document into a publication. New starters get the current edition; the version page tells them, and anyone auditing later, exactly which one that was.

## Version history

| Version | Date | Change | Approved by |
| --- | --- | --- | --- |
| 3.2 | 2026-09-02 | Parental leave extended to 20 weeks (§3.4) | People team |
| 3.1 | 2026-05-14 | Expense limits updated (§4.2) | Finance |
| 3.0 | 2026-01-08 | Full revision for the new year | Leadership |

Put the version number and date on the cover as well, or on the page after it. A PDF that says *Employee Handbook, v3.2, September 2026* on its first page is one that can be filed.

Tables for policies, page numbers for references

Most policy content is tabular whether or not it is written that way: leave entitlements by length of service, expense limits by category, notice periods by role. A table is easier to check than the same facts buried in a paragraph, and easier to update — the number changes, the sentence around it does not have to. Tables that run over a page need the header row repeated on the next one, which bukpress does on its own; check that whatever you export with does the same, because a page of unlabelled numbers is a policy nobody can apply.

Page numbers are not decoration in a handbook. "See page 14" in an email, a signed acknowledgement that names a page, a grievance that cites one — all of them depend on the footer. Turn page numbers on, and write the contents page as a list of the numbered sections. Leave page numbers out of the contents unless the edition is final; the section numbers are the stable reference, the page numbers are for finding.

A Brand Kit so every edition matches

The handbook is the document most employees will read most carefully from the company, and it should look like the company. Set the typography once — the body face, the heading face, the colours, the cover artwork, the page background — and save it. In bukpress that is a Brand Kit: every edition starts from the same settings, so version 3.2 looks like 3.1 without anyone re-choosing a font, and the same kit typesets the onboarding guide and the security policy so the set reads as a set.

For the type: a plain, readable serif or sans at 11pt, generous margins, and a heading face with enough weight that section titles are visible when flipping. The six typographic decisions apply here as to any book; the only handbook-specific one is restraint. Nobody wants a distinctive handbook.

PDF for the record, EPUB for the phone

Export both. The PDF is the edition — fixed pages, fixed page numbers, embedded fonts, the file that is sent, signed for and filed. The EPUB is the copy someone reads on the train on their first morning, with the section outline as its navigation and the text reflowing to the screen. Same source, same edition number, two files.

That is the whole system: a folder of small files, a history, a numbered export. It takes an afternoon to set up, and the next time someone asks what the handbook said in March, the answer is a file rather than a shrug.

Read next

How-to · 4 min read

How to combine Markdown files into one book

Keep chapters as separate files while you write, named so they sort in book order, then concatenate them into one manuscript with a page-break marker between each file. Do this as a last step, not as a working habit — the combined file is what you typeset; the per-chapter files stay the thing you edit.

Read it
How-to · 4 min read

Markdown tables that survive the page break

A table that crosses a page loses its header because most Markdown-to-PDF pipelines emit a plain HTML table with no thead, and repeating a header row requires the renderer to know which row is the header. Fix the markup first, then the renderer.

Read it
How-to · 5 min read

How to add a table of contents to a Markdown book

A printed table of contents is a page you write: a list of chapter titles, in order, with a page break before the first chapter. An EPUB does not need that page — its table of contents is generated from the heading structure and lives in the reader's navigation. Get the headings right and both fall out of the same manuscript.

Read it

Write it in Markdown. Ship a book.

bukpress turns the file you are already writing into a typeset PDF and EPUB — your type, your covers, no watermark on any plan.

Start free — no card required