Notion Print: From Notion Page to Paper in One Step
Two Claude Code skills that fetch Notion pages, convert them to print-ready Markdown, and optionally send them straight to the printer.
Notion at 4 PM Is Not a Printer
Nurul builds our lesson plans in Notion. Databases, linked pages, inline tables — the whole apparatus. She's good at it. The problem is that Notion thinks "print" means "export a PDF that looks like a screenshot of your browser, sidebar and all." Try printing a checklist that way and you get navigation menus, share buttons, and about forty percent of the actual content.
I tried the Markdown export once. Broken image links. No page formatting. No margin control. The file was technically correct and practically useless.
So I built two skills that turn any Notion page into paper.
The Bridge: notion-printable-markdown
The first skill doesn't print anything. It just gets the content out of Notion and onto the filesystem in a shape that's ready for conversion.
Give it a page title or a Notion URL and it extracts the 32-character page ID — Notion URLs come in several formats, with dashes, without, sometimes with a title slug prepended, sometimes not. The skill strips all of that down to the raw hex ID. It fetches the full page via the Notion MCP's notion-fetch tool, appends any child pages or linked databases below horizontal rules, and writes the result to /tmp/notion-print-<page-id>.md with A4 PDF front-matter baked in — format, margins, print background, all preset.
The output is a file. Not a printout, not a PDF. Just a clean Markdown file that's ready for md-to-pdf.
The Whole Pipeline: notion-print
The second skill does everything the first one does, then keeps going. It converts the Markdown to PDF via npx md-to-pdf, sends it to the Brother printer via lp, reports the print job ID, and optionally keeps the PDF for re-printing. It keeps it by default — I got tired of re-fetching pages I'd already converted once.
Say "print the Week 3 lesson plan from Notion" and paper comes out.
Why Two Skills Instead of One?
Separation of concerns — and I mean that practically, not architecturally. The print-lesson-plans orchestration skill needs the intermediate Markdown file because it fetches multiple Notion pages and prints them as a batch. If the Notion fetch and the printing were fused into one skill, the orchestrator couldn't control the flow. By splitting them, each step is independently usable and composable.
This is the same instinct behind Unix pipes. Do one thing. Do it well. Let something else handle the next step.
The Quirks You Don't See
Expiring image URLs. Notion stores images on S3 with short-lived tokens. By the time md-to-pdf tries to render them, the URLs have expired and you get blank rectangles. The skill catches this — it downloads images locally and rewrites the Markdown paths to local file URIs. I discovered this one the hard way, staring at a lesson plan printout that had neat rectangles where the diagrams should have been.
Child pages and inline databases. Notion's API doesn't auto-expand these. A page that looks complete in the browser comes back hollow from the API — just a reference, no content. The skill explicitly fetches each child page and appends it below a horizontal rule. This is the difference between printing what you see and printing what the API gives you.
Page ID extraction. This sounds trivial. It isn't. Notion URLs come in at least four formats, and the page ID is buried differently in each one. The skill normalizes all of them to the raw 32-character hex ID before making any API calls.
What You Can Say
Both skills support the same natural-language modifiers as the Markdown print skills: multiple copies, duplex, landscape, no margins. You can say "just save the PDF" or "just save the Markdown" to stop at intermediate steps. You can say "print the whole database" to loop over all results from a Notion search and print each page.
What it doesn't do is reformat the content. What's in Notion is what comes out on paper. If the lesson plan has a typo, the printout has a typo. This is a pipeline, not an editor.
In a future iteration, I want to add a preview step — render the PDF and open it before sending to the printer. Right now, printing is an act of faith. Usually justified. Occasionally not.
Comments ()