init(claude): add resume optimizer tool

.claude/commands/resume-optimize.md

@@ -0,0 +1,130 @@
+---
+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.