resume

/resume: Create an editable resume

Generate a truly editable Chinese HTML resume, rather than embedding a screenshot of the resume into the page. Users can continue to modify text, photos, fonts, colors, and bolded content in the browser, and export to PDF via printing.

Resource location

ASu resources support two layouts; locate them in the following order:

1. Claude Code installation layout:../../assets/asu/；
2. Repository plugin layout:../../assets/。

Use a candidate directory only when it contains both resume-data-template.json、resume-template-editable.html、resume-template-two-page.html、template-overview.jpg、fictional-resume-photo.png, as well as all 18 built-in templates under templates-html/ , to avoid mistaking another skill's directory with the same name or an incomplete installation for the ASu resources:

• resume-data-template.json: Anonymous resume content structure;
• templates-html/: 18 Chinese HTML templates;
• resume-template-editable.html: Editable template starting point;
• resume-template-two-page.html: Two-page template starting point;
• template-overview.jpg: Template preview images;
• fictional-resume-photo.png: Fictional sample photos, used only for template demonstration.

If the skill is copied separately to another directory, first locate assets/asu/ and assets/by searching upward from the current skill directory, and do not create template resources out of thin air.

If, after searching upward, complete resources cannot be found in either layout, you must explicitly state that "the template resources were not installed with the skill," and enable the fallback plan:

• Prioritize creating a clean, editable A4 HTML that retains browser editing, a toolbar hidden during printing, and PDF export capability;
• Do not promise 18 template sets, template preview images, sample photos, or the replication accuracy of the original templates;
• State in the delivery notes that the fallback template is currently in use, along with the limitations: fewer visual styles, and no guarantee of complete consistency with the repository templates;
• Do not silently degrade due to missing resources, and do not reforge missing resources as "official templates used."

Workflow

1. First take stock of materials according to the "Input Checklist"; when the user provides a claim-evidence ledger, read the facts according to the ledger status rules . When key fields are missing, ask follow-up questions according to the "missing field follow-up rules"; if they cannot be completed, use 待补充 or 待确认 as placeholders, and do not fabricate experience.
2. If the user uploads a PDF, an existing resume, a screenshot, an image, or a document, first extract the content and inspect the layout; for screenshot-type inputs, also analyze columns, spacing, font hierarchy, colors, photo position, and pagination, then rebuild it as HTML.
3. Select the template, page count, and style according to the "Template Selection Matrix"; when the content can form a complete single page at a normal font size, prioritize a single page, and do not expand to more pages just because the template has a preset second page. If resources are missing, enable the fallback template and explain the limitations.
4. Output an HTML file, keeping the text and layout editable; place the toolbar outside the page and hide it when printing.
5. Treat print-preview as mandatory QA before export: open or simulate print preview, and check pagination, two-column layout, photo proportions, long-text overflow, Chinese fonts, print margins, and the A4 paper effect; then follow A4 page balance and visual density QA to measure the content occupancy of each page and save full-page screenshots. If problems are found, fix the HTML/CSS first before delivery.
6. When the user needs a PDF, explain the browser print settings or export command according to the "PDF Export Acceptance Criteria", or generate the PDF as requested by the user; do not substitute screenshots for editable source files.

The formal final draft uses only claims in the ledger that apply to the current position and have the status "Confirmed"; "Pending confirmation" may only be retained in internal drafts, and must be confirmed or deleted before exporting the final PDF. Claims marked "Expired" and "Not adopted" must not enter external materials.

Input checklist

First extract existing information from user messages, attachments, and project files, then ask only about the gaps that genuinely affect delivery.

• Basic information: name, phone, email, city/place of origin, job search direction, personal homepage/GitHub/portfolio (optional);
• Education background: school, degree, major, start and end dates, GPA/ranking, major courses, awards;
• Internship/work: company or team, position, start and end dates, business context, personal responsibilities, tech stack, evidence of results;
• Project experience: project name, relevance to the target position, personal boundaries, tech stack, core actions, evidence of results, presentable links or screenshots;
• Skills: languages, frameworks, databases, middleware, toolchain, English/certificates;
• Application target: position title, JD, campus recruitment/experienced hire, page count requirements, style preferences, whether a photo is needed;
• Output requirements: HTML save location, whether to also export a PDF, file naming, and privacy handling.

Rules for asking follow-up questions about missing fields

• Ask at most 3 of the most critical questions in one follow-up, prioritizing questions that would change the template and content structure: target position, page count, and whether a complete resume/attachment already exists.
• If the user requests "generate a first draft first", do not wait for all fields to be complete; use 待补充 to mark gaps such as name, dates, company, and achievement data.
• The official names and dates of education, work, and projects must not be filled in on the user's behalf; when there is no evidence for achievement metrics, write verifiable qualitative results or 待确认。
• When real private information is found in the user's materials, write it only into the resume file requested by the user, and not into the skill template, examples, README, or public documentation.
• If the same field conflicts across multiple sources, list the conflicting items and ask the user to confirm; do not choose the better-looking version on your own.

Template selection matrix

Select a template according to "position x page count x style x content density". When no corresponding resource exists, use a fallback template to replicate a similar structure.

Scenario	Recommended template structure	Applicable content density	Style
Backend development / Python / Java	A4 one page, two columns, or a compact single column, with project experience prioritized	Medium-high: 2-3 project/internship entries + skill stack	Steady, clear, engineering-oriented
Data analysis / algorithms / AI applications	A4 one page or two pages, with projects and paper/experimental results prioritized	High: many project metrics, models, datasets, and visualizations	Professional, evidence-oriented
Product / operations / business	A4 one page, with experience results and business metrics prioritized	Medium: internships/activities/projects are fairly balanced	Concise, results-oriented
Design / new media / portfolio positions	A4 one-page visual style or structure with portfolio links	Medium-low: emphasize the work entry point and visual hierarchy	More distinctive but not overly decorative
Campus recruitment with no internship or limited experience	A4 single-page two-column, with education, skills, and projects filling out the layout	Low to medium: 1-2 projects	Safe, with reasonable white space
Experienced hire or more experience	A4 two-page, with work experience in reverse chronological order	High: multiple work/project/achievement sections	Steady, with high information density

Default decision:

• For backend development positions, default to a single-page two-column layout: left side for information, skills, and awards; right side for education, internships, and projects;
• When content exceeds one page and compression would harm readability, switch to two pages instead of shrinking the font to an unreadable size;
• A single page should first form a complete loop of "identity positioning—strongest evidence—core experience—skills"; for two pages, fill the first page fully first, then let the second page carry secondary experience, and do not paginate prematurely just to fit the template structure;
• When the user explicitly asks for a "safe version", prioritize conservative wording and completeness of evidence; when explicitly asking for an "aggressive version", strengthen positioning, but must mark evidence to be supplemented.

Default layout

• Default A4, with left and right margins based on the template and stable pagination;
• Prioritize a clear Chinese font hierarchy and avoid excessive decoration;
• Default to a white background and use one primary accent color; within the first 1/4 page of the first screen, use font size, font weight, alignment, and thin lines to present the target identity and strongest public evidence, and do not default to a full-width dark header, card matrix, or grouped tags;
• Page content must be selectable, editable, and copyable;
• When the user has not provided a real photo, use a fictional sample photo and remind them to replace it;
• Do not write the user's real personal information into the plugin's templates, examples, or README.

Print-preview QA

Before delivering HTML, you must check the print preview or equivalent print media rendering result. Check items:

• A4 page size, page margins, and pagination are stable, with no extra blank pages;
• Page occupancy conforms to page balance rules: a single page is not too empty, non-final pages of a multi-page document are filled first, and the final page has no large area of blank space that can be eliminated by rearrangement;
• The single-column/two-column structure matches the template selection and will not be changed into an incorrect layout by mobile CSS in print preview;
• Long names, email addresses, links, project titles, and skill tags do not overflow, overlap, or obscure subsequent content;
• Photo proportions are normal, and it is not stretched, squashed, or cropped into key areas;
• The toolbar, edit buttons, and debug hints are hidden when printing;
• Chinese fonts are readable, and the font size is not lower than the acceptable range for normal applications;
• Background colors, dividers, and tags display normally after enabling "background graphics", and remain readable when background graphics are disabled.

If the browser cannot be opened automatically or a preview image cannot be generated, the delivery notes must state that automated QA was not completed, and provide the user with clear manual check steps.

PDF export acceptance criteria

A PDF is not acceptable simply because it "can be saved". When exporting or guiding the user to export, accept it according to the following criteria. When Edge/Chrome is installed on the machine, a zero-dependency script can be used scripts/export-resume-pdf.mjs for automatic export (npm run export:pdf -- <html路径> --out <pdf>，preferCSSPageSize make the PDF paper follow the template @page, unaffected by the browser's default paper size); saving as PDF via browser printing serves as a fallback.

• Page count meets expectations: a single-page template exports 1 page, a two-page template exports 2 pages, unless the user explicitly allows page expansion;
• The PDF contains no toolbars, editing dashed lines, browser headers/footers, URLs, dates, or extra blank pages;
• Pages are A4, recommended zoom is 100%, and content is not broken with either default or no margins;
• Two-column layouts, tables, labels, bullet points, and dividers are positioned correctly in the PDF;
• Text is selectable and copyable; a full-page screenshot must not be used as the PDF;
• Public links still identify their destination on paper: visible text should preferably use a normalized URL, DOI, or "domain/key path" (e.g. github.com/user/repo), and must not show only context-free labels such as "website", "PAPER", "CODE", or "click to view";
• Do not replace visible addresses with hidden clickable areas in the PDF. Long links should have irrelevant tracking parameters removed and be allowed to wrap naturally; after export, spot-check key domains or DOIs from the PDF text;
• If photos are used, they are clear and correctly proportioned; if placeholder photos are used, the delivery notes remind the user to replace them;
• The final notes include recommended browser settings: Chrome/Edge, Save as PDF, A4, background graphics on, headers and footers off, zoom 100%.

Deliverables

Default delivery: editable .html files, template instructions used, resource/fallback status, print-preview QA results, content occupancy ratio for each page, browser editing method, and PDF export method. If the user also needs experience rewriting, first call /asu to complete the text, then place the confirmed content into the resume.