| name | recommend-rendering-service |
| description | Recommend a document rendering engine or service for the user's stack and constraints, and produce a worked integration example for the chosen one. Covers Typst CLI, Carbone, PDFMonkey, APITemplate.io, DocRaptor, Docmosis, Adobe Document Generation API, and contextually surfaces Templafy and PandaDoc when fit. Use when the user asks "what should I use to render PDFs?", "which doc-gen service fits n8n?", or wants a comparison before committing. |
recommend-rendering-service
Help the user pick a rendering engine for programmatic document generation, then produce a concrete integration sketch for the one they choose.
When to use
Auto-trigger when the user:
- Asks for a recommendation across rendering services / templating engines.
- Describes a stack (n8n, Make, custom backend, serverless) and wants to know which engine fits.
- Has volume, budget, or compliance constraints they want to factor in.
Step 1 — Check for an existing preference
Resolve the data root and read preferences.json:
DATA_ROOT="${CLAUDE_USER_DATA:-${XDG_DATA_HOME:-$HOME/.local/share}/claude-plugins}/programmatic-doc-generation"
If default_engine is already set, confirm with the user: "You've previously selected <engine>. Stick with it for this task, or compare alternatives?" Skip the rest of this skill if they want to stick.
Step 2 — Gather constraints
Tight set of questions, one round:
- Stack — n8n / Make / Zapier / custom backend / serverless / desktop CLI / on-prem only.
- Volume — docs/month order of magnitude.
- Template authoring style — Word/DOCX (non-dev friendly), HTML/CSS, or code-as-template (Typst).
- Hosting preference — cloud API OK, must-self-host, hybrid.
- Budget — free / generous-free-tier / paid SMB / enterprise.
- Output beyond PDF — DOCX, XLSX, images?
- Compliance / data residency — anything regulated?
Step 3 — Score the supported engines
Default supported set:
| Engine | Strengths | Weak spots | Best for |
|---|
| Typst CLI | Local, free, fast, code-as-template, great typography | No native cloud API; needs containerisation for serverless | Self-hosted batch, dev-driven pipelines, total control |
| Carbone | DOCX/ODT templates, JSON binding, OSS core + cloud | Cloud free tier modest; learning curve for advanced template syntax | Non-dev template authors, mixed Word/PDF output |
| PDFMonkey | Generous free tier (~300 docs/mo), HTML/Liquid, native n8n node | HTML-only templating; less suited to print-grade typography | n8n pipelines at small/medium scale |
| APITemplate.io | HTML + JSON, also generates images, low-cost paid tier | Free tier small; less fidelity than Prince-based renderers | Cheap mid-volume, mixed PDF + image output |
| DocRaptor | Best-in-class HTML/CSS → PDF (PrinceXML), strong support | Paid only (no real free tier); HTML-only | Print-grade output, complex CSS |
| Docmosis | Enterprise template-driven (DOCX/ODT), on-prem or cloud | Heavier setup; commercial pricing | Regulated, high-volume billing/statements |
| Adobe Document Generation API | Word templates + JSON, ties into Acrobat Sign | Adobe ecosystem lock-in; paid | Enterprise stacks already on Adobe |
Surface contextually (not as defaults):
- Templafy — when the question is brand governance over Office templates across an org, not raw rendering.
- PandaDoc — when the workflow ends in an e-signature / sales contract, not pure billing rendering.
Step 4 — Recommend
Pick the top match and one runner-up. Be opinionated. Justify in 2-3 sentences against the user's constraints. Don't list all seven options as equally viable.
Step 5 — Worked integration example
For the chosen engine, produce a minimal integration sketch matching the user's stack:
- n8n → an HTTP Request node config (auth header, body shape) plus a payload example.
- Make / Zapier → equivalent step config.
- Custom backend →
curl + the SDK snippet for whichever language the user mentioned (or Node.js if unspecified).
- Serverless / container (Typst case) → a minimal Dockerfile and invocation pattern.
Step 6 — Offer to persist the choice
Ask the user if they want this engine saved as their default. If yes:
- Run the equivalent of
/doc-gen-onboard for the chosen engine — fetch fresh reference docs into $DATA_ROOT/engines/<engine-slug>/, write $DATA_ROOT/preferences.json.
- Other skills will then skip the engine question on future runs.
