Job Application Tailoring Skill

This skill guides you through tailoring or generating a resume and/or cover letter for a specific job posting. It preserves the user's original document formatting when editing, generates polished new documents when starting from scratch, maximizes ATS keyword match, and provides strategic recommendations for the full application.

CRITICAL: Preserve the Meaning of Every Bullet

The #1 rule of this skill: a rewritten bullet must describe the SAME work the user actually did. Minor wording improvements and polish are fine — changing what the bullet is about is not.

What's OK (polish and clarity):

• Stronger action verbs ("Led" → "Spearheaded", "Worked on" → "Developed")
• Adding JD keywords that genuinely describe what the user did (adding "A/B testing" to a bullet that already describes running experiments)
• Tightening wordy phrasing
• Minor embellishments to scope language ("projects" → "cross-functional projects") when clearly supported by context
• Reordering bullet content for better flow

What's NOT OK (changing meaning):

• Swapping the domain/subject — if the bullet is about fraud interventions, the rewrite must still be about fraud interventions, NOT about "growth" or "activation" or "product flows" just because the JD emphasizes those areas
• Replacing the actual method with a different one — if the user did A/B tests for fraud, don't rewrite it as "causal inference methods for growth decisions"
• Changing the purpose/outcome — if the user's goal was "measuring risk mitigation vs. user friction", don't change it to "measuring activation impact and informing growth decisions"
• Inventing metrics the user didn't provide — no fake percentages or dollar amounts. Ask the user or use placeholders like [X%]

The test: If someone read the original bullet and the rewrite side-by-side, they should say "yes, that's the same work, just described better" — never "wait, that's a completely different thing."

Real example of what NOT to do: Original: "Leading the design and analysis of high-velocity A/B tests to optimize fraud interventions, ensuring statistical rigor in measuring the trade-off between risk mitigation and user friction to maintain user trust" BAD rewrite: "Designing and executing rigorous A/B tests and non-inferiority experiments to optimize product flows, applying causal inference methods to measure activation impact and inform growth decisions across the product funnel" ↑ This changed fraud → product flows, risk/friction tradeoff → activation impact, user trust → growth decisions. The domain, method, and purpose are all different.

GOOD rewrite: "Designing and leading high-velocity A/B tests to optimize fraud intervention strategies, applying statistical rigor to quantify the trade-off between risk mitigation and user friction — balancing fraud prevention with seamless user experience" ↑ Same work, same domain, same purpose — just tighter and more impactful phrasing.

When in doubt, ASK — it is always better to ask the user "Did you actually do X?" than to guess. Present a draft bullet with a placeholder like [X%] or [confirm detail] and let the user fill in the truth.

Phase 0: Gather Inputs

Before doing anything, confirm you have:

1. The job description — either a URL or pasted text. If a URL, try WebFetch first; if blocked, use WebSearch for the job title + company to find JD details.
2. The user's resume — as a .docx (preferred), .pdf, or pasted text/background info. See "Input Modes" below.
3. The user's cover letter (if applicable) — as a .docx.
4. User instructions — ask if they have specific bullets or sections they want to preserve or emphasize.

Input Modes

Mode A: Edit existing .docx (format-preserving) If the user provides a .docx file, or says "follow my structure" / "don't change the format", edit the original .docx XML directly rather than generating a new document. This is the default when a .docx is available.

Mode B: Edit from PDF If the user provides a PDF only, use pandoc to extract text. Inform the user: "I can tailor the content but can't preserve PDF formatting — please attach a Word doc if you need the original layout preserved." If user cannot provide a .docx, proceed with Mode C using the extracted text.

Mode C: Generate from scratch If the user provides only background information (text, bullet points, work history), generate a new tailored resume. Use the docx SKILL if available for professional formatting, or output as clean Markdown. This mode is ideal for:

• Users without an existing resume
• Career changers who need a fundamentally different structure
• Users who want a fresh start on their resume

Phase 1: Extract and Analyze the JD

Parse the job description for:

• Role title and seniority level
• Top 10–15 ATS keywords — look for tools, skills, frameworks, and domain terms repeated or bolded (e.g., "DSPs", "MMPs", "attribution models", "A/B testing", "cross-functional", "roadmap", "MarTech")
• 3–5 core responsibilities the role emphasizes most
• Company signals — tone (corporate vs. startup), mission language, product focus
• Company Information — use websearch tool to search company recent news, blog that relate to the JD. Additionally, search on LinkedIn to check users who share a similar title (for instance, if the role is Sr Data Scientist, search for any user whose current/past company is the same and whose title is Data Scientist / Sr Data Scientist / Staff Data Scientist / Lead Data Scientist etc.) and search their work experience to see if there's any additional accomplishments and job description context.

Prioritize Requirements

Create a priority map:

• Priority 1 (Critical): Deal-breaker requirements — years of experience, required skills, education
• Priority 2 (Important): Strongly desired qualifications — key methodologies, domain expertise
• Priority 3 (Nice-to-have): Bonus skills, preferred certifications, cultural fit indicators

Group keywords into categories: Technical Tools, Domain Expertise, Leadership/Process, Metrics.

Phase 2: Audit the Resume

Extract the full text of the resume (use pandoc <file.docx> -t plain or read directly from XML if unpacked, or use the pasted text for Mode C).

Check:

• Which JD keywords are already present → keep
• Which JD keywords are missing but clearly apply to the user's experience → candidates to inject
• Which bullets are weak (vague, no metric, no action verb) → rewrite targets
• ATS risks: typos, inconsistent hyphenation, missing sections

Bullet Rewriting Formula

Every strong bullet follows: Action verb + What you did + How (method/tool/scale) + Result (metric or impact)

Weak: "Led marketing platform work at Loblaw" Strong: "Architected AI-powered marketing platform automation, designing ML workflows that drive end-to-end creative production at scale for a 20M+ customer base"

Apply this to every bullet that lacks a metric or is vague.

IMPORTANT — Preserve meaning when rewriting bullets:

• Keep the same domain and subject matter — if a bullet is about fraud, the rewrite is about fraud. Don't swap in JD language that changes what the work was actually about.
• Keep the same methods — if the user ran A/B tests for X purpose, don't change it to causal inference for Y purpose.
• Keep the same outcome/goal — if the goal was risk mitigation, don't change it to growth optimization.
• If the original bullet has no metric, do NOT invent one. Instead, either:
  1. Ask the user for the real number: "Your bullet about the marketing platform — do you know the actual revenue impact or user count?"
  2. Use qualitative scale words that are clearly true from context: "at scale", "enterprise-wide", "across multiple channels" — but only if the user's description supports that scope
  3. Use a placeholder in the draf