claude-resume-kit/resume_builder/reference/resume_reference.md

Resume Generation Reference

Default audience: International Tech employers hiring in Europe. Canonical authority: resume_builder/canonical/claims.json.

1. Audience Profile Selection

Choose before planning content:

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

International Tech is the default even when the role is physically located in Europe.

2. Evidence Preflight

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.

Accuracy remains: Accuracy > Relevance > Impact > ATS > Brevity.

3. Information Hierarchy

The reader must see these items in this order:

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.

Every experience header uses:

• Bold employer first.
• Dates on the same line.
• Formal or transparent normalized title second.
• Location second.

Do not place a JD-tailored marketing theme before the employer/title. Never turn a target phrase into a historical credential.

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.

4. Content Allocation

Use relevance and evidence, not page-filling quotas. For Dennis's normal 2-page resume:

• Swisscom: 4--5 bullets.
• Bosch: 3--4 bullets.
• Fraunhofer, Vizrt and Generali: 0--1 bullet each.
• Capgemini: NEVER include. Standing user preference (config.md); the resulting Nov 2014 - May 2015 gap is intentional and must not be "fixed" or explained away.
• Bundeswehr: include only when directly relevant (defence, public-sector and security employers).
• Typical total: 11--14 bullets. This is a guide, not a requirement.

A strong shorter resume is better than a full page padded with weak evidence. White space is acceptable when hierarchy and readability are strong.

5. Summary

The summary is optional. When used:

• 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.

6. Skills

• 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.

7. Bullet Writing

Write bullets from canonical facts and experience records, not from old resume wording.

Each bullet should make clear:

• what Dennis did;
• the system/domain and relevant scope;
• why the work mattered, only when evidence supports that result.

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).

Use metrics only when verified. Company size, customer names, generic industry volumes and market economics are context, not personal impact.

7a. Cadence variety (anti-monotony)

Individually honest bullets can still read as machine-written when they all share one rhythm. Measured across the 18 packages in output/ (368 bullets): 45 % used the same "X, Y and Z" triple, and the SBB package reached 85 % — 11 of 13 bullets, every Swisscom and Bosch line. Nothing in it was false; it simply had one cadence.

This is a style problem, never a truth problem. Never trade accuracy, scope discipline or a hedged verb to fix cadence — an accurate monotonous bullet beats a varied inaccurate one. Fix it by reshaping sentences, not by changing what is claimed.

Per document, aim for:

• At most about half the bullets carrying a three-part list. The triple is normal resume grammar and humans use it too; the tell is using little else.
• At least two or three bullets in a different shape — a short declarative with a single object; a bullet with one object rather than three; a bullet whose scope clause comes first.
• No two consecutive bullets opening with the same verb (the SBB resume had "Build and model…" directly followed by "Build and operate…").
• Visible length variation inside each position, not just across the document. Five bullets at 25–30 words read as generated even when the document's overall range looks fine.

validate_resume_system.py --document <file.tex> measures all three and reports them as WARN, never ERROR — cadence can never fail a document. The length threshold is calibrated on the 50 multi-bullet positions in output/, whose spreads are bimodal (1–9 words, then 15–17): it flags a spread of 4 words or less, the tight tail, not the median.

Diagnostic only — like character counts, these are checks, never targets, and no bullet should be padded or trimmed to hit them.

8. Titles and Seniority

• 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.

9. Mechanical Verification

After generation:

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.
7. Act on any cadence WARN from step 1 (§7a). These never fail the document; reshape the offending sentences, never the claims behind them.

Do not add content merely to reduce bottom whitespace.

10. Gap and Bridge Rules

Classify every JD requirement as:

• Direct: demonstrated with a canonical professional example.
• Adjacent: a real related method/tool with an explicit transfer explanation.
• Gap: no reliable evidence.

Never turn Adjacent into Direct by vocabulary substitution. A required, title-defining Gap is an application-fit problem, not a resume-writing problem.