A generic CV asks the recruiter to do the matching. They read the posting, then read your CV, and work out on their own which of your results answer which of their needs. Most of them won't. So you tailor, and tailoring by hand in a Word file has a known failure: after five applications you have five CVs, three versions of the same result with slightly different numbers, and no idea which one is true.
I treated it as a product problem. The user is a recruiter with a few seconds per page. The job is to show that I fit this posting. The constraint is that every fact must be true and the same everywhere.
What I built
The CV lives on my site as code. Pages two and three are the chronology: every role, every result, written once and shared by every version. Page one changes per job and holds three sections:
- Selected skills. Six or seven things I do as a product manager, each with one working principle in my own words.
- Motivation. One reason I want this particular job.
- Results. Six or seven past results, picked to answer the posting's priorities.
Each targeted page one is a small data file. The site renders it above the shared chronology and prints the three-page PDF that goes with my application.
Then I wrote a skill for Claude Code that drafts page one. It reads the posting, the application letter I already approved for that job, my fact file and every letter I have sent. Before it writes a word, it builds an evidence matrix: each priority in the posting, the evidence I have for it, the best item and what it left out and why. A priority with no evidence is named as a gap.
Every correction becomes a rule
The first version of the skill was a page of instructions. The current version is several pages, and almost every line in it is a correction I made to a draft.
One kind of item per section
An early draft mixed skills (“Shaping solutions”), domains (“Two-sided marketplaces”) and credentials (“Technical depth from building”) in the same list. I felt it was off before I could say why. The rule now: every skill is something a product manager does. Domains and credentials are proof, so they go in Results.
Results prove the skills
If the page says I make decisions on partial information, a result has to show me doing it. A skill without a result behind it is a finding, and the draft goes back.
A motivation gives a reason
One draft ended with the step-by-step plan from my letter: first this, then that. It read as rehearsed. A motivation ends on a bridge from the work I know to the part that is new to me, and the plan stays in the letter.
“We” means the team
A draft said I check feasibility with engineers, which makes me the gatekeeper. Product work is shared: we test ideas for value, usability and feasibility together. My own habits get their own sentence.
Keep the reason when you trim
Page one has to fit on one page. The easy cut is the clause that explains why a result mattered, and that clause is usually the point.
These are rules about writing a CV well, and I only found them because a draft broke them in front of me. Each correction is written into the skill, so the next CV starts where the last one ended.
The model grades itself too kindly
The skill has a quality gate: a rubric with five criteria, scored 0 to 2, and nothing under 9 out of 10 goes to me. On one CV the model rated its own page 8.5, then 9. I still found a weak skill line and a motivation that did not flow.
The writer knows what each line was meant to say, so it reads the intention and misses the text. The fix was the same one you use with people: a second reader with no stake in the draft. The score I see now comes from a separate session that gets the posting, the rendered PDF text, the approved letter, my fact files and the rubric. It never sees the conversation that wrote the page or the writer's own score.
What changed
A targeted CV still takes me an afternoon. The time goes to judgement: which result answers this posting best, what a recruiter might read as doubt, what I leave out on purpose. Every posting brings something the skill has not met before, so every CV ends with a new rule or a sharper one.
What the afternoon buys has changed. Each CV starts from every correction I have made so far, so it comes out better than the one before. And my history exists in one place, with one version of every number.
There is a second win I did not plan for. Every hiring manager asks for something slightly different, and when the evidence matrix shows a gap, the skill asks me about it. Often the answer is a story I had not thought about in years: something I achieved that never made it into a CV because nobody had asked for it. Each one goes into my fact file, so the next CV can use it. With every application, more of the work I had forgotten comes back.
If you build with AI at work, this is the pattern I would copy. Start with a short brief, let the model draft, and treat every correction you make as a requirement you forgot to write down. Then write it down where the model will read it next time.