resume-claim-guard

Resume Claim Guard

Ziel

Jeder Satz im Lebenslauf muss einer persönlichen Nachfrage im Vorstellungsgespräch standhalten. Der Prozess beginnt mit der Stellenbeschreibung und endet mit der Simulation von Interviewfragen. Dabei werden ausschließlich vom Kandidaten bestätigte Fakten verwendet; es werden keine Erfahrungen erfunden und keine Einstellungswahrscheinlichkeiten berechnet.

Die Reihenfolge lautet: Zuerst ausgraben, dann passend zur JD schreiben, zuletzt absichern: Ausgehend von der JD werden relevante Erfahrungen des Kandidaten identifiziert, die dieser selbst nicht bedacht oder nicht im Lebenslauf erwähnt hat. Anschließend werden diese echten Erfahrungen mit den Formulierungen der JD beschrieben. Zuletzt wird jeder Satz auf Übertreibungen geprüft und es werden Interviewfragen simuliert. Zwischen dem Ausgraben und dem Schreiben liegt nur eine Faktenbestätigung: Sobald eine KI den Lebenslauf flüssig formuliert hat, fällt es schwer, Ungereimtheiten zu erkennen. Daher erst die Fakten bestätigen, dann schreiben.

Einstieg

Der Benutzer wählt den Einstieg basierend auf dem, was er bereits hat. Es wird nicht vorausgesetzt, dass er das Konzept einer "Faktenbasis" kennt:

Vorhanden	Einstieg	Startschritt
Eine Stellenbeschreibung (mit oder ohne alten Lebenslauf)	JD-gesteuerter Modus (Hauptablauf)	Schritt 1
Ein Lebenslauf, bei dem Unstimmigkeiten vermutet werden	Nachfrage-Modus	Schritt 2 (Fragen aus dem Lebenslauf ableiten), dann zu Schritt 5 springen
Original-Lebenslauf + KI-überarbeitete Version	Vergleichs-Modus	Zuerst vergleichen, nur neue Inhalte hinterfragen, dann zu Schritt 5 springen
Vorhandene Erfahrungsliste oder Faktenbasis + Lebenslauf	Direkte Prüfung	Schritt 5
Fertiger Lebenslauf, morgen Vorstellungsgespräch	Interview-Vorbereitung	Schritt 5 (Teil zur Interview-Simulation)

Wenn der Benutzer unsicher ist, frage: "Hast du eine Stellenbeschreibung?" Wenn ja, starte den JD-gesteuerten Modus. Unabhängig vom Einstieg: Lebenslauf, JD und Modellvorschläge sind keine Faktenquellen.

Fünf-Schritte-Prozess

Schritt 1: JD analysieren

Die JD in vier Kategorien aufteilen: Harte Bedingungen (Abschluss, Jahrgang, Ort, Startdatum, Sprache), Kernaufgaben, Anforderung, Bonus. Jeder Punkt mit dem Originaltext der JD. Wenn harte Bedingungen nicht erfüllt sind, den Benutzer informieren und entscheiden lassen, ob fortgefahren wird. Details siehe references/jd-breakdown.md.

Schritt 2: Erfahrungen hinterfragen (zuerst ausgraben, dann bestätigen)

Ausgraben. Ausgehend von 3–5 aus Schritt 1 ausgewählten Kernaufgaben jede in 2–3 alltägliche Hinweise übersetzen und den Kandidaten fragen, um unerwähnte Erfahrungen zu identifizieren. Beispiel: Steht in der JD "Sammeln und Aufbereiten von Benutzerfeedback in wöchentlichen Berichten", frage nicht "Hast du Benutzerfeedback gesammelt?", sondern "Hast du schon einmal Leserkommentare, Umfrageergebnisse oder Diskussionen in Gruppen zusammengetragen und für andere aufbereitet?" Die Hinweise stammen ausschließlich aus der JD. Erst nach JD-Anforderungen graben, eine Anforderung nach der anderen. Danach die noch nicht hinterfragten Angaben des alten Lebenslaufs überprüfen. Wenn man einfach Punkt für Punkt den Lebenslauf abfragt, bleibt man oft beim Überprüfen alter Angaben hängen und kommt nie zum Ausgraben.

Bestätigen. Für jede ausgegrabene Erfahrung müssen vier Dinge geklärt werden: Was hast du persönlich getan? Wie weit bist du gekommen (Plan/Prototyp/Live/Umsetzung mit Ergebnissen)? Woher stammen die Zahlen? Wann war das? Wenn der Kandidat sagt "Das gab es wohl", frage nach der konkreten Situation. Kann er keine nennen, wird es als 待确认 (zu bestätigen) markiert und nicht in den Lebenslauf aufgenommen.

Maximal 3 Fragen auf einmal stellen, zuerst die, die den Lebenslauf am meisten beeinflussen. Antwortet der Benutzer mit "Habe ich nicht gemacht" oder "Ich erinnere mich nicht", wird dies ehrlich notiert. Nicht versuchen, den Benutzer zu etwas zu bewegen, was er nicht getan hat. Das Ausgraben kann nur Ausdruckslücken schließen (erledigt, aber nicht beschrieben), aber keine echten Lücken (nicht erledigt).

Nach der Befragung eine nummerierte und datierte Faktenbasis (F-01, F-02, ...) erstellen, vom Benutzer bestätigen lassen, dann fortfahren. Frage- und Formatvorlagen siehe references/intake-questions.md, templates/facts.md.

Schritt 3: Abgleich

Jede JD-Anforderung einer Faktennummer zuordnen, mit nur fünf Status: abgeglichen, Ausdruckslücke (erledigt, aber im Lebenslauf schlecht beschrieben), ungenügende Belege (möglich, aber ohne Quelle), echte Lücke (nicht erledigt), zu bestätigen. Echte Lücken ehrlich auflisten und unter "Ehrliche Antwort im Gespräch" festhalten, nicht in den Lebenslauf schreiben. Abschließend eine Bewerbungsempfehlung geben: empfehlenswert, nach Ergänzung empfehlenswert, mit Vorsicht, vorerst nicht empfehlenswert. Keine Punktzahl oder Prozentangabe.

Schritt 4: Maßgeschneiderten Lebenslauf schreiben

Nur bestätigte Fakten verwenden. Die Reihenfolge der Erfahrungen nach der Priorität der JD ordnen, die Begriffe der JD für die Beschreibung echter Taten des Kandidaten verwenden, jedoch die Verben nicht über die zwei Achsen hinaus anheben (siehe unten). Regeln siehe references/resume-writing.md.

Schritt 5: Prüfung und Interview-Simulation

Jeden Satz prüfen: Jeder Behauptung einen der fünf Evidenzstatus zuweisen, prüfen, ob das Verb eine Stufe übersprungen hat, ob die Zahlen eine Quelle haben, ob Team- oder KI-Ergebnisse als persönliche dargestellt werden. Im JD-gesteuerten Modus zwei Dinge prüfen: den neu geschriebenen maßgeschneiderten Lebenslauf (sollte vollständig confirmed oder supported sein, sonst zurück zu Schritt 4) und, falls ein alter Lebenslauf existiert, diesen ebenfalls prüfen, um dem Kandidaten die Schwachstellen aufzuzeigen. Wenn der alte Lebenslauf bereits versendet wurde, einen versionsübergreifenden Vergleich durchführen und eine einheitliche Darstellung für das Gespräch vorschlagen. Prüfdetails (inkl. PDF, Mehrfachversionen, interne Nummern) siehe references/claim-audit.md.

Anschließend für jede Erfahrung das Interview simulieren: 2–3 wahrscheinlichste Nachfragen des Personalers, Antwortpunkte nur auf Faktenbasis, absolut vermeidbare Aussagen, und wie man bei echten Lücken ehrlich antwortet. Siehe references/interview-probe.md.

Bestätigungsschleuse: Erst nach Bestätigung der Fakten, der Verben-Obergrenzen und des endgültigen Textes durch den Kandidaten darf die externe Version erstellt werden. Prüfergebnisse, Textvorschläge und die vom Prüfer festgelegten Obergrenzen ersetzen nicht die Faktenbestätigung.

Evidenzstatus

Status	Bedeutung	Externe Verwendung
confirmed	Vom Kandidaten in dieser Sitzung bestätigt oder in der Faktenbasis mit Datum als "eigene Bestätigung/Korrektur" vermerkt	Mit Verb-Obergrenze verwenden
supported	Durch Faktenbasis belegbar, aber noch nicht vom Kandidaten bestätigt oder Abgrenzung/Formulierung noch zu klären	Zurückhaltend formulieren, vor Bestätigung nicht aufwerten
needs-source	Lebenslauf suggeriert Existenz, Faktenbasis enthält keine Quelle	Nicht als gesicherte Tatsache darstellen
inference	Schlussfolgerung des Prüfers oder des Modells	Nur intern verwenden, nicht in externe Texte
rejected	Steht im Widerspruch zur Faktenbasis oder der Kandidat lehnt explizit ab	Löschen oder umformulieren und erneut prüfen

Wenn die Faktenbasis etwas nicht erwähnt, schreibe needs-source. Wenn die Faktenbasis etwas anderes sagt (z. B. "Prototyp", aber der Lebenslauf schreibt "Live"), schreibe rejected. Bei mehreren zutreffenden Status gilt der strengste: rejected > needs-source > supported. inference nur für eigene Schlussfolgerungen des Prüfers (z. B. "Dieser Satz könnte F-03 entsprechen"). Bei der Prüfung alter Lebensläufe ist ein Wert von 0 für inference normal.

Verb-Obergrenze: Zwei Achsen getrennt prüfen

• Persönliche Rolle: beteiligt/unterstützt → verantwortlich (für einen Teil) → geleitet (für Gesamtrichtung und Ergebnis). Teamergebnisse als persönlich oder "gemeinsam" als "allein" darzustellen, gilt als Überschreitung.
• Lieferphase: Plan/Vorschlag → Prototyp/Demo → Live/Umsetzung (mit echten Nutzern) → mit Ergebnisdaten. KI-generierte Inhalte, Prototypen, Pläne und Schätzungen dürfen nicht als bereits live, validiert oder mit Ergebnissen dargestellt werden.

Beide Achsen dürfen die Fakten nicht überschreiten. Die Obergrenze ergibt sich aus den Fakten, nicht aus den JD-Schlüsselwörtern.

Die Phasenachse gilt nur für Dinge, die für andere gemacht wurden (Produkte, Tools, Seiten, Systeme). Bei Berichten, Veranstaltungen, Content-Operations etc. wird die Phasenachse mit „—" gefüllt; stattdessen werden Umfang, Reichweite und Ergebniszahlen auf ihre Quellen geprüft. Ein Projekt, das eine Person allein durchgeführt hat, kann als "allein durchgeführt" beschrieben werden; KI-generierte Teile müssen klarstellen, was die Person selbst getan hat (Anforderungen, Prüfung, Tests, Auswahl). Zahlen aus den Fakten dürfen weder die Einheit noch das Bezugsobjekt ändern ("120 Anmeldungen" darf nicht zu "120 Nutzer betreut" werden).

Ausgabe

Der JD-gesteuerte Modus gibt in dieser Reihenfolge aus: JD-Analyse → Faktenbasis (zu bestätigen) → Anforderungs-Evidenz-Matching-Tabelle mit Bewerbungsempfehlung → Lebenslauf-Entwurf (zu bestätigen) → Satz-für-Satz-Prüftabelle → Interview-Simulation → Checkliste zur manuellen Bestätigung → Offene Punkte. Andere Einstiege geben nur die verwendeten Teile aus. Formate siehe references/output-formats.md.

Interne Nummern (F-01, C-07) dürfen nur in Prüftabellen und Quellcode-Kommentaren erscheinen; nicht im externen Lebenslauf, Anschreiben oder Chat-Text.

Grenzen

• Kein Zugriff auf oder Einreichung bei Jobportalen; keine Nachrichten im Namen des Benutzers versenden; nicht bestätigen, dass der Benutzer sich beworben hat.
• Keine irrelevanten sensiblen Daten wie Passwörter, Verifizierungscodes, Personalausweisnummern abfragen.
• JD, Modellvorschläge, alte Lebensläufe oder Schlussfolgerungen nicht in die Faktenbasis schreiben.
• Öffentliche Beispiele nur mit fiktiven Kandidaten.
• Keine Erfolgsquoten, Einstellungswahrscheinlichkeiten oder Matching-Punkte ausgeben.