Vibe Resume Skill

---
name: html-resume-builder
description: Build one-page HTML/PDF resumes from copy-paste YAML using one of 12 official templates. HARD GATES: deliver exactly one A4 page; never invent a layout — copy assets/templates/<id> into output/<id>/ and edit that copy only. Keep a full inventory in raw.data.yaml. For each job, COPY selected entries into resume.data.yaml (polish there), then apply that file to a template. Apply pasted YAML by replacing visible text in the official resume.html, then run QA. Default template is basic-a4. Use when creating, iterating, polishing copy, migrating, exporting, or designing resume/CV HTML/PDF. For polishing resume copy, prefer writing-oriented models (Claude Fable 5 / Claude Opus 4.6-4.7 or Opus 5 / Kimi K3 / GLM-5.1-5.3-max / Qwen 3.8 Max); do not use GPT-5.6 Terra/Luna or GPT-5.5 Instant.
---

# HTML Resume Builder

Use this skill to produce polished, **one-page** resume artifacts from structured facts. The default loop is **data first**: keep a `raw.data.yaml` inventory, copy selected entries into one `resume.data.yaml` per job, then apply that file to an official template. The default output is an editable HTML file and an exported PDF that follows a selected template exactly enough for recruiting use: stable A4 dimensions, consistent typography, predictable spacing, clear hierarchy, verified screenshot, and no accidental sensitive-material leaks.

This skill is intentionally workflow-heavy. Resume work fails when the model jumps straight into writing prose, invents a new HTML document, or nudges layout by eye without QA. Follow the **Mandatory Workflow** below before any other step.

When expanding the template library, work one direction at a time: produce a brief, implement in an isolated workspace, QA and compare against the baseline, then seek user approval before admission. Do not split the resume into module Agents; components are AI-decided slots inside the selected template.

## Mandatory Workflow (do this every time)

These steps are hard gates. Skipping them is a failed run, even if the page looks fine.

There are two data files. Do not mix them.

| File | What it is |
|------|------------|
| `raw.data.yaml` | 履历库. Every job, project, campus thing the user wants remembered. Can be long. **Never printed.** |
| `resume.data.yaml` | One application. Copied from raw, then polished for this JD. This is what you apply to a template. |

Job A and job B share the same raw. Each gets its own `resume.data.yaml` (e.g. `output/ai-intern/resume.data.yaml` vs `output/growth/resume.data.yaml`).

### 1. Collect facts into `raw.data.yaml`

Extract education, internships, projects, skills, contacts, and assets into the inventory. Use `examples/raw.data.yaml` as the shape. Keep extra experiences even if they will not fit one page. Add `id` / `tags` on entries so later jobs can select them (`ai-product`, `growth`, `frontend`, …).

**Show the raw file** so the user can copy it and keep adding facts. Do not hide the inventory in chat-only notes.

Do **not** write `resume.data.yaml` yet unless the user already named a target job and asked to export.

### 2. For a job: copy from raw → `resume.data.yaml`

When the user names a role or pastes a JD:

1. **Copy** (do not move) the matching entries from `raw.data.yaml` into a new `resume.data.yaml`. Set `layer: resume` and `source_raw`.
2. Leave unused entries in raw (frontend intern stays in raw when exporting an AI-product resume).