Resume Tailor

Resume Tailor

Turn a resume plus a job description into a tailored, ATS-safe, honest resume the candidate can edit in Google Docs — with every change visible so they can approve it.

The job here is not to maximize keyword overlap. It is to make every genuine match legible to a recruiter in six seconds, and to tell the candidate the truth about the gaps rather than papering over them. A resume that wins a screen and loses the interview has cost the candidate more than a rejection would have.

Workflow

Follow these six steps in order. Step 4 is a gate — do not skip it.

1. Read both inputs

Resume — usually a PDF or .docx in /mnt/user-data/uploads. If its content is not already visible in context, consult the file-reading and pdf-reading skills. Extract every role, date, metric, tool, and claim. Note what's missing too: education, dates, certifications, and unexplained gaps all matter later.

Job description — may arrive as pasted text, a bulleted list, a link, or a spreadsheet. For .xlsx/.csv, consult the xlsx skill; JD spreadsheets typically carry one requirement per row, sometimes with a priority or must-have column — respect that column if present, since it tells you which gaps are fatal.

If the user gives a JD but no resume, ask for the resume — do not invent a history. If they give a resume but no JD, skip to the review path in references/writing-rules.md (Review Mode) and produce a scorecard plus a rebuilt resume.

2. Extract the JD's real requirements

Pull out and group:

• Named hard skills — specific tools, platforms, languages, certifications. These are the gates. Count how many times each appears and where (title and first paragraph = gate; buried in a nice-to-have list = soft).
• Responsibilities — the verbs. These become bullet openers.
• Seniority signals — years required, team size, scope, leadership language.
• Domain — the industry or problem space.
• Recurring vocabulary — the exact phrasing the JD reuses. Prefer their words over synonyms; ATS keyword matching is literal, and a human reader recognizes their own language.

3. Cross-reference against the resume

Build a match table. Three verdicts only:

Adjacency is where the value is, and where the discipline is. Testing an analytics product is genuine adjacency to "data quality." Having used a database is not adjacency to a named BI platform. When unsure, mark it 🟡 and ask.

4. Report before you write

Show the user the match table and a blunt fit estimate before producing the resume. State plainly which named requirements are absent and that they will not be added. If the absent items are the JD's headline requirements, say the role is a stretch and say what would actually change that — usually a specific certification or a cover note that names the gap.

This step exists because the candidate, not the assistant, decides whether to apply. Handing over a polished document that quietly overstates their background takes that decision away from them.

5. Build the resume

Write a JSON spec and render it:

node scripts/build_resume.js spec.json                    # working copy
node scripts/build_resume.js spec.json --clean            # send-ready copy

Inline markup, usable in any text field:

--clean strips highlights, drops note blocks, and refuses to build if any [placeholder] remains, printing the offenders. That guardrail is the point: it makes it structurally hard to send out a resume with [N] still in it.

Schema and a complete worked example: references/resume-json.md. Bullet formulas, section order, ATS rules, and the defects to fix on sight: references/writing-rules.md.

Default output is one working copy. Produce a second variant only when the user has a real reason for one — a different target title, a different seniority level, or a one-page hard limit. Variants are a cost to maintain; don't generate them reflexively.

6. Deliver

Upload to Google Drive as a native Google Doc so the user can edit immediately:

Google Drive:create_file(
  title="<Name> — <Target Role> — <Company>",
  base64Content=<base64 of the .docx>,
  contentMimeType="application/vnd.openxmlformats-officedocument.wordprocessingml.document"
)

Drive converts .docx to a Google Doc automatically — highlights and colours survive. If the connector is unavailable, search the MCP registry and offer it; meanwhile deliver the .docx with present_files, which opens in Google Docs anyway.

Then close with: the Drive link, the count of highlighted changes, and the three or four placeholders that matter most — ranked by what they do for the application, not by where they appear in the document.

Non-negotiables

Never add a skill, tool, employer, date, or metric the resume does not support. Not in the summary, not in a skills row, not softened to "exposure to." The candidate will be asked about it by someone who does the job for a living.

Numbers come from the candidate. Where a bullet needs a metric that isn't in the source resume, emit a [placeholder] rather than a plausible-sounding figure. An invented "reduced regression by 40%" is the single most damaging thing this skill could produce, because it reads perfectly and cannot be defended.

Reframing is fair; relabelling is not. Rewriting "drive continuous improvement in automation practices" as "drive continuous improvement initiatives that cut regression from X to Y" is honest reframing into the JD's vocabulary. Adding a platform they have never opened is not.

Flag contradictions rather than smoothing them. Mismatched locations, an award dated before the job that granted it, a claimed year count the timeline doesn't support — a recruiter will spot these, so surface them to the user.

Say when the fit is poor. A candidate who applies knowing they are a 60% match and addresses the gap in a cover note does better than one who was told everything looked great.

Reference files

• references/writing-rules.md — bullet formulas, section order and cuts, ATS constraints, tense and style rules, standing defects to fix, and Review Mode (no JD).
• references/resume-json.md — the spec schema with a full worked example.