emrekgn/tailored-resume-skill

Tailored Resume

Turn one person's base resume plus a job posting into a tailored resume (.md + .pdf). Then report how well it covers the posting and what's missing.

Accuracy is the point of this skill. A tailored resume that overstates experience can cost the user an offer, or a job after the offer. So this skill keeps a ledger of verified facts, never invents anything, and treats gaps as something to report, not hide.

The resume workspace

Work in the user's resume folder, usually the current directory. It holds:

File	Purpose
base-resume.md	The master resume in this skill's Markdown format. Every tailored variant starts from it.
facts.md	The ledger: corrections, confirmed facts missing from the base resume, things never to claim, and preferences (page count, paper size, contact line).
<slug>-resume-<company>.md / .pdf	One tailored variant per application. <slug> is the person's name in kebab-case.
anything else	Supporting sources the user provides: a LinkedIn export, old PDFs, a GitHub profile, project READMEs.

If the folder has a resume under a different name, use it and note its name in facts.md, rather than renaming the user's files.

First run: bootstrap

If there's no base resume yet:

1. Ask for the user's existing resume (PDF, DOCX, text, or a LinkedIn export). For a PDF, extract it with pdftotext -layout.
2. Convert it to the format in references/format.md, keeping the wording. Don't tailor at this stage.
3. Create facts.md from assets/facts-template.md, filling in the contact line and any preferences the user mentions.
4. Show the user the base resume and ask them to check it before you tailor anything. Mistakes here spread to every variant.

Workflow for a new posting

1. Read the sources. Read base-resume.md, facts.md, and any supporting sources. facts.md overrides the base resume wherever they disagree.

2. Analyze the posting. Sort its requirements into three tiers:

   • P1: must-haves (deal-breakers)
   • P2: strongly desired
   • P3: nice-to-haves

   Note the posting's vocabulary and repeated keywords. ATS keyword matching is literal, so the posting's terms beat synonyms when both are true.

3. Map evidence. For each requirement, find real evidence in the sources. Mark it as strong, partial, or a gap.

4. Write the variant at <slug>-resume-<company>.md. Start from a copy of the base resume, then:

   • Summary: rewrite it to lead with what this role values most. It's the first thing a recruiter reads.
   • Skills: reorder and regroup rows so the most relevant come first, and rename row labels to the posting's terms (e.g. "Message Queues & Streaming", "Platform & Delivery"). Write the full term next to key acronyms the posting uses, once each, e.g. "Terraform (Infrastructure as Code, IaC)", "Kubernetes (K8s)". An ATS may search for either form.
   • Bullets: reorder and reword them within each role so the most relevant come first, and trim ones that don't matter for this posting. Older roles can shrink to 1–3 bullets.
   • Facts ledger: apply every item in facts.md.
   • Open source / projects: for technical roles with public work, add the GitHub/portfolio link to the contact line and a short ## Open Source or ## Projects section. Pick the 2–3 most relevant items.
   • Career change: if the role is a pivot (e.g. engineer to developer relations), keep the normal chronological layout. Add a short highlights section between the summary and skills that collects real, transferable evidence. Don't use a "functional" resume; recruiters and ATS software tend to distrust it.

5. Build and verify (see below). Fix layout problems before reporting.

6. Report in the format below.

Honesty rules

These rules exist because the pull toward overclaiming is constant and subtle. Each one guards against a mistake that actually happened in practice.

• Never invent skills, tools, metrics, scale numbers, titles, or responsibilities. If the posting asks for something the sources don't show, leave it out and list it as a gap. The user may well have the experience. Asking takes one message; a fabricated claim can surface in an interview.
• Rewording is fine; strengthening is not. Matching the posting's vocabulary is fine. Raising a claim's strength is not, for example:
  • "worked on" becoming "led"
  • adding "in minutes", "at scale", or "under production load" without a source
  • merging two separate facts into one bigger claim. For example, "led the team on open-source and enterprise projects; the enterprise ones had 200k users" must not become "led an open-source team whose projects reached 200k users".
• No self-praise the sources don't contain, e.g. "go-to engineer for hard problems" or "can explain anything to any audience". Show it with evidence instead.
• Attribute carefully. Keep a fact tied to the role it came from. A fact the user confirmed without a role ("I've used Terraform") goes in the summary or skills, not under a guessed job.
• Keep metrics verbatim. Percentages, counts, and timeframes stay exactly as the sources state them.
• Keep real job titles. Framing in the summary ("Staff-level Backend Engineer") is fine.
• Check every new or changed bullet against a source before building. When something is a reasonable inference but not stated, either drop it or flag it in your report.

When the user corrects or confirms something

Add it to facts.md right away, with the date and, if known, the role it belongs to. Then search every other variant for the same error and fix those too. Skip any the user says were already sent, and list those in facts.md so future runs leave them alone. Rebuild the PDFs you changed, and tell the user which files changed.

Build and verify

python3 "${CLAUDE_SKILL_DIR}/scripts/build_resume.py" <slug>-resume-<company>.md --check

• What it does: writes the PDF next to the Markdown file, then prints the page count and the text an ATS parser would extract. Pass --paper a4 if facts.md says the user prefers A4.
• If ${CLAUDE_SKILL_DIR} isn't set: use the absolute path of this skill's directory.
• If no browser is found: ask the user to install Chrome or Chromium, or to set CHROME_BIN to its path.

Then check three things:

1. Page count. Use the user's preference from facts.md. Otherwise aim for 1 page under ~10 years of experience and 2 pages above that.
2. Visual layout. If pdftoppm is available, run pdftoppm -r 60 -png <pdf> <tmpdir>/preview and look at every page image. Check for awkward page breaks and lines that wrap badly.
3. Extracted text. Every skill row should read as one line with its label, and every role header should be one line that includes its dates. If not, the Markdown probably drifted from the format.

If it's over the page target, trim in this order

1. least relevant bullets in older roles
2. long skill rows (merge rows, keep each to one line)
3. certificates (merge onto one line, drop unrelated ones)
4. summary length

Don't shrink fonts or margins to fit. Dense pages read worse to humans and gain nothing with an ATS.

Layout rules

The builder's layout is designed for ATS parsing, so don't change it. Tables, multiple columns, and right-aligned dates (flex or float) look fine but extract badly: labels separate from values, and dates separate from job titles. The builder also keeps hyphenated words unbroken, because a hyphen at a line break is dropped on extraction ("high-throughput" becomes "highthroughput").

Report format

After building, reply with:

1. Files: the paths of the .md and .pdf.

2. Coverage table:

   Tier	Requirement	Evidence in resume (or gap)

3. Emphasis: a few lines on what you emphasized and what you trimmed.

4. Questions: ask about experience that could close P1/P2 gaps, or about claims you inferred and need confirmed. Be specific: "Did you work directly with X, or only through Y?"

5. Optional offers: mention, without writing them unasked, that you can draft cover letter openers, answers to application questions, or interview talking points.

If the role is a big stretch (several P1 gaps), say so plainly and suggest what would help most. For example: a portfolio project, an open-source contribution to the company's repos, or a cover letter explaining the career change.

Application questions and cover letters

Use the same facts ledger and honesty rules. Answer in the user's voice (first person), concisely, and name any specifics you inferred so the user can fix them. Write cover letters as <slug>-cover-letter-<company>.md. build_resume.py is built for resumes, so for a PDF letter write simple HTML and print it with the same headless-browser command the script uses.

Reference files

• references/format.md: the exact Markdown format the builder parses, with a full example. Read it before writing or converting a resume.
• assets/facts-template.md: starting point for a new facts.md.
• assets/example-resume.md: a fictional sample resume for testing the builder.