A resume rewritten by hand for every role drifts: language softens, scope gets buried, and the length a recruiter will actually open is never guaranteed. This pipeline applies the same discipline as a design system, declared and measured rather than eyeballed, to a document instead of a product.
Blocked byA bullet written from memory, with no signal about what the specific role actually rewards.
The pipeline's first phase is not writing. It names the one hiring signal a role actually tests for, then triages which accomplishments serve that signal and which get cut, so a bullet written before that triage does not end up optimizing for nothing in particular.
The second phase turns what survives into one formula: a power verb, what was built, and the scope or outcome it changed. The README states its own before and after: "Responsible for designing mobile app and design system" becomes "Architected cross-platform UI across 4 surfaces (iOS, Android, Tablet, Web Admin) and standardized 60+ design system tokens, eliminating visual drift and accelerating dev handoff." Same work, stated as scope instead of duty.
Weak
Strong (Scope Indicator)
Responsible for designing mobile app and design system.
Architected cross-platform UI across 4 surfaces (iOS, Android, Tablet, Web Admin) and standardized 60+ design system tokens, eliminating visual drift and accelerating dev handoff.
The README's own example of the XYZ formula: a power verb, what was built, the scope it changed.
Blocked byTailored content with no shared visual system to render it consistently.
The third phase turns markdown into HTML under one design system, not a fresh layout per resume. Six tokens set every color in the document: black, white, and one grey for dates and metadata, and the spec bans the rest outright, no box shadows, no gradients, no arbitrary color, blue or red or purple included.
Type carries the same discipline: DIN Condensed for headings, SF Pro Rounded for body, a fixed 1811px container with 73px of horizontal padding. The same six tokens produce two different layouts, an editorial single column and a two-column classic grid, because a design system's job is holding the values still while the arrangement changes, not holding the arrangement still too.
v2-modern layout
The editorial layout's own demo render: DIN Condensed headers, a five-column scope banner, the six-token palette.
open-cv-pipeline, MIT, rendered from the repo's own demo content. Source document 03The guarantee, checked by hand
Blocked byA hand-built HTML file with no guarantee it prints at the length a recruiter will actually open.
The fourth phase exports the HTML through a headless Chromium instance and prints it to PDF at a fixed viewport: 1811 by 2560 pixels for the editorial layout, 1811 by 2800 for the classic one. Two documents, two heights, both chosen so the content lands on exactly two pages.
The docs call this an "automated check confirming pageCount == 2." It is not one: the export script sets the height constant and calls Chromium's PDF printer, with no assertion anywhere in the 66-line script or the rest of the repo that counts the pages it produced. The two sample PDFs in the repo's own output folder are, verified directly, exactly two pages each, but that is true because the height was tuned by hand to fit today's content, not because anything would catch it if tomorrow's content ran long.
Blocked byNo way to know whether the tailoring worked, beyond a feeling that it reads better.
The fifth phase generates a second document: an audit report scoring the résumé it just built against the draft it started from. The repo's own demo run scores a before at 5.0 out of 10, zero metric impact, passive verbs, underplayed scale, generic profile, against an after at 9.4, each line paired with what changed: scope and volume metrics, FAANG power verbs, the XYZ formula applied, a rewritten executive summary.
A second report mode runs the same résumé against multiple target roles at once, scoring fit per track rather than producing one verdict: 96% for a principal design-role track, 94% for product management, 95% for a design-systems lead in the repo's own demo run, each with its own reasoning for what to emphasize.
Audit report
The audit report's own before/after: a 5.0 draft scored against a 9.4 rewrite, each finding paired with what changed.
open-cv-pipeline, MIT, rendered from the repo's own demo content. Source document Reflection
This system can prove its export is two pages today, and that a demo score moved from 5.0 to 9.4. It cannot prove a page count survives tomorrow's edit, or that the same audit would hold up against a role it was not tuned for: the docs claim an automated guard, and the code does not carry one yet. That gap stays open on purpose. A case that only lists what got built is a feature list, not evidence.
