Reviewing model-assisted résumé edits
A résumé and cover-letter workflow that proposes edits to selected text, checks the format, shows a diff, and builds a PDF for review.
Public legacy source · Private successor
The problem
I wanted to see how much of résumé tailoring I could handle with a smaller model running locally, within the hardware I already had. The model proposes edits to selected text; ordinary code handles the surrounding workflow and checks. The interesting part was working out what to ask the model to do, how much text to give it, and what to keep out of its hands. The public version can also use configured API providers, but local inference avoids per-token API charges.
What I built
I built the workflow around marked LaTeX sections, structured edit proposals, targeted checks, diff review, and PDF compilation.
- A Python CLI that extracts editable text from marked LaTeX sections and requests JSON edit proposals from a configured model provider, including local Ollama.
- Targeted checks for edit schema, disallowed LaTeX commands, text length, and excluded skills before patching marked sections.
- Diff inspection and PDF compilation through latexmk, so text changes and the rendered document can both be reviewed.
- A Vue editor and Express backend that connect document editing and recompilation to the Python workflow.
The engineering decision
Making document changes easy to inspect
The public implementation uses markers to identify editable text and structured proposals to describe replacements. Validation and patching are separate steps, and a diff makes the resulting changes visible.
Those checks constrain the edit format and catch specific content problems. They do not establish that every sentence is true. Reviewing the claims and the compiled PDF remains part of the workflow.
Private successor design · Fictional worked example
Change the emphasis. Keep the evidence.
Follow an invented candidate through the later private workflow. This illustrates design decisions beyond the linked public legacy version. No model runs here; the claims, context, and document are a small explanatory example.
Approved experience
E1Built a Python tool that combines weekly support reports.
E2Added validation that flags missing fields before export.
An unsupported draft
“Led a team of twelve and cut reporting time by 80%.”
Neither the team size nor the time saving appears in the evidence. I would remove those claims, not make them sound more convincing.
The example illustrates evidence boundaries. It does not prove that an automated validator can detect every unsupported claim.
The public source covers the earlier version
The linked auto-tailor-v2 repository contains the earlier LaTeX workflow described above. The later version is private and uses a different design.
In the later workflow, structured document content is separate from controlled templates. The diagram and fictional example explain that design; they are simulations, not running code from the public repository.
What I checked
- Public Python source includes the extract, propose, and apply commands, plus schema validation and diff inspection.
- The public patcher applies replacements to marked LaTeX sections; the CLI integrates latexmk for PDF compilation.
- The public Vue editor and Express recompile route expose the editing and rendering integration for inspection.
Limits
- Targeted validation does not eliminate hallucinations or provide comprehensive factual verification. Generated documents still need review.
- The original service is parked, so the public repository is available as source rather than a live application.
- The worked example uses invented experience to explain the later private workflow. It does not run a model or compile a document.
Tools and foundations
I built the editing workflow, targeted validation, and rendering integration. Configured model providers supply inference; Python, Vue, Express, LaTeX, and latexmk provide the application and document foundations.