Resume Tailor: No Claim Without Evidence

How I got here

I was rewriting my own resume for a specific role and caught myself doing the thing everyone does. A bullet sounded good, so I kept it. I could not have defended it in an interview.

That is the failure mode nobody talks about. The risk is not getting caught lying. The risk is getting through: a claim wins you the screen, and then you lose the room in ten minutes because you cannot answer a follow-up on your own resume.

Most resume advice is about keywords. Keywords are one gate out of five, and not the one that quietly loses people.

How I thought about it

One rule holds the whole thing up: no claim without evidence.

Every bullet has to trace to an entry in your evidence ledger. If nothing backs it, it does not get written. It goes on an open-items list instead, and you get told what is missing. That turns a vague worry into a task you can actually go and close.

A resume is read five times, by three kinds of reader, in a fixed order. A parser extracts fields. A model ranks you against the posting. A human scans for about seven seconds. Then the bullets get read. Then a hiring manager asks whether any of it is real.

Optimising for a later gate at the cost of an earlier one is the most common mistake in the genre, because if gate one fails, the rest never happen.

What it refuses is as much of the design as what it does. No hidden text of any kind, including white-on-white and instructions in the metadata aimed at a model. No invented or rounded-up numbers. No fake titles or stretched dates. No third-party match score, because that number is a stranger's guess at what an employer runs.

What I actually did

The part I am most attached to is the verification pass, because it is the step almost nobody takes. The skill renders the resume to PDF, then reads the text back out of it the way a parser would: page count, font embedding, whether every field survives extraction, whether a section heading landed on its own line, whether a line break welded two words together.

You list your name, phone, email, every employer, every school and every date range in a probe file. Every one has to survive extraction. A missing probe means that field is invisible to a parser even though it looks perfect on screen.

A resume you have not extracted the text from is a resume you have not checked.

The evidence ledger lives in your home directory rather than the project folder, so it follows you and cannot end up committed to a repo by accident.

Being honest about the evidence

Every factual claim in the reference doc carries a tag: measured, reported, or directional. A good deal of what circulates as resume fact is the third kind, so it is labelled rather than laundered.

Two of those facts are uncomfortable and stay in anyway. A referral converts several times better than a cold application, which means the resume is your second priority if one is reachable. And callback discrimination on names is real and measured. Nothing in this repository fixes that. It is named so a candidate facing silence does not conclude the problem is their bullet points.

Where it's heading

It clears gates. It does not produce interviews, and it emits no match percentage, because that number would be invented. I use it on my own applications, which is the only reason I trust it.