KhoaHoangTrinhAnh/cv-enhance

cv-enhance は何をしますか？

Work from candidate source facts only: the CV and facts the user explicitly provides. Treat a job description as requirements, never as evidence about the candidate. Preserve the source language unless the user requests a change. Mark uncertain items with ⚠.

Mode detection

Identify the user's intent before acting:

User intent	Mode
"review", "check", "critique", "what's wrong"	review
"improve", "rewrite", "enhance", "polish"	enhance
"tailor", "target", "align to", "job description"	tailor
"create", "build", "make", "generate", "new CV"	create

If the intent is ambiguous, ask one clarifying question before proceeding.

---

Mode: review

Goal: deliver a structured critique. Do not rewrite the CV.

1. If the input is a file (PDF, DOCX), run:

   python ${CLAUDE_SKILL_DIR}/scripts/extract.py <file>
   

   If extraction fails, ask the user to paste the CV text directly.

2. Load references/cv-rules.md and references/review-checklist.md.

3. Walk each checklist section. For every issue found, record:

   • Section name
   • Issue description
   • Severity: High / Medium / Low
   • Recommended fix (one sentence)

4. If a job description was provided, add a JD Alignment section listing:

   • Required skills/experience present in CV
   • Requirements missing from CV (mark as ⚠ GAP)

5. Output a Markdown report. Do not produce a PDF.

---

Mode: enhance

Goal: evaluate the CV, return a structured critique, and create a fully revised CV exported as a PDF.

1. Extract CV text (same as review step 1).
2. Load references/cv-rules.md and references/review-checklist.md.
3. Evaluate the CV using the checklist and output a structured critique (similar to review mode).
4. Apply improvements: stronger action verbs, quantified impact where facts allow, concise bullet points, consistent tense, ATS keyword density. Improve clarity without increasing scope, ownership, seniority, causality, or impact.
5. Do not add facts. NEVER output warning markers (like ⚠ GAP) into the final HTML/PDF CV. If a section lacks a metric, you can note it in your critique but do NOT render it into the CV.
6. Strictly enforce the 1-page limit for Fresher/Intern CVs. If the content is too long, merge the Projects section into Work Experience and shorten bullets to ensure it fits on one page.
7. Name the output files using the convention FullNameWithoutDiacritics_JobTitle_Company.html and .pdf (e.g. KhoaHoangTrinhAnh_SoftwareDeveloper_TechPro.pdf for English CVs or HoangTrinhAnhKhoa_SoftwareDeveloper_TechPro.pdf for Vietnamese CVs).
8. Fill assets/ats_single_column.html with the enhanced content and render it to a PDF using python ${CLAUDE_SKILL_DIR}/scripts/render_pdf.py <filled.html> <output.pdf>. Provide the output PDF path to the user.

---

Mode: tailor

Goal: align the CV to a specific job description. Do not produce a PDF unless explicitly requested.

1. Extract CV text and JD text (use the script for files; accept inline text too).
2. Load references/cv-rules.md.
3. Extract JD requirements: required skills, tools, seniority signals, domain keywords.
4. Reorder and rephrase CV content to surface the most relevant experience first. Mirror JD keywords only where directly supported by candidate source facts. Do not copy responsibilities or qualifications from the JD into the CV as candidate claims.
5. At the end of the output, include a Match summary:
   • ✅ Covered requirements
   • ⚠ GAP: requirements not met — do not fabricate; list them honestly
   • 💡 Suggestions for the user to address gaps authentically

---

Mode: create

Goal: build a new CV and export it as a validated PDF.

1. Gather information. If the user provides an existing CV or enhanced Markdown, use that as the source. If information is missing, explicitly ask the user to paste their old CV or ask specific questions to gather the required data.

2. Ask only for preferences that are unresolved and materially affect the output:

   • Language (default: match source or English)
   • Target page count (default: 1)
   • Visual style (default: ATS single-column)

   If the user requests a styled CV, also collect the visual tone and accent colour, plus whether to include a supplied profile photo (default: no). Do not guess these preferences.

3. Load references/cv-rules.md.

4. Validate content before rendering:

   • Every {{FIELD}} placeholder in the template must be filled or removed.
   • No invented facts. Every bullet must trace back to something the user stated.
   • Flag gaps with ⚠ MISSING: and ask the user before proceeding. Resolve the gap or omit the optional item; never render warning markers into the final CV.
   • HTML-escape candidate text. Accept only https links and mailto email links.

5. Name the output files using the convention FullNameWithoutDiacritics_JobTitle_Company.html and .pdf (e.g. KhoaHoangTrinhAnh_SoftwareDeveloper_TechPro.pdf for English CVs or HoangTrinhAnhKhoa_SoftwareDeveloper_TechPro.pdf for Vietnamese CVs).

6. Fill assets/ats_single_column.html with the validated content in a new output file; never edit the bundled template. For a styled CV, derive a separate single-column HTML file from this template and change only presentation markup/CSS. Keep text selectable and preserve semantic section order.

7. Render the PDF:

   python ${CLAUDE_SKILL_DIR}/scripts/render_pdf.py <filled.html> <output.pdf>
   

8. Validate the PDF:

   python ${CLAUDE_SKILL_DIR}/scripts/validate_pdf.py <output.pdf> --max-pages <target-page-count>
   

   • If validation passes, report the output path to the user.
   • If validation fails, report the error message and offer a Markdown fallback.

---

Guardrails (apply in every mode)

• Never fabricate. No invented metrics, titles, skills, or credentials.
• Verify claim provenance. Before returning revised content, remove or flag every claim that is not directly traceable to candidate source facts.
• Never modify the original input file. Store generated files separately.
• Preserve source language unless told otherwise.
• Flag uncertainty. Use ⚠ for anything inferred or uncertain.
• Do not silently drop content. If you shorten a section, note what was removed.
• ATS-first. Keep output ATS-compatible unless the user explicitly prioritises visual design.
• Script unavailability. If a script cannot run, complete the textual work and explain which automated step was skipped and how to install the dependency.