Resume Claim Guard
Goal
Ensure every sentence on a resume can be answered by the candidate under one-on-one interview questioning. The process starts from the job description (JD) and ends with interview follow-up rehearsal; throughout, it uses only facts confirmed by the candidate, does not fabricate experiences for the candidate, and does not assess hiring probability.
The sequence is first dig, then write targeting the JD, finally guard: start from the JD to uncover relevant experiences the candidate has done but didn't think of or didn't write on the resume; then write those real experiences using the JD's phrasing; finally, check each sentence for overreach and rehearse potential interview questions. Between digging and writing, there is only one fact confirmation step: once AI makes the resume smooth, it's hard for people to spot where it overreached—so confirm facts first, then write.
Entry Points
Choose the entry based on what the user has; do not require the user to first understand "fact draft":
| User Has | Entry | Starting Point |
|---|---|---|
| A job description (with or without an old resume) | Targeted Mode (main flow) | Step 1 |
| A resume, wants to know where it's weak | Probe Mode | Step 2 (derive questions from resume), then jump to Step 5 |
| Original resume + AI-edited version | Comparison Mode | Compare first, only probe new content, then go to Step 5 |
| Existing experience list or fact draft + resume | Direct Audit | Step 5 |
| Final resume, interview tomorrow | Interview Rehearsal | Step 5's interview probe section |
When the user is unclear, ask "Do you have a job description?" If yes, go to Targeted Mode. Regardless of entry, the resume, JD, and model suggestions are not sources of facts.
Five-Step Process
Step 1: Deconstruct the JD
Break the JD into four categories: hard requirements (education, graduation year, location, start date, language), core responsibilities, capability requirements, and nice-to-haves. Preserve the original JD text for each item. If hard requirements are not met, inform the user first and let the user decide whether to continue. Details in references/jd-breakdown.md.
Step 2: Elicit Experiences (Dig first, then solidify)
Dig. From the 3–5 core responsibilities selected in Step 1, translate each into 2–3 real-life clues and ask questions to help the candidate recall experiences not on the resume. For example, if the JD says "collect and organize user feedback to create weekly reports," instead of asking "Did you handle user feedback?", ask "Have you ever compiled reader comments, survey responses, or group chat complaints into a summary for others to see?" Clues come only from the JD, not from guessing what the candidate might have done. Dig according to JD requirements first, one requirement at a time; only after digging, verify claims from the old resume that haven't been addressed. If you follow the resume line by line, you'll keep verifying old claims and never get to digging.
Solidify. For every experience uncovered, clarify four things before entering the draft: what part you personally did, how far it went (plan/prototype/launch/has results), where the numbers came from, and when it happened. If the candidate says "I think I did something like that," ask for the specific instance; if they can't give one, mark it as pending confirmation and do not write it into the resume.
Ask no more than 3 questions at a time, focusing on what most affects the resume. If the user answers "never did it" or "don't remember," record it honestly; do not lead the user to admit something they didn't do, and do not fill in gaps. Digging can only fill expression gaps (did it but didn't write it), not real gaps (never did it).
After asking, compile a numbered, dated fact draft (F-01, F-02…), get the candidate's confirmation first, then proceed. Questioning and draft format in references/intake-questions.md; template in templates/facts.md.
Step 3: Match
Map each JD requirement to a fact number using only five states: matched, expression gap (did it but resume poorly written), insufficient evidence (might have done but lacks source), real gap (never did), pending confirmation. List real gaps honestly and include them in "how to honestly respond during interview"; do not write them into the resume. Finally, give a submission recommendation: recommend to apply, apply after supplementing materials, apply with caution, not recommend applying—no match score or percentage.
Step 4: Write the Targeted Resume
Write using only confirmed facts. Order experiences by JD priority, describe what the candidate actually did using JD terminology, but do not exceed verb limits on the two axes (see below). Rules in references/resume-writing.md.
Step 5: Audit & Interview Rehearsal
Line-by-line audit: mark each claim with one of five evidence states, check whether verbs are overstated, whether numbers have sources, and whether team or AI outputs are presented as personal. Targeted mode audits two things: the newly written targeted resume (should be all confirmed or supported—otherwise return to Step 4), and if there was an old resume, audit it too so the candidate sees where it was weak. If the old resume was already submitted, do a cross-version comparison with the new resume and provide a unified interview narrative. Audit details (including PDF, multi-version comparison, internal codes) in references/claim-audit.md.
Then for each experience, rehearse the interview: the 2–3 most likely follow-up questions from an interviewer, answer points written using only facts, phrases you must never say, and how to honestly respond to a real gap. See references/interview-probe.md.
Confirmation Gate: Only after the candidate confirms facts, verb limits, and final copy can a public version be generated. Audit results, suggested text, and limits raised by the auditor are not equivalent to fact confirmation.
Evidence States
| State | Meaning | External Use |
|---|---|---|
confirmed | Candidate confirmed in this session, or a dated "confirmed/corrected" entry in the draft states this value | Use within verb limits |
supported | Draft supports it, but candidate hasn't confirmed yet, or boundaries/phrasing need clarification | Use conservatively; do not upgrade before confirmation |
needs-source | Resume implies existence, but draft lacks source | Do not write as established fact |
inference | Inference by auditor or model | Internal only; do not include in external text |
rejected | Contradicts draft, or candidate explicitly declined | Delete or rewrite and re-audit |
If the draft doesn't mention it, write needs-source; if the draft says something else (e.g., resume says "launched" but fact says "prototype"), write rejected. When multiple states apply, take the strictest: rejected > needs-source > supported. inference is only for the auditor's own inferences (e.g., "this sentence might correspond to F-03")—it's normal for the count to be 0 when auditing an old resume.
Verb Limits: Check on Two Axes
- Personal Role:
participated/assisted → responsible (for one part) → led (for overall direction and outcome). Presenting team accomplishments as personal, or "shared" as "independent," counts as escalation. - Delivery Stage:
plan/proposal → prototype/demo → launch/deployment (with real users) → has result data. AI-generated content, prototypes, plans, and estimates cannot be written as launched, validated, or having results.
Neither axis can exceed the facts. Verb limits are determined by facts, not by JD keywords.
The stage axis only applies to things built for others to use (products, tools, pages, systems). For experiences like reports, events, or content operations, fill the stage axis with "—" and instead check scope, scale, and whether result numbers have sources. For projects done independently by a single person, the role can be "completed independently"; if parts were AI-generated, clarify what the person did (requirements, review, testing, curation). Numbers in facts cannot change units or targets (e.g., "120 registration records" cannot become "served 120 users").
Output
Targeted mode outputs in order: JD breakdown → fact draft (pending confirmation) → requirement–evidence matching table with submission recommendation → targeted resume draft (pending confirmation) → line-by-line audit table → interview follow-up rehearsal → manual confirmation checklist → unresolved items. Other entry modes output only the parts used. Output formats for each part in references/output-formats.md.
Internal codes (F-01, C-07) may only appear in audit tables and source file comments; they must not appear in external resumes, cover letters, or chat text.
Boundaries
- Do not access or submit to job boards, do not send job applications on behalf of the user, do not confirm submissions for the user;
- Do not ask for passwords, verification codes, ID numbers, or other irrelevant sensitive information;
- Do not write back the JD, model suggestions, old resume, or inferences into the fact draft;
- Public examples must use only fictional candidates;
- Do not output pass rate, hiring probability, or match score.