/make-resume: Create Editable Resume
Generate truly editable Chinese HTML resumes, instead of embedding resume screenshots into the page. Users can continue to modify text, photos, fonts, colors, and bold content in the browser, and export PDF via printing.
Resource Location
ASu resources support two layouts, located in the following order:
- Claude Code Installation Layout: ;
- Repository Plugin Layout: .
Only use the candidate directory if it contains all of the following items at the same time, to avoid misjudging directories with the same name from other skills or incomplete installations as ASu resources:
resume-data-template.json
: Anonymous resume content structure;
- : Single source of shared outer frames (styles / top toolbar / editing scripts) for 18 sets of templates;
- : 18 Chinese template shell files (pure design drafts without toolbars or scripts; must be inlined into self-contained HTML via scripts/inline-template.mjs before delivery);
- : Template preview image;
fictional-resume-photo.png
: Fictional sample photo, only used for template demonstration.
If the skill is copied separately to another directory, first locate
and
by moving up from the current skill directory in sequence, do not create template resources out of thin air.
If neither layout can be found with complete resources after searching upwards, you must explicitly state "Template resources are not installed with the skill" and enable the fallback solution:
- Prioritize creating a concise A4 editable HTML, retaining browser editing, print-hidden toolbar and PDF export capabilities;
- Do not promise 18 sets of templates, template preview images, sample photos or the replication accuracy of the original templates;
- Clearly state in the delivery instructions that the fallback template is currently in use, along with limitations: fewer visual styles, cannot guarantee full consistency with repository templates;
- Do not silently degrade due to missing resources, nor forge missing resources as "official templates used".
Workflow
- First inventory materials according to the "Input Checklist"; when the user provides a claim-evidence ledger, read facts according to the Ledger Status Rules. When key fields are missing, follow the "Missing Field Follow-up Rules" to ask supplementary questions; if unable to complete, use or as placeholders, do not fabricate experiences.
- If the user uploads PDFs, existing resumes, screenshots, images or documents, first extract the content and check the layout; for screenshot inputs, also analyze fields, spacing, font hierarchy, colors, photo positions and pagination, then reconstruct into HTML.
- Select templates, page count and style according to the "Template Selection Matrix"; prioritize single-page when content can form a complete single page at normal font size, do not expand pages due to the template's preset second page. If resources are missing, enable the fallback template and explain the limitations.
- Output HTML files, keeping text and layout editable; place the toolbar outside the page and hide it during printing. Built-in templates are stored as shell files (pure design drafts without toolbars/scripts), must be inlined into self-contained HTML (including styles, top toolbar, editing scripts) via
scripts/inline-template.mjs
before delivery to users, cannot directly use shell files as deliverables.
- Use print-preview as mandatory QA before export: Open or simulate print preview, check pagination, two-column layout, photo ratio, long text overflow, Chinese fonts, print margins and A4 paper effect; then measure the content occupancy of each page and save full-page screenshots according to A4 Page Balance and Visual Density QA. Fix HTML/CSS first before delivery if problems are found.
- When the user needs a PDF, explain browser print settings or export commands according to the "PDF Export Acceptance Criteria", or generate a PDF as required by the user; do not use screenshots instead of editable source files.
Only use claims in the ledger that are applicable to the current position and marked as "Confirmed" for the final draft; "To be confirmed" can only be retained in internal drafts, must be confirmed or deleted before exporting the final PDF. Claims marked as "Expired" and "Not adopted" must not be included in external materials.
Input Checklist
First extract existing information from user messages, attachments and project files, then only ask supplementary questions for gaps that truly affect delivery.
- Basic Information: Name, phone number, email, city/hometown, job-seeking direction, personal homepage/GitHub/portfolio (optional);
- Educational Background: School, degree, major, start/end time, GPA/ranking, major courses, awards;
- Internship/Work Experience: Company or team, position, start/end time, business background, personal responsibilities, tech stack, result evidence;
- Project Experience: Project name, relevance to target position, personal scope, tech stack, core actions, result evidence, displayable links or screenshots;
- Skills: Languages, frameworks, databases, middleware, toolchains, English/certificates;
- Delivery Target: Position name, JD, campus recruitment/social recruitment, page count requirements, style preferences, whether photos are needed;
- Output Requirements: HTML save location, whether to export PDF at the same time, file naming and privacy handling.
Missing Field Follow-up Rules
- Ask at most 3 most critical questions in one follow-up, prioritize questions that will change the template and content structure: target position, page count, whether a complete resume/attachment already exists.
- If the user requests "Generate a draft first", do not wait for all fields to be complete; mark gaps such as name, time, company, achievement data with .
- Formal names and times for education, work, and projects must not be filled in on behalf of the user; when there is no evidence for achievement indicators, write verifiable qualitative results or .
- When real privacy information is found in user materials, only write it into the resume file as required by the user, do not write it into skill templates, examples, README or public instructions.
- If the same field conflicts in 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 templates according to "Position × Page Count × Style × Content Density". If corresponding resources are not available, use the fallback template to replicate similar structures.
| Scenario | Recommended Template Structure | Applicable Content Density | Style |
|---|
| Backend Development / Python / Java | A4 single-page two-column or compact single-column, prioritize project experience | Medium to high: 2-3 projects/internships + tech stack | Steady, Clear, Engineering-oriented |
| Data Analysis / Algorithms / AI Applications | A4 single-page or double-page, prioritize projects and papers/experimental results | High: Abundant project indicators, models, datasets, visualizations | Professional, Evidence-oriented |
| Product / Operation / Business | A4 single-page, prioritize experience achievements and business indicators | Medium: Balanced internships/activities/projects | Concise, Result-oriented |
| Design / New Media / Portfolio Positions | A4 single-page visual type or structure with work links | Medium to low: Emphasize work entry and visual hierarchy | More recognizable but not over-decorated |
| Campus Recruitment with No Internship or Few Experiences | A4 single-page two-column, use education, skills, projects to fill the layout | Low to medium: 1-2 projects | Stable, Reasonable white space |
| Social Recruitment or Rich Experiences | A4 double-page, work experience in reverse chronological order | High: Multiple work/projects/achievements | Steady, High information density |
Default Decisions:
- For backend development positions, prioritize single-page two-column layout by default: left side for information, skills, awards; right side for education, internships and projects;
- When content exceeds a single page and compression would harm readability, switch to double-page instead of reducing font size to unreadable levels;
- Single-page should prioritize forming a complete closed loop of "Identity Positioning—Strongest Evidence—Core Experience—Skills"; for double-page, fill the first page first, then let the second page take secondary experiences, prohibit premature pagination for template structure;
- When the user explicitly requests a "safe version", prioritize conservative wording and evidence integrity; when explicitly requesting an "aggressive version", positioning can be strengthened, but must mark evidence to be supplemented.
Default Typesetting
- Default A4 size, left and right margins based on templates and maintain stable pagination;
- Prioritize clear Chinese font hierarchy, avoid over-decoration;
- Default white background with one main accent color; within the first 1/4 of the screen, display target identity and strongest public evidence using font size, font weight, alignment and thin lines, do not use full-width dark headers, card matrices or grouped tags by default;
- Page content must be selectable, editable and copyable;
- Use fictional sample photos when the user does not provide real photos, and remind them to replace;
- Do not write the user's real personal information into the plugin's templates, examples or README.
Print-preview QA
Must check print preview or equivalent print media rendering results before delivering HTML. Check items:
- A4 page size, margins and pagination are stable, no extra blank pages;
- Page occupancy complies with Page Balance Rules: single page is not too empty, non-last pages of multi-page documents are filled first, no large areas of blank space on the last page that can be eliminated by rearrangement;
- Single-column/two-column structure conforms to template selection, will not be changed to incorrect layout by mobile CSS in print preview;
- Long names, emails, links, project titles and skill tags do not overflow, overlap or block subsequent content;
- Photo ratio is normal, not stretched, squashed or cropped in key areas;
- Toolbars, edit buttons, debugging prompts are hidden during printing;
- Chinese fonts are readable, font size is not lower than the acceptable range for normal delivery;
- Background colors, dividers and tags perform normally after enabling "Background Graphics", still readable when background graphics are disabled.
If unable to automatically open the browser or generate preview images, must state in the delivery instructions that automatic QA is not completed, and provide clear manual inspection steps for the user.
PDF Export Acceptance Criteria
PDF is not just "able to be saved". When exporting or guiding users to export, accept according to the following standards. When Edge/Chrome is installed locally, the zero-dependency script
scripts/export-resume-pdf.mjs can be used for automatic export (
npm run export:pdf -- <html path> --out <pdf>
,
makes PDF paper follow the template's
, not affected by the browser's default paper size); browser print save as PDF is the fallback.
- File page count meets expectations: single-page template exports 1 page, double-page template exports 2 pages, unless the user explicitly allows page expansion;
- No toolbars, edit dashed lines, browser headers/footers, URLs, dates or extra blank pages in the PDF;
- Page size is A4, recommended zoom is 100%, margins do not damage content when using default/no margins;
- Two-column layout, tables, tags, bullet points and dividers are positioned correctly in the PDF;
- Text is selectable and copyable, cannot use full-page screenshots as PDF;
- Public links are still identifiable on paper: visible text should use standardized URLs, DOIs or "domain name/key path" (e.g., ), cannot only display context-free labels such as "Website", "PAPER", "CODE", "Click to view";
- Do not use hidden clickable areas in PDF instead of visible addresses. Long links should remove irrelevant tracking parameters and allow natural line breaks, spot-check key domain names or DOIs from PDF text after export;
- If photos are used, they are clear and have correct proportions; if placeholder photos are used, remind users to replace them in the delivery instructions;
- Final instructions include recommended browser settings: Chrome/Edge, Save as PDF, A4, Background Graphics enabled, Headers and Footers disabled, Zoom 100%.
Delivery Content
Default delivery: Editable
file, explanation of the template used, resource/fallback status, print-preview QA results, content occupancy ratio of each page, browser editing methods and PDF export methods. If the user also needs experience rewriting, first call
to complete the text, then put the confirmed content into the resume.