Skip to content

Teaching Claude Code to Print One-Pagers for a Doctor

How a custom Claude Code skill turns messy conversation-length analysis into branded, print-ready executive summaries — with a design system, component library, and one command to the printer.

Matt Dennis

The practice owner doesn’t want a terminal. She wants a sheet of paper.


Dr. Julia Ray runs an OBGYN practice. I build the automation that keeps it running — fax pipelines, patient intake, scraper workflows, lab request routing. When I finish an analysis (cost breakdown, operational audit, patient sync report), the deliverable isn’t a Slack message or a Notion doc. It’s a one-page printout she can read between appointments.


For months, the last step of every analysis was the same: copy numbers into a Google Doc, fight with margins, export to PDF, print. It took longer than the analysis itself.


So I built a Claude Code skill that does it in one command.


What’s a Skill?

Claude Code has a skill system. A skill is a markdown file that gives Claude a specialized capability — a prompt with instructions, context, and references it can pull in when triggered. Skills live in ~/.claude/skills/ and activate on natural language triggers or slash commands.


The exec-summary skill triggers on /exec-summary, “make a summary,” “print a report,” or “create a report for Julia.” When invoked, Claude reads the skill definition, pulls in the referenced design system, and generates a self-contained HTML file tuned to fit exactly one printed page.


The Design System

The skill has two files. The first is the workflow spec — what to do, in what order, for what audience. The second is a full CSS component library packaged as a markdown reference doc.


The design system defines the practice’s visual language:


  • Typography: Fraunces (serif, for headings and stat values) and Plus Jakarta Sans (sans-serif, for everything else), loaded from Google Fonts
  • Colors: Terracotta #B8847A as the primary accent, cream #FBF8F4 background, charcoal #3D3833 text, with semantic greens, reds, and oranges for status
  • Page dimensions: 8.5 x 11in, 0.45in padding, with print media queries that strip backgrounds and adjust margins

The component library gives Claude a vocabulary of building blocks:


Stat cards — a row of 3-4 KPIs at the top of the page with colored top borders (terracotta for neutral, green for positive, red for negative). Fraunces serif numbers at 20px make the key figures pop.


Data tables — dark charcoal headers, tabular-nums for alignment, row color classes (.row-danger, .row-warn, .breakeven-row) that let the table tell a story without annotation.


Key-value boxes — line-item breakdowns with a bold total row. Good for cost structures.


Inline SVG bar charts — no JavaScript libraries, no external dependencies. Claude builds the SVG directly — viewBox, grid lines, bars with rounded corners, color thresholds. A 320x110 chart fits cleanly in a half-width column.


Callout boxes — 2-3 color-coded cards at the bottom for the “so what.” Green for good news, orange for watch-this, red for act-now.


Every component includes the exact CSS and HTML pattern. Claude doesn’t improvise the styling — it reads the reference and assembles from known-good parts.


The Workflow

The skill defines a six-step process:


  1. Gather context from the conversation — what was the analysis about, what are the key numbers, what are the 2-3 things Dr. Ray needs to know
  2. Read the design system — Claude loads the component reference on every invocation
  3. Choose layout components based on data type — financial reports get stat cards + cost breakdowns + trend charts; operational audits get urgency-tiered sections with color-coded headers; patient summaries get categorized tables with status distributions
  4. Write the HTML — a single self-contained file, all CSS in a <style> block, no external deps except the font link
  5. Save to /private/tmp/{slug}.html
  6. Offer to printlp -o media=Letter -o fit-to-page

The audience constraint matters. The spec says: “Dr. Julia Ray, practice owner. She is not technical — translate data into business impact.” Claude doesn’t show Lambda invocation counts. It shows “23 faxes processed, 2 need manual review.” The skill forces a translation layer between raw findings and the printed output.


Fitting the Page

The hardest part of a one-pager is the “one page” part. The skill handles this with a fitting protocol:


Start with standard sizes from the design system. If content overflows, reduce in order: table font to 9px, stat values to 18px, callout body to 9px, then tighten margins by ~15%. If content is sparse, scale up stat cards, add a chart, increase spacing.


The target is 10.1 usable inches (11in minus padding). Claude measures by component height estimates rather than rendering — it doesn’t have a browser. In practice, this works well enough that I rarely need to adjust. When it’s off, it’s off by a quarter-inch, not a full section.


Layout Patterns

The skill pre-defines four layout archetypes that cover most of what the practice needs:


Financial reports — stat cards (MRR, overhead, net, runway) at top, cost breakdown + trend chart in a two-column middle, month-by-month table below, callouts at bottom.


Operational audits — summary stat bar, then urgency-tiered sections (urgent/warning/info) using color-coded headers, categorized tables within each tier, action items as callouts.


Proposals — problem stat cards, current vs. proposed comparison in two columns, impact projections as a chart, recommendation callouts.


Patient summaries — patient count stats, categorized tables (by status, provider, or visit type), status distribution, follow-up actions.


These aren’t rigid templates. They’re starting shapes that Claude adapts to the actual data. A financial report with only two months of data skips the trend chart and expands the cost breakdown. An audit with no urgent items drops the red tier entirely.


What This Actually Looks Like

A typical invocation: I spend twenty minutes in Claude Code analyzing the practice’s fax volume for the month — how many came in, processing success rate, which ones needed manual intervention, average Textract confidence scores. Then:


/exec-summary

Claude reads back through the conversation, picks out the numbers, selects a stat-card + table + callout layout, writes the HTML, and saves it. I open it in a browser to verify, then print.


The entire generation takes about fifteen seconds. The output is a branded document that looks like it came from a design tool, not a terminal. Fraunces headings, terracotta accents, clean data tables, color-coded insights at the bottom.


Why a Skill and Not a Template

A Jinja template or React component could generate this too. The difference is flexibility.


A template needs structured input — a JSON blob with exactly the right fields. The skill takes unstructured conversation context. I can do a rambling thirty-minute analysis that touches cost data, patient counts, and three tangential observations, and the skill extracts what matters and decides which components to use.


The design system is the constraint. The conversation is the input. The skill bridges them. That’s the part that would be painful to do with traditional templating — the judgment about what goes on the page and how to arrange it.


Building Your Own

The pattern generalizes. If you have a repeated output format — weekly reports, client deliverables, internal dashboards — you can build a skill for it:


  1. Design your component library as a CSS reference doc
  2. Write the workflow spec: what triggers it, what steps to follow, who the audience is
  3. Put both files in ~/.claude/skills/your-skill/
  4. Add trigger phrases to the skill frontmatter

The key insight is separating the design system from the generation logic. Claude is good at selecting and composing components from a reference. It’s less good at inventing a visual language from scratch on every invocation. Give it the parts and let it assemble.