How Jack's Resume Pipeline Works

Every application starts from the same three source files. A prior job-specific resume is never used as a starting point for a new application — existing tailored resumes are archival history only.

• Base Resume — 12 years of career history. The raw content pool.
• Optimization Rules — ATS and hiring-manager philosophy. The job description is the only filter.
• Skills Inventory — Confirmed skills only. If it's not here, it doesn't go on a resume, period.
• Content Wiki — Accumulated job notes, reusable application answers, and platform quirks.

Before writing a single word, the job description is broken into a checklist of every requirement, responsibility, skill, tool, and qualification it mentions. That checklist is the blueprint.

• Pull exact phrases and keywords, not paraphrases.
• Note the seniority level: IC contributor, manager, director, etc.
• Flag any required skills that are not confirmed in the Skills Inventory. Those get flagged as gaps rather than added to the resume.
• Note whether the role is in-house/brand-side or agency — changes which experience to lead with.

A new .md file is created, named for the company and role. The resume is assembled from the base content with strict rules on what makes the cut:

• Only bullets that map directly to the job posting blueprint are kept.
• The summary is rewritten entirely from scratch for each role.
• Most recent role: ~6 bullets. Second role: ~3 bullets. Older roles: 1-2 bullets or a single title/date line.
• Exact job-description keywords are used where truthful. No flowery language, no AI-sounding filler words.
• No skills, tools, or platforms that are not in the Skills Inventory, even if the posting asks for them.
• Location formatted as New York, New York. No em dashes anywhere.

Each resume has a paired Python script that builds a Word document using the python-docx library. The content is hardcoded in the script, and running it outputs the final .docx. The formatting spec is fixed:

• Font: Arial, 10.5pt body, 22pt name, 10.5pt bold section headers
• Margins: 0.6–0.65 inches (tighter than default to fit content without shrinking text)
• Layout: Single-column only. No tables, text boxes, sidebars, images, or decorative lines.
• Bullets: Standard round bullets via Word's List Bullet style
• Section heads: All-caps, bold — SUMMARY, SKILLS, EXPERIENCE, EDUCATION
• Line spacing: 1.0 throughout with tight paragraph spacing (0-3pt before/after)

The .docx is converted to page-by-page PNG images using LibreOffice (called via a render script, with the app bundle binary path added to PATH). These land in a folder like rendered_gusto_paid_social/page-1.png.

• Every rendered page is inspected visually for clipping, cramped spacing, or bad pagination.
• If anything looks off, the Python script is revised and rerun until the render is clean.
• This step catches issues that Word's own preview hides — particularly content overflowing the page or orphaned lines at the top of page 2.

After generating and visually checking the resume, the process fully stops. The resume is not uploaded to any application form until explicit sign-off is given.

For supported application systems (mainly Greenhouse), a JavaScript autofill script fills standard form fields. A second hard stop fires before any final submission click.

• Source of truth: .env file, not browser autofill (which can insert stale email addresses).
• Legal name / Preferred name: Always "John" / "Jack" respectively.
• React fields: Filled via native input value setters plus dispatched input/change events so React-controlled fields register the update.
• Demographic dropdowns: Must be actually selected from the menu — typing into the field is not sufficient in Greenhouse.
• Country code dropdown: Always the "+1 / US" option.
• Non-compete: Jack has confirmed no active non-competes — answer is "No."
• Second gate: Process stops at "filled and uploaded, no submit" until Jack confirms he's ready.