HarryXC09/resume-portfolio-skill

Resume Portfolio Replica

Take the directory containing this skill as the project root, preserving React, GSAP scroll animations, card layout, and responsive visuals. When a user requests a personal website, first check the materials, then complete the entire site based on the real resume. This repository contains runnable source code and does not require any specific agent, cloud service, or API key.

First Takeover

1. Read references/materials.md and run node scripts/intake.mjs. The script creates fixed material directories and outputs any missing items.
2. Explain in the user's language, all at once: Place resume in inputs/resume/; action videos in inputs/videos/; photos in inputs/photos/; school and work unit logos in inputs/logos/; optional models in inputs/models/. Provide the shot suggestions from the materials guide, remind them to light the green screen evenly and to avoid green clothing on the person.
3. Check submitted materials; wait if the resume is missing—do not fabricate experience. If some videos are missing, first analyze the resume and complete the copy; tell the user which sections will temporarily use photos/repeated footage and which materials still need to be provided. Empty directories and placeholder images do not count as user materials.
4. Read references/adaptation.md, perform fact extraction, copy mapping, material processing, component replacement, and browser verification. After the user says materials are ready, re-run intake without repeatedly asking whether to continue.
5. Use template/resume-portfolio-content-template-general.docx as the text input form. It follows the maintainer's optimized four-column table layout; first fill in identity, About, education/work experience, and contact information, then densely fill in modules[]. The modules[] in the Word table do not presuppose an industry; the Agent should select project experience, personal portfolio, awards and honors, research, papers, client cases, or professional practice based on the CV; the first draft can fill in 3 modules, with the first module having at most 4 entries; trim after human confirmation. The repository uses template/resume-portfolio-layout-source.docx as the layout source stripped of personal metadata; when a generic field version needs to be rebuilt, run python scripts/adapt_user_word_template.py, do not write back to the source file.

Facts and Content

• The original resume is the source of factual information about the person. Record each fact to be published along with its page/paragraph number from the original document in work/facts.md. Distinguish between formal job titles, study stages, participation vs. leadership, published vs. under submission. If there are conflicts or unclear dates, only ask about missing items that affect the output.
• src/content/profile.js is the sole data entry point for page copy and media identifiers. The Word table is the user editing entry point; profile.json is only an intermediate conversion artifact and should not be maintained in parallel with the page long‑term. For routine replication, prioritize modifying this data; if the structure is not a good fit, components can be adjusted—do not force six skills or four experiences.
• Generate concise Chinese copy and faithful English translations; preserve the person's actual professional direction. Clinical, Research, and Publication are just visual slots from the original demo, not industry constraints. For non‑academic individuals, map these to project experience, personal portfolio, awards and honors, client cases, or professional practice, and update titles, captions, and model descriptions accordingly; generic medical/microscope/tumor visuals must not be interpreted as a junior's qualifications.
• External contact information is provided by the user and designated for publication; phone numbers, birthdays, addresses, documents, etc., that are not explicitly designated shall not be published. Keep the original resume and original videos only in inputs, do not copy them into public.

Materials and Delivery

Use npm run media to process green screen MP4 files numbered 01–07; parameters and shot mappings are in the materials document. After processing, check edges, skin tones, and loop seams; script parameters are a starting point, not a quality guarantee that works for arbitrary green screens.

Run npm ci, npm run intake, Word conversion / content mapping, npm run media, npm run build, and npm run preview in order. Use an available browser tool to check desktop and mobile, bilingual display, carousel, scrolling, transparent video, and fallback for missing models. First deploy the preview to static hosting or a locally accessible address; the user clicks to verify and requests changes; modifications should first go back to the Word table, then synchronize to profile and the webpage. Only perform the formal deployment after the user explicitly confirms final approval. Verify the replacement with a genuinely different newcomer profile; search for all names, institutions, contact information, and placeholder copy—do not declare the replica complete just because the build succeeded.

Standardized Closure and Pitfalls

After downloading the project, first collect the inputs/ materials, then read the resume facts and fill in the Word table; after material processing and copy mapping, build the static site and give the user a preview URL first; write user modification feedback back into the Word table and rebuild; finally deploy after explicit confirmation. The static site does not depend on a backend server by default, but videos, fonts, and 3D models still affect bundle size, above‑the‑fold speed, and hosting quotas.

Common pitfalls include: complex resume format causing incomplete fact extraction, green screen edge spill, logos without public license, oversized video or GLB files, some agents lacking a DOCX parsing library, static hosting unable to handle large files or SPA fallback. Solutions are: keep page/paragraph fact indices, first fall back to photos, record material sources, compress WebM/GLB, use scripts/word_to_profile.py and bundled Python, store large materials on object storage or use a static CDN instead, and perform real browser verification after each build.

Deliver the local preview, the finished website source code, a material usage index, and verification results. By default, do not upload new user materials and do not auto‑deploy. Follow the user's current authorization when publishing or uploading. Clearly list any placeholder sections caused by missing materials.