latex-document-skill ships 27 templates and 27 shell scripts, but four Python packages cover only three of them

Four Python packages, three Python scripts, and a TeX toolchain nobody installs for you

The Python dependency list is short and each entry names the script that needs it.

# Python dependencies for LaTeX document skill
# Install: pip install -r requirements.txt

# Chart generation (scripts/generate_chart.py)
matplotlib>=3.5.0
numpy>=1.21.0

# CSV-to-LaTeX conversion (scripts/csv_to_latex.py) + chart CSV input
pandas>=1.3.0

# Mail merge template rendering (scripts/mail_merge.py)
jinja2>=3.0.0

So four libraries, three named Python scripts, and one of them, pandas, serving two consumers. The rest of the automation is shell. The headline count on the project page is 27 automation scripts against 27 templates, 26 reference guides and 4 OCR profiles, and the Python side accounts for three of those 27.

That leaves the LaTeX dependencies invisible to any manifest here. The templates are written against named packages: `tcolorbox` for the colour-coded theorem environments, `tikzposter` for the conference poster, `booktabs` for generated tables, `biblatex` with biber for the thesis bibliography, `siunitx` for units, `authblk` for multi-author affiliations, `cleveref`, `microtype`, `mathtools` and the `exam` class for the test paper. None of them are listed anywhere in the repository's Python requirements, because they are not Python packages. They come from a TeX distribution you are expected to already have, and a chart-heavy document that compiles on the author's machine can fail on yours purely because a macro package is missing.

There is one other external tool with a configuration file committed for it: `.chktexrc` at the repository root, for the style checker the readiness check runs.

Five ATS templates with hard layout rules, plus one that admits it breaks them

The resume set is the clearest statement of intent in the repository, because the rules are stated as prohibitions rather than as styling preferences. Five templates are described as ATS-optimized, and the constraints on all five are no columns, no tables used for layout, no graphics in the header, and machine-readable text.

Those four rules are why the set looks plainer than a typical resume template. Two-column and sidebar layouts are the reason many applicant tracking systems mis-parse a resume, and the templates here avoid them on purpose.

Each template is aimed at a specific reader.

| Template | Target Role | Key Design Choices | |---|---|---| | `resume-classic-ats.tex` | Finance, law, government | Single-column, minimal styling, maximum parsability | | `resume-modern-professional.tex` | Tech, corporate | Clean sections, subtle color accents | | `resume-executive.tex` | VP / Director / C-suite | Multi-page, executive summary section | | `resume-technical.tex` | Software, data, engineering | Skills matrix, project highlights | | `resume-entry-level.tex` | New graduates | Education-first, coursework, activities |

A sixth file is kept as a legacy template for regions that require a photograph in the application, and it is explicitly marked as not ATS-compatible. That contrast is the useful part of the set: the photo layout exists, and it is labelled as the tradeoff it is rather than quietly mixed in with the parsable ones.

The generation path for a resume selects from these templates, compiles with `pdflatex`, and produces a PDF plus a PNG preview, so you get something you can look at rather than only a file you have to open.

Two type systems on purpose: Palatino for the thesis, Times for the arXiv paper

The academic templates are not variations on one document. They are separate documents with separate conventions, and the differences are the point.

The thesis and dissertation template is a full book-class document of 38 pages or more. It uses Palatino fonts, `microtype` for micro-typography, `mathtools`, and `cleveref` for cross-references. Front matter is complete: title page, declaration, abstract, acknowledgments and a table of contents, followed by chapters, appendices, and a bibliography handled by `biblatex` with biber. One setting is worth noting because it is about the physical object rather than the screen: `\geometry{bindingoffset=1.5cm}` reserves extra inner margin for binding, which is what you want when the thesis is printed rather than uploaded.

The academic paper template is 11 pages and described as arXiv-compatible. It uses Times fonts, the colorblind-safe Tol palette, `authblk` for multi-author affiliations, `siunitx` for consistent units, algorithm environments, and theorem and proof environments. It also sets `\pdfoutput=1`, a line whose entire purpose is submission.

The lecture notes template is the most opinionated. `lecture-notes.tex` uses `tcolorbox` with semantic colours rather than decoration: blue theorems, green definitions, orange examples, purple remarks. It adds TikZ graph theory macros and defines its own math operators, `\E`, `\Var` and `\Cov`.

The academic CV is separate again, and it is a bibliographic instrument: publications numbered `[J1]`, `[C1]`, `[W1]`, grants with dollar amounts, student advising split between current and graduated, professional service and invited talks, plus ORCID and Google Scholar links.

Quality is stated as a per batch rate, not as a guarantee

The project page makes a specific verification claim about PDF to LaTeX conversion: pages are split at 200 DPI, parallel OCR agents run, the output is a clean `.tex` with profile-tuned formatting, and the result is zero errors per seven-page batch, validated on a 115-page PDF.

That phrasing is worth reading carefully rather than paraphrasing into a stronger claim. A rate per seven-page batch is not the same as zero errors overall, and a validation on one 115-page document is not a claim about your scan. What it does establish is that someone measured a rate on a specific input, which is more than most document generators offer.

The same shape applies to the rest. The headline line counts 27 templates, 27 automation scripts, 26 reference guides, 4 OCR profiles and 217 tests, and promises zero LaTeX commands required. The template gallery states that every template has been compiled, tested and verified to produce zero errors. The handwritten notes path renders pages at 200 DPI, runs seven parallel OCR agents per batch, and selects a profile named `math-notes.md` that produces coloured `tcolorbox` environments, blue for theorems, green for definitions and orange for examples, before a multi-pass `pdflatex` run.

Multi-pass compilation is the part that matters mechanically. `compile_latex.sh` runs `pdflatex` more than once, which is what resolves cross-references, the table of contents and page numbers. A single pass produces a document with undefined references that a person has to notice and fix, so the fact that the script loops is doing real work.

The OCR profiles are the extension point. There are four of them, selected by what the input is, which is why a textbook scan and a set of lecture notes take different paths and produce differently formatted output rather than one generic conversion.

The shell scripts do the PDF surgery: split, compile, diff, fetch, encrypt

The named scripts are where the real work happens, and each one wraps an external binary.

`pdf_to_images.sh` renders a PDF to images at 200 DPI, which is the input OCR agents consume. `compile_latex.sh` runs the multi-pass `pdflatex` loop. `latex_diff.sh` runs `latexdiff` and produces a change-tracked PDF with additions in blue and deletions in red, which is how a thesis revision gets reviewed. `fetch_bibtex.sh` hits `doi.org` with an `Accept: application/x-bibtex` request header, appends the result to a `.bib` file, and cross-references every `\cite{}` key.

`pdf_encrypt.sh` applies AES-256 with print and modify restrictions. Mail merge runs the other way round: `mail_merge.py` loads a template and a CSV, renders with Jinja2, then runs four parallel `pdflatex` workers and merges the outputs into a single PDF with `qpdf --pages`. Five hundred personalised letters is therefore four concurrent compilers and one merge step, not five hundred sequential compiles.

Chart generation is a Python script. `generate_chart.py` reads JSON or CSV and produces bar, line, scatter, pie, heatmap, box, histogram, area and radar charts, with multi-series support, legends and a colorblind-safe Tol palette. `csv_to_latex.py` converts data into `booktabs` tables. The quarterly report path combines both with Mermaid and TikZ flowcharts compiled inline into `report.tex` under a table of contents.

The external binaries are the dependency list that is not written down: `pdflatex`, `qpdf` and `latexdiff` at minimum. Everything else the templates need comes from the TeX distribution.

Filling a form takes the fielded path or the visual one

PDF form handling is split into two mechanisms, and the second one is the interesting case.

The first is the ordinary path. For a PDF with fillable fields the skill detects them, validates them, and fills text, checkbox, radio and choice fields, producing a completed document. Nothing is guessed.

The second path handles a PDF that has no fillable fields at all, which is the ordinary case for a scanned application form. There it renders the pages, runs visual analysis to work out where the fields are, validates bounding boxes, and writes the values as FreeText annotations at the computed positions. So a non-fillable form is completed by drawing text onto the page rather than by populating form objects, which is why the bounding box validation step exists and why the result is a visual approximation of a filled form rather than a semantically filled one.

The exam template has a comparable two-state design. It uses the `exam` class with a `\printanswers` toggle, adds a grading table, and covers six question types: multiple choice, true or false, fill in the blank, matching, short answer and essay. The toggle means the same source produces both a paper and an answer key, which is the difference between writing it once and writing it twice. The homework and assignment template follows the same idea with custom `problem` and `solution` environments, code listings for Python, Java, C++ and Matlab, and a section reserved for an honour code.

The submission readiness check is the last piece. It verifies that required packages are present, cross-references citations, counts figures, tables and equations, and runs `chktex` for style issues, using the configuration committed at the repository root. The homework section of the template gallery ends mid-sentence on the phrase about toggling solutions globally, so the exact switch it names is not given there.

No licence file at the root, no releases, and examples that are all images

Three facts about the repository itself are worth having in front of you.

The first is licensing. The project metadata records no licence, and the top-level entries do not include a licence file. The tree is `.chktexrc`, `.github/`, `README.md`, `SKILL.md`, `assets/`, `examples/`, `references/`, `requirements.txt`, `scripts/`, `setup.sh`, `stats/` and `tests/`. So there is nothing in the repository that states what you are allowed to do with it, and the metadata does not fill the gap. That is a question to ask the authors rather than one to resolve by assuming a default.

The second is releases. The repository has none. There is no version to install, no tag to pin, and no changelog of compiled templates, so the only thing to depend on is a commit.

The third is what is actually committed as examples. Every entry under `examples/` is a PNG. There are page-by-page images for the book template, ten of them, four each for the academic CV and the academic paper, two for the cheat sheet, one chart image and one cover letter. No `.tex` sources are committed, so the templates themselves are the only readable form of the code and the images are only the rendered result.

The rest of the layout matches the claims. `SKILL.md` is the entry point a Claude Code skill is built from, `scripts/` holds the automation, `references/` holds the 26 guides, `tests/` holds the 217 tests, and `stats/` is a directory whose purpose is not described. `setup.sh` exists at the root, and the only installation command visible in the project's own files is `pip install -r requirements.txt` in the dependency file.

The project page also states it was made with Claude Code on the HappyCapy AI platform, and links that platform as its homepage.

Editorial conclusion

This is a skill for people who need finished documents rather than for people learning LaTeX, and its strongest entries are the mechanical ones: mail merge with parallel compilation, change tracking through latexdiff, DOI to bibliography, AES encryption, and form filling. Verify the toolchain before anything else, because the Python requirements cover three scripts while the templates depend on a full TeX installation with tcolorbox, tikzposter, biblatex, siunitx, authblk and the exam class that no manifest in the repository installs. Check the licence too: no licence file appears at the repository root and the metadata records none, which is not something to resolve by assumption if you plan to publish anything produced with it. The quality figures are per batch rates validated on specific documents, so treat them as evidence rather than as guarantees for your input.

Frequently asked questions

Official sources

1. Issues
2. ndpvt-web/latex-document-skill on GitHub
3. Project website
4. README