emrekgn/tailored-resume-skill

Maßgeschneiderter Lebenslauf (Tailored Resume)

Aus einem Basis-Lebenslauf plus einer Stellenausschreibung einen maßgeschneiderten Lebenslauf (.md + .pdf) erstellen. Anschließend berichten, wie gut er die Anforderungen der Ausschreibung abdeckt und was fehlt.

Genauigkeit ist der Kern dieser Fähigkeit. Ein maßgeschneiderter Lebenslauf, der Erfahrungen überhöht darstellt, kann den Nutzer ein Jobangebot oder sogar die Stelle nach der Zusage kosten. Daher führt diese Fähigkeit ein Fakten-Ledger mit verifizierten Tatsachen, erfindet niemals etwas und behandelt Lücken als etwas, das berichtet, nicht versteckt werden muss.

Der Arbeitsbereich für Lebensläufe

Im Benutzerordner für Lebensläufe arbeiten, normalerweise dem aktuellen Verzeichnis. Er enthält:

Datei	Zweck
base-resume.md	Der Master-Lebenslauf im Markdown-Format dieser Fähigkeit. Jede maßgeschneiderte Variante beginnt von hier.
facts.md	Das Ledger: Korrekturen, bestätigte, aber im Basis-Lebenslauf fehlende Tatsachen, Dinge, die nie behauptet werden sollen, und Präferenzen (Seitenzahl, Papierformat, Kontaktzeile).
<slug>-resume-<unternehmen>.md / .pdf	Eine maßgeschneiderte Variante pro Bewerbung. <slug> ist der Name der Person in Kebab-Schreibweise.
alles andere	Unterstützende Quellen, die der Nutzer bereitstellt: ein LinkedIn-Export, alte PDFs, ein GitHub-Profil, Projekt-READMEs.

Wenn der Ordner einen Lebenslauf unter einem anderen Namen enthält, verwenden Sie diesen und notieren Sie seinen Namen in facts.md, anstatt die Dateien des Nutzers umzubenennen.

Erster Durchlauf: Bootstrap

Wenn noch kein Basis-Lebenslauf vorhanden ist:

1. Fragen Sie nach dem vorhandenen Lebenslauf des Nutzers (PDF, DOCX, Text oder ein LinkedIn-Export). Extrahieren Sie bei einem PDF den Text mit pdftotext -layout.
2. Konvertieren Sie ihn in das Format in references/format.md, wobei Sie die Wortwahl beibehalten. In diesem Stadium noch nicht anpassen.
3. Erstellen Sie facts.md aus assets/facts-template.md, füllen Sie die Kontaktzeile und alle vom Nutzer erwähnten Präferenzen aus.
4. Zeigen Sie dem Nutzer den Basis-Lebenslauf und bitten Sie ihn, ihn zu überprüfen, bevor Sie etwas anpassen. Fehler hier setzen sich in jede Variante fort.

Arbeitsablauf für eine neue Stellenausschreibung

1. Quellen lesen. Lesen Sie base-resume.md, facts.md und alle unterstützenden Quellen. facts.md hat Vorrang vor dem Basis-Lebenslauf, wo immer sie abweichen.

2. Ausschreibung analysieren. Sortieren Sie deren Anforderungen in drei Stufen:

   • P1: Muss-Kriterien (Ausschlusskriterien)
   • P2: Stark gewünscht
   • P3: Nice-to-have

   Notieren Sie die Fachbegriffe der Ausschreibung und wiederholte Schlüsselwörter. ATS-Keyword-Matching ist wörtlich, daher haben die Begriffe der Ausschreibung Vorrang vor Synonymen, wenn beides zutrifft.

3. Nachweise zuordnen. Finden Sie für jede Anforderung echte Belege in den Quellen. Markieren Sie diese als stark, teilweise oder als Lücke.

4. Variante schreiben unter <slug>-resume-<unternehmen>.md. Beginnen Sie mit einer Kopie des Basis-Lebenslaufs und:

   • Zusammenfassung: Umschreiben, sodass sie mit dem beginnt, was für diese Rolle am wichtigsten ist. Personalverantwortliche lesen dies zuerst.
   • Skills: Reihenfolge und Gruppen so ändern, dass die relevantesten zuerst kommen, und Zeilenbezeichnungen an die Begriffe der Ausschreibung anpassen (z. B. "Message Queues & Streaming", "Platform & Delivery"). Schreiben Sie den vollständigen Begriff neben wichtige Akronyme, die die Ausschreibung verwendet, einmal jeweils, z. B. "Terraform (Infrastructure as Code, IaC)", "Kubernetes (K8s)". Ein ATS sucht möglicherweise nach beiden Formen.
   • Bullet Points: Innerhalb jeder Rolle neu anordnen und umformulieren, sodass die relevantesten zuerst kommen, und solche kürzen, die für diese Ausschreibung unwichtig sind. Ältere Rollen können auf 1–3 Bullet Points schrumpfen.
   • Fakten-Ledger: Jeden Eintrag in facts.md anwenden.
   • Open Source / Projekte: Bei technischen Rollen mit öffentlicher Arbeit den GitHub/Portfolio-Link in die Kontaktzeile und einen kurzen Abschnitt ## Open Source oder ## Projekte einfügen. Die 2–3 relevantesten Elemente auswählen.
   • Karrierewechsel: Wenn die Rolle einen Richtungswechsel darstellt (z. B. von Ingenieur zu Developer Relations), das normale chronologische Layout beibehalten. Einen kurzen Abschnitt mit Highlights zwischen der Zusammenfassung und den Skills einfügen, der echte, übertragbare Belege sammelt. Keinen "funktionalen" Lebenslauf verwenden; Personalverantwortliche und ATS-Software misstrauen ihm tendenziell.

5. Erstellen und überprüfen (siehe unten). Beheben Sie Layout-Probleme, bevor Sie berichten.

6. Bericht im untenstehenden Format.

Ehrlichkeitsregeln

Diese Regeln existieren, weil der Drang, Dinge überhöht darzustellen, ständig und subtil ist. Jede schützt vor einem Fehler, der in der Praxis tatsächlich passiert ist.

• Niemals erfinden von Fähigkeiten, Tools, Metriken, Skalengrößen, Titeln oder Verantwortlichkeiten. Wenn die Ausschreibung etwas verlangt, was die Quellen nicht zeigen, lassen Sie es weg und listen Sie es als Lücke auf. Der Nutzer hat die Erfahrung möglicherweise. Eine Nachfrage kostet eine Nachricht; eine erfundene Behauptung kann in einem Vorstellungsgespräch auffliegen.
• Umformulieren ist in Ordnung; Verstärken ist nicht erlaubt. Die Fachbegriffe der Ausschreibung zu übernehmen ist in Ordnung. Die Stärke einer Behauptung zu erhöhen ist nicht erlaubt, zum Beispiel:
  • "hat mitgearbeitet an" wird zu "hat geleitet"
  • "in Minuten", "im großen Maßstab" oder "unter Produktionslast" ohne Quelle hinzufügen
  • zwei separate Fakten zu einer größeren Behauptung verschmelzen. Zum Beispiel darf "hat das Team bei Open-Source- und Enterprise-Projekten geleitet; die Enterprise-Projekte hatten 200.000 Nutzer" nicht zu "hat ein Open-Source-Team geleitet, dessen Projekte 200.000 Nutzer erreichten" werden.
• Kein Eigenlob, das die Quellen nicht enthalten, z. B. "erster Ansprechpartner für schwierige Probleme" oder "kann alles jedem erklären". Stattdessen mit Belegen zeigen.
• Sorgfältig zuordnen. Halten Sie eine Tatsache an die Rolle gebunden, aus der sie stammt. Eine vom Nutzer ohne Rolle bestätigte Tatsache ("Ich habe Terraform verwendet") gehört in die Zusammenfassung oder die Skills, nicht unter eine vermutete Position.
• Metriken wörtlich übernehmen. Prozentsätze, Anzahlen und Zeiträume bleiben exakt so, wie sie in den Quellen angegeben sind.
• Echte Berufsbezeichnungen beibehalten. Eine Einordnung in der Zusammenfassung ("Backend-Ingenieur auf Staff-Level") ist in Ordnung.
• Jeden neuen oder geänderten Bullet Point vor dem Erstellen gegen eine Quelle prüfen. Wenn etwas eine vernünftige Schlussfolgerung, aber nicht explizit genannt ist, entweder weglassen oder im Bericht markieren.

Wenn der Nutzer etwas korrigiert oder bestätigt

Sofort zu facts.md hinzufügen, mit Datum und, falls bekannt, der zugehörigen Rolle. Anschließend jede andere Variante auf denselben Fehler durchsuchen und auch dort korrigieren. Überspringen Sie alle, die der Nutzer als bereits versendet markiert hat, und listen Sie diese in facts.md auf, damit zukünftige Durchläufe sie in Ruhe lassen. Erstellen Sie die geänderten PDFs neu und teilen Sie dem Nutzer mit, welche Dateien geändert wurden.

Erstellen und überprüfen

python3 "${CLAUDE_SKILL_DIR}/scripts/build_resume.py" <slug>-resume-<unternehmen>.md --check

• Was es tut: Schreibt das PDF neben die Markdown-Datei und gibt dann die Seitenzahl und den Text aus, den ein ATS-Parser extrahieren würde. Übergeben Sie --paper a4, wenn facts.md angibt, dass der Nutzer A4 bevorzugt.
• Wenn ${CLAUDE_SKILL_DIR} nicht gesetzt ist: Verwenden Sie den absoluten Pfad des Skill-Verzeichnisses.
• Wenn kein Browser gefunden wird: Bitten Sie den Nutzer, Chrome oder Chromium zu installieren oder CHROME_BIN auf dessen Pfad zu setzen.

Dann drei Dinge überprüfen:

1. Seitenzahl. Die Präferenz des Nutzers aus facts.md verwenden. Ansonsten bei ca. 10 Jahren Erfahrung auf 1 Seite abzielen, darüber auf 2 Seiten.
2. Visuelles Layout. Wenn pdftoppm verfügbar ist, führen Sie pdftoppm -r 60 -png <pdf> <tmpdir>/preview aus und betrachten Sie jedes Seitenbild. Achten Sie auf ungünstige Seitenumbrüche und Zeilen, die schlecht umbrechen.
3. Extrahierter Text. Jede Skill-Zeile sollte als eine Zeile mit ihrer Bezeichnung gelesen werden, und jede Rollenüberschrift sollte eine Zeile sein, die ihre Daten enthält. Wenn nicht, ist das Markdown wahrscheinlich vom Format abgewichen.

Wenn das Seitenziel überschritten wird, in dieser Reihenfolge kürzen

1. unwichtigste Bullet Points in älteren Rollen
2. lange Skill-Zeilen (Zeilen zusammenführen, jede auf eine Zeile beschränken)
3. Zertifikate (auf eine Zeile zusammenführen, irrelevante weglassen)
4. Länge der Zusammenfassung

Schriftgrößen oder Ränder nicht verkleinern, um Platz zu schaffen. Dichte Seiten lesen sich für Menschen schlechter und bringen bei einem ATS keinen Vorteil.

Layout-Regeln

Das Layout des Builders ist für die ATS-Parsing ausgelegt, daher nicht ändern. Tabellen, mehrere Spalten und rechtsbündige Daten (flex oder float) sehen gut aus, aber die Extraktion ist schlecht: Bezeichnungen trennen sich von Werten, und Daten trennen sich von Jobtiteln. Der Builder hält auch Silbentrennung an Zeilenumbrüchen aufrecht, da ein Trennstrich bei der Extraktion verloren geht ("High-Throughput" wird zu "Highthroughput").

Berichtsformat

Nach dem Erstellen mitteilen:

1. Dateien: Die Pfade der .md und .pdf.

2. Abdeckungstabelle:

   Stufe	Anforderung	Nachweis im Lebenslauf (oder Lücke)

3. Schwerpunkte: Einige Zeilen dazu, worauf Sie den Schwerpunkt gelegt und was Sie gekürzt haben.

4. Fragen: Fragen Sie nach Erfahrungen, die P1/P2-Lücken schließen könnten, oder nach Behauptungen, die Sie abgeleitet haben und bestätigt werden müssen. Seien Sie spezifisch: "Haben Sie direkt mit X gearbeitet oder nur über Y?"

5. Optionale Angebote: Erwähnen Sie, ohne sie ungefragt zu schreiben, dass Sie Anschreiben-Einleitungen, Antworten auf Bewerbungsfragen oder Interview-Argumente entwerfen können.

Wenn die Rolle eine große Herausforderung darstellt (mehrere P1-Lücken), sagen Sie dies deutlich und schlagen Sie vor, was am meisten helfen würde. Zum Beispiel: ein Portfolio-Projekt, ein Open-Source-Beitrag zu den Repos des Unternehmens oder ein Anschreiben, das den Karrierewechsel erklärt.

Bewerbungsfragen und Anschreiben

Verwenden Sie dasselbe Fakten-Ledger und dieselben Ehrlichkeitsregeln. Antworten Sie in der Stimme des Nutzers (erste Person), prägnant, und nennen Sie alle Details, die Sie abgeleitet haben, damit der Nutzer sie korrigieren kann. Schreiben Sie Anschreiben als <slug>-cover-letter-<unternehmen>.md. build_resume.py ist für Lebensläufe ausgelegt. Für ein PDF-Anschreiben schreiben Sie einfaches HTML und drucken es mit demselben Headless-Browser-Befehl, den das Skript verwendet.

Referenzdateien

• references/format.md: Das exakte Markdown-Format, das der Builder parst, mit einem vollständigen Beispiel. Lesen Sie es, bevor Sie einen Lebenslauf schreiben oder konvertieren.
• assets/facts-template.md: Ausgangspunkt für eine neue facts.md.
• assets/example-resume.md: Ein fiktiver Beispiel-Lebenslauf zum Testen des Builders.