feat: rebuild evidence-first application workflow
This commit is contained in:
@@ -0,0 +1,74 @@
|
||||
# Application Strategy
|
||||
|
||||
## Positioning
|
||||
|
||||
Default professional identity:
|
||||
|
||||
> Staff/Senior Data Engineer with production platform ownership, AWS data products, Kubernetes delivery and direct production-ML integration experience.
|
||||
|
||||
Core targets:
|
||||
|
||||
- Senior/Staff Data Engineer.
|
||||
- AWS-oriented Data Platform Engineer when Terraform/SRE background is not mandatory.
|
||||
- ML Platform/MLOps roles centered on deployment, infrastructure and operation.
|
||||
- Semiconductor data, analytics and production-ML infrastructure roles.
|
||||
- Swiss/DACH enterprise data-engineering roles.
|
||||
|
||||
Stretch targets include LLM/agent engineer, AI Manager, pure SRE, strategic-account FDE, and Principal roles requiring company-wide architecture or external-customer authority.
|
||||
|
||||
## Application Gate
|
||||
|
||||
Before generating a resume, complete Evidence Fit from `critique_framework.md`.
|
||||
|
||||
- **Core:** 75+ and no hard-gate failure.
|
||||
- **Adjacent:** 60--74, no required Gap, normally at most one serious preferred gap.
|
||||
- **Stretch:** below 60 or a defining responsibility is only Adjacent.
|
||||
- **No-go:** required/title-defining Gap or unresolved practical constraint.
|
||||
|
||||
Do not spend a full resume/cover-letter cycle on a no-go role. Record the decision and move on.
|
||||
|
||||
## Controlled Ten-Application Cohort
|
||||
|
||||
The next diagnostic cohort uses:
|
||||
|
||||
- 7 Core applications.
|
||||
- 2 Adjacent applications.
|
||||
- 1 Stretch application maximum.
|
||||
|
||||
Track fit class, hard gates, channel, application date, stage and outcome. Evaluate the cohort only after ten applications or a meaningful screen/interview result; do not infer profile quality from a few high-variance FAANG outcomes.
|
||||
|
||||
## Channel Strategy
|
||||
|
||||
For every Core application, attempt at least one warm action before or immediately after applying:
|
||||
|
||||
- credible internal referral;
|
||||
- targeted note to a relevant recruiter;
|
||||
- concise outreach to the hiring manager or team member;
|
||||
- former colleague/customer/vendor connection who can establish work quality.
|
||||
|
||||
Record the channel as Strong, Moderate or Weak. Tailoring alone does not upgrade a cold channel.
|
||||
|
||||
## Resume Strategy
|
||||
|
||||
- Use International Tech format by default.
|
||||
- Keep the first half page focused on identity, compact skills and current evidence.
|
||||
- Preserve conventional employer/title/date hierarchy.
|
||||
- Favor 11--14 strong bullets over padding.
|
||||
- Capture verified impact rather than inventing metrics.
|
||||
- Generate the Swiss/DACH variant only when local conventions fit the employer.
|
||||
|
||||
## Cover-Letter Strategy
|
||||
|
||||
Apply the decision gate in `cl_reference.md`. A letter is not a default package component. Put effort into portal questions, referral context and outreach when those have higher information value.
|
||||
|
||||
## Feedback Loop
|
||||
|
||||
After the ten-application cohort, compare:
|
||||
|
||||
- Core vs Adjacent/Stretch progression.
|
||||
- Warm vs cold progression.
|
||||
- Recruiter rejection vs hiring-manager rejection.
|
||||
- Tool/domain patterns among successful and unsuccessful roles.
|
||||
- Whether resume changes affected outcomes.
|
||||
|
||||
Change one major variable at a time. Do not react to a single rejection by adding unsupported skills or broader positioning.
|
||||
@@ -1,104 +1,62 @@
|
||||
# Cover Letter Generation — Reference
|
||||
# Cover Letter Reference
|
||||
|
||||
> CL-specific rules. Read by `/make-cl` and `/edit-resume` (for CL edits).
|
||||
> Shared rules (provenance, anti-fabrication, LaTeX notation): `CLAUDE.md`
|
||||
> A cover letter is optional by default. The resume must earn a screen on its own.
|
||||
|
||||
---
|
||||
## Decision Gate
|
||||
|
||||
## CL Format Rules
|
||||
Generate a cover letter when at least one is true:
|
||||
|
||||
- Cover letter with resume: 1 page (250-300 words)
|
||||
- Cover letter with CV: 1-2 pages (350-450 words). If 2 pages, page 2 >= half filled before signature.
|
||||
- Full package: Resume + CL = 3 pages | CV + CL = 6-7 pages
|
||||
- The posting or portal requests one.
|
||||
- The employer is a traditional Swiss/DACH institution, public body, NGO or mission-led organization where motivation is material.
|
||||
- A credible career/location/domain transition needs a short explanation.
|
||||
- Work authorization, language, relocation or a genuine personal connection materially strengthens the application.
|
||||
- The user explicitly requests a letter.
|
||||
|
||||
---
|
||||
Normally skip it when:
|
||||
|
||||
## Institution Type Detection
|
||||
- The portal provides no upload field.
|
||||
- A standardized process already asks motivation questions.
|
||||
- It would merely repeat the resume or paraphrase company news.
|
||||
|
||||
- **Industry:** Any company (manufacturing, tech, consulting, energy, etc.)
|
||||
- **National Lab:** DOE labs, national research facilities, government lab fellowships
|
||||
- **Academic:** University postdoc or faculty positions
|
||||
Record `Cover Letter Decision: YES/NO` and the reason in the session file before writing.
|
||||
|
||||
---
|
||||
## Evidence Rules
|
||||
|
||||
## INDUSTRY Cover Letter (250-300 words, 3 paragraphs)
|
||||
1. Read `resume_builder/canonical/claims.json` first.
|
||||
2. Every work claim must be traceable to the resume and canonical registry.
|
||||
3. Significance files supply optional context only; reverify external claims from current primary sources.
|
||||
4. Company or industry scale never becomes Dennis's personal scale or impact.
|
||||
5. Do not introduce a skill, metric, customer, ownership claim or result absent from the resume.
|
||||
|
||||
**P1 — HOOK:** Connect their product/technology to your achievement. State core identity + position. Open with a specific reference to their work, not a generic opener. Minimize jargon for HR readers.
|
||||
## International Tech / Industry Letter
|
||||
|
||||
**P2 — EVIDENCE:** 2-3 achievements translated to business value. Max 3-4 quantified claims. Mirror JD terms. Frame as deliverables.
|
||||
- One page, normally 200--300 words.
|
||||
- Two or three short paragraphs.
|
||||
- Open with the candidate-role connection, not a company press-release summary.
|
||||
- Use one or two proof points and explain why they matter for this role.
|
||||
- Add motivation or context the resume cannot show.
|
||||
- Close directly and professionally.
|
||||
|
||||
**P3 — CLOSING:** Forward-looking value + active call to action. Address "why industry" positively if pivoting — frame what industry enables, not what academia lacks.
|
||||
## Swiss/DACH Letter
|
||||
|
||||
---
|
||||
- One A4 page.
|
||||
- Match the language and formality of the posting.
|
||||
- Explain motivation, relevant evidence and practical fit such as location/language.
|
||||
- References and diplomas remain separate attachments when requested.
|
||||
|
||||
## NATIONAL LAB Cover Letter (350-450 words, 4 paragraphs)
|
||||
## Employer-Specific Formats
|
||||
|
||||
**P1 — HOOK:** Mission alignment + division/group + position. Reference specific programmatic thrust or group's publication. Technical vocabulary OK.
|
||||
For NATO, government or academic applications, follow the employer's explicit format and portal fields. Do not force a generic three-paragraph industry structure when the application requests a motivation statement or competency answers.
|
||||
|
||||
**P2 — CURRENT POSITION:** Current work with mission framing. Theory-experiment bridge. HPC scale. Collaborative tone.
|
||||
## Hook Verification
|
||||
|
||||
**P3 — PRIOR WORK:** Transferable methodology arc. Custom tools → ML infrastructure. International collaboration. Quantify.
|
||||
Verify every named product, programme, paper, executive statement or current company initiative before use. Prefer first-party sources. Record the source in the session file. If a hook is not necessary, omit it rather than spending a paragraph proving company familiarity.
|
||||
|
||||
**P4 — CLOSING:** Programmatic vision + collaboration offer + seminar availability. Lab vocabulary: "thrust area," "programmatic direction."
|
||||
## Quality Checks
|
||||
|
||||
---
|
||||
|
||||
## ACADEMIC Cover Letter (350-450 postdoc, 450-650 faculty; 4 paragraphs)
|
||||
|
||||
**P1 — HOOK:** Connection to PI's specific paper + your identity + position. Name the PI.
|
||||
|
||||
**P2 — CURRENT RESEARCH:** Current position with field-context framing (use significance files if available). Future direction: 1-2 sentences MANDATORY.
|
||||
|
||||
**P3 — PRIOR FOUNDATION:** Transferable methodology + collaboration + mentorship. Faculty: departmental fit narrative.
|
||||
|
||||
**P4 — CLOSING:** Forward-looking + name 2-3 faculty for collaboration. Postdoc: "contribute to your research program." Faculty: "build independent research program complementing..."
|
||||
|
||||
---
|
||||
|
||||
## Universal CL Rules
|
||||
|
||||
- Open with a specific reference to their work — avoid generic openers like "I am writing to express my interest"
|
||||
- Add narrative context the CV cannot — motivation, "why this company," research vision
|
||||
- Limit quantified claims to 3-5 per CL
|
||||
- Credentials woven into body paragraphs, not dumped in closing
|
||||
- Active call to action in closing — not passive "Thank you for your consideration"
|
||||
- If pivoting domains: lead with methodology in P1, not apologetic framing
|
||||
|
||||
---
|
||||
|
||||
## Jargon Calibration
|
||||
|
||||
- **Industry:** Assume HR reads first. Minimize subfield jargon.
|
||||
- **National Lab / Academic:** Domain expert reads. Use field vocabulary.
|
||||
|
||||
---
|
||||
|
||||
## Package Reading Rules
|
||||
|
||||
- Resume/CV must stand alone — many hiring managers never read the CL
|
||||
- CL deepens, not introduces — every major CL claim traceable to a resume/CV bullet
|
||||
- No contradictions between documents
|
||||
- Resume + CL = 3 pages | CV + CL = 6-7 pages
|
||||
|
||||
---
|
||||
|
||||
## CL Hook Verification (MANDATORY)
|
||||
|
||||
Before presenting any CL draft to the user, web-search and verify every external reference:
|
||||
- **Academic:** PI name + cited paper title/topic → confirm paper exists, journal, year
|
||||
- **National Lab:** Named program, thrust area, or group publication → confirm it exists
|
||||
- **Industry:** Product name, technology claim, or company news → confirm accuracy
|
||||
|
||||
**If verified:** Note source URL in session file Cover Letter Plan.
|
||||
**If unverified:** Flag as **"UNVERIFIED — please confirm"** in the draft. Never guess names, titles, or journal details.
|
||||
|
||||
---
|
||||
|
||||
## CL Anti-Patterns
|
||||
|
||||
- No generic opener ("I am writing to express my interest...")
|
||||
- No defensive framing ("Despite my background in...")
|
||||
- No credential dump in closing paragraph
|
||||
- No repeating resume bullets verbatim — CL deepens, doesn't duplicate
|
||||
- Limit quantified claims to 3-5 per CL
|
||||
- **Em-dashes in CLs:** Max 2 per document. CLs are prose-heavy and em-dashes compound quickly. Use commas for parenthetical asides, colons for elaborations, periods for new sentences. Paired em-dashes (X --- detail --- Y) should use commas or parentheses instead.
|
||||
- The resume stands alone.
|
||||
- The letter adds motivation, decision context or a meaningful connection.
|
||||
- The voice is direct and natural.
|
||||
- No generic opening, credential dump, defensive gap list or copied resume bullet.
|
||||
- The canonical validator passes for the cover-letter `.tex`.
|
||||
- The compiled document is one readable page unless the employer explicitly requests otherwise.
|
||||
|
||||
@@ -1,78 +1,14 @@
|
||||
# Critical Rules — Compact Re-Read
|
||||
# Critical Rules — Generation Preflight
|
||||
|
||||
> Quick reference for Phase 2 generation. Full rules in `resume_reference.md`.
|
||||
|
||||
## Character Limits
|
||||
|
||||
**Resume (10pt, textwidth=7.5in):**
|
||||
|
||||
| Target Lines | Rendered Char Range | HARD MAX | Orphan Threshold |
|
||||
|-------|---------------|---------|------------------|
|
||||
| 1 line | 105-111 chars | 117 | -- |
|
||||
| 2 lines | 189-205 chars | 218 | Last line >= 78 chars |
|
||||
|
||||
**CV (11pt, textwidth=7.5in):**
|
||||
|
||||
| Target Lines | Rendered Char Range | HARD MAX | Orphan Threshold |
|
||||
|-------|---------------|---------|------------------|
|
||||
| 1 line | 88-93 chars | 101 | -- |
|
||||
| 2 lines | 168-182 chars | 190 | Last line >= 65 chars |
|
||||
| 3 lines | 250-268 chars | 280 | Last line >= 65 chars |
|
||||
|
||||
### Variant Naming
|
||||
|
||||
| Variant | Document | Lines | Target Range | HARD MAX | Orphan | Word Target |
|
||||
|---------|----------|-------|-------------|----------|--------|-------------|
|
||||
| Resume-1L | 1/2-page resume | 1 | 105-111 | 117 | -- | ~13 words |
|
||||
| Resume-2L | 2-page resume | 2 | 189-205 | 218 | >= 78 | ~23-25 words |
|
||||
| CV-2L | 5-page CV | 2 | 168-182 | 190 | >= 65 | ~21-22 words |
|
||||
| CV-3L | 5-page CV | 3 | 250-268 | 280 | >= 65 | ~31-32 words |
|
||||
|
||||
## Bold Width Penalty
|
||||
|
||||
Resume (10pt): Effective limit = 119 - (0.5 x bold_char_count)
|
||||
CV (11pt): Effective limit = 91 - (0.25 x bold_char_count)
|
||||
|
||||
## Orphan Rule
|
||||
|
||||
Multi-line bullet last rendered line must fill >= 70% of line width.
|
||||
Resume 2L: last line >= 78 chars. CV 2L: >= 65 chars. CV 3L: >= 65 chars.
|
||||
|
||||
## FIXED Sections — NEVER Modify
|
||||
|
||||
All FIXED sections (internships, education, publications, honors/awards, header block) are set in the template.
|
||||
NEVER change: \vspace values, \geometry settings, .cls formatting, header layout.
|
||||
Only modify VARIABLE sections: Summary, Technical Skills, Experience bullets/headers.
|
||||
|
||||
## Provenance Flags
|
||||
|
||||
See `CLAUDE.md` for your project-specific provenance flags. Common patterns:
|
||||
|
||||
| Item Status | Rule |
|
||||
|-------------|------|
|
||||
| Under review | State journal name: "under review at [Journal]" |
|
||||
| Unpublished | No specific numbers or publication claims |
|
||||
| Internal/proprietary | "infrastructure I developed" — not peer-reviewed |
|
||||
| Preprint only | Always flag provenance |
|
||||
|
||||
## LaTeX Notation Quick-Ref
|
||||
|
||||
| Item | Correct LaTeX | Wrong | Rendered |
|
||||
|------|--------------|-------|----------|
|
||||
| Chemical formulas | `\ce{H2O}` | `H2O`, `H$_2$O` | H₂O |
|
||||
| Superscript labels | `X$^2$Y` | `X2Y` | X²Y |
|
||||
| R² values | `R$^2$=0.99` | `R^2`, `R2` | R² |
|
||||
| Greek letters | `$\alpha$-phase` | `alpha-phase` | α-phase |
|
||||
| Approximately | `$\sim$64` | `~64` (LaTeX non-breaking space!) | ~64 |
|
||||
|
||||
CRITICAL: ~ in LaTeX = non-breaking space. Use $\sim$ for "approximately."
|
||||
|
||||
## KB Corrections
|
||||
|
||||
See `CLAUDE.md` for your project-specific KB corrections log. Always check before generation to avoid re-introducing known errors.
|
||||
|
||||
## Budget Reminder
|
||||
|
||||
Resume: ~20 variable bullets (exact count depends on skills config + immigration line). CV: 19-21 bullets, 45 rendered lines.
|
||||
Resume bullets: ALL 2L. CV bullets: 2L/3L mix OK.
|
||||
**CV Page 1 rule:** First bullet of first experience MUST be 2L. A 3L first bullet overflows page 1.
|
||||
1. Read `resume_builder/canonical/claims.json`; it overrides every narrative source.
|
||||
2. Run `python resume_builder/helpers/validate_resume_system.py` before generation.
|
||||
3. Never use an `output/` resume or cover letter as source material.
|
||||
4. Choose International Tech by default; use Swiss/DACH only for an appropriate employer.
|
||||
5. Put employer, formal title and dates before any narrative framing.
|
||||
6. Use an optional 2--3 line summary, 4--6 skills lines and normally 11--14 evidence-led bullets.
|
||||
7. Mix natural bullet lengths. There is no character target and no page-fill quota.
|
||||
8. Do not list unverified skills, metrics, customers, scale or causal impact.
|
||||
9. Scope Swisscom migration and Data Mesh claims to Dennis's domains, components and products.
|
||||
10. Security Champion means the 2025/2026 team role only; omit by default.
|
||||
11. LLM evidence is configuration/integration level; no LangChain, fine-tuning, formal evaluation or production LLM ownership.
|
||||
12. Run the canonical document validator, compile, inspect and test extracted text before presenting.
|
||||
|
||||
@@ -1,494 +1,99 @@
|
||||
# Critique Framework — Consolidated Multi-Perspective Protocol
|
||||
# Application Critique Framework
|
||||
|
||||
**Purpose:** Single-pass comprehensive critique that catches what would otherwise take multiple passes. Run AFTER generation but BEFORE presenting to user.
|
||||
> Never collapse candidate-role fit and document polish into one score.
|
||||
|
||||
**Key insight:** 85% of score improvement typically comes from ONE thing — domain reframing. The Achievement Reframing Guide handles this during generation. The critique's job is to catch what leaked through, identify remaining gaps, and assess interview likelihood from multiple reader perspectives.
|
||||
## 1. Hard-Gate Audit
|
||||
|
||||
---
|
||||
Classify each JD requirement as **Direct**, **Adjacent**, **Gap**, or **Constraint**.
|
||||
|
||||
## Part 0: Domain-Specialist Lens (generate BEFORE the five perspectives)
|
||||
Flag a **NO-GO** when:
|
||||
|
||||
Before running the five-perspective read-through, construct a domain-specialist lens for THIS specific JD + company. The lens is not a static lookup — it is generated fresh each time by analyzing the JD, the company, and the hiring context.
|
||||
- A minimum/required qualification is a Gap.
|
||||
- A title-defining capability is not Direct.
|
||||
- The level requires absent scope, such as people management, strategic external-account ownership, or company-wide architecture authority.
|
||||
- Location, authorization, clearance, travel, or mandatory relocation is unresolved.
|
||||
|
||||
### Build the Lens
|
||||
An employer's general "apply anyway" message does not erase a title-defining or minimum gap.
|
||||
|
||||
**If a session file exists** (`output/session_<name>.md`) with JD Analysis and Company Context sections, use those as the foundation for the lens instead of re-researching from scratch. Supplement only the elements not already covered (competitive landscape, methodology transfer test, reviewer persona details).
|
||||
## 2. Evidence Fit Score — 0 to 100
|
||||
|
||||
**If no session file exists,** research THIS company + THIS JD from scratch. No pre-built templates. No reference lenses.
|
||||
Score the candidate-role pairing before reading tailored prose.
|
||||
|
||||
**For each critique, produce these 7 elements:**
|
||||
| Dimension | Weight | Question |
|
||||
|---|---:|---|
|
||||
| Required qualifications | 35 | How many are Direct? |
|
||||
| Core responsibilities | 25 | Has Dennis performed the actual function? |
|
||||
| Level and ownership | 15 | Do title, decisions and leadership match? |
|
||||
| Recency and depth | 10 | Is the strongest evidence current and substantial? |
|
||||
| Domain/tool transfer | 10 | Are missing tools genuinely substitutable? |
|
||||
| Practical constraints | 5 | Are location, language, authorization and travel workable? |
|
||||
|
||||
1. **Reviewer persona construction:** Who actually reads this resume? Construct from the JD's reporting line, department name, level, and company context.
|
||||
- Their job title and seniority
|
||||
- What they do daily (what tools they use, what problems they solve)
|
||||
- How many CVs they've read for this posting (estimate from company size + role level)
|
||||
- What they've seen 100 times before that makes them roll their eyes
|
||||
- What would genuinely surprise or impress them
|
||||
- **75--100 Core:** apply when no hard gate fails.
|
||||
- **60--74 Adjacent:** selective; normally no more than one serious preferred gap.
|
||||
- **Below 60 Stretch:** normally do not cold-apply.
|
||||
- Any hard-gate failure overrides the number.
|
||||
|
||||
2. **Company research:** What does this company MAKE, SELL, or RESEARCH?
|
||||
- Core business and revenue model
|
||||
- R&D culture: academic-leaning? patent-driven? product-shipping? mission-driven?
|
||||
- Recent news, strategic priorities, or technology bets (if known)
|
||||
- What vocabulary signals "insider who understands our business" vs "outsider applying generically"?
|
||||
- Note any assumptions and flag uncertainty
|
||||
## 3. Document Quality Score — 0 to 100
|
||||
|
||||
3. **JD deep read — vocabulary extraction:**
|
||||
- Read the JD 3 times. First for requirements, second for culture signals, third for vocabulary.
|
||||
- Extract the 8-10 most important terms/phrases (ranked by: frequency in JD, placement in title/header vs body, and whether they represent binary capabilities vs spectrum skills)
|
||||
- For each: what does THIS company mean by this term? (e.g., "emerging computing paradigms" at a given company might mean quantum/neuromorphic — not just "we use ML")
|
||||
- Identify the JD's implicit hierarchy: what's the #1 thing they need vs nice-to-haves?
|
||||
| Dimension | Weight | Question |
|
||||
|---|---:|---|
|
||||
| Truth and provenance | 25 | Does every claim match canonical scope? |
|
||||
| Information hierarchy | 20 | Are employer, title, dates and strongest evidence obvious? |
|
||||
| Bullet evidence and impact | 20 | Are bullets specific and scoped without invention? |
|
||||
| Relevance and terminology | 15 | Does it cover the JD naturally? |
|
||||
| Skills evidence | 10 | Is every skill evidence-backed and interview-ready? |
|
||||
| Mechanics/readability | 10 | Does it compile, parse and read cleanly? |
|
||||
|
||||
4. **Domain vocabulary map:** For this specific JD, what are the 5-8 vocabulary swaps that separate "outsider applying" from "insider who gets it"? Generate these purely from the JD's language and the company context you just researched.
|
||||
Truth/provenance below 8/10 is an automatic document failure.
|
||||
|
||||
Format:
|
||||
| Resume currently says | Should say for THIS JD | Why |
|
||||
|---|---|---|
|
||||
| [term] | [replacement] | [JD uses this language because...] |
|
||||
## 4. Channel Strength — Separate Rating
|
||||
|
||||
5. **Fatal vs cosmetic gap ranking:** Which missing JD keywords would cause immediate rejection vs which are nice-to-have?
|
||||
- **Fatal gaps:** Binary capabilities the JD requires (e.g., "CFD" — you either do it or you don't), terms in the JD title, or phrases repeated 3+ times
|
||||
- **Serious gaps:** Preferred qualifications that multiple competitive candidates will have
|
||||
- **Cosmetic gaps:** Terms buried in preferred quals that most candidates also won't have
|
||||
- For each gap: can it be bridged truthfully? Or is it a hard limitation of the candidate's background?
|
||||
|
||||
6. **Methodology transfer test:** For each of the candidate's top 5 resume achievements, write one sentence explaining how a domain expert at THIS company would see it mapping to THEIR work.
|
||||
- If you CAN write that sentence naturally: the resume has bridged the gap
|
||||
- If you STRUGGLE to write it: the resume hasn't made the transfer explicit enough
|
||||
- If you CAN'T write it honestly: this is a hard gap, not a reframing problem
|
||||
|
||||
7. **Competitive landscape intuition:** Who else is applying for this role?
|
||||
- What background does the "obvious fit" candidate have?
|
||||
- What does THIS candidate offer that the obvious fit doesn't? (e.g., high-venue publication, cross-scale breadth, platform building)
|
||||
- What does the obvious fit offer that this candidate doesn't? (e.g., domain-specific publications, direct tool experience)
|
||||
- This determines what the resume must EMPHASIZE (unique strengths) and what it must BRIDGE (gaps relative to the obvious fit)
|
||||
|
||||
### Output and persist the lens
|
||||
|
||||
Write out all 7 elements as a structured section at the top of the critique file. This lens then informs EVERY subsequent perspective in Parts 1-6. The five readers (ATS, Recruiter, HR, HM, Technical) all read through this lens — they are people at THIS company, not generic archetypes.
|
||||
|
||||
**Persistence rule:** The lens is built ONCE per JD, during the first critique. If the resume is revised and critiqued again (multi-pass), reuse the same lens — do NOT re-research. The lens lives in the critique output file (`output/critique_[name].md`) and is carried forward across passes. Only rebuild the lens if the JD itself changes.
|
||||
|
||||
---
|
||||
|
||||
## Part 1: Five-Perspective Read-Through
|
||||
|
||||
Read the resume/CV from five different personas, in order. Each persona sees only what they'd actually read in their time window. Flag issues per persona.
|
||||
|
||||
### Perspective 1: ATS Robot (0 seconds — keyword scan)
|
||||
|
||||
**What it does:** Pattern-matches JD keywords against resume text. No context, no synonyms (unless configured), no reading comprehension.
|
||||
|
||||
**Check:**
|
||||
- Extract top 20 JD keywords/phrases (tools, methods, domain terms, soft skills)
|
||||
- For each: verbatim match? Semantic match? Absent?
|
||||
- Count match rate: >=70% = PASS, 60-69% = MARGINAL, <60% = FAIL
|
||||
- Flag any JD keyword that appears 3+ times in JD but 0 times in resume (high-priority gap)
|
||||
- Check domain bridges — do they appear enough to pass a domain-specific ATS filter?
|
||||
|
||||
**Output:** Keyword match table + match rate + top 3 missing keywords that could be added truthfully.
|
||||
|
||||
### Perspective 2: Recruiter Glance (10 seconds)
|
||||
|
||||
**What they read:** Name, current title/employer, education line, header tagline, first 2 lines of summary. Nothing else.
|
||||
|
||||
**What they decide:** "Forward to hiring manager or reject?"
|
||||
|
||||
**Check:**
|
||||
- Does the header tagline use target-domain language (not source-domain)?
|
||||
- Does the current employer signal credibility for this role type?
|
||||
- Does the education line clear the bar? If pedigree gap exists, does the summary compensate in the first 2 lines?
|
||||
- Is there a prestige signal in the first 2 lines (top venue, major metric)?
|
||||
- Would a non-technical recruiter understand what this person does?
|
||||
|
||||
**Output:** "Forward" / "Maybe" / "Reject" + one-sentence reasoning.
|
||||
|
||||
### Perspective 3: HR Screen (30 seconds)
|
||||
|
||||
**What they read:** Full summary + skills section headers + first bullet per position + education.
|
||||
|
||||
**What they decide:** "Does this person meet the basic qualifications? Schedule phone screen?"
|
||||
|
||||
**Check:**
|
||||
- Does the summary bridge from actual domain to target domain? (The bridge sentence is the single most important sentence in the document)
|
||||
- Do skills group NAMES (not just content) signal target-domain relevance?
|
||||
- Does the first bullet under each position deliver the strongest JD-relevant achievement?
|
||||
- Are years of experience consistent with JD requirements?
|
||||
- Immigration status present if required?
|
||||
|
||||
**Output:** "Phone screen" / "Borderline" / "Pass" + one-sentence reasoning.
|
||||
|
||||
### Perspective 4: Hiring Manager Read (2 minutes)
|
||||
|
||||
**What they read:** Everything on the resume/CV. They're a domain expert.
|
||||
|
||||
**What they decide:** "Interview or not? What would I ask?"
|
||||
|
||||
**Check:**
|
||||
- **Methodology transfer:** For each major bullet, can the HM see how this applies to THEIR work? Or do they have to imagine the transfer themselves? (If the HM has to do the translation, you've lost points)
|
||||
- **Narrative arc:** Does the story progress logically? (Typical good arc: deep science → engineering discipline → leadership → tools/platforms)
|
||||
- **Red flags:** Any overclaiming? Any "this person doesn't know what we do" signals? Any keyword stuffing that feels forced?
|
||||
- **Differentiation:** What makes this candidate different from other applicants? Is that differentiator visible?
|
||||
- **Domain gap honesty:** Does the resume acknowledge what it ISN'T (transparent about actual domain) while showing what transfers? Honest reframing beats pretend expertise.
|
||||
|
||||
**Output:** "Interview" / "Maybe" / "No" + top 3 things HM would notice + predicted first interview question.
|
||||
|
||||
### Perspective 5: Deep Technical Reviewer (10 minutes)
|
||||
|
||||
**What they do:** Read every bullet carefully. Check publications. Assess truthfulness. Look for inconsistencies.
|
||||
|
||||
**Check:**
|
||||
- **Truthfulness audit:** For each quantitative claim, is it verified against extractions/experience files?
|
||||
- **Provenance flags:** All works-in-progress or under-review items properly flagged?
|
||||
- **Verb discipline:** Contributing-author bullets use hedged verbs? Full-ownership verbs only where justified?
|
||||
- **Publication coherence:** Do pub tags match the resume's domain framing? Do paper titles (which can't be changed) create cognitive dissonance with the reframed bullets?
|
||||
- **Internal consistency:** Does the summary match the bullets? Does the cover letter match the resume?
|
||||
- **Over-saturation:** Any keyword repeated >8 times? (Borderline at 6-8, concern at 9+)
|
||||
|
||||
**Output:** Truthfulness table (claim → verified? → source) + any inconsistencies found.
|
||||
|
||||
---
|
||||
|
||||
## Part 2: Eight-Dimension Scoring
|
||||
|
||||
Score each dimension independently, then compute weighted total.
|
||||
|
||||
| # | Dimension | Weight | What to Assess |
|
||||
|---|-----------|--------|---------------|
|
||||
| 1 | ATS Keyword Match | 15% | JD keyword coverage rate, verbatim vs semantic, missing high-value terms |
|
||||
| 2 | Summary | 10% | Bridge sentence, target-domain language, prestige signals, forward-looking intent |
|
||||
| 3 | Skills Section | 10% | Group names (domain signal), content relevance, bold accuracy, no wasted entries |
|
||||
| 4 | Bullet Quality | 25% | Per-bullet JD alignment (HIGH/MEDIUM/LOW), reframing quality, quantification, action verbs |
|
||||
| 5 | Publication Selection | 10% | Venue prestige, tag relevance, first-author ratio, domain gap acknowledgment |
|
||||
| 6 | Narrative Coherence | 15% | Header-to-footer story, domain thread count, first-impression timing |
|
||||
| 7 | Page Fill & Visual | 5% | Budget compliance, orphan check, compile clean, slack acceptable |
|
||||
| 8 | Credibility Signals | 10% | Venue quality, metrics (papers, citations, awards), platform adoption, leadership evidence |
|
||||
|
||||
**Scoring rubric per dimension:**
|
||||
- 9-10: Essentially optimal for this candidate-JD pairing
|
||||
- 8-8.5: Strong, minor improvements possible but diminishing returns
|
||||
- 7-7.5: Good but identifiable gaps that reframing could close
|
||||
- 6-6.5: Significant gaps — missing domain bridge, wrong vocabulary, weak bullets
|
||||
- <6: Major problems — wrong role framing, overclaiming, format violations
|
||||
|
||||
**Overall score interpretation:**
|
||||
- 85+: At or near ceiling. Submit.
|
||||
- 80-84: Strong. 1-2 targeted improvements could push to ceiling.
|
||||
- 75-79: Good foundation but missing domain reframing or key bullets.
|
||||
- 70-74: First-draft quality. Needs systematic reframing pass.
|
||||
- <70: Fundamental issues (wrong role type, missing sections, accuracy problems).
|
||||
|
||||
---
|
||||
|
||||
## Part 3: Interview Likelihood Assessment
|
||||
|
||||
After scoring, assess interview probability from each reader's perspective.
|
||||
|
||||
### Assessment Matrix
|
||||
|
||||
| Reader | Time | Question They Ask | Likely Outcome |
|
||||
|--------|------|-------------------|----------------|
|
||||
| ATS | 0 sec | "Do keywords match?" | PASS / FAIL |
|
||||
| Recruiter | 10 sec | "Credible for this level?" | FORWARD / REJECT |
|
||||
| HR | 30 sec | "Meets basic quals?" | PHONE SCREEN / PASS |
|
||||
| Hiring Manager | 2 min | "Would I learn something in an interview?" | INTERVIEW / MAYBE / NO |
|
||||
| Technical Panel | 10 min | "Can this person do the work?" | STRONG YES / YES / CONCERNS |
|
||||
|
||||
For each reader, give a probability estimate (e.g., "80% forward") and the single factor that most influences their decision.
|
||||
|
||||
### Ceiling Analysis
|
||||
|
||||
| Scenario | Estimated Score |
|
||||
|----------|----------------|
|
||||
| Current resume | [X] |
|
||||
| + Top 3 improvements applied | [X + delta] |
|
||||
| Theoretical max (this candidate + this JD) | [X_max] |
|
||||
| Hard ceiling (structural background gap) | [X_ceiling] |
|
||||
| What would close the gap | [e.g., "1 domain publication → +3 pts"] |
|
||||
|
||||
---
|
||||
|
||||
## Part 4: Actionable Improvements (Ranked)
|
||||
|
||||
List ALL identified improvements in three tiers:
|
||||
|
||||
### Tier 1: HIGH IMPACT (each worth >= 1 point)
|
||||
These are the improvements that move the score meaningfully. Typically:
|
||||
- Domain reframing that was missed during generation
|
||||
- Missing JD keyword that can be added truthfully
|
||||
- Bullet swap (weak bullet → stronger unused achievement)
|
||||
- Summary bridge sentence missing or weak
|
||||
|
||||
For each: Current text → Proposed text → Why → Expected point impact.
|
||||
|
||||
### Tier 2: MEDIUM IMPACT (each worth 0.3-0.9 points)
|
||||
- Minor reframing (vocabulary swap)
|
||||
- Publication tag refinements
|
||||
- Skills group name adjustments
|
||||
- One additional keyword insertion
|
||||
|
||||
### Tier 3: COSMETIC / DIMINISHING RETURNS (each worth < 0.3 points)
|
||||
- Keyword saturation reduction
|
||||
- Minor wording polish
|
||||
- Alternative pub selection
|
||||
|
||||
### Verdict
|
||||
State clearly: "Apply Tier 1 changes. Tier 2 are optional. Tier 3 are not worth the edit."
|
||||
|
||||
---
|
||||
|
||||
## Part 5: Interview Bridge Points
|
||||
|
||||
For each major resume topic, provide the verbal bridge the candidate should use if asked in an interview. Format:
|
||||
|
||||
| Resume Topic | Target Domain Equivalent | Opening Line for Interview |
|
||||
|---|---|---|
|
||||
| [Achievement X] | [How it maps to target] | "The same methodology I used for X applies directly to Y because..." |
|
||||
|
||||
This section converts resume claims into interview talking points. Include 5-7 bridges covering highlights from all positions.
|
||||
|
||||
---
|
||||
|
||||
## Part 6: Cover Letter Critique (Context-Aware)
|
||||
|
||||
If a cover letter was generated in the same session, run all checks below. Detect institution type first: Industry / National Lab / Academic.
|
||||
|
||||
### 6A. Anti-Pattern Checklist
|
||||
- [ ] Does NOT open with "I am writing to express my interest" or similar generic opener
|
||||
- [ ] Does NOT rehash CV bullet points in prose (adds narrative context instead)
|
||||
- [ ] Names a specific PI/group/product/paper from the target institution
|
||||
- [ ] Has a clear "why THIS position at THIS institution" sentence (not generic)
|
||||
- [ ] Strongest qualification appears in paragraph 1, not buried in P3/P4
|
||||
- [ ] No defensive/apologetic language about background gaps ("Although my background is not in...")
|
||||
- [ ] Closing has active call to action, not passive "Thank you for your consideration"
|
||||
- [ ] Credentials (pubs, awards) woven into body paragraphs, not dumped in closing
|
||||
|
||||
### 6B. Tailoring Signal Checklist
|
||||
- [ ] Names specific PI/group/program (academic/lab) or product/technology (industry)
|
||||
- [ ] Uses at least 3 JD terms that supplement (not just duplicate) resume keywords
|
||||
- [ ] References institution's mission, culture, or recent work
|
||||
- [ ] Proposes specific connection between candidate's method and their need
|
||||
- [ ] Correctly identifies institutional type and adjusts tone/emphasis accordingly
|
||||
|
||||
### 6C. Context-Specific Checks
|
||||
|
||||
**Industry:**
|
||||
- [ ] Business value translation present for each achievement? ("enabling X, reducing Y")
|
||||
- [ ] "Why industry" addressed positively? (not "leaving academia")
|
||||
- [ ] Jargon minimized for HR/recruiter first reader?
|
||||
|
||||
**National Lab:**
|
||||
- [ ] Mission alignment in P1? (specific programmatic thrust, not generic "clean energy")
|
||||
- [ ] HPC/collaboration signals present?
|
||||
- [ ] Lab vocabulary used? ("thrust area," "programmatic direction," "capability development")
|
||||
|
||||
**Academic:**
|
||||
- [ ] PI named with specific research connection?
|
||||
- [ ] Future research direction included? (mandatory even for postdoc, 1-2 sentences minimum)
|
||||
- [ ] Departmental fit articulated? ("Your department's strength in X...")
|
||||
|
||||
### 6D. CL ATS Keyword Check
|
||||
- Extract 10 high-priority JD keywords
|
||||
- Check how many appear in CL (target: 5-8 that supplement resume keywords)
|
||||
- Industry/lab: keywords matter (~60% of large employers use ATS/AI on CLs). Academic: less critical.
|
||||
|
||||
### 6E. Structural Checks
|
||||
- [ ] **Consistency:** Key claims match resume bullets (no contradictions, no unsupported new claims)
|
||||
- [ ] **Complementarity:** Adds narrative context the resume cannot (motivation, "why this company," research vision)
|
||||
- [ ] **Word count:** Industry 250-300, Lab 350-450, Academic postdoc 350-450, Academic faculty 450-650
|
||||
- [ ] **Tone match:** Industry = results-driven, Lab = mission-aligned, Academic = scholarly/forward-looking
|
||||
- [ ] **Quantification:** 3-5 quantified claims (more = fact sheet, fewer = vague)
|
||||
- [ ] **Domain pivot:** If pivoting, leads with methodology in P1, not apologetic framing
|
||||
|
||||
### 6F. Package Cohesion Check
|
||||
- [ ] **Resume/CV stands alone:** If CL were deleted, does the resume/CV independently earn an interview? No critical context only in CL.
|
||||
- [ ] **CL deepens, not introduces:** Every major CL claim is traceable to a resume/CV bullet. CL adds context/significance, not new achievements.
|
||||
- [ ] **No contradictions:** Dates, metrics, claims, and framing consistent across both documents.
|
||||
- [ ] **Complement, not repeat:** CL is NOT a prose restatement of resume bullets. It adds motivation, "why this institution," research vision, methodology arc.
|
||||
- [ ] **Page budget:** Resume+CL = 3pp, CV+CL = 6-7pp. If CV CL is 2 pages, page 2 >= half filled before signature.
|
||||
|
||||
---
|
||||
|
||||
## Critique Output Template
|
||||
|
||||
```markdown
|
||||
# Critique: [Company] [Role Title] ([Job ID])
|
||||
|
||||
**Resume/CV File:** `output/[filename].tex`
|
||||
**Date:** [date]
|
||||
|
||||
---
|
||||
|
||||
## Domain-Specialist Lens (researched for this JD)
|
||||
|
||||
### Reviewer Persona
|
||||
[Constructed persona — who reads this, what they do daily, what they've seen before]
|
||||
|
||||
### Company Context
|
||||
[What they make/do, R&D culture, strategic priorities]
|
||||
|
||||
### JD Vocabulary Extraction (top 8-10 terms, ranked)
|
||||
| # | JD Term | Frequency | Meaning at THIS Company | Resume Match? |
|
||||
|---|---|---|---|---|
|
||||
| 1 | [term] | [N times] | [what they mean by it] | YES/PARTIAL/NO |
|
||||
|
||||
### Domain Vocabulary Map
|
||||
| Resume Currently Says | Should Say for This JD | Why |
|
||||
|---|---|---|
|
||||
| [term] | [replacement] | [reasoning] |
|
||||
|
||||
### Gap Ranking
|
||||
- **Fatal:** [gaps that cause rejection]
|
||||
- **Serious:** [gaps competitive candidates won't have]
|
||||
- **Cosmetic:** [nice-to-have, most candidates also miss]
|
||||
|
||||
### Methodology Transfer Test
|
||||
| Achievement | How THIS Company's Expert Sees It |
|
||||
| Rating | Evidence |
|
||||
|---|---|
|
||||
| [achievement] | "[one sentence transfer explanation]" |
|
||||
| Strong | Referral/internal sponsor plus targeted hiring-team contact |
|
||||
| Moderate | Recruiter conversation, known hiring manager or warm introduction |
|
||||
| Weak | Tailored cold application only |
|
||||
|
||||
### Competitive Landscape
|
||||
- **Obvious fit candidate:** [description]
|
||||
- **Our advantage:** [what we offer they don't]
|
||||
- **Their advantage:** [what they offer we don't]
|
||||
Do not mix channel strength into either score. A polished cold application remains a weak channel.
|
||||
|
||||
---
|
||||
## 5. Competitive Read
|
||||
|
||||
## Five-Perspective Read-Through
|
||||
Describe the obvious-fit competitor and compare direct function, cloud/tool ecosystem, domain, level/scope, and access to the team. State Dennis's real advantage and the competitor's real advantage. Do not value a bridge as highly as direct evidence.
|
||||
|
||||
### ATS Robot (keyword scan)
|
||||
[Keyword match table]
|
||||
**Match rate:** X/20 = Y%
|
||||
## 6. Reader Sequence
|
||||
|
||||
### Recruiter Glance (10 seconds)
|
||||
**Verdict:** [Forward/Maybe/Reject]
|
||||
[Reasoning]
|
||||
Use verdicts, not invented probability percentages:
|
||||
|
||||
### HR Screen (30 seconds)
|
||||
**Verdict:** [Phone screen/Borderline/Pass]
|
||||
[Reasoning]
|
||||
1. **Parser/ATS:** extraction and relevant terms.
|
||||
2. **Recruiter glance:** Forward / Borderline / Reject, with one reason.
|
||||
3. **Hiring manager:** Interview / Maybe / No, focused on functional evidence.
|
||||
4. **Technical reviewer:** credibility and likely first challenge.
|
||||
|
||||
### Hiring Manager (2 minutes)
|
||||
**Verdict:** [Interview/Maybe/No]
|
||||
**Top 3 observations:**
|
||||
1. [What they notice first]
|
||||
2. [What impresses or concerns them]
|
||||
3. [What they'd ask about]
|
||||
**Predicted first interview question:** "[question]"
|
||||
## 7. Claim Audit
|
||||
|
||||
### Technical Reviewer (10 minutes)
|
||||
**Truthfulness:** [All verified / N concerns]
|
||||
**Consistency:** [Clean / N issues]
|
||||
Audit every material summary, skills and high-value bullet claim:
|
||||
|
||||
---
|
||||
|
||||
## Eight-Dimension Scoring
|
||||
|
||||
| Dimension | Score | Weight | Weighted | Notes |
|
||||
| Claim | Canonical ID/evidence | Direct/Adjacent | Safe? | Fix |
|
||||
|---|---|---|---|---|
|
||||
| ATS Keywords | X/10 | 15% | X.XX | [1-line note] |
|
||||
| Summary | X/10 | 10% | X.XX | |
|
||||
| Skills Section | X/10 | 10% | X.XX | |
|
||||
| Bullet Quality | X/10 | 25% | X.XX | |
|
||||
| Publications | X/10 | 10% | X.XX | |
|
||||
| Narrative Coherence | X/10 | 15% | X.XX | |
|
||||
| Page Fill & Visual | X/10 | 5% | X.XX | |
|
||||
| Credibility Signals | X/10 | 10% | X.XX | |
|
||||
| **Total** | | **100%** | **XX.X** | |
|
||||
|
||||
---
|
||||
Run `validate_resume_system.py --document` first. Any validator failure is Tier 1.
|
||||
|
||||
## Interview Likelihood
|
||||
## 8. Cover Letter
|
||||
|
||||
| Reader | Probability | Key Factor |
|
||||
|--------|------------|------------|
|
||||
| ATS | X% | [factor] |
|
||||
| Recruiter (10s) | X% | [factor] |
|
||||
| HR (30s) | X% | [factor] |
|
||||
| Hiring Manager (2m) | X% | [factor] |
|
||||
| Technical Panel (10m) | X% | [factor] |
|
||||
If present, assess whether the letter was useful under the decision gate, adds information, uses current first-party hooks, and contains only canonical/resume claims. Consider whether deleting it would improve the application.
|
||||
|
||||
**Ceiling:** Current [X] → Max achievable [Y] → Hard ceiling [Z]
|
||||
If absent, assess whether the resume stands alone. Do not penalize an optional missing letter.
|
||||
|
||||
---
|
||||
## 9. Required Critique Output
|
||||
|
||||
## Actionable Improvements
|
||||
1. Fit verdict and hard-gate failures.
|
||||
2. Evidence Fit score with dimension table.
|
||||
3. Document Quality score with dimension table.
|
||||
4. Channel Strength rating.
|
||||
5. Competitive read and reader sequence.
|
||||
6. Claim audit.
|
||||
7. Tier 1 truth/fit fixes and Tier 2 presentation improvements.
|
||||
8. Cover-letter decision/critique.
|
||||
9. Mechanical verification.
|
||||
|
||||
### Tier 1 (HIGH — do these)
|
||||
1. [Change] — [+N pts]
|
||||
|
||||
### Tier 2 (MEDIUM — optional)
|
||||
1. [Change] — [+N pts]
|
||||
|
||||
### Tier 3 (COSMETIC — skip)
|
||||
1. [Change]
|
||||
|
||||
---
|
||||
|
||||
## Interview Bridge Points
|
||||
|
||||
| Resume Topic | Target Equivalent | Opening Line |
|
||||
|---|---|---|
|
||||
| [topic] | [equivalent] | "[bridge statement]" |
|
||||
|
||||
---
|
||||
|
||||
*End of critique.*
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Part 6G: AI Fingerprint Scan
|
||||
|
||||
Run the 12-item checklist from `resume_builder/support/ai_fingerprint_rules.md` Section 6. Key scans:
|
||||
- Count em-dashes (`---`) in full document — flag if >2
|
||||
- Scan all bullet endings for -ing analysis phrases (the #1 structural AI marker)
|
||||
- Search for any Tier 1 banned word (delve, tapestry, multifaceted, pivotal, etc.)
|
||||
- Check CL for generic opener and uniform sentence length
|
||||
|
||||
Any failure is a Tier 1 fix in Part 4.
|
||||
|
||||
---
|
||||
|
||||
## Part 7: Post-Generation Verification
|
||||
|
||||
Final mechanical checklist. Run AFTER all other critique parts. These are pass/fail checks, not scored dimensions.
|
||||
|
||||
### Mechanical Checks
|
||||
- [ ] All bullets within char limits (no OVER violations from char_count.py)
|
||||
- [ ] All multi-line bullets pass orphan check (last line >= 70% fill)
|
||||
- [ ] Page fill within budget (resume: <= 3 lines white space on page 2; CV: 45 rendered bullet lines)
|
||||
- [ ] No ordering errors in bullet sequencing
|
||||
|
||||
### Content Checks
|
||||
- [ ] ATS keywords present (>= 70% match rate)
|
||||
- [ ] All provenance flags correct (see CLAUDE.md for project-specific flags)
|
||||
- [ ] No forbidden terms (see CLAUDE.md for project-specific corrections)
|
||||
- [ ] No inflation (contributing-author verbs hedged, no false claims)
|
||||
- [ ] Publication entries match pub_metadata.md (titles, journals, years)
|
||||
- [ ] Cover letter claims traceable to resume/CV bullets
|
||||
|
||||
### Structural Checks
|
||||
- [ ] Company/institution name spelled correctly throughout
|
||||
- [ ] .tex file has complete preamble (will compile standalone)
|
||||
- [ ] Date format consistent (Mon YYYY -- Mon YYYY)
|
||||
- [ ] Email address is correct (see CLAUDE.md for configured email)
|
||||
- [ ] Page count correct after compile (resume=2, CV=5)
|
||||
|
||||
**If any check fails, flag it as a Tier 1 fix in Part 4.**
|
||||
|
||||
---
|
||||
|
||||
## When to Use Multi-Pass vs Single-Pass
|
||||
|
||||
**Single pass (this framework):** Use for ALL new generations going forward. The Achievement Reframing Guide ensures the first draft is already reframed, so one comprehensive critique should catch remaining issues.
|
||||
|
||||
**Multi-pass (iterative refinement):** Only needed when:
|
||||
- Score is below 80 after first critique (indicates systematic reframing failure)
|
||||
- User requests specific changes and wants re-evaluation
|
||||
- A fundamentally new approach is tried (e.g., switching role-type framing mid-stream)
|
||||
|
||||
When doing multi-pass, each subsequent critique should:
|
||||
1. State "Changes Since Pass N" at the top
|
||||
2. Only re-score dimensions that changed
|
||||
3. Track score trajectory (Pass 1 → Pass 2 → ...)
|
||||
4. Declare ceiling when score stops moving (typically after 2-3 passes with the reframing guide)
|
||||
Never issue a single overall score or call a package submit-ready solely because Document Quality is high.
|
||||
|
||||
@@ -1,315 +1,127 @@
|
||||
# Resume & CV Generation — Reference
|
||||
# Resume Generation Reference
|
||||
|
||||
> Resume/CV-specific rules. Read by `/make-resume` and `/edit-resume`.
|
||||
> Companion files: `cl_reference.md` (CL rules), `critical_rules.md` (compact re-read).
|
||||
> Shared rules (provenance, anti-fabrication, LaTeX notation): `CLAUDE.md`
|
||||
> Default audience: International Tech employers hiring in Europe.
|
||||
> Canonical authority: `resume_builder/canonical/claims.json`.
|
||||
|
||||
---
|
||||
## 1. Audience Profile Selection
|
||||
|
||||
## QUICK BUDGET CARD (read this FIRST)
|
||||
Choose before planning content:
|
||||
|
||||
```
|
||||
RESUME (2-page, resume.cls): ~20 variable bullets | Skills 13 lines (4-3-2-2-2) | 5 pubs | 5 awards
|
||||
CV (5-page, cv.cls): 19-21 variable bullets (45 rendered lines) | Skills 17 lines (4-4-3-3-3) | all pubs | 6 awards
|
||||
| Profile | Use when | Defaults |
|
||||
|---|---|---|
|
||||
| International Tech | FAANG, US-tech, international scale-up, English-language engineering role | 2 pages; no photo or demographic data; conventional headers |
|
||||
| Swiss/DACH | Traditional Swiss/German/Austrian employer or explicit local dossier request | 2 pages normally; optional photo only by user choice; references/certificates separate |
|
||||
| Employer-specific | NATO, public sector, academic or a mandated portal format | Follow the employer's explicit rules |
|
||||
|
||||
Resume bullet: max 2 rendered lines | 1L: 105-111 chars | 2L: 189-205 chars (target ~200)
|
||||
CV bullet: max 3 rendered lines | 2L: 168-182 chars | 3L: 250-268 chars (target ~175/~260)
|
||||
International Tech is the default even when the role is physically located in Europe.
|
||||
|
||||
Cover letter: Resume = 1 page (250-300 words) | CV = 1-2 pages (350-450 words)
|
||||
Full package: Resume + CL = 3 pages | CV + CL = 6-7 pages
|
||||
```
|
||||
## 2. Evidence Preflight
|
||||
|
||||
**If your bullet count doesn't match the budget above, STOP and fix before generating.**
|
||||
Before selecting or writing content:
|
||||
|
||||
---
|
||||
1. Read `resume_builder/canonical/claims.json` completely.
|
||||
2. Run `python resume_builder/helpers/validate_resume_system.py`.
|
||||
3. Read `config.md` corrections and the relevant experience files.
|
||||
4. Never use a historical output as a source or starting draft.
|
||||
5. Apply each canonical claim's scope, allowed verbs and forbidden phrases.
|
||||
6. If a metric is unverified, omit it or ask the user. Never estimate it.
|
||||
|
||||
## Section-by-Section Specs
|
||||
Accuracy remains: **Accuracy > Relevance > Impact > ATS > Brevity**.
|
||||
|
||||
### Resume (resume.cls)
|
||||
## 3. Information Hierarchy
|
||||
|
||||
1. **Summary** (bundle Section 2): 4-5 sentences, exactly 5 body lines. 500-555 rendered chars (HARD MAX 570, floor ~490). Orphan: last line >= 78 chars.
|
||||
- **Headline Tagline:** 80-95 rendered chars, exactly 1 line.
|
||||
2. **Technical Skills** (bundle Section 4 + skills_taxonomy.md): Format C — 5 groups, default 4-3-2-2-2 (13 lines). Each dash = exactly 1 rendered line. Bold penalty: 119 - (0.5 x bold_chars).
|
||||
3. **Research Experience** (experience files + achievement_reframing_guide.md): Write bullets FRESH per Experience Bullet Writing Protocol (below). Max 2 rendered lines per bullet. Run char_count.py after each position.
|
||||
- resume.cls: Args 3+4 on SAME italic line
|
||||
- **After all positions: verify total variable bullet count matches budget**
|
||||
4. **Education**: FIXED — copy from template
|
||||
5. **Selected Publications** (pub_metadata.md): 5 publications scored per JD. Copy FIXED author+journal blocks, GENERATE JD-shortened title + tags. 2 rendered lines hard limit per entry.
|
||||
6. **Honors & Awards**: FIXED — items from template
|
||||
7. **Immigration notice**: FIXED for USA JDs. Delete for non-USA JDs.
|
||||
The reader must see these items in this order:
|
||||
|
||||
### CV (cv.cls)
|
||||
1. Name, professional identity, contact/location/work authorization.
|
||||
2. Optional 2--3 line summary.
|
||||
3. Four to six compact skills lines.
|
||||
4. Professional Experience, reverse chronological.
|
||||
5. Education and relevant certifications once.
|
||||
|
||||
1. **Research Summary** (bundle Section 2): Exactly 6 body lines. 500-540 rendered chars (HARD MAX 545, floor ~490). Orphan: last line >= 62 chars. Technical identity, not narrative.
|
||||
2. **Education**: FIXED — copy verbatim from cv_template.tex
|
||||
3. **Technical Expertise** (bundle Section 4 + skills_taxonomy.md): 4-4-3-3-3 ALWAYS (17 body lines). Bold penalty: 91 - (0.25 x bold_chars).
|
||||
4. **Research Experience**: Exactly 45 rendered bullet lines across 19-21 bullets, plus sub-theme lines.
|
||||
- cv.cls: Args 3+4 on SEPARATE italic lines
|
||||
- Max 3 rendered lines per bullet. CV-2L <= 190, CV-3L <= 280 (target ~175/~260)
|
||||
- **Running total must reach exactly 45 rendered lines**
|
||||
5. **Fellowships & Honors**: FIXED — items from cv_template.tex
|
||||
6. **Publications**: FIXED — full list from cv_template.tex
|
||||
7-10. **Presentations, Mentorship, Collaborations, Computing**: All FIXED from cv_template.tex
|
||||
Every experience header uses:
|
||||
|
||||
---
|
||||
- Bold employer first.
|
||||
- Dates on the same line.
|
||||
- Formal or transparent normalized title second.
|
||||
- Location second.
|
||||
|
||||
## Character Limits (HARD STOPS — ZERO TOLERANCE)
|
||||
Do not place a JD-tailored marketing theme before the employer/title. Never turn a target phrase into a historical credential.
|
||||
|
||||
**MANDATORY: Count rendered characters for EVERY bullet BEFORE writing it.** Do not write a bullet and check afterward — pre-calculate the count. If a bullet exceeds the limit, rewrite it BEFORE moving to the next bullet. This is not a post-generation check; it is a per-bullet gate.
|
||||
Work authorization is optional in the visible header. Dennis is a German/EU
|
||||
citizen with a Swiss B residence permit and requires no visa or employer
|
||||
sponsorship. Use the shortest useful form only when it resolves uncertainty or
|
||||
the application explicitly asks; otherwise location and contact details are enough.
|
||||
|
||||
**How to count rendered characters:**
|
||||
Strip all LaTeX markup before counting: `\textbf{X}` -> X, `\textit{X}` -> X, `\ce{X}` -> X, `$\beta$` -> 1 char, `\sim` -> 1 char, `$<$` -> 1 char, `$^\dagger$` -> 1 char, `--` -> 1 char (en-dash), `\underline{X}` -> X, `\href{url}{text}` -> text only.
|
||||
Count: all remaining characters including spaces.
|
||||
## 4. Content Allocation
|
||||
|
||||
**Resume (10pt, textwidth=7.5in):**
|
||||
Use relevance and evidence, not page-filling quotas. For Dennis's normal 2-page resume:
|
||||
|
||||
| Target Lines | Rendered Char Range | HARD MAX | Orphan Threshold |
|
||||
|-------|---------------|---------|------------------|
|
||||
| 1 line | 105-111 chars | 117 | -- |
|
||||
| 2 lines | 189-205 chars | 218 | Last line >= 78 chars |
|
||||
- Swisscom: 4--5 bullets.
|
||||
- Bosch: 3--4 bullets.
|
||||
- Fraunhofer, Vizrt and Generali: 0--1 bullet each.
|
||||
- Capgemini/Bundeswehr: include only when directly relevant.
|
||||
- Typical total: 11--14 bullets. This is a guide, not a requirement.
|
||||
|
||||
**CV (11pt, textwidth=7.5in):**
|
||||
A strong shorter resume is better than a full page padded with weak evidence. White space is acceptable when hierarchy and readability are strong.
|
||||
|
||||
| Target Lines | Rendered Char Range | HARD MAX | Orphan Threshold |
|
||||
|-------|---------------|---------|------------------|
|
||||
| 1 line | 88-93 chars | 101 | -- |
|
||||
| 2 lines | 168-182 chars | 190 | Last line >= 65 chars |
|
||||
| 3 lines | 250-268 chars | 280 | Last line >= 65 chars |
|
||||
## 5. Summary
|
||||
|
||||
> **WARNING: AIM FOR THE MIDDLE OF THE TARGET RANGE — NOT THE HARD MAX.**
|
||||
> A Resume-2L bullet should target ~200 chars, not 218. A CV-2L should target ~175, not 190.
|
||||
> The hard max exists as a safety valve, not a target. Proportional fonts have variable char widths —
|
||||
> a bullet at the hard max WILL overflow if it contains wide characters (m, w, W, capitals, em-dashes).
|
||||
> Em-dash (---) counts as 1 char but renders ~2x wide. Budget 2 extra chars per em-dash in the bullet.
|
||||
The summary is optional. When used:
|
||||
|
||||
### Variant Naming
|
||||
- Keep it to 2--3 rendered lines and normally two sentences.
|
||||
- State the demonstrated professional identity and two strongest proof points.
|
||||
- Do not state the desired role as if it were prior experience.
|
||||
- Avoid credential lists and unsupported scale claims.
|
||||
|
||||
| Variant | Document | Lines | Target Range | HARD MAX | Orphan | Word Target |
|
||||
|---------|----------|-------|-------------|----------|--------|-------------|
|
||||
| Resume-1L | 1/2-page resume | 1 | 105-111 | 117 | -- | ~13 words |
|
||||
| Resume-2L | 2-page resume | 2 | 189-205 | 218 | >= 78 | ~23-25 words |
|
||||
| CV-2L | 5-page CV | 2 | 168-182 | 190 | >= 65 | ~21-22 words |
|
||||
| CV-3L | 5-page CV | 3 | 250-268 | 280 | >= 65 | ~31-32 words |
|
||||
## 6. Skills
|
||||
|
||||
> **Word targets** are approximate first-draft heuristics for prose bullets (~7.9 chars/word). After drafting, always verify with precise char count. Skills dashes: NO word proxy -- use iterative char count only (technical tool lists average ~11 chars/word).
|
||||
- Use 4--6 compact lines from `skills_taxonomy.md`.
|
||||
- List only canonical `allowed` or context-appropriate `allowed-with-context` skills.
|
||||
- Certification-only skills stay in certification context.
|
||||
- Do not use Expert/Proficient/Familiar self-ratings.
|
||||
- Do not list a technology merely because it appears in the JD.
|
||||
- Be ready with a specific example for every listed skill.
|
||||
|
||||
### Bold Width Penalty (COMPILE-VERIFIED)
|
||||
## 7. Bullet Writing
|
||||
|
||||
Bold characters render wider than normal text. Adjust effective char limits accordingly.
|
||||
Write bullets from canonical facts and experience records, not from old resume wording.
|
||||
|
||||
**Resume (10pt):** Effective limit = 119 - (0.5 x bold_char_count)
|
||||
- 0 bold: safe up to 119 chars/line
|
||||
- 2-4 bold tools (~10-25 bold chars): 107-112 effective --> use 105-111 as default
|
||||
- 5+ bold tools (~28+ bold chars): ~105 effective --> tighten to 99-105
|
||||
Each bullet should make clear:
|
||||
|
||||
**CV (11pt):** Effective limit = 91 - (0.25 x bold_char_count)
|
||||
- 0 bold: safe up to 91 chars/line (HARD MAX 93)
|
||||
- 2-3 bold tools (~10-18 bold chars): 85-88 effective --> use 83-88 as default
|
||||
- 5+ bold tools (~28+ bold chars): 83-85 effective --> tighten to 80-85
|
||||
- what Dennis did;
|
||||
- the system/domain and relevant scope;
|
||||
- why the work mattered, only when evidence supports that result.
|
||||
|
||||
Practical rule: count bold characters, subtract half (resume) or quarter (CV) from base limit.
|
||||
Natural one-, two- and three-line bullets may be mixed. There are no target character bands. Flag only bullets that are genuinely difficult to scan (normally over about 35 words or containing more than two distinct accomplishments).
|
||||
|
||||
**Per-bullet enforcement protocol:**
|
||||
1. Write the bullet text (LaTeX source)
|
||||
2. Strip all markup mentally → count rendered chars
|
||||
3. If count > HARD MAX → rewrite immediately (do NOT proceed)
|
||||
4. If multi-line and last line < orphan threshold → rewrite to fill or shorten
|
||||
5. **Aim for the middle of the range**, not the max. A bullet at 220 rendered chars (resume 2L) is risky — target ~200.
|
||||
Use metrics only when verified. Company size, customer names, generic industry volumes and market economics are context, not personal impact.
|
||||
|
||||
**Orphan rule:** For any multi-line bullet, the last rendered line must fill at least 70% of the line width. If it doesn't, rewrite to either fill the line or shorten to one fewer line.
|
||||
## 8. Titles and Seniority
|
||||
|
||||
### Char Verification Protocol (EVERY written element)
|
||||
- Preserve official titles when recognizable.
|
||||
- A transparent normalized parenthetical is allowed, e.g. `Senior Engineer, Data Analysis (Data & ML Engineering)`.
|
||||
- Do not self-promote to Principal, Architect, Manager, SRE, Forward Deployed Engineer or Consultant without verified title/function evidence.
|
||||
- Preserve promotion timing at Swisscom.
|
||||
|
||||
For each element you write from scratch or modify (summary, skills dash, tagline, any edited bullet):
|
||||
## 9. Mechanical Verification
|
||||
|
||||
1. **DRAFT** -- Use word-count target as initial guess (prose only, NOT skills dashes)
|
||||
2. **STRIP** -- Remove LaTeX markup (\textbf{}, \ce{}, $..$) to get rendered text
|
||||
3. **COUNT** -- Count rendered characters precisely. In Claude Code, use the helper: `python3 resume_builder/helpers/char_count.py "bullet text"` or verify a full .tex file: `python3 resume_builder/helpers/char_count.py -f [resume|cv] output/file.tex`
|
||||
4. **CHECK** -- Compare against target range (use tighter targets from Variant Naming table, not HARD MAX)
|
||||
5. **FIX** -- If OVER and attempts < 3: rewrite/trim, go to step 2
|
||||
6. **FLAG** -- If OVER after 3 attempts: add `% OVER LIMIT: [N] chars, target [M]` LaTeX comment, move on
|
||||
7. **PASS** -- If within range: move to next element
|
||||
After generation:
|
||||
|
||||
**RULE: Never move to the next section with a violation in the current one. Fix first, then proceed.**
|
||||
1. Run `python resume_builder/helpers/validate_resume_system.py --document <file.tex>`.
|
||||
2. Compile with the local LaTeX distribution.
|
||||
3. Verify exactly 2 pages unless the chosen profile explicitly allows otherwise.
|
||||
4. Extract text with `pdftotext` and confirm employer/title/date order.
|
||||
5. Inspect the rendered PDF: no clipping, overlap, tiny text, isolated headings or awkward page break.
|
||||
6. Check that experience begins comfortably on page 1 and certifications are not duplicated.
|
||||
|
||||
---
|
||||
Do not add content merely to reduce bottom whitespace.
|
||||
|
||||
## Page Fill Budgets
|
||||
## 10. Gap and Bridge Rules
|
||||
|
||||
**2-Page Resume (resume.cls, 10pt):**
|
||||
Classify every JD requirement as:
|
||||
|
||||
Technical Skills uses Format C (categorized dash sub-items, 5 groups).
|
||||
Any internship/fixed position is ALWAYS present (FIXED bullets, not counted in variable budget).
|
||||
- **Direct:** demonstrated with a canonical professional example.
|
||||
- **Adjacent:** a real related method/tool with an explicit transfer explanation.
|
||||
- **Gap:** no reliable evidence.
|
||||
|
||||
**Variable Bullet Budget (Format C):**
|
||||
|
||||
The exact variable bullet count depends on your skills configuration and whether a USA immigration line is present. Typical range: **20-21 variable bullets** across all research positions. Count your FIXED bullets separately — they are set in the template.
|
||||
|
||||
**Adjustments:**
|
||||
- Adding a skills line (e.g., 4-4-2-2-2 instead of 4-3-2-2-2): -1 variable bullet
|
||||
- Removing immigration line (non-USA JD): +1 variable bullet in some configurations
|
||||
|
||||
**5-Page CV (cv.cls, 11pt) — LOCKED:**
|
||||
|
||||
Total: **~209 rendered text lines** across 5 pages. 1-2 lines slack at bottom of page 5 is acceptable.
|
||||
|
||||
The exact line budget depends on your template's FIXED sections (publications, presentations, awards, etc.). Count the FIXED lines in your template, then allocate the remainder to JD-dependent content. The key constraints:
|
||||
|
||||
| Category | Status |
|
||||
|----------|--------|
|
||||
| Header, Education, Honors, Pubs, Presentations, etc. | FIXED (count from template) |
|
||||
| Research Summary | JD-DEPENDENT (typically 7 lines: 1 heading + 6 body) |
|
||||
| Technical Expertise | JD-DEPENDENT (typically 18 lines: 1 heading + 17 body) |
|
||||
| Experience bullets | JD-DEPENDENT (**target 45 rendered lines**, 19-21 bullets, 2L/3L mix) |
|
||||
| Sub-theme names | JD-DEPENDENT (varies by position count) |
|
||||
|
||||
**Experience bullet mix options (45 rendered lines):**
|
||||
- 18x2L + 3x3L = 21 bullets | 15x2L + 5x3L = 20 | 12x2L + 7x3L = 19
|
||||
- Allocate more bullets to JD-relevant positions, fewer to tangential ones
|
||||
|
||||
**Sub-theme rebalancing:** To shift bullet weight toward a more JD-relevant sub-theme: (a) drop the weakest bullet from a less-relevant sub-theme (-2L), (b) split a high-content 3L achievement into two 2L bullets (method + finding, +1L). Net = -1L saved while adding a bullet where it matters. Both split bullets must stay within char limits. Never split a 2L bullet — it becomes two 1L fragments that look thin.
|
||||
|
||||
**Position header rule:** The position title + date must fit on ONE line. If the title is too long, shorten the title so the date doesn't wrap to a second line. Wrapped dates waste a full vertical line and break visual alignment. Test by compiling — if the date wraps, trim the title.
|
||||
|
||||
**CV Page 1 rule:** The FIRST bullet of the FIRST experience position MUST be 2L (not 3L). A 3L first bullet pushes content below the page 1 fold, wasting prime real estate. Plan this during Phase 1 bullet planning — if the top-priority achievement needs 3L, make it the SECOND bullet and lead with a strong 2L bullet instead.
|
||||
|
||||
**Budget workflow:** The line budget is pre-calculated from your template. Do NOT recalculate. Use the bullet counts above directly. After generation, verify that total bullet rendered lines = 45 (count each bullet's rendered lines and sum).
|
||||
|
||||
---
|
||||
|
||||
## Experience Bullet Writing Protocol (Experience-File-First)
|
||||
|
||||
**DO NOT use pre-written bullets.** Write every bullet FRESH from experience files, reframed for the target JD.
|
||||
|
||||
**Required files:** Experience files (all) + achievement_reframing_guide.md + bundle Section 1 (Priority Matrix) + bundle Section 3 (Reframing Map)
|
||||
|
||||
**Protocol:**
|
||||
1. Determine document format -> look up bullet variant (Resume-1L/2L, CV-2L/3L) and budget
|
||||
2. Allocate bullet count per position by JD relevance
|
||||
3. For each position, consult bundle's **Priority Matrix** (Section 1) to rank achievements
|
||||
4. For each achievement, consult **Achievement Reframing Guide** for role-type-specific framing directives
|
||||
5. Write the bullet FRESH using target-domain vocabulary from bundle's **Reframing Map** (Section 3)
|
||||
6. Verify char count per-bullet BEFORE moving to the next bullet
|
||||
7. After all bullets written: run the **First-Pass Reframing Checklist** (in achievement_reframing_guide.md)
|
||||
|
||||
**Reframing during writing (NOT after):** Every bullet should use target-domain vocabulary from the start. Do not write in academic language and then "translate" -- write in target language directly using the Reframing Map. This is the single highest-ROI step: reframing alone moves scores from ~60 to ~85.
|
||||
|
||||
**Hybrid JDs (two role types):** Use primary role type's Priority Matrix for achievement ranking. Use secondary role type's Reframing Map for 1-2 bullets that bridge to the secondary domain.
|
||||
|
||||
---
|
||||
|
||||
## Position Title Format
|
||||
|
||||
**Resume -- FLIPPED format (JD theme as bold title, role as subtitle):**
|
||||
Bold line = JD-customized domain theme (the single most powerful JD customization lever).
|
||||
Italic subtitle = formal role + institution.
|
||||
|
||||
| Position | Bold Line (JD-customizable) | Subtitle |
|
||||
|----------|-----------------------------|----------|
|
||||
| Position 1 | [Theme, e.g., "First-Principles Discovery & ML-Accelerated Simulation"] | [Your Role], [Institution] |
|
||||
| Position 2 | [Theme] ([Notable Award if applicable]) | [Your Role], [Institution] |
|
||||
| Position 3 | [Theme] ([Fellowship if applicable]) | [Your Role], [Institution 1] & [Institution 2] |
|
||||
| Internship | [Theme — FIXED] | [Your Role], [Company] | FLIPPED but FIXED |
|
||||
|
||||
**CV -- CONVENTIONAL format:**
|
||||
Bold line = formal role title. Mentors on separate line. Sub-headers = story threads (underlined).
|
||||
|
||||
---
|
||||
|
||||
## Immutable Elements — NEVER Modify
|
||||
|
||||
The following elements are set in the `.cls` files and templates. **NEVER change them in generated output:**
|
||||
|
||||
- **`\vspace` values** between sections — these are calibrated. Do not add, remove, or adjust.
|
||||
- **`\geometry` settings** (margins, textwidth, textheight) — locked per template.
|
||||
- **FIXED section content** (Education, Fellowships, Publications, Presentations, Mentorship, Collaborations, Computing, Internship) — copy verbatim from template. Never rewrite, trim, or reorder.
|
||||
- **`.cls` formatting** (font sizes, section rules, item separators, skill group spacing) — never override with inline LaTeX.
|
||||
- **Header layout** (name, email, location, icons) — structure is template-locked. Only the email address and link URLs are configurable.
|
||||
|
||||
**If content spills to an extra page (orphan lines):** Fix by shortening VARIABLE content only (summary, skills dashes, experience bullets). Count rendered characters to ensure bullets actually fit their target line count (2L or 3L). A bullet that is "2L" in the budget but renders as 3L due to character overflow is the most common cause of page spill. Before declaring any output done, compile with pdflatex and verify page count matches target (resume=2, CV=5).
|
||||
|
||||
**When updating an existing .tex output (not generating from scratch):** Only modify VARIABLE content — summary text, skills group names/dashes, experience bullet text, sub-theme names. Never touch FIXED sections, vspaces, geometry, or cls overrides, even if a critique flags them as improvable. If a critique targets a FIXED section, note it for the next full regeneration instead.
|
||||
|
||||
---
|
||||
|
||||
## Post-Generation Verification
|
||||
|
||||
Run this checklist after compile gate passes, before critique. Also used as Part 7 of critique_framework.md.
|
||||
|
||||
Before presenting final output, verify:
|
||||
|
||||
- [ ] All mechanical checks pass (chars, orphans, page fill, no submitted, sequences, variants)
|
||||
- [ ] Em-dash count: max 2 per document (resume or CL). Fellowships items use `. ` not `---`.
|
||||
- [ ] No -ing analysis endings on bullets ("...advancing the field", "...contributing to Y"). Restructure to end with a concrete result or metric.
|
||||
- [ ] All content checks pass (ATS, terms, inflation, provenance, pubs, cover letter)
|
||||
- [ ] All narrative checks pass (scan test, per-position flow, cross-position arc, CV sub-headers)
|
||||
- [ ] Company/institution name spelled correctly throughout
|
||||
- [ ] .tex file has complete preamble (will compile standalone)
|
||||
- [ ] Date format consistent (Mon YYYY -- Mon YYYY)
|
||||
|
||||
---
|
||||
|
||||
## Role-Type Decision Tree
|
||||
|
||||
| If JD mentions... | Primary profile | Secondary (hybrid) |
|
||||
|-------------------|----------------|-------------------|
|
||||
| _[your domain keywords]_ | _[your role type]_ | _[secondary or --]_ |
|
||||
| _Example: national lab, DOE, postdoc_ | _National Lab_ | _--_ |
|
||||
| _Example: machine learning, neural networks_ | _ML/AI_ | _National Lab_ |
|
||||
| _Example: protein modeling, structural biology_ | _Computational Biology_ | _--_ |
|
||||
|
||||
**Hybrid resumes:** When a JD spans two role types, merge the two profiles. Primary sets priority matrix; secondary contributes supplementary bullets and keywords.
|
||||
|
||||
Customize the decision tree above with your own role types, tools, and domains in `CLAUDE.md`.
|
||||
|
||||
---
|
||||
|
||||
## Gap Assessment & Bridge Mappings
|
||||
|
||||
For each identified gap, assess:
|
||||
- **Gap description:** What the JD asks for
|
||||
- **Bridge framing (if available):** Use "methodology transferable to X" or "equivalent experience with Y" -- NEVER "experienced with X" unless directly demonstrated
|
||||
- **Bridge confidence:** HIGH / MEDIUM / LOW
|
||||
- **User decision:** Omit or bridge? (User decides per gap)
|
||||
|
||||
**Example bridge mappings** (customize for your own tools/methods):
|
||||
- Tool A → "Custom solvers (Tool B/Tool C; computational methodology transferable to Tool A)" [HIGH]
|
||||
- Framework A → "Deep learning framework expertise (Framework B; directly transferable to Framework A)" [HIGH]
|
||||
- Simulation Package A → "Molecular dynamics expertise (Package B; transferable to Package A)" [HIGH]
|
||||
- Language A → "Scientific computing (Language B, Language C; transferable to Language A)" [MEDIUM]
|
||||
|
||||
---
|
||||
|
||||
## Content Density Rules
|
||||
|
||||
| Format | Bullets | Publications | Awards | Presentations |
|
||||
|--------|---------|-------------|--------|---------------|
|
||||
| 1-page resume | ~6 | 3-5 | 2 | Omit |
|
||||
| 2-page resume | ~12+ | 5-8 | 2-3 | May omit |
|
||||
| 5-page CV | Comprehensive | All published + under review | All | All |
|
||||
| Full CV | Everything | All published + under review | All | All |
|
||||
|
||||
---
|
||||
|
||||
## Files to Upload (by format)
|
||||
|
||||
**For resumes (1-page or 2-page):**
|
||||
1. `bundle_[role_type].md` — Role-specific generation content (Sections 1-5)
|
||||
2. `achievement_reframing_guide.md` — Role-type framing directives for all achievements
|
||||
3. `skills_taxonomy.md` — Full skills inventory for Format C generation
|
||||
4. `pub_metadata.md` — Publication database with scoring tags
|
||||
5. `resume.cls` — Document class file
|
||||
6. `resume_template.tex` — Structural template (contains FIXED sections)
|
||||
7. Experience files from `resume_builder/experience/`
|
||||
|
||||
**For CVs (5-page or full):**
|
||||
1. `bundle_[role_type].md` — Role-specific generation content (Sections 1-5)
|
||||
2. `achievement_reframing_guide.md` — Role-type framing directives for all achievements
|
||||
3. `skills_taxonomy.md` — Full skills inventory for Technical Expertise generation
|
||||
4. `pub_metadata.md` — Publication database with scoring tags
|
||||
5. `cv.cls` — Document class file
|
||||
6. `cv_template.tex` — Structural template (contains FIXED sections)
|
||||
7. Experience files from `resume_builder/experience/`
|
||||
|
||||
**Role type to bundle mapping:**
|
||||
Bundles live in `resume_builder/bundles/`. Map each JD role type to its corresponding bundle file (e.g., `bundle_[role_type].md`).
|
||||
Never turn Adjacent into Direct by vocabulary substitution. A required, title-defining Gap is an application-fit problem, not a resume-writing problem.
|
||||
|
||||
@@ -1,118 +1,77 @@
|
||||
# Session File Template
|
||||
|
||||
Every JD gets a persistent session file: `output/<FolderName>/session_<name>.md`
|
||||
|
||||
## Template
|
||||
Every JD gets `output/<Folder>/session_<name>.md`.
|
||||
|
||||
```markdown
|
||||
# Session: [Company] [Role Title]
|
||||
# Session: [Company] — [Role]
|
||||
|
||||
## JD Info
|
||||
- **File:** JDs/[file].txt
|
||||
- **Role:** [title]
|
||||
- **Company:** [company] ([context])
|
||||
- **Bundle:** [role_type]
|
||||
- **Format:** [Resume/CV] ([N]-page, [cls]) + [N]-page cover letter
|
||||
- **Salary/Details:** [if available]
|
||||
## JD Integrity
|
||||
- File/source:
|
||||
- Retrieval method and date:
|
||||
- Verbatim posting: YES/NO
|
||||
- Posting status:
|
||||
|
||||
## JD Analysis
|
||||
### Requirements
|
||||
| # | Requirement | Match | Evidence |
|
||||
|---|-------------|-------|----------|
|
||||
| 1 | ... | Direct/Bridge/Gap | ... |
|
||||
## Application Decision
|
||||
- Audience profile: International Tech / Swiss-DACH / Employer-specific
|
||||
- Evidence Fit: [0-100]
|
||||
- Fit class: Core / Adjacent / Stretch
|
||||
- Hard gate: PASS / FAIL — [reason]
|
||||
- Channel Strength: Strong / Moderate / Weak
|
||||
- Channel plan: [referral/recruiter/hiring-team/cold]
|
||||
- Cohort slot: Core [n]/7, Adjacent [n]/2, Stretch [n]/1
|
||||
- Decision: PROCEED / HOLD / NO-GO
|
||||
|
||||
### ATS Keywords
|
||||
- **ML/AI:** ...
|
||||
- **Domain:** ...
|
||||
- **Methods:** ...
|
||||
- **Tools:** ...
|
||||
- **Soft Skills:** ...
|
||||
## Requirements
|
||||
| # | Requirement | Required/preferred | Direct/Adjacent/Gap/Constraint | Canonical evidence | Gate? |
|
||||
|---|---|---|---|---|---|
|
||||
|
||||
### Gap Assessment
|
||||
- **Direct:** [list]
|
||||
- **Bridge:** [list with confidence]
|
||||
- **Gap:** [list -- what we can't claim]
|
||||
|
||||
## Company Context
|
||||
- **Mission:** ...
|
||||
- **This role:** Why it exists, what success looks like
|
||||
- **Culture:** ...
|
||||
- **"Why them" angle:** ...
|
||||
## Competitive Read
|
||||
- Obvious-fit candidate:
|
||||
- Dennis's advantage:
|
||||
- Their advantage:
|
||||
- Level/scope comparison:
|
||||
|
||||
## Framing Strategy
|
||||
- **Lead narrative:** ...
|
||||
- **Reframing map:** [domain term] → [JD term]
|
||||
- **Emphasize:** ...
|
||||
- **Downplay:** ...
|
||||
- **CL hooks:** ...
|
||||
- **User directives:** ...
|
||||
- Professional identity:
|
||||
- Strongest proof points:
|
||||
- Honest adjacent bridges:
|
||||
- Explicit gaps:
|
||||
- User directives:
|
||||
|
||||
## Critique Context (captured in Phase 0, used in /critique)
|
||||
- **Reviewer persona:** Who reads this? Their title, daily work, what impresses/bores them
|
||||
- **Competitive landscape:** Who else applies? What does the "obvious fit" have that we don't?
|
||||
- **Domain vocabulary:** What terms separate insider from outsider at THIS company?
|
||||
## Resume Plan
|
||||
- Summary: omit / 2--3 lines
|
||||
- Skills: [4--6 evidence-backed lines]
|
||||
- Swisscom: [4--5 selected canonical IDs]
|
||||
- Bosch: [3--4 selected canonical IDs]
|
||||
- Earlier experience: [0--1 per role]
|
||||
- Total bullets: [normally 11--14; no page-fill quota]
|
||||
- Impact evidence still needed:
|
||||
|
||||
## Cover Letter Plan
|
||||
- **Institution type:** Industry / National Lab / Academic
|
||||
- **Paragraph count:** [N] paragraphs, [word count target]
|
||||
- **P1 hook:** [specific product/paper/program to reference]
|
||||
- **P2-P3 evidence:** [which achievements to highlight, how to frame]
|
||||
- **Domain pivot:** [methodology bridge sentence, if pivoting]
|
||||
- **Jargon level:** HR-safe / Technical / Academic
|
||||
- **"Why them" hook:** [specific connection to their work]
|
||||
|
||||
## Bullet Plan
|
||||
|
||||
Note: Any FIXED positions (e.g., internships) are not included in this plan.
|
||||
|
||||
### Position 1 ([N] bullets, [N] rendered lines)
|
||||
| # | ID | Achievement | Variant | Lines | Rationale |
|
||||
|---|-----|------------|---------|-------|-----------|
|
||||
|
||||
### Position 2 ([N] bullets, [N] rendered lines)
|
||||
[same table]
|
||||
|
||||
### Position 3 ([N] bullets, [N] rendered lines)
|
||||
[same table]
|
||||
|
||||
**Budget:** [N] variable bullets, [N] rendered lines vs target [N]
|
||||
## Cover Letter Decision
|
||||
- YES/NO:
|
||||
- Reason:
|
||||
- Information it adds beyond resume:
|
||||
- Verified hook sources:
|
||||
|
||||
## Output Files
|
||||
- Resume/CV: `output/<FolderName>/e2e_<name>_[resume|cv].tex`
|
||||
- Cover Letter: `output/<FolderName>/e2e_<name>_cover_letter.tex`
|
||||
- Critique: `output/<FolderName>/critique_<name>.md`
|
||||
- Resume:
|
||||
- Cover letter: [path or intentionally omitted]
|
||||
- Critique:
|
||||
|
||||
## Critique Summary
|
||||
- **Score:** [N]/100
|
||||
- **Key findings:** ...
|
||||
- **Tier 1 fixes:** ...
|
||||
|
||||
## Edit History
|
||||
### Edit [N] ([date]): [description]
|
||||
- Changes: ...
|
||||
- Source: [critique item # / user request / auto-detected]
|
||||
- Verification: [gates passed]
|
||||
- Evidence Fit:
|
||||
- Hard gate:
|
||||
- Document Quality:
|
||||
- Channel Strength:
|
||||
- Tier 1 fixes:
|
||||
|
||||
## Status
|
||||
- Phase 0: [PENDING | DONE]
|
||||
- Phase 1: [PENDING | DONE (N bullets confirmed)]
|
||||
- Phase 2 Resume:
|
||||
- Summary: [PENDING | DONE]
|
||||
- Skills: [PENDING | DONE]
|
||||
- Position 1 ([N] bullets): [PENDING | DONE | IN_PROGRESS]
|
||||
- Position 2 ([N] bullets): [PENDING | DONE | IN_PROGRESS]
|
||||
- Position 3 ([N] bullets): [PENDING | DONE | IN_PROGRESS]
|
||||
- Compile: [PENDING | DONE]
|
||||
- Cover Letter: [PENDING | IN_PROGRESS | DONE]
|
||||
- Critique: [PENDING | IN_PROGRESS | CURRENT (score) | STALE]
|
||||
- **Next:** [exact command to copy after /clear]
|
||||
- **Next CL:** /make-cl output/<FolderName>/session_<name>.md
|
||||
- **Next Critique:** /critique output/<FolderName>/session_<name>.md
|
||||
- Fit gate:
|
||||
- Resume:
|
||||
- Cover letter:
|
||||
- Critique:
|
||||
- Application/outcome:
|
||||
- Next:
|
||||
```
|
||||
|
||||
## Context Efficiency Notes
|
||||
|
||||
- Session 1 (resume): resume_reference.md + critical_rules.md re-read + experience files + bundle + support files + template. Peak depends on knowledge base size.
|
||||
- Session 2 (CL): cl_reference.md + significance files (if available) + session file + resume .tex + bundle S5. Much lighter context.
|
||||
- Session 3 (critique): critique_framework.md + session file + both .tex + bundle. Moderate context.
|
||||
- Folder created in Phase 0 — all files go to output/<FolderName>/ from the start.
|
||||
The session file records application state, but it is not evidence authority. Canonical claims remain authoritative.
|
||||
|
||||
@@ -1,158 +1,91 @@
|
||||
# Shared Operations — All Skills
|
||||
# Shared Operations — All Application Skills
|
||||
|
||||
> Referenced by `/make-resume`, `/make-cl`, `/critique`, and `/edit-resume`.
|
||||
> Read this file at skill startup. Skills reference specific sections by name.
|
||||
## Canonical Evidence Preflight
|
||||
|
||||
---
|
||||
Before generation, editing or critique:
|
||||
|
||||
## JD Integrity (MANDATORY — applies to every skill)
|
||||
1. Read `resume_builder/canonical/claims.json` completely.
|
||||
2. Read `config.md` and `AGENTS.md` corrections/status.
|
||||
3. Run `python resume_builder/helpers/validate_resume_system.py`.
|
||||
4. Treat canonical claims as higher authority than extractions, experience files, bundles, sessions or outputs.
|
||||
5. Never use a file under `output/` as source content for a new application. Consult `resume_builder/canonical/historical_outputs.json`.
|
||||
6. Omit or ask about anything absent, ambiguous or unverified.
|
||||
|
||||
The job description is **ground truth**. Every requirement classification, framing decision, ATS keyword, and critique is derived from it. A wrong JD silently corrupts the entire package. Therefore:
|
||||
## JD Integrity
|
||||
|
||||
1. **The JD must be the real posting, verbatim.** Use the exact text of the live posting. Never invent, "reconstruct," paraphrase, summarize, infer, or fill gaps from training knowledge or a JD "template." There is **no such thing as a reconstructed JD** — if you don't have the real text, you don't have a JD.
|
||||
2. **A URL is not a JD.** If the user gives a link, you must fetch the actual posting text from it before doing anything else.
|
||||
3. **`WebFetch` is JS-blind on careers boards** (Google, Cisco, Apple, Meta, Workday/Phenom/Greenhouse/Lever/Recruitee SPAs). It returns the static shell or a stale search cache — do NOT trust it for JD text. Use the headless-browser scraper instead (recipe below).
|
||||
4. **If you cannot obtain the real JD text, STOP and ask the user to paste it.** Do not proceed to Phase 0/bullets/critique on a guessed JD. Blocking is correct; fabricating is not.
|
||||
5. **Record provenance.** The session file `JD source` line must state how the JD was obtained: `pasted by user` / `live scrape <date> via Playwright` / `file provided`. Never label a JD as authoritative unless it is the real text.
|
||||
- Use the real posting text verbatim.
|
||||
- A URL is not a JD; retrieve the visible posting body first.
|
||||
- Do not reconstruct, infer or complete a missing posting.
|
||||
- If the real JD cannot be obtained, stop and ask the user to paste it.
|
||||
- Record source, retrieval method, retrieval date and posting status in the session.
|
||||
- Recheck that a live role still exists before investing in a package.
|
||||
|
||||
### Fetching a JS-gated JD (Playwright recipe)
|
||||
For JavaScript-heavy boards, use the in-app Browser skill or the existing Playwright environment under `job_scout`. Save the retrieved text in the output folder.
|
||||
|
||||
The job_scout repo ships a Chromium + Playwright venv: `C:\Workspace\claude-resume-kit\job_scout\.venv\Scripts\python.exe` (the bare `py`/`python` on PATH do NOT have Playwright). To pull a single posting's full text:
|
||||
## Fit Before Writing
|
||||
|
||||
```bash
|
||||
cd "C:/Workspace/claude-resume-kit/job_scout" && .venv/Scripts/python.exe -c "
|
||||
import scout, io
|
||||
b = scout._get_browser(); ctx = b.new_context(); p = ctx.new_page()
|
||||
p.goto('<JOB_URL>', timeout=45000, wait_until='domcontentloaded')
|
||||
p.wait_for_timeout(5000)
|
||||
io.open('jd_dump.txt','w',encoding='utf-8').write(p.inner_text('body'))
|
||||
scout._close_browser()"
|
||||
```
|
||||
Read `resume_builder/reference/application_strategy.md` and `critique_framework.md`. Complete the Evidence Fit and hard-gate assessment before planning bullets.
|
||||
|
||||
Then Read `job_scout/jd_dump.txt`, extract the posting body (Minimum/Preferred qualifications, About, Responsibilities), and save it verbatim to `output/<FolderName>/JD_<name>.txt`. (Windows console can't print some Unicode — always write to a UTF-8 file, then Read it; don't `print()` the body.) See `[[reference_live_posting_check]]` in memory.
|
||||
- Core: proceed.
|
||||
- Adjacent: proceed selectively and state the serious gap.
|
||||
- Stretch: confirm cohort capacity and user intent before full generation.
|
||||
- No-go: record the decision; do not generate a package unless the user explicitly overrides after seeing the gate.
|
||||
|
||||
If the scrape fails (selector/timeout/captcha), fall back to rule 4: ask the user to paste the JD.
|
||||
## Audience and Cover-Letter Decisions
|
||||
|
||||
---
|
||||
Select International Tech, Swiss/DACH or Employer-specific format before writing. International Tech is default.
|
||||
|
||||
## Three-Session Workflow
|
||||
Apply `cl_reference.md` and record `Cover Letter Decision: YES/NO`. A deliberately omitted letter is a valid complete package.
|
||||
|
||||
Standard JD pipeline uses 3 sessions for token efficiency + quality:
|
||||
## Session Files
|
||||
|
||||
Session 1: `/make-resume JDs/JD_xyz.txt`
|
||||
→ Phase 0 (research) → STOP → Phase 1 (bullets) → STOP → Phase 2 (resume) → STOP
|
||||
→ "Resume done. Copy after /clear: /make-cl output/<Folder>/session_<name>.md"
|
||||
Store each application at `output/<Folder>/session_<name>.md`; use `session_file_template.md` for new sessions.
|
||||
|
||||
Session 2: `/make-cl output/<Folder>/session_<name>.md`
|
||||
→ Load context → generate CL → compile → STOP
|
||||
→ "CL done. Copy after /clear: /critique output/<Folder>/session_<name>.md"
|
||||
Derive `<name>` from company and role using lowercase underscores. Related files use the same key:
|
||||
|
||||
Session 3: `/critique output/<Folder>/session_<name>.md`
|
||||
→ Full package critique → STOP
|
||||
→ If approved: finalization check → "Package complete in output/<Folder>/"
|
||||
- `session_<name>.md`
|
||||
- `e2e_<name>_resume.tex`
|
||||
- optional `e2e_<name>_cover_letter.tex`
|
||||
- `critique_<name>.md`
|
||||
|
||||
If edits needed after critique:
|
||||
/clear → /edit-resume output/<Folder>/e2e_<name>_cv.tex output/<Folder>/critique_<name>.md
|
||||
/clear → /critique output/<Folder>/session_<name>.md (re-critique)
|
||||
To find a session from a `.tex` path, strip `e2e_` and the document suffix, search the same folder, then `output/**/session_*<company>*.md`.
|
||||
|
||||
---
|
||||
Re-read the session at the start of each phase and resume from its Status. Do not restart completed work.
|
||||
|
||||
## Fresh Session Startup
|
||||
## Folder Creation
|
||||
|
||||
CLAUDE.md is auto-loaded. These files are NOT — read them at skill start:
|
||||
1. `CLAUDE.md` — check Active Sessions and KB Corrections Log
|
||||
2. If resuming work on an existing JD: read its session file and pick up at Status → Next
|
||||
3. If starting a new JD: proceed to Phase 0
|
||||
At the start of an approved application:
|
||||
|
||||
---
|
||||
1. Create `output/<Folder>/`.
|
||||
2. Copy the verbatim JD into it.
|
||||
3. Create the session file.
|
||||
4. Copy `resume.cls` and the selected template only when generation begins.
|
||||
|
||||
## Session File System
|
||||
Do not copy a prior application resume.
|
||||
|
||||
Every JD gets a persistent session file: `output/<FolderName>/session_<name>.md` — the single source of truth for all context.
|
||||
## Validation and Visual QA
|
||||
|
||||
**Naming:** Derive `<name>` from company/role — lowercase, underscores (e.g., `acme_engineer`, `natlab_postdoc`).
|
||||
After creating or editing a document:
|
||||
|
||||
**All output files use the same key:**
|
||||
- `output/<FolderName>/session_<name>.md` — context file
|
||||
- `output/<FolderName>/e2e_<name>_resume.tex` or `_cv.tex` — generated document
|
||||
- `output/<FolderName>/e2e_<name>_cover_letter.tex` — cover letter
|
||||
- `output/<FolderName>/critique_<name>.md` — critique
|
||||
1. Run `python resume_builder/helpers/validate_resume_system.py --document <file.tex>`.
|
||||
2. Compile with the local LaTeX distribution.
|
||||
3. Inspect the PDF at normal size.
|
||||
4. Extract text with `pdftotext` and verify heading/employer/title/date order.
|
||||
5. Check page count, clipping, overlap, page breaks and contact information.
|
||||
|
||||
**Re-read the session file at the start of EVERY phase** to restore context after compaction.
|
||||
Character counts may diagnose an unwieldy bullet, but there are no target character bands and no page-fill quota.
|
||||
|
||||
---
|
||||
## Finalization
|
||||
|
||||
## Session File Derivation (for /make-cl, /critique, and /edit-resume)
|
||||
After explicit approval:
|
||||
|
||||
From .tex path: strip `e2e_` prefix (if present) + `_resume.tex`/`_cv.tex`/`_cover_letter.tex` suffix → `<name>`.
|
||||
1. Verify the session, resume source/PDF and critique exist.
|
||||
2. Verify the cover-letter source/PDF only when the session decision is YES.
|
||||
3. Run the canonical validator again on every submitted document.
|
||||
4. Copy final PDFs to `Dennis_Thiessen_Resume.pdf` and, when applicable, `Dennis_Thiessen_Cover_Letter.pdf`.
|
||||
5. Record submission date, fit class, Evidence Fit, hard gate, channel and outcome status.
|
||||
6. Add the application to the active cohort with `cohort_tracker.py add`.
|
||||
|
||||
Example: `output/Acme/e2e_acme_engineer_resume.tex` → `acme_engineer` → look for `session_acme_engineer.md`
|
||||
## Progress and Recovery
|
||||
|
||||
**Search order:**
|
||||
1. Direct path from $ARGUMENTS
|
||||
2. Folder path: `output/<FolderName>/session_<name>.md` (derive FolderName from JD filename or session name)
|
||||
3. Flat `output/` (legacy): `output/session_<name>.md`
|
||||
4. `CLAUDE.md` Active Sessions pointer
|
||||
5. Glob: `output/**/session_*<company>*.md`
|
||||
|
||||
**If still not found:**
|
||||
- `/edit-resume`: Tell user — "No session file exists. Run `/make-resume` first, or I can create a minimal one (JD Info + Framing Strategy inferred from .tex content)."
|
||||
- `/critique`: Do 1-2 web searches to build minimal context. Note in critique: "No session file — framing context is approximate."
|
||||
- `/make-cl`: Tell user — "No session file exists. Run `/make-resume` first."
|
||||
|
||||
---
|
||||
|
||||
## Progress Commentary
|
||||
|
||||
Provide brief status updates at each major step. Minimum: what you're doing + what you found.
|
||||
|
||||
If a step takes more than ~30 seconds of silent processing, output a progress line. The user should never wonder if things are stuck.
|
||||
|
||||
Per-phase examples are in each SKILL.md.
|
||||
|
||||
---
|
||||
|
||||
## Char Count Enforcement
|
||||
|
||||
Run `python3 resume_builder/helpers/char_count.py` after each section or position you write/edit.
|
||||
|
||||
The tool is authoritative — never trust mental math for char counts. If the tool fails, fall back to manual count and flag: "char_count.py unavailable — manual count, verify after compile."
|
||||
|
||||
---
|
||||
|
||||
## Folder Creation (Phase 0 of /make-resume)
|
||||
|
||||
**Trigger:** Start of Phase 0 in `/make-resume`.
|
||||
|
||||
**Steps:**
|
||||
1. Derive folder name from JD filename: `JDs/JD_Acme.txt` → `output/Acme/`
|
||||
2. `mkdir -p output/<FolderName>/`
|
||||
3. Copy JD file into output folder: `cp JDs/<filename> output/<FolderName>/`
|
||||
4. Write session file to `output/<FolderName>/session_<name>.md`
|
||||
5. All subsequent output files (from ALL skills) go in this folder
|
||||
|
||||
## Finalization (after /critique approval)
|
||||
|
||||
**Trigger:** User approves final output at `/critique` STOP.
|
||||
|
||||
**Steps:**
|
||||
1. Verify all expected files exist in `output/<FolderName>/`:
|
||||
- `session_<name>.md`
|
||||
- `e2e_<name>_[resume|cv].tex` + `.pdf` + compile artifacts
|
||||
- `e2e_<name>_cover_letter.tex` + `.pdf` + compile artifacts
|
||||
- `critique_<name>.md`
|
||||
2. Rename final PDFs for submission (derive name from `config.md` Personal Info):
|
||||
- `cp e2e_<name>_[resume|cv].pdf <Firstname>_<Lastname>_[Resume|CV].pdf`
|
||||
- `cp e2e_<name>_cover_letter.pdf <Firstname>_<Lastname>_Cover_Letter.pdf`
|
||||
- Keep originals alongside
|
||||
3. Confirm to user: "Package complete in output/<FolderName>/ — [N] files"
|
||||
|
||||
---
|
||||
|
||||
## Session End Protocol
|
||||
|
||||
Before the session ends or user does `/clear`:
|
||||
|
||||
1. **Update session file Status** — reflects actual state (which phase completed, what's next)
|
||||
2. **Update memory pointer** in `CLAUDE.md` Active Sessions
|
||||
3. **If mid-phase:** Write a `## Resume Point` section to the session file noting exactly where you stopped and what remains
|
||||
Give short progress updates at major steps. Before ending or clearing context, update session Status and the Active Sessions pointer. If interrupted, add a Resume Point describing completed work and the exact next action.
|
||||
|
||||
Reference in New Issue
Block a user