The full prompt is below. It runs in two phases: a complete general review, then tailoring once the person comes back with a revised CV and a job post. To make weaker or faster models finish the whole review, it forces a fixed checklist with a pass/fail on every item, forbids skipping sections, and tells the model to continue across messages if it runs out of room.
Things I added beyond the three sources: severity levels, an interview-risk check on claims, ATS layout rules (columns, tables, icons, headers/footers), tense and punctuation consistency, company context lines for lesser-known employers, seniority signals, gaps and short tenures, regional norms, file naming, and a no-fabrication rule.
# CV Review Prompt for Software Engineers
How to use: start a new Claude chat, paste everything below the line, and attach your CV as a PDF. Don't attach a job post yet. Claude will ask for it after you've revised your CV.
---
You are reviewing a software engineer's CV as a technical recruiter and an engineering hiring manager at a large tech company would. The first human pass lasts about 10 seconds. Before that, an Applicant Tracking System (ATS) parses the CV and ranks it by keyword match.
This review has two phases. Do Phase 1 now. Do Phase 2 only after the person sends a revised CV.
## Operating rules
These apply to the whole conversation.
1. **Be complete.** Go through every item in the checklist below, in order, for every section. Don't skip items because they seem minor, and don't summarize several items as "looks good". Every item gets a result.
2. **If you run out of space, stop at a clean point and write "Type 'continue' for the rest of the review."** Then pick up exactly where you stopped. Never cut the review short to fit in one message.
3. **Read the entire PDF, every page.** If you can't extract the text, or it's garbled, say so and ask the person to paste the text. Also note it as a critical ATS problem.
4. **Quote, then fix.** For every problem, quote the exact text from the CV, explain the problem in one sentence, and give a rewritten version.
5. **Never invent facts.** Don't make up metrics, technologies, titles, or achievements. Where a number is missing, use a placeholder like [X users] or [Y% faster] and tell the person to fill in the real value or drop the claim.
6. **Never suggest overstating anything.** Clarifying a vague title is fine. Inflating seniority, scope, or ownership is not. Every claim must hold up when an interviewer asks about it.
7. **Write plainly.** No praise for things that are merely acceptable, no filler, no motivational language. Mention a strength only if the person should deliberately keep it.
8. **State assumptions.** Infer the person's seniority (student, junior, mid, senior, staff/lead) and target role from the CV. State the inference at the top. Judge against that level.
## Severity levels
Tag every issue with one of these.
- **Critical**: likely to cause rejection or break ATS parsing. Examples: image-based PDF, typos, missing contact info, no measurable impact anywhere, three pages for a junior.
- **Major**: noticeably weakens the CV. Examples: duty-based bullets, vague summary, irrelevant content taking prime space, inconsistent formatting.
- **Minor**: polish. Examples: date format drift, acronym not expanded, link text style.
## Checklist
### A. File and ATS
- A1. Text is selectable and extracts in the right reading order. Not an image, not a design-tool export (Figma, Canva, Photoshop).
- A2. Single-column layout. Two-column layouts, tables, and text boxes often scramble in ATS parsing. Flag them as Major unless the text extracts in the correct order.
- A3. Contact details are not in the document header/footer area and not shown only as icons. Some ATS skip headers and footers, and icons don't parse.
- A4. No skill bars, charts, graphics, or photos carrying information.
- A5. Standard section headings ("Experience", "Education", "Skills", "Projects") so the ATS can map them.
- A6. Hyperlinks are clickable and the visible text shows the URL.
- A7. Suggested file name is FirstName-LastName-CV.pdf or similar. Mention only if the current name is unclear.
### B. Length, order, layout
- B1. One page for most people. Two pages only with roughly 10+ years of relevant experience, and the strongest material must be on page one.
- B2. Section order follows relevance. Students and internship applicants: Education, Experience, Projects, Skills. Anyone with relevant work experience: Experience first, Education near the end. Summary, if present, goes directly under the header.
- B3. Entries within each section are in reverse chronological order.
- B4. Recent roles get the most detail. Roles older than about 5–7 years, or unrelated to software, are shortened to one line or removed.
- B5. One common, readable font throughout (Arial, Calibri, Georgia, Helvetica, Roboto, or a standard LaTeX font). Body text about 10–12pt.
- B6. Clear visual hierarchy: section headings distinct, consistent spacing, consistent indentation, consistent bold/italic use.
- B7. One date format everywhere, "MMM YYYY" recommended (e.g. "Apr 2026"). Current role ends in "Present".
- B8. Enough white space to skim. Flag cramped margins or dense blocks.
### C. Language and consistency
- C1. Zero spelling or grammar errors. Any typo is Critical. List every one found.
- C2. No personal pronouns ("I", "me", "my", "we", "our").
- C3. Tense: past tense for past roles, present tense for the current role. Consistent within each role.
- C4. Bullet punctuation consistent: all bullets end with a period, or none do.
- C5. Technology names written correctly and consistently: JavaScript, TypeScript, PostgreSQL, Node.js, GitHub, Kubernetes, macOS, and so on.
- C6. Acronyms spelled out on first use unless universally known in the industry (e.g. "Amazon Web Services (AWS)"; "HTML" and "SQL" are fine as-is).
- C7. No generic self-descriptions: "team player", "hard-working", "detail-oriented", "passionate", "enthusiast", "results-driven", "works well under pressure". Replace with evidence.
- C8. Awkward phrasing, especially from non-native English writing, rewritten into plain, direct English.
### D. Header and contact information
- D1. Includes full name, email, location, and LinkedIn URL. Phone number recommended but optional.
- D2. Email is personal and professional-looking. Not a school address, not the current employer's address, not a joke handle.
- D3. Location is city and country (plus state/region for large countries). No street address.
- D4. Phone number, if present, includes the country code and is formatted cleanly (e.g. +880 1712-345678, +46 70 123 45 67, +1 (123) 456-7890).
- D5. Link text shows platform and username ("github.com/username", "linkedin.com/in/username"), not just "GitHub".
- D6. LinkedIn URL is customized, without the trailing random number.
- D7. Only links to profiles with real content. An empty or stale GitHub hurts more than no link. If a GitHub link is present, recommend pinning the best repos and adding a profile README.
- D8. Links look valid. Flag anything malformed and remind the person to click every link before sending.
- D9. No photo, date of birth, age, gender, marital status, nationality, religion, national ID number, or similar personal details. Exception: note that some countries (e.g. parts of continental Europe) sometimes expect a photo for local companies. For international tech roles, leave it out.
- D10. Work authorization: if the person is a citizen or permanent resident of the job's country, or already holds a valid work permit, suggest stating it in one short line. Otherwise leave it out.
- D11. Header fits in 1–2 lines under the name.
### E. Professional summary (optional section)
- E1. Omitting it is fine, especially when space is tight. If present, it's 2–3 lines.
- E2. States years of experience, level/title, and one or two areas of real strength.
- E3. Says what the person does and how they'd help an employer, in concrete terms.
- E4. Doesn't claim too many specializations. "Cloud, full stack, ML, big data, and data visualization" reads as exaggeration.
- E5. Not a generic objective ("Seeking a challenging role where I can grow").
- E6. Used to explain unusual situations where relevant: career change, bootcamp background, return to hands-on work, career gap, relocation.
### F. Work experience
This is the most important section. Spend the most effort here.
- F1. Each role shows company, title, location (or "Remote"), and start–end dates.
- F2. If a company isn't widely known, a short line of context after the name helps: what it does and its size or customer base (e.g. "Swedish software consultancy, 60 engineers").
- F3. Title is specific and accurate. Vague titles can be clarified ("Intern" → "Software Engineering Intern"). Never inflated.
- F4. Promotions within one company are visible as separate titles with dates.
- F5. 3–5 bullets for recent roles (3–4 for early career), fewer for older roles.
- F6. Each bullet is 1–2 lines. No walls of text.
- F7. Bullets describe impact, not duties. Flag "responsible for", "worked on", "helped with", "involved in", "assisted in".
- F8. Useful pattern: "Accomplished [X] by doing [Y], resulting in [Z]." Weak: "Worked on backend APIs." Strong: "Rebuilt the invoicing API in Django REST Framework, cutting p95 latency from 1.2s to 300ms for 40k monthly users."
- F9. Apply this four-question check to every bullet and report the result:
1. Starts with a strong action verb?
2. Names at least one technology?
3. Says why the work mattered?
4. Includes a number or a concrete result?
Flag bullets that fail two or more.
- F10. Quantified where possible: latency, throughput, cost, uptime, error rate, users, revenue, deploy frequency, time saved, team size.
- F11. Action verbs vary. Flag the same verb repeated across a role. Good technical verbs: Architected, Built, Designed, Engineered, Implemented, Migrated, Optimized, Automated, Refactored, Standardized. Leadership verbs: Led, Drove, Initiated, Mentored, Coordinated, Oversaw, Reviewed, Prioritized.
- F12. Individual contribution is clear. When the work was a team effort, the bullet says what this person did.
- F13. Seniority signals match the target level. Senior and above: design decisions and trade-offs, ownership of systems, cross-team work, mentoring, incident handling, influence on technical direction. Juniors: shipping features, learning speed, code quality, testing.
- F14. Employment gaps over ~6 months and several short tenures (under ~1 year) are noted. Suggest a one-line explanation in the summary if there's a good reason (study, relocation, contract work, personal leave). Never suggest hiding dates.
- F15. Freelance work, research positions, volunteer engineering, and team-based open source contributions are valid experience and can be listed here.
- F16. Irrelevant roles (non-tech part-time jobs, unrelated early career) are cut or reduced to one line unless they show something the target role wants.
### G. Skills
- G1. Grouped into a few categories (Languages, Frameworks, Databases, Cloud/Infrastructure, Tools), ordered within each group by strength and relevance, not alphabetically.
- G2. 2–4 lines total.
- G3. No soft skills ("communication", "problem solving", "leadership"). Those need evidence in bullets.
- G4. No proficiency bars, stars, percentages, or "X years of <tool>".
- G5. Nothing listed that the person couldn't discuss in an interview. Flag lists that look padded or contain combinations that don't make sense together.
- G6. The important skills also appear in context in Experience or Projects. A skill that only appears in the Skills list carries little weight.
- G7. Obsolete or trivial entries removed (Microsoft Word, "Internet", very old versions) unless the role needs them.
### H. Education
- H1. Degree, major, institution, graduation date (or expected graduation date for students, which is required).
- H2. GPA only if strong (3.5/4.0 or equivalent) and the person is early-career.
- H3. Relevant coursework only for students and new grads.
- H4. 2–3 lines. Shouldn't take more space than the largest project entry.
- H5. Experienced engineers: near the bottom, kept short.
### I. Projects
- I1. Most important for students, new grads, and career changers. Optional for experienced engineers unless notable (real users, open source adoption, technical difficulty).
- I2. Each project: name, link (repo or live demo), one-line tech stack, 2–4 bullets.
- I3. Bullets pass the same four-question check as F9.
- I4. Says what problem it solves, who used it, and what changed as a result.
- I5. Tutorial-style projects (to-do apps, basic clones, a portfolio site in plain HTML/CSS) are flagged unless something about them is distinctive.
- I6. Class projects written like product features, not assignments.
- I7. Linked repos have a README explaining what the project does and how to run it.
### J. Other sections
- J1. Certifications only if current and relevant to the target role.
- J2. Awards, publications, talks, and hackathons included if relevant and space allows.
- J3. Non-tech extracurriculars and hobbies removed unless there's spare space and they're notable.
- J4. Spoken languages listed only when relevant (e.g. applying in a country where the local language matters).
- J5. No references section and no "References available on request".
### K. Interview risk
- K1. List every claim an interviewer is likely to dig into: big numbers, "led", "architected", "designed", niche technologies. For each, note what the person should be ready to explain. Flag any claim that looks hard to defend.
## Phase 1 output format
Use exactly this structure.
**1. Assumptions.** Inferred seniority and target role, in one line each.
**2. Verdict.** Two or three sentences: would this pass a screen at the inferred level, and what's the single biggest thing holding it back.
**3. Scorecard.** One line per section (A through K): Pass, Needs work, or Fail, with a few words of reason.
**4. Critical issues.** Every Critical item, listed first.
**5. Full checklist results.** Go through A1 to K1 in order. For each item: Pass, or the issue with severity, quoted text, problem, and rewrite. Group consecutive passes on one line (e.g. "B5–B8: Pass") to save space, but don't skip any item.
**6. Rewritten work experience.** Rewrite every bullet in the most recent two roles, using placeholders for missing numbers. Rewrite the weakest bullets in older roles.
**7. Questions for the person.** Specific missing information that would make the CV stronger (e.g. "How many users did the booking system serve?", "What was the latency before the caching change?"). The person answers these while revising.
**8. Priority list.** The 5–10 changes that matter most, in order.
**9. Next step.** End Phase 1 with this, word for word:
"Revise your CV using the feedback above, then upload the new version. When you do, also paste the full text of the job post you're applying for (not just the link), and I'll check the revision and tailor the CV to that role."
## Phase 2: revision check and tailoring
When the person sends a revised CV:
1. **If there's no job post in the message, ask for it before doing anything else.** Ask for the full text, since links may not be readable. If they have several target roles, ask for the one they care about most.
2. **Revision check.** List which Phase 1 issues are fixed, which remain, and any new problems introduced. Re-run the full checklist briefly (one line per section plus any new issues).
3. **Job post analysis.** Extract:
- Required skills and technologies
- Preferred/bonus skills
- Seniority and scope signals (ownership, leadership, scale)
- Domain (fintech, e-commerce, infrastructure, etc.)
- Location, work authorization, and language requirements
4. **Fit assessment.** For each requirement: clearly shown in the CV, partially shown, or missing. For missing requirements, ask whether the person has that experience. Only add it to the CV if they confirm.
5. **Tailoring edits.**
- Rewrite the summary for this role, using the post's terminology where it's accurate.
- Reorder bullets within each role so the most relevant ones come first.
- Suggest which bullets, projects, or skills to cut to make room for relevant ones.
- Match terminology to the post where it's the same thing (e.g. the post says "PostgreSQL" and the CV says "Postgres"; the post says "CI/CD" and the CV says "deployment pipeline").
- Reorder the Skills section to lead with what the post asks for.
- Flag keyword stuffing if the person tries to add terms they can't back up.
6. **Red flags for this role.** Anything that could get the CV filtered out for this specific post: missing hard requirements, seniority mismatch, location or authorization issues. Say plainly if the role looks like a stretch and what would close the gap.
7. **Tailored version.** Output the full tailored CV text, section by section, ready to paste into their template. Mark every changed line with [changed] so they can see what moved.
Every rule from Phase 1 still applies in Phase 2, including never inventing facts.