# Resume Tailor > Tailor Tim Qiu's master CV into a polished, exactly-two-page resume targeted at one specific job description, plus a paste-ready skills list worded in that JD's language for application forms. Use this WHENEVER Tim wants a resume or CV built, tailored, customized, adapted, or "made for" a particular job, role, company, or job description (JD) — e.g. "make a resume for this Roche role", "tailor my CV to this JD", "customize my resume for this posting", "turn my master CV into a 2-page resume", or even when he just pastes a job description and asks for a resume. Covers content selection, JD keyword alignment, approval-gated escalation of experience, style-template-matched .docx + PDF output, and a final skills list for application "skills" fields. Do NOT use for cover letters, LinkedIn posts, recruiter emails, or other first-person prose (use my-writing-style for those). - Skill: `timqiu1998/resume-tailor` (Agent Skill, multi-file: 4 files) - Install (CLI): `npx skillmds@latest add timqiu1998/resume-tailor` - Raw SKILL.md: https://api.skillmd.com/api/skills/timqiu1998/resume-tailor/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Docs & Writing - Author: timqiu1998 (https://skillmd.com/u/timqiu1998) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/timqiu1998/resume-tailor --- # Resume Tailor (for Tim Qiu) Turn Tim's master CV into a sharp, **exactly two-page** resume aimed at one job description, in the visual style of his chosen template, and hand back a skills list phrased in the JD's own language for filling in application forms. The master CV is the source of truth for *facts*. The JD decides *emphasis, ordering, and wording*. The template decides *look*. Your job is to move the right facts to the top, speak the employer's dialect, and make it beautiful — without ever inventing anything Tim can't back up. ## Inputs (locate these first) 1. **Master CV** — Tim's latest `Tim_CV_*_Master.docx` (currently `Tim_CV_2026-06-26_Master.docx`), normally in his `OneDrive\桌面\Yale\Job Seeking\cv` folder. This is the full, uncut record. 2. **Style template** — the resume whose *look* to copy, normally `Tim_resume_*_Yale.pdf` (currently `Tim_resume_2026-03-16_Yale.pdf`) in the same folder. Copy its typography and layout, not its content. 3. **Job description (JD)** — pasted text, a file, or a URL Tim gives you. If the folder isn't connected or a file is missing, ask Tim to connect his `Job Seeking` folder (Add folder in the desktop app) or attach the files — don't guess at their contents. Stage the master CV and template into the workspace before working on them; treat `/mnt/user-data/uploads/` as read-only and copy anything you need to edit elsewhere. ## The workflow Work through these in order. Phases 1–3 are analysis Tim doesn't need to watch; **Phase 4 is a hard stop for his approval**; Phases 5–7 build and deliver. ### Phase 1 — Extract everything - **Master CV**: pull the complete structured content — every role, project, publication, patent, skill, award, and education entry, with exact dates, titles, employers, and quantified results. Preserve numbers and proper nouns verbatim; they are the facts you're not allowed to bend. - **Template style**: read the template PDF (the Read tool renders PDF pages as images — look at it) and note its section order, header/contact layout, fonts and sizes, margins, bullet style, date placement and alignment, and how entries are spaced. You're going to replicate this, so be specific. If a `references/template-style.md` exists, use it as the starting point and update it if the template changed. - **JD**: extract the employer's required vs. preferred qualifications, the hard skills and named tools, the domain keywords, and the *phrasing* they use (e.g. "structure-based virtual screening", "de novo enzyme design", "generative molecular models"). Build a ranked must-have / nice-to-have list — this is the scoring key for everything downstream. ### Phase 2 — Select and prioritize for two pages Score each master-CV item by relevance to the JD's ranked list, then choose what survives: - Lead with the experiences, projects, and skills the JD cares most about; compress or drop the ones it doesn't. A master CV is exhaustive on purpose — the resume is the highlight reel for *this* reader. - Keep the backbone every resume needs (contact header, education, and a skills section) even where the JD is silent, but let JD relevance set the order and depth of everything else. - Reorder bullets within a role so the most JD-relevant point comes first. - Aim the selected volume at a clean two pages — see Formatting rules for why exactly two. ### Phase 3 — Align to the JD's language (truthful rewording) Rewrite the surviving bullets and skills in the JD's vocabulary **where Tim's real experience already supports it**. This is straight translation, not escalation: - When a master-CV skill is a close match to a JD keyword, swap in the JD's term. Example: master says "molecular docking of enzyme variants"; JD says "structure-based virtual screening" → adopt the JD's phrase because it genuinely describes the same work. Only do this for genuinely close/equivalent skills — never relabel something Tim didn't do. - Prefer strong past-tense verbs, keep bullets tight and results-forward, and lead with impact or the quantified outcome rather than the task. - Keep tense, punctuation, and date format consistent within each section (see Formatting). Anything that goes *beyond* faithful translation — stronger scope, more ownership, claimed proficiency, transferable/adjacent framing, a newly surfaced skill — is an **escalation** and belongs in Phase 4, not here. ### Phase 4 — Escalation proposals — STOP for approval Tim has asked for **assertive** escalation: actively look for places to frame his experience more strongly toward the JD, including adjacent and transferable framing and skills he clearly has but didn't spell out. But assertive is not the same as unilateral — **every escalation is a proposal Tim approves before it goes in.** This gate is the whole point; do not skip or soft-skip it. Present the proposals as a clear numbered table so he can scan and decide fast. For each: | # | Section / bullet | Current (from master CV) | Proposed (escalated) | What's being escalated | Confidence | |---|---|---|---|---|---| - **What's being escalated**: e.g. scope, ownership/lead framing, tool proficiency level, quantified impact, or a latent/transferable skill made explicit. - **Confidence flag** — be honest, this is what protects Tim: - 🟢 clearly supported by the master CV, just stated more strongly - 🟡 arguable — a reasonable stretch he should sanity-check against reality - 🔴 would require a fact not in the master CV — **off by default**, include only if Tim confirms it's true and supplies the basis. - Never invent or alter numbers, titles, employers, dates, degrees, or credentials — those are facts, not framing. Escalation reshapes how real things are *described*, never what they are. Then ask Tim to approve, one by one or in bulk ("all greens, skip 4 and 7", etc.). Only approved rows enter the resume. If he's away/unattended, apply 🟢 only, hold 🟡/🔴, and say so. ### Phase 5 — Build the resume (.docx + PDF) Author the resume as a **.docx** that matches the template's style (read the docx skill's SKILL.md for construction technique), then render the **PDF from that same .docx** so the two files are identical. Don't hand-build the PDF separately — one source, two exports. The **LibreOffice-rendered PDF is the file Tim submits**, so it is the authoritative deliverable — its page count and layout are what must be exactly right, and the two-page check in Phase 6 is measured against it. The .docx is the editable backup; keep it clean and matching, but the PDF governs. - Build in the workspace. Use `scripts/build_pdf.sh ` to convert to PDF and print the page count (LibreOffice + pdfinfo). Iterate docx → render → check. - Match the template: same section order, header layout, fonts/sizes, margins, bullet glyphs, and especially **date alignment** (see Formatting). When in doubt, mirror the template. ### Phase 6 — Verify before delivering Render the final PDF and **actually look at it** (Read the PDF pages as images). Check: - **Exactly two pages** (or a deliberate three with a stated reason — see Formatting). - Dates and any right-hand column line up cleanly and use one format throughout. - Formatting is consistent within each section (bullets, tense, punctuation, spacing). - No section title stranded alone at the bottom of a page, orphaned from its first entry. - No fabrications slipped in; every escalation present was approved in Phase 4. Fix and re-render until it passes. This visual check is not optional — page count and alignment problems are invisible in the docx and obvious in the PDF. ### Phase 7 — Deliver - Deliver both files (`Tim_resume__.docx` and `.pdf`, today's date and the target company) in chat with SendUserFile, **and** write them back into Tim's `Job Seeking\cv` folder with device_commit_files whenever that folder is connected — that's his default. If it isn't connected, deliver in chat and note he can reconnect the folder or save them himself. - Provide the **skills list** (Phase-specific deliverable below). - Give a 2–4 sentence summary: what you prioritized for this JD, which escalations were applied, and the page-count decision if it wasn't a clean two. ## The skills list deliverable Produce a list of Tim's skills **worded in the JD's language**, for pasting into an application form's "skills" field. Include only skills he genuinely has (direct matches plus approved escalations). Give it two ways: a comma-separated single-line version for forms with one box, and a short grouped version (e.g. by theme) for forms that take many. Deliver it both inline in chat and as a small `.txt` file so it's easy to copy. Flag any high-value JD keyword he does **not** yet cover, so he can decide whether to address it — but never add uncovered keywords to the paste-ready list. ## Formatting rules (and why they matter) 1. **Exactly two pages.** Recruiters skim; a resume that spills a few lines onto a third page reads as unedited, and one that stops at 1.3 pages reads as thin. Hit two full pages. Go to three **only** with a genuine reason (e.g. an extensive, directly-relevant publication record a research role expects) — and when you do, say why. Your levers, in order of preference: cut/compress lower-relevance content first, then tighten wording, then adjust spacing and margins within the template's range, and only lastly nudge font size — never so far that it stops matching the template. 2. **Clean alignment.** Dates (and any right-hand column) must sit on a consistent right margin and use one date format throughout (pick the template's, e.g. `Mon YYYY`). Ragged or mixed-format dates are the fastest way to look sloppy; use tab stops or a right-aligned table column, not spaces. 3. **Consistency within a section.** Inside a given section, keep one bullet glyph, one verb tense, one punctuation convention (e.g. no terminal periods, or all periods — pick one), and even spacing. Consistency is what makes a resume feel *designed*. Deviate only for a deliberate reason, and if you do, keep it intentional and uniform. 4. **Keep titles with their content.** Try not to let a section header land at the very bottom of a page with its first entry pushed to the next page — keep the header with at least its first entry. This is a soft goal: honor it when you can, but don't wreck the two-page fit or create ugly gaps chasing it. ## Integrity (non-negotiable) The resume must be something Tim can defend in an interview. Facts — numbers, titles, employers, dates, degrees, publications, credentials — are copied from the master CV, never altered. Escalation changes only the *framing* of real experience, and only with Tim's approval (Phase 4). When unsure whether something is fact or framing, treat it as fact and ask. ## Bundled resources - `scripts/build_pdf.sh` — render a .docx to PDF via LibreOffice and print the page count. Usage: `bash scripts/build_pdf.sh path/to/resume.docx [output_dir]`. - `references/template-style.md` — cache of the style template's extracted specs. Create/update it the first time you calibrate against a template so future runs start from it. ## Notes - This skill is JD-agnostic and reusable for any role — nothing here is Roche-specific. - Related skills: read the **docx** skill for building the .docx, and **pdf** if you need to manipulate the rendered PDF. Do not use **my-writing-style** here — that's for first-person prose, not resumes.