// Convert a Markdown file to a styled PDF and iterate on the design visually. Use when the user asks to render markdown as a PDF, style a PDF, produce a printable handout, or tune the look of a generated PDF. Ships a neutral default theme; pairs with any styling skill that provides a CSS file.
| name | markdown2pdf |
| description | Convert a Markdown file to a styled PDF and iterate on the design visually. Use when the user asks to render markdown as a PDF, style a PDF, produce a printable handout, or tune the look of a generated PDF. Ships a neutral default theme; pairs with any styling skill that provides a CSS file. |
| license | MIT |
| compatibility | Requires Python 3.10+ and `uv` on PATH. Rasterize step requires `poppler` (`pdftoppm`) — install with `brew install poppler` (macOS) or `apt-get install poppler-utils` (Debian/Ubuntu). |
Render a Markdown file to a styled PDF, then iterate on the design by reading the rasterized pages as images.
Use this skill whenever the user asks to:
Does: Markdown → HTML (via markdown-it-py) → PDF (via WeasyPrint) with a single CSS file controlling all styling. Rasterizes the result so the agent can visually inspect pages.
Does not: Dictate visual design. Styling is fully decoupled — this skill ships a neutral default CSS and lets any styling skill, project config, or explicit flag override it.
Styling is a single CSS file. Resolution order (first match wins):
--css <path> passed to scripts/render./.markdown2pdf/style.css relative to the current working directoryassets/default.css bundled with this skill (neutral fallback)Any other skill can plug in by producing or pointing at a CSS file. Brand skills should expose a path like <their-skill>/assets/pdf.css and instruct the user to pass it via --css.
Run these steps. Do not skip the visual inspection — page breaks, code-block overflow, and callout styling often look wrong in the PDF even when the Markdown source looks fine.
Render the Markdown to PDF:
scripts/render <file>.md [--css <path>] [-o <out.pdf>]
Output: <file>.pdf (or the -o target) plus a printed PDF: / CSS: summary.
Rasterize the PDF to PNG pages:
scripts/rasterize <file>.pdf
Output: one PNG per page under /tmp/pdf-preview/. Each page's absolute path is printed on its own line.
Read every PNG with the Read tool and inspect the actual rendered layout. Check:
Iterate. Edit either the Markdown (content/structure) or the CSS (visual design), then repeat from step 1. Keep iterating until the user approves.
| What to change | Where to edit |
|---|---|
| Content, order, wording | The Markdown file |
| Fonts, colors, spacing | The CSS file (--css or project-local) |
| Page size, margins | @page { size: ...; margin: ...; } in CSS |
| Page breaks | page-break-before/after/inside in CSS, or <div style="page-break-before: always"></div> in Markdown |
See references/css-cookbook.md for common print-CSS recipes (page breaks, avoiding splits, headers/footers, code-block overflow).
Render with the default theme:
scripts/render report.md
Render with an explicit brand stylesheet from another skill:
scripts/render report.md --css ~/.claude/skills/brand-acme/assets/pdf.css
Render with a project-local override (automatic, no flag needed):
# project has ./.markdown2pdf/style.css committed
scripts/render report.md
Debug by dumping the intermediate HTML:
scripts/render report.md --dump-html
Triage all open issues in a GitHub repository: fetch them via the gh CLI, classify each by type, priority, and quality, flag likely duplicates and stale/low-quality reports, suggest labels, and produce a prioritized triage report. Read-only by default — recommends writes (labels, comments, closes) but never applies them without explicit human approval, one batch at a time. Use this skill when the user wants to triage their GitHub issues, clean up their backlog, label untriaged issues, find duplicate issues, identify stale bugs, prioritize what to work on next, or asks things like "help me triage my issues", "what should I work on from my backlog", or "which of my open issues are duplicates".
Applies Computer Love's official brand colors and typography to any sort of artifact that may benefit from having Computer Love's look-and-feel. Use it when brand colors or style guidelines, visual formatting, or company design standards apply.
Creates or extends static HTML slide decks under presentations/ using the shared iframe shell, slides.js manifest, and per-slide HTML. Use when the user asks to make, create, build, or add presentations, slide decks, slides, or HTML decks in this repository, or when they mention PRESENTATION_GUIDE or presentations/supply-chain-security as a template.
Author a new ralph — a directory containing a RALPH.md file that defines an autonomous agent loop for the ralphify runtime. Use when the user wants to create, draft, design, or scaffold a ralph for a repeatable autonomous task (test coverage, bug hunting, migrations, research, TODO execution, docs improvement, etc.). Asks a thorough set of questions up front, explores the target project for real test/lint/type commands, drafts RALPH.md from scratch using the canonical 5-section body shape, bundles helper scripts when commands need shell features, presents the draft for review, and writes the files only after sign-off.
Drive a Claude-Code-style plan-mode interview for ambitious work and emit a set of small, self-contained plan files that a ralph (or any fresh-context agent) can execute independently. Use when the user wants to plan something too big for a single plan file — multi-subsystem refactors, migrations, new features touching unrelated areas, or any work they intend to run through the execute-plans ralph. Runs an iterative interview → explore → decompose → draft → review → write loop. Each emitted plan file follows Claude Code's plan format (Context, recommended approach, critical files, existing code to reuse, verification) — not the research-plan-implement/create-plan framework. Read-only until the user signs off, then writes numbered plan files to ./plans/ or ./plans/groups/<name>/ in the project repo.
Set up a persistent workspace/ directory for AI agents in any project. The workspace gives agents a place to store artifacts, reports, and notes that persist between chat sessions. Use this skill when the user mentions "agent workspace", "workspace setup", wants to set up a shared working area for agents, or when another skill needs workspace/ and it doesn't exist yet. Also use when the user asks where agents should save their output or how to organize agent artifacts.