Resume tailor

Resume Tailor

Tailors a resume for Ernest Matthew Moore (San Antonio, TX — DevOps / Private Cloud Infrastructure) to a specific job posting. Output is a 2-page reverse-chronological resume in three formats, plus a soft fit-check report.

Why this skill exists

Matt applies to roles where the keyword density and bullet phrasing materially affect ATS scoring and recruiter screening. Rather than manually re-cutting his master experience for each posting, this skill reads the JD, pulls the most relevant achievements from /context/ work history files, and rewrites bullets so they speak the JD's language without inventing experience.

The skill is also opinionated about job fit: Matt's Basic_Information.md lists hard preferences (full-time only, generative culture, 4.0+ rating, specific industries, location/remote rules). Rather than gate on these, the skill still produces the resume but surfaces violations in a Fit Concerns section so Matt can decide whether to apply.

Inputs the skill needs

1. A job posting URL. If the user did not provide one, ask for it before doing anything else. Do not invent a URL or proceed without one.
2. The /context/ folder at C:\Users\Tench\.claude\context\Resume Builder\. Read every .md file there — Basic_Information.md, Professional_Summary.md, Education.md, every USAA-*.md, and every USAF-*.md. These are the source of truth for contact info, summary, and experience. Do not embellish beyond what these files state.

Throughout this skill, /context/ always means C:\Users\Tench\.claude\context\Resume Builder\ — the single canonical source.

Workflow

Follow these steps in order. Each step has a specific reason — do not skip ahead.

1. Confirm the URL and fetch the JD

Ask the user for the posting URL if not already provided. Then fetch it with WebFetch (or the Chrome MCP if WebFetch is blocked by the site). Extract:

• Company name
• Job title
• Location and remote/hybrid policy
• Employment type (full-time, contract, contract-to-hire, etc.)
• Required and preferred skills/technologies
• Years of experience expected
• Industry signals (FinTech, defense, edtech, etc.)
• Any rating signals if visible (Glassdoor stars, etc.) — usually not in the JD itself, note "unknown" if absent

If the fetch fails, tell the user which method failed and ask whether to try the Chrome MCP, paste the JD text directly, or abort.

2. Run the soft fit-check

Read references/fit_check.md and apply each rule against the JD facts gathered in step 1. Build a short table of Preference -> JD signal -> Pass/Concern/Unknown. This becomes the Fit Concerns section in the markdown output. Do not refuse to proceed even if everything fails — Matt asked for soft warnings, not gates.

3. Read all /context/ files

Read every .md file in /context/. Build a mental map keyed by role: company, dates, unit, responsibilities, and the explicit Core Competencies and Technologies list. Treat the tech lists as authoritative — if a technology is not listed for a role, do not claim Matt used it in that role.

4. Select and rewrite bullets

Score each bullet from each role against the JD's required and preferred skills. Pick the highest-density bullets per role until the resume fits two pages (typically 4–6 bullets for the current Lead DevOps role, 3–4 for prior USAA roles, 1–2 condensed lines for USAF roles).

When rewriting, follow these rules:

• Lead with the JD's vocabulary when Matt's source bullet describes the same thing in different words. Example: if the JD says "GitOps pipelines" and the source bullet says "GitLab CI/CD pipelines," it is fine to write "GitOps-style GitLab CI/CD pipelines" — both are accurate.
• Never invent technologies. If the JD asks for Kubernetes and the role's tech list says OpenShift, say OpenShift (which is Kubernetes-based) — do not write "Kubernetes" if it is not in the source.
• Never artificially bolster, imply, or over represent expertise or experience.
• Quantify where the source already quantifies. Do not fabricate metrics.
• Use strong past-tense verbs (Architected, Led, Automated, Migrated, Mentored) and present-tense for the current role.
• One line per bullet when possible; never more than two physical lines on the page.
• Correct common misspellings, grammatical, punctuation, and syntax mistakes.
• Avoid sounding overly sterile or AI written/generated, keep items succinct, professional, and prose as human as possible. when possible. Employers usually prefer human written resume versus AI written prose, which is becoming esier to identify using AI.

5. Assemble the resume

Use the template in references/resume_template.md. Section order, top to bottom:

1. Contact header — pulled verbatim from Basic_Information.md (name, location, phone, email, LinkedIn)
2. Professional Summary — start from Professional_Summary.md and tighten/retarget to the JD's seniority and stack in 2–3 sentences
3. Core Competencies — a 2- or 3-column compact list of technologies that appear in BOTH the JD and at least one role's tech list. This is the keyword block that ATS systems look for.
4. Professional Experience — reverse-chronological. USAA roles newest-to-oldest, then USAF roles. Each role: title, company, location, dates, then bullets.
5. Education — from Education.md
6. (Optional) Certifications / Additional — only if /context/ has them and they are relevant

Aim for 2 pages. If the content runs over, trim oldest USAF bullets first, then oldest USAA bullets.

6. Write outputs

Create the output folder using the company and job title. Sanitize the folder name by replacing spaces with underscores and removing characters illegal in Windows paths (< > : " / \ | ? *).

`C:\Users\Tench\.claude\output\Resume Builder\<Company>-<Position>\` and make copy in `M:\Github\ai-sandbox\output\Resume Builder\<Company>-<Position>\`

Write three files into that folder:

• Ernest_Moore_Resume.md — the markdown source. Include a final ## Fit Concerns section at the bottom from step 2. This is for Matt's eyes; the Fit Concerns section is intentionally not in the docx.
• Ernest_Moore_Resume.docx — produced via the docx skill. Read the docx SKILL.md first and follow its guidance. Use a clean single-column ATS-friendly layout — no tables for the body, no text boxes, no headers/footers.

Also write a short JD_summary.md into the same folder containing the company, title, URL, fetch date, and the extracted JD facts. This makes it easy for Matt to revisit later why a particular resume was cut the way it was.

7. Present results to the user

Use computer:// links for each generated file. Lead with the .docx (the primary submission artifact), then PDF, then markdown. Surface the Fit Concerns summary inline in the chat response so Matt sees it without opening the markdown — but keep it short (one line per concern).

Output naming convention

Folder: <Company>-<Position> with spaces replaced by underscores.

Example: a Staff DevOps Engineer posting at Charles Schwab becomes:

output/Charles_Schwab-Staff_DevOps_Engineer/
  ├── Ernest_Moore_Resume.md
  ├── Ernest_Moore_Resume.docx
  └── JD_summary.md

If the folder already exists from a prior run for the same posting, overwrite the files (do not append a timestamp). Matt iterates on these — versioning is handled by git in the project, not by filename.

What this skill does NOT do

• It does not write cover letters. That is a separate skill.
• It does not auto-submit applications anywhere.
• It does not invent experience, certifications, or metrics that aren't in /context/.
• It does not gate on fit. Even a contract role at a 2.1-rated consulting shop will get a resume — just with a loud Fit Concerns section.

Related references

• references/fit_check.md — the preference rules to evaluate against
• references/resume_template.md — the section-by-section structure with length guidance and bullet examples