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

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

# Resume Optimizer

<!--toc:start-->
- [Resume Optimizer](#resume-optimizer)
  - [Inputs](#inputs)
  - [Template selection & facelift](#template-selection-facelift)
  - [Hard constraints](#hard-constraints)
  - [Workflow](#workflow)
    - [1. Analyze the role description](#1-analyze-the-role-description)
    - [2. Score and select content](#2-score-and-select-content)
    - [3. Refactor wording](#3-refactor-wording)
    - [4. Compile and verify page fit (loop)](#4-compile-and-verify-page-fit-loop)
    - [5. Report](#5-report)
  - [Notes](#notes)
<!--toc:end-->

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)
```bash
# <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.