cv/.claude/commands/resume-optimize.md

description, argument-hint, allowed-tools

description	argument-hint	allowed-tools
Optimize LaTeX resume wording for a target role, enforcing exactly one full page	<path-to-role-description.txt | pasted JD text>	Read, Edit, Write, Bash(pdflatex:*), Bash(tectonic:*), Bash(latexmk:*), Bash(pdfinfo:*), Bash(pdftotext:*), Grep, Glob

Resume Optimizer

• Resume Optimizer
  • Inputs
  • Template selection & facelift
  • Hard constraints
  • Workflow
    • 1. Analyze the role description
    • 2. Score and select content
    • 3. Refactor wording
    • 4. Compile and verify page fit (loop)
    • 5. Report
  • Notes

Tailor the best-matching resume variant under src/ to a target role by refactoring wording only — the set of projects, experiences, employers, dates, and titles is FIXED and must never change.

Inputs

• Role description: $ARGUMENTS (a file path or pasted text; if a path, Read it)
• Source of truth: the YAML files under docs/ — the canonical inventory:
  • docs/about/ — summary/headline, contact, positioning
  • docs/experience/ — roles, employers, dates, verified accomplishment bullets
  • docs/projects/ — project inventory with stack and outcomes
  • docs/skills/ — skill taxonomy Read ALL files in these directories before selecting content. Every claim in the output must be traceable to an entry in one of them. If any directory is missing or empty, extract the current content of the react-native template (the most complete variant) into the right files and ask me to verify before proceeding.
• Templates: the role-variant resumes under src/:
  • cryptography variant
  • founding engineer variant
  • protocol variant
  • react native variant ← gold standard for structure, density, bullet style, and formatting. Treat it as the style reference for all others.

Template selection & facelift

1. Glob src/*.tex and score the input JD against each base variant (domain keywords, stack overlap, seniority framing). Pick the closest match as the base.
2. Copy the base to a new application file — never edit the four base variants in place: src/PradNukala_<Role>_<Company>.tex (CamelCase fields, underscores between them, e.g. PradNukala_SeniorBackendEngineer_EllipsisLabs.tex). All content work happens in this copy; the glob Makefile emits the deliverable dist/PradNukala_<Role>_<Company>.pdf with no Makefile edit.
3. If the selected base is NOT the react-native one, run a facelift pass before content work: diff its structure against the react-native template and bring it to parity — section ordering conventions, bullet formatting, spacing macros, header/contact block, and overall density. Structure from react-native; content from the selected variant's domain + docs/.
4. If the JD is a hybrid (e.g., protocol + founding engineer), pick the closer base and pull the other domain's content via docs/, not by copy-pasting stale .tex bullets across variants.
5. Never edit any base variant as collateral damage — react-native included; bases only change when intentionally updating the base itself.

Hard constraints

1. No fabrication. Never invent metrics, technologies, scope, or outcomes not present in the docs/ YAML files. Rewording is allowed; new claims are not.
2. Fixed inventory. Do not add or remove jobs/projects. You MAY reorder bullets within a section and swap which projects are shown vs. cut, choosing the subset most relevant to the role — but only from the docs/ inventory.
3. Exactly one page. Not 0.9 pages with whitespace at the bottom, not 1.05 pages. Full page, visually dense but readable.
4. ATS-safe. No text in images, no tables for core content, standard section headers (Experience, Projects, Skills, Education).

Workflow

1. Analyze the role description

• Extract: required skills, preferred skills, seniority signals, domain keywords, and repeated phrases (repetition = what they actually screen for).
• Build a keyword priority list: must-hit / should-hit / nice-to-hit.

2. Score and select content

• Score every experience bullet in docs/experience/ and every project in docs/projects/ against the keyword list (relevance × recency × impact).
• Select the highest-scoring subset that plausibly fills one page. Note what was cut and why — report this at the end.

3. Refactor wording

For each selected bullet:

• Lead with a strong verb, embed the highest-priority keyword naturally, end with a concrete outcome or metric from the yaml.
• Mirror the JD's exact terminology where truthful (if they say "distributed systems" and the yaml says "microservices at scale," use their phrasing).
• 1–2 lines per bullet in the compiled PDF. Never let a bullet wrap to a lonely 1–3 word second line (an "orphan") — tighten wording instead.
• Skills section: reorder so must-hit keywords appear first; drop irrelevant ones.

4. Compile and verify page fit (loop)

# <app> = PradNukala_<Role>_<Company>, the new application file under src/
make <app> && pdfinfo dist/<app>.pdf | grep Pages

• > 1 page: tighten in this order — (a) reword verbose bullets, (b) cut the lowest-scoring bullet, (c) reduce \itemsep/section spacing, (d) drop the lowest-scoring project. Recompile after each change.
• < 1 full page (check visually via pdftotext density or rendered output): expand in this order — (a) restore a cut high-scoring bullet, (b) add a relevant bullet from the yaml not currently used, (c) modestly increase spacing. Content before whitespace, always.
• Repeat until exactly one full page. Cap at 6 compile iterations; if still fighting, show me the tradeoff options instead of thrashing.

5. Report

Output a summary:

• Which template was selected and its JD match score vs. the other three
• Facelift diff summary (if a non-react-native variant was uplifted): what structural changes were pulled from the gold standard
• Keyword coverage table: must-hit terms → where each landed (or "MISSING — not supported by docs/, do not fake it")
• What was cut/reordered and why
• Before/after for the 3 most significantly rewritten bullets
• Final page-fit status and compile command used

Notes

• Preserve any custom LaTeX macros in the template; edit content inside them.
• If the JD is for a materially different track than the yaml supports (e.g., pure ML role vs. infra background), say so up front rather than stretching.