resume-version-manager

Original：🇨🇳 Chinese

Translated

Manage resume master versions and customized versions for different companies, positions, and JDs. It is used when users need to save multiple resume versions, compare differences, name files, trace application versions, or maintain the resume fact source. Protect the master version and do not overwrite existing versions or unconfirmed facts.

2installs

Sourcechasen-liao/resume-skills

Added on2026-08-12

NPX Install

npx skill4agent add chasen-liao/resume-skills resume-version-manager

SKILL.md Content (Chinese)

View Translation Comparison →

Resume Version Manager

Use the private

resume-facts.yaml

as the sole source of truth to create traceable, comparable master and customized versions for each application. HTML/PDF are deliverables generated from confirmed facts and do not replace fact records.

It does not occupy the user's main workflow entry: record the version only after the master version is confirmed or the JD customized version is confirmed; display version operations only when the user needs to compare, restore, or maintain application records.

Preread

Read Resume Fact Contract, JD Matching Report Template and Writing Guidelines.

Workflow

Locate or create the private
```
resume-facts.yaml
```
and clearly identified master version; the fact file saves all confirmed claims of the candidate and cannot be overwritten by customization operations.
Create an independent directory for a company/position/JD:
```
tailored/<Company Name>-<Position>/
```
.
Record the parent version, target JD, creation date, candidate facts used, reordered items, rewritten items, keyword sources, unmatched requirements, and pending confirmation fields.
Generate the
```
resume_visual.html
```
for this version, generate
```
resume_ats.html
```
and
```
matching-analysis.md
```
if necessary; verify PDF page count, extractable text, and HTML overflow, and only record a valid manifest whose hash corresponds to the current file.
Group by facts, order, wording, and styles when comparing versions; mark conflicts and request candidate confirmation when fact inconsistencies are found.

Git Version History (Recommended)

Place

resume/

in a local private Git repository, use commit records to confirm facts and application versions; do not push to public remote repositories by default, as resumes may contain contact information and other personal information.

After the candidate confirms changes to the master version, create a commit with a clear description, e.g.:
```
Update master version: Add RAG project
```
.
After confirming the generation of a customized version each time, create a commit, e.g.:
```
Customized: ByteDance - Frontend Intern
```
.
When comparing, restoring, or auditing, rely on commit differences; the comparison scope is still grouped by facts, order, wording, and styles, and fact conflicts are prioritized for confirmation.
Create branches only when the candidate wants to try mutually exclusive master version directions at the same time; ordinary JD customizations are saved in the
```
tailored/
```
directory and traced with commits.
Do not automatically perform Git initialization, commit, push, or overwrite; explain the scope and obtain the candidate's confirmation before each operation that changes the version history.

Recommended Directory Structure

text

resume/
├── resume.html                         # Master version
└── tailored/
    └── <Company Name>-<Position>/
        ├── resume_visual.html
        ├── resume_ats.html            # Generate on demand
        ├── matching-analysis.md
        └── version-notes.md

version-notes.md

should at least record: parent version,

resume-facts.yaml

used, JD source/date, change summary, keyword sources, unmatched requirements, pending confirmation fields, and export verification results.

If Git is used,

version-notes.md

should also record the corresponding commit ID to facilitate returning to the master version facts and generation basis from the customized version.

Constraints

Customized versions can only reorder, emphasize, or rewrite confirmed facts; writing back to the master version requires explicit user request.
Naming can use
```
Name_Position_Company_YYYYMM.pdf
```
, but follow the requirements of the target platform.
Do not "organize" the workspace by deleting historical versions, silently overwriting files, or falsifying version records.