tailoring-resumes

これはレビュー時に保存された抜粋です。完全で最新の内容は外部ソースを確認してください。

---
name: tailoring-resumes
description: Tailors a candidate's resume to a specific job description so it passes automated resume screening (ATS), while preserving the existing Typst template and staying on one page. Use when the user pastes or links a job description and asks to tailor, customize, optimize, or "ATS-proof" their resume for a role, or mentions applying to a job, beating the resume screener, or matching a posting's keywords.
metadata:
  version: 1.1.0
---

# Tailoring Resumes

Rewrite a candidate's resume to match one specific job description so it ranks well in automated resume screening (ATS), **without changing the visual format and without exceeding one page**. The job is keyword alignment and emphasis, grounded in true experience — never fabrication and never a redesign.

> [!important] Two hard rules that override everything else
> 1. **Truth only.** Every claim must trace to the candidate's own materials (their resume and background file). If the job wants a skill the candidate doesn't have, you do NOT add it — you report the gap. Keyword stuffing with skills they can't back up gets caught by a human and burns the application.
> 2. **Never edit the master.** The candidate's resume file is the source of truth. Write tailored output to `tailored/<company>-<role>.typ`. Keep the master untouched.

## Inputs

This skill needs two files. **Locate them first** (don't assume specific names):

- **The resume** — the Typst `.typ` resume file in the project. This is both the content baseline and the **exact format to preserve** (layout, sections, one-page budget). If there's exactly one `.typ` resume, use it; if there are several or none, ask the user which file is their resume.
- **The background file** — a Markdown file holding the candidate's fuller background/bio: experience that did *not* make the one-page resume. Look for something like a file under an `about/`/`bio/` folder or named `*info*.md`, `bio.md`, `background.md`, `about.md`. This is the reservoir to pull from when a job calls for something the resume currently downplays.

Read both before editing. Treat the background file as the wider truth and the resume as the current one-page selection from it. If no background file exists or it's thin, work from the resume and **ask the user** for missing detail rather than inventing it.

## What ATS screening actually rewards

An ATS is a pipeline: it converts the file to text, **parses** it into fields, then **matches and ranks** candidates against the job — and surfaces a shortlist (e.g., top 30 of 300) to a recruiter. Most ATSs **rank rather than auto-reject**, so the goal is to *parse cleanly and rank near the top*, then survive the human read. The two levers a resume controls are **parseability** (does the machine extract the text right?) and **relevance** (does the extracted text match the JD's language?). Parseability comes first — a term the parser never extracts can't match anything. Full detail in `references/ats-rules.md`. The essentials:

- **Parse-first.** Parsing is the #1 failure point (multi-column scramble, headers/footers skipped, scanned PDFs). Keep contact info in the body, keep substantive keywords in the left content column of the `twocol` rows (dates only on the right), and never submit a scanned/image resume.
- **Mirror the posting's exact words.** If the JD says "CI/CD," "TypeScript," "RAG," "Kubernetes" — use those literal strings. Legacy keyword/Boolean search (still ubiquitous) won't match a synonym; modern embeddings still reward exact alignment.
- **Spell out acronym + expansion once** (e.g., "Model Context Protocol (MCP)") so both forms match.
- **Only claim what's true.** Reframe and re-emphasize real experience to speak the JD's language; do not add skills the candidate lacks.
- **Knockouts live on the form, not the resume.** Hard objective requirements (work authorization, minimum years, licensure) are the real auto-reject gate and can't be tailored away — flag them as gaps ins