定制简历
将一个人的基础简历与一份职位描述相结合，生成一份定制简历（.md + .pdf）。然后报告简历对职位描述的覆盖程度以及存在哪些缺失。
准确性是此技能的核心。一份夸大经历的定制简历可能会让用户失去录用机会，甚至入职后的工作。因此，此技能会维护一份已验证事实的账本，绝不虚构任何内容，并将差距视为需要报告而不是隐藏的问题。
简历工作区
在用户的简历文件夹中工作，通常是当前目录。该文件夹包含：
| 文件 | 用途 |
|---|---|
base-resume.md | 以此技能Markdown格式保存的母版简历。每个定制变体都基于它构建。 |
facts.md | 账本：更正信息、基础简历中缺失但已确认的事实、绝不能声称的内容以及个人偏好（页数、纸张大小、联系行）。 |
<slug>-resume-<company>.md / .pdf | 每个申请对应一个定制的变体。<slug> 是用户姓名的kebab-case形式。 |
| 其他任何文件 | 用户提供的辅助资料：LinkedIn导出文件、旧的PDF、GitHub个人资料、项目README文件。 |
如果该文件夹中已有不同名称的简历，请使用该文件并在facts.md中注明其名称，而不是重命名用户的文件。
首次运行：初始化
如果还没有基础简历：
- 要求用户提供他们现有的简历（PDF、DOCX、纯文本或LinkedIn导出文件）。如果是PDF，使用
pdftotext -layout提取内容。 - 将其转换为
references/format.md中规定的格式，保留原始措辞。此阶段不要进行定制。 - 基于
assets/facts-template.md创建facts.md，填入联系行以及用户提到的任何偏好。 - 向用户展示基础简历，并请他们在进行任何定制前检查确认。此处的错误会扩散到所有变体。
新职位描述的工作流程
-
读取资料。 读取
base-resume.md、facts.md以及任何辅助资料。在存在分歧时，以facts.md为准。 -
分析职位描述。 将职位要求分为三个层级：
- P1： 必须具备（关键因素）
- P2： 强烈期望
- P3： 锦上添花
注意职位描述的用语和重复使用的关键词。ATS关键词匹配是字面的，因此当职位描述的术语和同义词都真实的情况下，优先使用职位描述中的术语。
-
映射证据。 针对每个要求，在资料中寻找真实的证据。将其标记为强匹配、部分匹配或存在差距。
-
撰写变体 文件名为
<slug>-resume-<company>.md。从基础简历的副本开始，然后：- 摘要： 重写，使其首先突出该职位最看重的方面。这是招聘人员首先阅读的内容。
- 技能： 重新排序和重组技能行，使最相关的技能排在前面，并将技能行标签重命名为职位描述中使用的术语（例如，“消息队列与流处理”、“平台与交付”）。在职位描述使用的关键缩写旁，各写出一次全称，例如，“Terraform（基础设施即代码，IaC）”、“Kubernetes（K8s）”。ATS可能会搜索这两种形式中的任何一种。
- 项目符号： 在每个职位经历中，重新排序和调整项目符号，使最相关的放在前面，并删除那些对该职位不重要的内容。较早的职位经历可以缩减到1-3个要点。
- 事实账本： 应用
facts.md中的每一项。 - 开源 / 项目： 对于有公开作品的技工岗位，在联系行中添加GitHub/作品集链接，并添加一个简短的
## 开源贡献或## 项目章节。挑选最相关的2-3项。 - 职业转换： 如果职位是一次转型（例如，从工程师转到开发者关系），保持标准的时间顺序布局。在摘要和技能之间添加一个简短的高亮章节，汇集真实、可转移的证据。不要使用“功能型”简历；招聘人员和ATS软件通常不信任这种格式。
-
构建并验证（见下文）。在报告之前修复布局问题。
-
按以下格式报告。
真实性规则
这些规则的存在是因为夸大事实的冲动持续存在且不易察觉。每条规则都防止了实际中出现过的错误。
- 绝不虚构 技能、工具、指标、规模数字、头衔或职责。如果职位描述要求的某项内容在资料中没有体现，则将其省略并在报告中列为差距。用户很可能确实有相关经验。询问只需要一条消息；而虚构的歪曲事实可能在面试中暴露。
- 可以调整措辞，但不能加强力度。 匹配职位描述的用语是可以的。但提高一个主张的力度则不行，例如：
- “参与过”变成“主导了”
- 在没有来源的情况下添加“几分钟内”、“大规模地”或“在生产负载下”
- 将两个独立的事实合并成一个更大的主张。例如，“带领团队完成了开源和企业项目；企业项目有20万用户”绝不能变成“带领一个开源团队的成果达到了20万用户”。
- 不得添加资料中未包含的自我赞美，例如，“解决难题的首选工程师”或“能向任何受众解释任何事情”。应该用证据来展现。
- 谨慎归因。 将一个事实与它来源的职位经历保持关联。用户在没有指定职位经历的情况下确认的事实（“我使用过Terraform”）应放在摘要或技能部分，而不是放在猜测的职位下。
- 保持指标原样。 百分比、计数和时间范围必须严格按照来源所述。
- 保持真实职位头衔。 在摘要中进行框架描述（“Staff级后端工程师”）是可以的。
- 在构建之前，对照资料检查每个新增或修改的项目符号。 当某内容属于合理推断但未明确说明时，要么放弃它，要么在你的报告中标记出来。
当用户更正或确认某些事项时
立即将其添加到facts.md中，并注明日期，如果知道的话，注明属于哪个职位经历。然后搜索所有其他定制变体中的相同错误并一并修复。跳过那些用户说已经发送过的变体，并在facts.md中列出它们，使未来的运行不再修改它们。重新构建你修改过的PDF，并告知用户哪些文件发生了更改。
构建与验证
python3 "${CLAUDE_SKILL_DIR}/scripts/build_resume.py" <slug>-resume-<company>.md --check
- 功能： 将PDF生成在Markdown文件旁边，然后打印页数以及ATS解析器会提取到的文本。如果
facts.md中指明用户偏好A4纸，则传递--paper a4参数。 - 如果
${CLAUDE_SKILL_DIR}未设置： 使用此技能目录的绝对路径。 - 如果未找到浏览器： 要求用户安装Chrome或Chromium，或者设置
CHROME_BIN环境变量指向其路径。
然后检查三件事：
- 页数。 使用
facts.md中用户的偏好。否则，大约10年以下经验的目标是1页，10年以上为2页。 - 视觉布局。 如果
pdftoppm可用，运行pdftoppm -r 60 -png <pdf> <tmpdir>/preview并查看每个页面的图像。检查是否存在尴尬的分页和严重换行的行。 - 提取的文本。 每个技能行应该读作一行，包含其标签；每个职位头衔应该是一行，包含其日期。如果不是，说明Markdown可能偏离了标准格式。
如果超过页面限制，按以下顺序削减
- 较早职位中最不相关的项目符号
- 长的技能行（合并行，每行保持在一个行内）
- 证书（合并到一行，放弃不相关的）
- 摘要长度
不要为了缩进而缩小字体或边距。密集的页面对人来说可读性更差，对ATS也毫无益处。
布局规则
构建器的布局是为ATS解析而设计的，因此不要改变它。表格、多列和右对齐的日期（flex或float方式）看起来不错，但提取效果很差：标签与值分离，日期与工作职位分离。构建器还会保持连字符单词的完整性，因为行尾的连字符在提取时会被丢弃（“high-throughput”会变成“highthroughput”）。
报告格式
构建完成后，回复：
-
文件：
.md和.pdf文件的路径。 -
覆盖率表格：
层级 要求 简历中的证据（或 差距） -
重点说明： 简要说明你强调了哪些方面以及削减了哪些内容。
-
提问： 询问可能帮助填补P1/P2空白的经验，或者询问你需要确认的推断性陈述。要具体：“你是直接与X合作，还是仅仅通过Y？”
-
可选服务： 提及（在用户没有主动要求时不写）你可以草拟求职信的开头、回答申请问题或面试谈话要点。
如果职位描述与现实差距很大（存在几个P1方面的空白），要直白地说明，并建议什么帮助最大。例如：一个作品集项目、对公司仓库的开源贡献，或者一封解释职业转变的求职信。
申请问题和求职信
使用相同的事实账本和真实性规则。以用户的口吻（第一人称）回答，简洁明了，并明确指出你推测出的任何具体内容，以便用户修正。将求职信写作<slug>-cover-letter-<company>.md。build_resume.py是为简历设计的，因此对于PDF求职信，只需编写简单的HTML，并使用脚本使用的相同无头浏览器命令打印它。
参考文件
references/format.md：构建器解析的确切Markdown格式，包含一个完整示例。在编写或转换简历之前，请阅读此文件。assets/facts-template.md：新facts.md的起点。assets/example-resume.md：用于测试构建器的虚构示例简历。