tangshengming/personal_website

Generate Website

Overview

Use this skill to reproduce a careful CV-to-website workflow. The key principle is to create reviewable source material before generating pages: first extract the CV into Markdown, then decide what is public, then build the website from structured content.

Workflow

1. Inspect The Workspace

Check the current project files before editing:

• Find workflow/status files such as WEBSITE_WORKFLOW.md, PROJECT_STATUS.md, or similar.
• Find the CV/profile source file: usually .pdf, .tex, .docx, or a text/Markdown CV.
• Check whether a website already exists: package.json, astro.config.*, src/, public/, dist/.
• Check Git state lightly with git status --short when useful.

Do not assume a blank project.

2. Read And Inspect The CV

If the source is a PDF:

• Use the PDF skill.
• Extract text with pdfplumber or another reliable PDF text tool.
• Render pages to images when possible and visually inspect them so layout and section boundaries are not misread.
• Expect PDF text extraction to have spacing/icon artifacts; clean them manually in the structured output.

If the source is LaTeX:

• Read the .tex source directly.
• Treat section commands, macros, and lists as structure.
• Do not require local LaTeX compilation unless the user asks for PDF regeneration.

If the source is .docx:

• Use the documents skill to extract structure and content.

3. Extract To Reviewable Markdown

Create a Markdown source file before building website pages. Prefer:

content/cv_extracted.md

Include structured sections such as:

• Identity
• Public contact
• Private or hidden contact/details
• Profile
• Languages
• Technical expertise
• Professional skills
• Working experience
• Education
• Publications
• Projects
• Website presentation potential for each project

Keep this file factual. It is the source material, not final marketing copy.

4. Ask Or Confirm Public/Private Decisions

Before putting personal details on a public website, confirm:

• Public email
• Whether to show phone number
• Whether to show birth date
• Whether to show full address
• Whether to show residence/permit/visa/license details
• Which links are public or hidden: GitHub, LinkedIn, Google Scholar, ORCID, ResearchGate, etc.
• Preferred audience: industry, academic, mixed, clients, recruiters, collaborators
• Visual preference: minimal, academic, expressive technical portfolio, etc.

Default privacy posture:

• Hide birth date, phone number, full address, residence permit, driving license, and similar sensitive details unless the user explicitly wants them public.
• Prefer public email, city/country, and selected professional links.

5. Draft The Website Structure

Create a structure draft before scaffolding or heavily editing pages. Prefer:

WEBSITE_STRUCTURE_DRAFT.md

Include:

• Design direction
• Intended audience
• Navigation
• Page list
• Page purpose
• Suggested content per page
• Open questions or decisions
• Technical recommendation

A good first structure:

• Home
• About
• CV
• Projects
• Contact

For research-heavy profiles, leave room for later academic web-presentation pages.

6. Scaffold The Website

Use Astro by default for a content-heavy personal website unless the user requests another stack.

Suggested structure:

src/
  pages/
    index.astro
    about.astro
    cv.astro
    projects.astro
    contact.astro
  content/
    profile.ts
    projects.ts
  layouts/
    BaseLayout.astro
  styles/
    global.css
public/

Build website content from structured source files, not by scattering hardcoded CV text everywhere.

Recommended content files:

• src/content/profile.ts for identity, profile, expertise, experience, education, publications.
• src/content/projects.ts for project entries and later presentation notes.

Copy public assets into public/:

• CV PDF, if the user wants downloadable CV.
• Portrait image, if available and approved.
• Project images or figures later.

7. Design The First Version

For a first personal site:

• Make the first screen the actual identity/profile, not a marketing landing page.
• Use real visual assets where available.
• Keep contact information privacy-conscious.
• Build pages that can be scanned quickly but expanded later.
• For industry audiences, emphasize engineering usefulness, R&D workflows, technical depth, and transferable capabilities.
• For academic audiences, emphasize research questions, methods, publications, and presentation flow.

Avoid overfitting the first version. Leave clear places for future project presentation pages.

8. Verify Locally

Run:

npm.cmd install
npm.cmd run build
npm.cmd run dev

On Windows/PowerShell, prefer npm.cmd if npm is blocked by script execution policy.

If Astro telemetry tries to write outside the workspace, set scripts in package.json like:

"dev": "set ASTRO_TELEMETRY_DISABLED=1&& astro dev",
"build": "set ASTRO_TELEMETRY_DISABLED=1&& astro build",
"preview": "set ASTRO_TELEMETRY_DISABLED=1&& astro preview"

Verify:

• Build succeeds.
• Local routes return 200.
• Public assets load.
• No sensitive details are accidentally shown.
• Browser visual QA is performed when available, or the user reviews manually.

9. Update Status And Readme Files

Update a status/dashboard file if the project uses one, for example:

PROJECT_STATUS.md

Useful support files:

• readme_website.txt: how to edit, preview, build, and commit the website.
• readme_git.txt: Git setup and common commands.
• WEBSITE_WORKFLOW.md: long-term workflow.

Keep status concise. Do not add noisy Git details unless the user asks.

Output Expectations

At the end of a first pass, the project should have:

• Extracted CV source Markdown.
• Website structure draft.
• A working Astro site.
• Content separated from page/layout code.
• A successful build.
• A local preview URL.
• Clear notes about what remains pending.