document-export
Skill6 starsChanged 8 months agoApache-2.0View on GitHub
Export Markdown to DOCX and PDF that meets submission rules: reference styles, pandoc Typst, page and font checks. Use for .docx or .pdf deliverables.
1 other project uses a version of this.
Adopted by
Most recently taken up by
- chacosoldier/compabobtheir own version, first seen Oct 23, 2026
Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 1
- chacosoldier/compabob★ 34same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository141 other files it gives its agents.
- AGENTS.mdAGENTS.md
- ad-bingSkill
- ad-frameworksSkill
- ad-googleSkill
- ad-linkedinSkill
- ad-metaSkill
- ad-redditSkill
- ad-tiktokSkill
- ad-xSkill
- ad-youtubeSkill
- ai-agent-designSkill
- ai-cost-finopsSkill
- ai-evals-designSkill
- ai-prompt-injection-defenseSkill
- ai-rag-patternsSkill
- analytical-reportSkill
- ats-optimizationSkill
- browser-backlink-submissionSkill
- browser-social-account-maintenanceSkill
- chef-budget-mealsSkill
- coaching-frameworksSkill
- code-review-lensesSkill
- code-reviewSkill
- content-auditSkill
- content-formatsSkill
- content-geoSkill
- content-groundingSkill
- content-humanizeSkill
- content-locale-humanize-arSkill
- content-locale-humanize-deSkill
- content-locale-humanize-esSkill
- content-locale-humanize-frSkill
- content-locale-humanize-hiSkill
- content-locale-humanize-itSkill
- content-locale-humanize-jaSkill
- content-locale-humanize-koSkill
- content-locale-humanize-ptSkill
- content-locale-humanizeSkill
- content-locale-humanize-thSkill
- content-locale-humanize-zhSkill
- content-translateSkill
- content-voiceSkill
- cover-letterSkill
- device-computer-automationSkill
- device-mobile-automationSkill
- geo-visibility-auditSkill
- git-workflowSkill
- issue-diagnosisSkill
- learning-scienceSkill
- marketing-social-gtmSkill
- markup-landing-pageSkill
- octomind-cliSkill
- octomind-configSkill
- octomind-runtimeSkill
- octomind-supervisorSkill
- octomind-workflowSkill
- os-alpineSkill
- os-debianSkill
- os-fedoraSkill
- os-linuxSkill
- The first 60 shown.
The file
We split this skill into the rules it gives an agent
5 rules. About 0 are common, 3 are distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈3
Distinctive · estimate
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 37
Read the formatting instructions first (RFP Section L or the submission guide, a portal's upload rules, a template the client sent).
- Very specific: line 38
Write the Markdown with real headings (#, ##) so Word gets heading styles and a navigation pane, tables as pipe tables, and footnotes as …
- Very specific: line 46
Read the pdf report: page count, page size, words in the text layer.
- Distinctive: line 47
When the deliverable is Word only, still export the PDF once to count pages.
- Distinctive: line 68
Avoid raw HTML; it is dropped in both formats.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Overview
Buyers, recruiters, and portals receive files, not Markdown. This skill keeps one Markdown source and produces the Word and PDF versions from it with the formatting the recipient demands, then verifies the PDF the way a reviewer or a parser will see it. The doc-export command does the conversion and the checks; no hand-built HTML-to-PDF scripts, no "copy this into Word yourself".
Mental model
- Source of truth:
<name>.md. Edits happen there; both files are regenerated from it. - Word output takes its look from a reference document.
doc-exportbuilds one from flags (font, size, heading color, line spacing, paper, margins) or uses the client's template with--reference. - PDF output goes through Typst with the same settings: real text, embedded fonts, consistent spacing.
- Checking is part of exporting: page count against the limit, every font embedded, a text layer that reads in order.
doc-export is installed on PATH with the documents capability (the same file is the bundled scripts/doc_export.py, listed under Skill Resources). doc-export <docx|pdf|reference|check> --help lists options.
Rules
Pipeline
- Read the formatting instructions first (RFP Section L or the submission guide, a portal's upload rules, a template the client sent). Write them down: font, size, margins, line spacing, paper, page limit, file type, file naming, what counts toward the limit.
- Write the Markdown with real headings (
#,##) so Word gets heading styles and a navigation pane, tables as pipe tables, and footnotes as[^1]. - Export both formats with identical settings:
doc-export docx proposal.md -o "Acme_RFP-2026-117_Vol1_Technical.docx" --font "Times New Roman" --size 12 --margins 1in --paper us-letter
doc-export pdf proposal.md -o "Acme_RFP-2026-117_Vol1_Technical.pdf" --font "Times New Roman" --size 12 --margins 1in --paper us-letter --max-pages 20- Read the
pdfreport: page count, page size, words in the text layer. Fix and re-export until it is clean. - When the deliverable is Word only, still export the PDF once to count pages; Word may paginate a little differently, so leave a margin of half a page under a hard limit.
Formatting decisions
| Situation | Setting |
| RFP specifies font, size, margins | Use exactly those; --line-spacing 1.0 unless spacing is specified |
| No instructions, business document | --font Calibri --size 11 --line-spacing 1.15 --margins 1in |
| Formal letter, legal-style document | --font "Times New Roman" --size 12 --margins 1in |
| Outside the US and Canada | --paper a4 |
| Client sent a Word template | doc-export docx in.md -o out.docx --reference their-template.docx |
| House style reused across documents | doc-export reference -o house.docx --font ... --heading-color 0B3D91, then --reference house.docx |
| Long proposal or report | --toc, and --numbered when the instructions number sections |
Check the font exists before relying on it: typst fonts for PDF. When Calibri, Cambria, Arial, Times New Roman, or Courier New is missing, the PDF uses its metric-compatible clone (Carlito, Caladea, Liberation), so line breaks and page counts hold; any other missing font gets a warning. Word substitutes silently on the reader's machine when a font is missing, so prefer Calibri, Arial, Times New Roman, or Georgia for files that leave the organization.
Markdown that converts well
- Page break: a raw block per format, e.g.
```{=openxml}with<w:p><w:r><w:br w:type="page"/></w:r></w:p>for Word and```{=typst}with#pagebreak()for PDF. - Images:
{width=80%}; pass--resource-pathwhen images live elsewhere. - Title block: YAML front matter with
title,subtitle,author,date. - Avoid raw HTML; it is dropped in both formats.
Verification
doc-export check file.pdf --max-pages N --text 30 reports:
- pages over the limit,
- fonts not embedded (some portals reject them),
- little or no text (an image-only PDF: parsers and screen readers read nothing),
- private-use glyphs (icon fonts that turn into junk characters in parsers),
- the first lines of the text layer in reading order (contact details, headings, and bullets should come out in the order a reader expects).
Examples
Example 1: page limit
❌ Draft exported once, sent: 21 pages against a 20-page limit; the evaluator stops reading at page 20, or the proposal is non-compliant.
✅ doc-export pdf ... --max-pages 20 flags 21 pages; the agent tightens the weakest section and re-exports at 19 pages.
Example 2: font rules
❌ "Converted to Word" with pandoc defaults: Aptos 12, blue headings, no page setup, against an RFP requiring Times New Roman 12 with 1-inch margins.
✅ doc-export docx ... --font "Times New Roman" --size 12 --margins 1in sets theme fonts, sizes, and margins in the file itself.
Checklist
- Formatting instructions captured before writing (font, size, spacing, margins, paper, page limit, naming).
- One Markdown source; DOCX and PDF both regenerated from it with identical settings.
- PDF report clean: within the page limit, fonts embedded, text layer present and in order.
- Files named as the instructions require.
- Both files and the Markdown source saved in the working directory.
Composition / References
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

