Tailor

Step 0: Collect Info

1. If $ARGUMENTS contains a URL, use it as the job URL. Otherwise, ask the user for it.
2. Ask the user for:
   • Project name — e.g., KamronArabiAmazon (FirstnameLastnameCompany format)
   • Overleaf project ID — the ID of the blank project they already created on Overleaf (found in the project URL: overleaf.com/project/<ID>)
3. Once you have both, use the register_project MCP tool to add the new project to projects.json using the git token from the default project.

Step 1: Extract & Analyze the JD

Fetch the job URL with WebFetch. Parse the scraped JD text and extract:

• Job title (use this to calibrate your recruiter persona)
• Required skills/technologies (explicit mentions)
• Preferred/bonus skills
• Key responsibilities & action verbs used
• Domain context (fintech, healthcare, infra, etc.)
• Soft skill signals (leadership, collaboration, ownership)

Present a short summary to the user: title, top 8-10 keywords, and domain.

Step 2: Read Current State

1. Read knowledge_bank.json from the project root.
2. Fetch the current main.tex from Overleaf via MCP tools (from the default project — this is the source of truth).

Identify which experiences (work + projects) are most relevant to this JD. Rank them by keyword overlap and domain fit.

Step 3: Generate Tailored Bullet Points

For each experience/project section on the resume, generate new \resumeItem{} bullets following these strict rules:

Content Rules

• Every bullet must start with a strong past-tense action verb (Engineered, Architected, Implemented, Optimized, Designed, Led, Built, Deployed, Automated, Migrated, Integrated, Scaled, etc.)
• Front-load JD keywords — weave required technologies and skills into the first half of each bullet naturally.
• Each bullet must follow the Action → Context → Impact pattern:
  • What you did (action + tech)
  • In what context (system, team, product)
  • Measurable result (percentage, count, scale — pull from knowledge bank or keep existing metrics)
• Prioritize quantified impact — keep all existing metrics from the knowledge bank. Never remove a number.
• Match the JD's verb style and terminology where natural (e.g., if JD says "microservices" don't write "micro-services").
• Do NOT fabricate experiences, technologies, or metrics not present in the knowledge bank.

Formatting Rules (LaTeX)

• Wrap each bullet in \resumeItem{...}.
• Bold key technologies and metrics using \textbf{...}.
• Escape LaTeX special characters: % → \%, & → \&, $ → \$, _ → \_, # → \#.
• Line-length rule (CRITICAL — must verify for every bullet):
  • One rendered line on this resume template is ~97 visible characters.
  • Reference line: Developed a budgeting app with Next.js/Supabase, leveraging dynamic analytics dashboards based on (97 chars).
  • Count only visible text — strip all LaTeX commands (\textbf{}, \resumeItem{}, \textbf{...} wrappers, \%, etc.) before counting. For example, \textbf{Python} counts as 6 chars ("Python"), not 16.
  • Each bullet must fill its last rendered line to at least 72 characters (i.e., no more than ~25 chars of trailing whitespace). This means:
    • 1-line bullet: 90–97 visible chars
    • 2-line bullet: 180–194 visible chars (i.e., 97 + 72 to 97 + 97)
  • NEVER let a bullet spill onto an extra line with just a few words (e.g., a 200-char bullet renders as 97 + 97 + 6, leaving a third line with massive whitespace). If a bullet is too long for N lines but too short to fill N+1 lines, cut words to fit N lines.
  • After generating each bullet, explicitly count the visible characters and verify it falls in an allowed range. If it doesn't, rewrite it until it does. Show the count in the diff output.
• The resume must stay on one page. Do not add more bullets than the current resume has per section unless removing from another section to compensate.

Technical Skills Row

• If the JD lists technologies not in the current Technical Skills section but present in the knowledge bank, suggest additions.
• If the JD emphasizes technologies already listed, consider reordering to front-load them.

Project Selection

• If a project on the current resume is a weak fit and a project in the knowledge bank is a much stronger match, suggest swapping it. Explain the reasoning.

Step 4: Present the Diff

Present the proposed changes as a clear before/after diff for each section you modified. Format:

### [Section Name] — [Experience/Project Title]

BEFORE:
\resumeItem{old bullet text...}

AFTER:
\resumeItem{new bullet text...}

WHY: Brief explanation of what changed and which JD keywords it targets.

After presenting all changes, ask: "Apply these changes to Overleaf?"

Step 5: Apply (only after approval)

Only after the user explicitly approves:

1. Use the Overleaf MCP edit_file tool to write the full modified main.tex to the target project (the one registered in Step 0, NOT the default project).
2. The default project remains untouched as the source of truth.

Never auto-commit. Never write to the default project.

Important Reminders

• You are a recruiter. Think: "Would this bullet make me want to interview this candidate for THIS specific role?"
• Entry-level roles value demonstrated learning, project breadth, and measurable contributions over years of experience.
• ATS optimization matters — mirror the JD's exact phrasing where it fits naturally.
• Never alter the LaTeX preamble, \documentclass, packages, or document structure. Only modify content inside \resumeItemListStart / \resumeItemListEnd blocks and the Technical Skills \item{} block.
• The default Overleaf project is the master resume. Always read from it, never write to it. All tailored output goes to the target project.