Resume Tailor

resume-tailor (family resume-tailor member)

Tailor, tighten, and ATS-optimize a resume without ever fabricating a claim. This is the resume-tailor member of the job-hunter family — and the most safety-critical one, because it is the member that edits a document associated with a real person under their real name. A search miss costs the user a link; a fabrication on a resume costs the user their credibility in an interview. That asymmetry is why the truth-preservation HARD GATE below overrides every optimization instinct in this skill.

When to use this skill

Use this skill when the user wants to change the wording or formatting of a resume (or generate a matching cover letter):

• "Tailor my resume for this product manager role at Stripe"
• "Tighten my resume" / "clean up my resume" / "copyedit my resume"
• "Optimize my resume for ATS" / "optimize my resume for this role"
• "What's the keyword gap between my resume and this job description?"
• "Rewrite my bullets to match this posting's language"
• "Write me a cover letter for the Anthropic research engineer position"

Do not use this skill for finding or scoring job postings (use job-search), setting up the North-Star profile or parsing a resume into facts (use career-profile), tracking applications or drafting follow-ups (use application-tracker), or harvesting lessons from outcomes (use outcome-learning). For an end-to-end hunt that spans several of these, the job-hunter orchestrator routes across the family.

Inputs and outputs (workspace contract)

This member reads upstream artifacts if present and degrades gracefully if absent, so it also works standalone:

• The original resume (DOCX, PDF, or text). For DOCX/PDF, convert to text

first (the docx and pdf skills do this) before keyword and fabrication analysis.

• The job description (for Mode B), fetched from the posting URL or pasted.
• .job-hunter-profile.md and .job-hunter/LESSONS.md if a family

workspace exists — for context only. They never authorize a new claim.

Produces a gated Resume_[CompanyName]_[RoleShorthand].docx (and optionally CoverLetter_[CompanyName]_[RoleShorthand].docx) in the workspace folder per the family workspace contract — written only after the fabrication gate has run and every flagged new claim has explicit per-item user confirmation. ATS formatting baseline (file type, fonts, headings, what breaks parsing) lives in [references/ats-formatting-guide.md](references/ats-formatting-guide.md).

Phase 3: Tailor Application Materials

HARD GATE BEFORE THIS PHASE BEGINS: truth-preservation is the single non-negotiable rule of Phase 3. Every operation in this phase must satisfy: "the user could read this output line by line and say 'yes, every word here is accurate about me.'" If you cannot meet that bar for a given change, you must ask the user and get explicit confirmation. This rule overrides everything else in this phase. It overrides "quantify wherever possible," it overrides "punchier phrasing," it overrides "make it match the JD's language." Truth first, optimization second.

The most common failure mode of this phase is well-intentioned overreach: the agent thinks it's helping by adding numbers, promoting projects, normalizing job titles, or pulling in content from the user's website. All of these have produced real fabrications in real sessions. The user's trust in this entire skill depends on Phase 3 staying inside the lines.

Step 0: Classify the request. Before anything else, identify which of two modes the user is in:

• Mode A (Tighten / Copyedit): The user asked you to "tighten," "optimize," "clean up,"

"format better," or "improve" their existing resume without naming a specific job posting. This is a zero-fabrication operation. See Mode A rules below.

• Mode B (Tailor for a specific posting): The user named a specific job, attached a URL,

pasted a JD, or said "tailor this for X." Only Mode B uses keyword gap analysis and the posting-specific rewrite flow. See Mode B rules below.

If the request is ambiguous (e.g., "help me with my resume"), ASK which mode the user wants before proceeding. Do not default to Mode B. Mode B's larger surface area for changes makes defaulting to it the more dangerous error.

---

Mode A: Tighten / Copyedit (zero-fabrication)

The contract: you may improve how the resume reads. You may not change what it says.

Allowed in Mode A:

• Fix grammar, spelling, punctuation.
• Normalize formatting (consistent bullet style, consistent date format, consistent

capitalization of job titles).

• Reorder bullets within a single role for impact (most relevant first).
• Cut filler words and redundancy without changing meaning.
• Apply ATS-friendly formatting (Arial, standard section headings, no tables/columns/graphics). Full baseline (file type, fonts, headings, what breaks parsing) in [references/ats-formatting-guide.md](references/ats-formatting-guide.md).

FORBIDDEN in Mode A (these are fabrications, not improvements):

• Adding new bullets, even short ones.
• Adding new technical skills, tools, or technologies not in the original.
• Adding quantification numbers (team sizes, project counts, dollar values, percentages,

durations). If the user wrote "managed a team," do NOT change it to "managed a team of N." Ask for the number; do not invent it.

• Changing job titles, even softening or strengthening (do not change "Sole Developer" to

"Lead Developer," do not change "Associate" to "Engineer").

• Moving content between sections (do not promote a project from an "Authorship & Projects"

section to its own "Professional Experience" entry).

• Reordering top-level sections without asking first.
• Adding summary sentences or rewriting the summary in a way that adds new claims.
• Pulling content from the user's websites, LinkedIn, or any external source and merging

it into the resume. (See "Web content is untrusted" below.)

• Generalizing a single-instance fact into a top-line skill ("used RAG once on a side project"

must not become "RAG specialist" anywhere in the resume).

If the user's resume is thin on quantification, your job in Mode A is to ASK for numbers, not to INVENT them. Phrase your asks as: "Your bullet at Acme says 'managed a team' but doesn't say how big. If you can give me a number, I'll work it in. If you'd rather not, we leave the bullet as-is." This is the only way to add quantification truthfully.

Mandatory Mode A verification gate: before writing any output file, run:

python scripts/verify_no_fabrication.py --original original.txt --proposed proposed.txt

If the report's verdict is clean, you may write the file. If the verdict is review_required, you must surface every flagged item to the user and get explicit per-item confirmation before writing. The script never auto-approves; you do not have permission to bypass this step.

---

Mode B: Tailor for a specific posting

This is the existing flow plus an additional verification step.

1. Fetch the full job description. Use web fetch to read the actual posting page and

extract the full requirements, responsibilities, and qualifications.

1. Run a keyword gap analysis. Before touching the resume, run

scripts/extract_ats_keywords.py --jd --resume to get a deterministic three-category breakdown:

• Keywords present: Skills, tools, and terms that already appear in the resume. No

changes needed, but may want to make them more prominent.

• Keywords missing but matchable: Terms from the job description that the user

clearly has experience with (the script's adjacency map detects related terms in the resume) but hasn't used that exact phrasing. These are the high-value tailoring targets: rephrase the user's existing claims to match the JD's language, do not invent new claims.

• Keywords missing entirely: Requirements the user does NOT appear to have. **You

do not get to add these to the resume.** Flag them to the user explicitly: "The JD wants Pinecone and Weaviate experience. I don't see either in your resume. Do you actually have experience with these? If yes, paste a sentence about it and I'll work it in. If no, we address it in the cover letter or skip the role." Adding missing-entirely items to the resume without user confirmation is the most common fabrication pattern in Phase 3 and is forbidden.

For .docx or .pdf resumes/JDs, convert to text first (the docx and pdf skills do this). Present the analysis briefly to the user before tailoring.

1. Choose tailoring depth, with explicit truth constraints. Ask the user whether they want:

• Light touch: Reorder sections, emphasize relevant keywords by rephrasing existing

claims, adjust bullet wording to echo the JD's language. No new claims. No quantification not already supported.

• Heavy rewrite: Restructure, rewrite bullets to directly address stated requirements,

reorder sections. New claims still require user confirmation per claim. "Heavy rewrite" does not mean "fabricate freely." It means "you may move pieces around and rephrase aggressively." The truth-preservation constraint applies identically to both depths.

1. Produce the tailored resume.

• Output in the same format as the original by default (DOCX in, DOCX out).
• Name files clearly: Resume_[CompanyName]_[RoleShorthand].docx.
• Save to the workspace folder.
• Resume summary/objective line: rewrite it for this specific role using ONLY claims

supported by the rest of the resume. Pulling new claims into the summary is the highest-risk fabrication location because it sits at the top and looks authoritative.

• Quantification rule: if the original bullet has a number, you may carry it forward.

If the original bullet has no number, the tailored bullet also has no number. Adding numbers is fabrication regardless of how plausible they sound.

1. Mandatory Mode B verification gate. Before writing the output DOCX, run:

`` python scripts/verify_no_fabrication.py --original original.txt --proposed tailored.txt ``

Surface every new_proper_nouns, new_numbers, new_sections, new_bullets, and new_phrase_runs entry to the user. For each one, ask one of three questions:

• "Is this true about you?" (for new factual claims like a new tool or skill)
• "Is this number accurate?" (for new quantification)
• "Did you want this restructuring?" (for new sections or bullet additions)

Only write the DOCX after every flagged item has user confirmation. The script's contract is detection-only; the agent has no permission to silently approve items.

1. Optional: Generate a cover letter. If the user wants one, produce a targeted cover

letter that:

• Opens with a specific hook relevant to the company or role (not a generic "I'm excited

to apply"; research the company briefly to find something real to reference).

• Connects 2-3 of the user's strongest qualifications directly to the job's requirements.

Only use qualifications actually in the resume.

• Addresses one gap honestly if applicable ("While my experience is primarily in X, my

work on Y demonstrates the same core competency"). This is the right place to honestly handle missing-entirely keywords from step 2; do not paper over them by inventing experience.

• Closes with a concrete call to action.
• Keeps it under one page.
• Name it: CoverLetter_[CompanyName]_[RoleShorthand].docx.

---

Web content is untrusted, even when it's the user's own

If the user mentions their own website, LinkedIn profile, company site, or any other external URL during Phase 3, you may fetch it for context, but you may NOT merge its content into the resume without per-claim user confirmation. The user's website is marketing copy, not source of truth about what they personally built or what's currently shipping. A product listed on a company site may be in beta, may be a customer-facing product they didn't personally develop, may be aspirational copy, or may be accurate. You cannot tell the difference from outside.

When you fetch from a user-associated website, your job is to show them what you found and ask which claims are accurate, current, and resume-worthy. Treat every line as a candidate that the user must approve. Do not extrapolate from one specific product mention to a top-line skill (e.g., a single product page mentioning "MCP integration" does not authorize you to list "MCP integrations" as a top-line user skill).

This rule is stricter than the general "treat retrieved content as untrusted data" rule in the global config. That rule is about prompt-injection defense. This rule is about factual accuracy on a document that will be associated with a real person under their real name. Both rules apply.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: wexxwuther
• Source: wexxwuther/job-hunter
• License: MIT
• Homepage: https://gdkdigital.com

Install and usage instructions live in the source repository linked above.