From Skill to Printable: The Render-to-DOCX/HTML Scripts

Chat is not a lesson plan. You cannot walk into a third-period classroom holding a scroll of conversation, and you cannot photocopy a chat window for twenty-eight students. Yet most AI-for-education demos stop exactly there — at a wall of well-formatted text in a panel — and quietly leave the last, tedious hop to you: the copy-pasting, the reformatting, the fighting with margins at 9:40pm.

The open-source k12-lesson-planning skill takes a different stance, and it's the part builders should study most closely. Buried in the skill's scripts/ folder are two small programs — render_lesson_docx.py and render_lesson_html.py — plus a theme.css. They exist to turn a structured lesson into an actual file: a Word document and a styled web page. That design choice tells you what Anthropic and Learning Commons decided the deliverable really is. Not a transcript. A printable.

The last mile no one budgets for

Ask any teacher where AI tools fall down and you'll hear a version of the same complaint: the output looks great and is useless in its current form. It lives in a browser tab. It has to be extracted, cleaned, split into a teacher version and a student version, and dropped into whatever format the school actually uses. That last mile is unglamorous, and it's where the time savings evaporate.

The k12-lesson-planning skill, part of the open-source repo at github.com/anthropics/k12-teacher-skills, is built to draft a standards-aligned plan and student-facing materials — and then to hand them over as documents. Because the skill draws on widely used curricula mapped to state standards and on the fine-grained learning components beneath each standard, the content that reaches the render step is already scaffolded. The scripts just make it tangible. The design principle is simple and worth stating plainly: a lesson you can't print is a draft, not a deliverable.

The finish line for a teaching tool isn't a good answer on screen — it's a classroom-ready file in a teacher's hands. Everything before the file is preamble.

What the render scripts actually do

The scripts/ directory carries three files, and each earns its place. If you clone the repo and look, here's the division of labor:

• render_lesson_docx.py — takes the lesson (a structured JSON representation) and produces a .docx Word document. Word is the lingua franca of the staff room: it opens on every district laptop, it prints without surprises, and it can be edited by a teacher who has never touched a terminal. This is the format that survives contact with real school infrastructure.
• render_lesson_html.py — renders the same lesson into a styled .html page. HTML is what you project on the board, share as a link, or paste into an LMS. It's the screen-facing twin of the printable, generated from the identical source so the two never drift apart.
• theme.css — the stylesheet the HTML renderer applies. Pulling styling into one file means the look of every lesson is consistent, adjustable in one place, and separated from the content. Change the theme once and every future lesson inherits it.

One structured lesson, two rendered artifacts, one shared theme. That's the whole shape, and it's deliberately small.

Why a JSON in the middle is the smart move

The quietly clever decision here is the intermediate representation. Claude doesn't render straight to Word prose; it produces a structured lesson — sections, objectives, materials, tiers, student-facing tasks — and then the scripts render that structure into formats. Separating the content from its presentation is a discipline borrowed from good software, and it pays off three ways for teachers.

First, one source of truth means the printed handout and the projected page can never contradict each other; they're rendered from the same object. Second, a structured lesson is easy to re-render: fix a typo or reorder an activity in the plan, run the scripts again, and both files regenerate cleanly — no manual reformatting in two places. Third, structure is what makes differentiation composable. The sibling k12-lesson-differentiation skill adapts a lesson into below-, at-, and above-level tiers while keeping the core content consistent; because everything is structured rather than free text, those tiers can be rendered into per-proficiency student materials the same way. The render layer doesn't care how many versions you asked for — it just prints them.

If you've read Inside k12-lesson-planning, this is the back half of that pipeline: the skill's references/ folder grounds the content in subject-specific rigor, and the scripts/ folder turns the result into something you can staple.

A file you can edit is a file you'll trust

There's a trust argument hiding in the file format, too. A teacher is the accountable professional in the room, and the tools that earn a place in a real planning routine are the ones that hand back editable artifacts rather than locked outputs. A .docx invites revision. You open it, you strike the example that won't land with your fourth-period kids, you add the vocabulary word your ELL students need, you initial it and it's yours.

That's the right relationship. Claude for Teachers is explicitly designed to assist instructionally and give teachers more time for the human relationships at the heart of learning — not to replace professional judgment. Rendering to a plain Word document keeps the teacher firmly in the editor's chair. The skill does the assembly; you do the final call. A tool that produces something you can change is a tool you'll actually use on Monday.

It also means the output degrades gracefully. If your school blocks a connector, or you're planning offline on the train home, the artifact is still a file on disk — not a session you have to be logged in to recover. The printable outlives the chat.

Where the printable ends and the design tool begins

Render-to-DOCX/HTML is the right default because it's universal and editable, but it's intentionally plain. Sometimes a lesson wants more than clean type: a one-page visual organizer, an interactive activity, a slide deck with real polish. That's the seam where the render scripts hand off to the connector ecosystem — the Canva for Education connector turns lesson materials into classroom-ready designs and interactive experiences, and other partners take the content further still.

Think of it as a spectrum. The scripts give you the dependable, printable core that works everywhere and edits anywhere. The design connectors give you the high-production version for the lessons that warrant it. Both start from the same grounded, standards-aligned content — you're choosing a finish, not regenerating the substance.

For builders, the lesson is portable well beyond K-12: your skill's job isn't done when the model produces good text. It's done when a non-technical user has a file they can open, change, and use. Study render_lesson_docx.py and theme.css not for the Python, but for the philosophy — the artifact is the product. If you're assembling your own classroom stack, marketplace skills like Lesson Plan Studio and Exam Blueprint sit naturally alongside this same file-first mindset.

Ship the file. That's the finish line.

---

Part of the Claude for Teachers series. Related: Inside k12-lesson-planning: How the Open-Source Skill Works · Canva for Education + Claude: Lessons into Classroom-Ready Designs. Browse AI tutoring skills or more builder insights.