| name | resume-generation |
| description | Generate a highly targeted YAML resume from a Job Description. Use when the user provides a JD (job description, job posting, job ad, role description) and asks for a tailored resume, an updated resume, a resume polish, or a resume that matches the role. |
Resume Generation
Produce one tailored resume in YAML for a single Job Description, by combining the candidate's master timeline with JD-specific analysis. The result is validated and placed under data/resumes/.
When to trigger
Activate when the user supplies a Job Description (raw text, a link, or a file path) and asks for a resume, a tailored resume, or a resume for that role.
Inputs you must read
data/profiles/basics.ymldata/profiles/education.ymldata/profiles/certificates.yml- All files under
data/timeline/*.yml
- The user-provided JD
Outputs you will produce
- Intermediate artifacts in
data/.cache/<UTC-Timestamp>/ (one per generation run).
- Final resume in
data/resumes/{CandidateName}_{JobTitle}_{Company}.yml.
Review & Revision Options
Before starting the pipeline, present the user with these options:
- Auto review + revise — should the pipeline automatically review and revise the resume after De-AI? (default:
yes)
- Revision rounds — how many review-revise cycles to run? (default:
1, options: 1 / 2 / 3)
- yamlresume compatibility — should the final output pass
pnpm yamlresume validate? (default: no)
Present as a single prompt:
Resume generation pipeline ready. Quick setup:
- Auto review & revise after generation? [Y/n]
- Review-revise rounds? [1/2/3] (default: 1)
- yamlresume format compatibility? [y/N] (default: no)
If the user does not respond, use defaults (yes, 1, no). Store the answers in the run context for steps 5 and 10.
Format routing:
- yamlresume compatible =
yes → generate in Legacy (YAMLResume) format. Use assets/resume.example.yml as the structural template for step 6, and assets/section-*.example.yml for step 5.
- yamlresume compatible =
no → generate in New Schema v1.0 format. Use assets/resume-new-schema.example.yml as the structural template for step 6, and assets/section-*.new-schema.example.yml for step 5.
Store the chosen format (legacy or new-schema) in the run context for steps 5–10.
Workflow
1. Initialize a run directory
Create data/.cache/<UTC-Timestamp>/ (e.g. data/.cache/20260608_104500/). All intermediate artifacts for this run go here.
2. Analyze the company and business context
Follow references/company-business-analysis.md. Save the result to data/.cache/<Timestamp>/company-business-analysis.yml.
Use DeepWiki, Context7, and Web Search as directed in the reference to build a complete picture of the company's business lines, strategic direction, tech stack, and the business unit this role supports. This output is required input for the next step.
3. Analyze the JD
Follow references/job-analysis.md. Save the result to data/.cache/<Timestamp>/job-analysis.yml. The language field detected here governs the entire downstream pipeline.
This step must consume the company business analysis from step 2. The JD alone is not enough — job requirements are inseparable from business context. The output includes a rewritten_jd field that is sharper and more honest than the raw HR posting. The resume generation steps target this rewritten JD, not the original.
4. Gather context and match timelines
- Read all files in
data/timeline/.
- Select the work and project entries most relevant to the Job Analysis and Company Analysis. Filter out clearly irrelevant ones; prioritize the rest.
- Project priority confirmation: if the candidate has more than two viable projects, ask the user to nominate up to two priority projects. If the user does not specify, auto-select the two best flagship projects based on JD relevance, business impact, quantified outcomes, technical depth, architectural ownership, and complementarity.
- Non-selected projects are still mined for signal: any unselected project that contains JD-relevant capability, domain experience, architecture, or delivery outcomes must contribute those signals into the generated Work Experience or Skills section so they are not lost.
- Resume length budget: optimize for focus and scannability, ideally fitting within two pages. Preserve complete chronology, but compress older roles and non-flagship project detail before trimming the two highlighted projects.
- Name localization: if a school or organization name is stored in bilingual form
English | 中文, output only one side based on target language — Chinese side for zh, zh-hans, zh-hant-hk, zh-hant-tw; English side for en, es, fr, no. Do NOT output both names in a monolingual resume.
5. Generate sections, in this order
Pass Job Analysis (including language), Company Business Analysis, and the matched context to each step. Save each output under data/.cache/<Timestamp>/.
Format-aware generation — use the format chosen at startup:
- Legacy path: each section uses pipe-string
summary: | syntax. Reference assets/section-{name}.example.yml for structure.
- New Schema path: each section uses array
summary: [] syntax (each bullet as a separate string). Each item must include an id field. Reference assets/section-{name}.new-schema.example.yml for structure.
- Projects — see references/section-projects.md. At most two highlighted projects. Save as
section-projects.yml.
- Work Experience — see references/section-work.md. Save as
section-work.yml.
- Skills — see references/section-skills.md. Save as
section-skills.yml.
- Personal Summary — see references/section-personal-summary.md. Crucial: also pass the generated
section-projects.yml, section-work.yml, and section-skills.yml so the summary reflects the tailored resume. Save as section-personal-summary.yml.
Detailed length budgets, ATS rules, supported Markdown subset, and authenticity rules live in references/overview.md. Read it before generating sections.
6. Assemble the final resume
Merge into one YAML file. Use the structural template matching your chosen format — do not copy its content. Sources:
data/profiles/basics.yml (basics — merge the generated summary into basics.summary)data/profiles/education.ymldata/profiles/certificates.ymldata/.cache/<Timestamp>/section-{personal-summary,skills,work,projects}.yml
Profiles (social links): always include profiles from data/profiles/basics.yml if present (e.g. GitHub, LinkedIn). This is mandatory for both formats.
Order: always include section display order. This is mandatory for both formats.
Legacy path (yamlresume compatible = yes)
Use assets/resume.example.yml as the structural template.
Section order is strict — content must follow layouts.sections.order:
basics → education → work → skills → certificates → projects
Locale: set locale.language from the Job Analysis language field, or to the language the user explicitly requested. Supported: en, zh-hans, zh-hant-hk, zh-hant-tw, es, fr, no.
Layout defaults (match the structure in assets/resume.example.yml):
- LaTeX engine:
template: jake, font size 10pt | 11pt | 12pt (default 11pt), page margins 1.5cm all sides, showPageNumbers: true.
- Markdown engine: defaults.
- HTML engine:
template: jake, font size in px from 14px to 20px (default 16px).
Profiles placement: profiles appears under content as a sibling of basics (or inside content.basics.profiles).
New Schema path (yamlresume compatible = no)
Use assets/resume-new-schema.example.yml as the structural template.
Top-level structure: schema → document → basics → order → sections.
schema.version: "1.0"document.title: "{JobTitle} – {Company}"document.language: from Job Analysis language field. Supported: en, zh-hans, zh-hant-hk, zh-hant-tw, es, fr, no.basics: name, headline, phone, email, url, summary (as string[]), profilesorder: ["education", "work", "skills", "certificates", "projects"]sections: array of discriminated section objects, each with id, type, items
Profiles placement: profiles appears under basics.profiles.
Summary format: all summary fields must be string[] (each bullet as a separate string). Do NOT use pipe-string | syntax.
Section order (via top-level order array):
education → work → skills → certificates → projects
Each section object must include id (matching the order value) and type (one of: work, education, projects, skills, certificates). Each item within a section should include an id field.
7. De-AI the resume text
After assembling the YAML, run a humanizer pass to strip AI writing patterns from all free-text fields. This step makes the resume read as human-written.
Select the humanizer based on language from Job Analysis:
Fields to process (string values only — never touch keys, dates, URLs, or structure):
basics.summary- Each work entry's
summary and highlights[]
- Each project entry's
summary and highlights[]
- Skills group
summary (if present)
- Any
description fields
Format-aware processing:
- Legacy path:
summary fields are pipe-strings (|). Process the multiline string in place, rewriting each bullet line independently.
- New Schema path:
summary fields are string[]. Process each array element independently — each element is a single bullet string. Edit the array elements in place, preserving the array structure.
Constraints:
- Preserve YAML validity — edit string values in place.
- Rewrites must be the same length or shorter, never longer.
- The resume is professional register; skip personality/soul injections.
- No em dashes (—) or en dashes (–) in the final output.
- Save the humanized YAML back to the same file, overwriting the pre-humanized version.
8. Review the resume
Follow references/resume-review.md. Read the De-AI'd resume YAML, job-analysis.yml, and company-business-analysis.yml. Save the review output to data/.cache/<Timestamp>/resume-review.yml.
The review produces a structured YAML analysis covering first impression, deep audit (holistic + per-section), revision blueprint, and final verdict.
HITL checkpoint (skipped in auto mode):
If the user chose auto review+revise at startup, proceed directly to step 9. Otherwise, present the review summary (final_verdict + summary counts) and ask:
Review complete. Score: {score}/100 | Issues: {total} ({fail} critical, {warn} warnings). Would you like to revise? [y/N]
If the user declines, skip step 9 and proceed to step 10.
9. Revise the resume (optional)
If revision was selected (auto or HITL-confirmed):
Follow references/resume-revision.md. Read resume-review.yml and the current resume YAML. Produce the revised resume and overwrite the assembled YAML file.
Mandatory De-AI after every revision: after the revision overwrites the YAML, immediately run the humanizer pass (step 7 rules) on the revised text. The humanizer selection (English vs Chinese) is the same as step 7. This ensures the final output is always free of AI writing patterns — regardless of how many revision rounds run.
Multi-round loop: after the humanizer pass, if more rounds remain (based on startup option), loop back to step 8 for another review pass. Each round's review is saved as resume-review-round{N}.yml in the same cache directory.
Round 1: review -> revise -> humanize
Round 2: re-review -> revise -> humanize
Round 3: re-review -> revise -> humanize (final)
After the final round (or if user declines revision), proceed to step 10.
10. Name and save the final file
-
File path: data/resumes/{CandidateName}_{JobTitle}_{Company}.yml
CandidateName — from data/profiles/basics.yml (basics.name).JobTitle — from Job Analysis (title).Company — from Job Analysis (company).- Join with underscores
_. Preserve spaces inside each part (do not replace spaces within a name/title/company with underscores).
-
Save the assembled YAML.
-
Validate (Legacy path only — if the user opted in to yamlresume compatibility at startup):
pnpm yamlresume validate "data/resumes/{CandidateName}_{JobTitle}_{Company}.yml"
If validation fails, report the errors and let the user decide whether to fix or keep the file as-is.
New Schema path: skip yamlresume validate (it only supports Legacy format). The resume-builder-app performs structural validation at load time.
General rules (apply to every section)
- Format: output must be valid YAML.
- Rich text:
summary fields support a limited Markdown subset only — Bold, Italic, Links, Lists (ordered, unordered, nested). Forbidden: headings, blockquotes, images, horizontal rules, tables.
- Dates: align with the format in the chosen template (
assets/resume.example.yml for Legacy, assets/resume-new-schema.example.yml for New Schema). For current roles or projects, omit endDate or set it to null. Do NOT use "Present" or "".
- URLs: omit if unknown, do NOT use
"".
- Forbidden sources: never read or copy content from
*.example.yml files. They are structural references only.
Quick reference
