bama
BAMA: Build Any Mac App. Agent skills to research, clone, design, build, optimize, and test native macOS apps with Swift and SwiftUI.
A Claude Code skill for LaTeX resume repos: one set of wording renders as many resumes (identities x roles x templates), with verification that a restructure changed no rendered PDF.
SkillsShell · TeXGitHub @RuokeZhangSelf-installOwner unconfirmed
Paste into Claude or ChatGPT for installation instructions suited to your environment.
Have you tried it? One tap is enough. No sign-in needed.
No updates detected yet. GitHub releases will appear here.
Owners of public repositories under a personal GitHub account can sign in to verify ownership and manage the introduction themselves. No administrator approval is needed.
Sign in, generate a verification file, and commit it to this repository’s default branch within 30 minutes. Files on other branches or forks do not count. Then check the file below to manage the project without administrator approval. Keep the file to retain your access.
If needed, you will go to sign-in. After signing in, return here and press your chosen verification button again.
Installable projects can be verified without a deployment domain. Use GitHub sign-in for a personal repository, or the repository verification file above for an organization repository.
Ask about other verification options
Loading the full README. The saved excerpt is shown below.
A Claude Code skill for LaTeX resume repos where one set of wording has to
become several documents.
You have one resume. Then you need it under a different name for a different
email account. Then a version aimed at one kind of
role and a version aimed at another. Then someone tells you a different
visual template performs better, and you want that layout for one of them.Read the full README ↗English · 简体中文
A Claude Code skill for LaTeX resume repos where one set of wording has to become several documents.
You have one resume. Then you need it under a different name for a different email account. Then a version aimed at one kind of role and a version aimed at another. Then someone tells you a different visual template performs better, and you want that layout for one of them.
The obvious move is to copy the file and edit. Do that twice and you have four documents that share 90% of their text, and no way to tell which copy has the current wording. They drift. A metric gets updated in one and not the others. An old inflated number survives in a file you forgot about.
This skill keeps the wording in exactly one place.
The same target composition, rendered two ways. Nothing below differs in wording — only the template and the typeface.
classic + sourcesans | engineering + caladea |
|---|---|
Swapping either one is a line in the driver. The wording exists once.
Rendered on Overleaf. Content is fictional.
Every resume is a selection, never a copy:
profiles/<person>.tex × templates/<layout>.tex × content/<target>.tex
× \ResumeFont
| Directory | Holds | One file per |
|---|---|---|
profiles/ | name, email, phone, links | identity |
templates/ | all layout, implementing a shared command interface | visual style |
content/ | target compositions, reusable experience entries, grouped project sets | target or reusable entry |
fonts/ | typeface selection; optional | face |
| drivers | a selection of the above, plus switches | finished resume |
CONTENT_LIBRARY/ | archived and candidate wording, in Markdown | topic |
A driver is about twelve lines:
\documentclass[letterpaper,11pt]{article}
\newcommand{\ResumeFont}{carlito}
\input{profiles/example.tex}
\input{templates/classic.tex}
\begin{document}
\ResumeHeader
\input{content/example-role.tex}
\end{document}
Inside content/, the target file is a small composition rather than a copy of
every entry:
content/
├── example-role.tex
├── experience/
│ ├── example-company.tex
│ └── earlier-company.tex
└── projects/
└── example-role.tex
example-role.tex selects experience entries with \input{...} and includes
one project-set file for the target. Work experience is split by entry because
the same internship is commonly reused across several targets. Projects stay
grouped by target because they are usually selected and reordered as a set;
making every project a separate file adds navigation without enabling a real
reuse case or addressing a demonstrated drift risk.
This granularity is intentional. profiles/ remains a separate, useful axis:
it lets the same resume content render for different names and contact details
without duplicating either content or templates.
Adding a person is one profile. Adding a target is one composition plus its grouped project set, reusing the relevant experience entries. Adding a visual template means implementing the command interface in references/INTERFACE.md — after which every existing resume can render in it.
git clone <this repo> ~/.claude/skills/resume-versioning
Claude Code picks it up automatically. Ask it to set up a resume repo, add a variant, or change a bullet, and it will follow the conventions here.
To scaffold a repo without Claude:
~/.claude/skills/resume-versioning/scripts/init.sh ~/my-resume
log-app companion skilllog-app/ is a second, self-contained skill for recording which rendered
resume you sent to which job. Install it alongside the main skill:
ln -s ~/.claude/skills/resume-versioning/log-app ~/.claude/skills/log-app
Then invoke with /log-app <sha> <driver> "<job title>". It appends one row to
a local CSV (default ~/Documents/RESUME/applications.csv, overridable via
RESUME_APPLICATIONS_CSV) after verifying the SHA and driver exist in your
resume repo (default ~/Documents/RESUME/overleaf, overridable via
RESUME_OVERLEAF_DIR). The CSV is private — the repo's .gitignore blocks
applications.csv from being committed here or anywhere this repo is cloned.
See log-app/SKILL.md for the full spec.
The reason this is a skill and not a blog post: restructuring a resume repo should not change what any resume looks like, and that is checkable.
./scripts/verify.sh
renders every driver at git HEAD and again in the working tree, then compares the decompressed PDF content streams:
NAME HEAD WORKING STATUS
Example_Resume 97080675e88112c4 97080675e88112c4 IDENTICAL
Second_Resume 5cfb6ff174e44187 cc42fc296a5e29eb CHANGED
Anything CHANGED is either an edit you meant or a regression. There is no
third case.
./scripts/preview.sh # render everything to build/
./scripts/preview.sh Example_Resume.tex
tectonic for local rendering (brew install tectonic, or see
tectonic-typesetting.github.io)python3 for the PDF fingerprintgitLocal rendering is optional. If the repo lives in Overleaf, Overleaf compiles it and none of the above is needed — the scripts exist so you can see a change without pushing first.
Overleaf projects are git remotes, so the repo can live there and be edited
locally. Two things to know, both handled by preview.sh:
\input{dir/file.tex} from the project root; tectonic
resolves it from the main file's directory.tectonic runs XeTeX, which lacks the pdfTeX
primitives glyphtounicode needs.Because of the second point, a local render is a good check but not proof of Overleaf output. See references/overleaf.md.
Nine faces ship in fonts/. Pick one by name in the driver:
\newcommand{\ResumeFont}{carlito}
Sans
Serif
carlito and caladea are metric-compatible with Calibri and Cambria —
same widths, so a layout tuned for those keeps its line breaks. Calibri and
Cambria are proprietary Microsoft fonts and cannot be bundled, which is why the
clones exist.
Changing the face changes line breaks. Re-run scripts/verify.sh and look at
the render afterwards.
The two bundled templates are adaptations of existing community resume
templates, not original designs. In both cases the visual settings come from
upstream; the \resume* command definitions are this project's own
implementation of its interface.
assets/templates/classic.tex — from
Jake Gutierrez's resume (MIT), itself
based on sb2nov/resumeassets/templates/engineering.tex — adapted from the
r/EngineeringResumes
community wiki templateSee NOTICE for full attribution and license terms.
MIT — see LICENSE.