project-resume-writer

name

project-resume-writer

description

Optimize, quantify, and generate resume-ready Chinese project experience from project directories, source code, README/design/API docs, configuration files, user work notes, internships, papers, open-source contributions, platform work, feature development, performance optimization, or other career context. Use when the user asks to write, polish, restructure, tailor, evaluate, quantify, data-enhance, or extract high-quality resume project descriptions, resume bullets, project experience, or role-focused experience. Also use for Chinese requests about 简历, 项目经历, 实习经历, 项目亮点, 个人贡献, 投递版, 校招/社招项目描述, 简历量化, 数据化表达, 可核证指标, or 简历润色 while avoiding README-style summaries, weak bullets, unverifiable claims, fabricated metrics, and overclaiming.

Project Resume Writer

根据项目目录、代码、项目说明、用户实际工作内容和补充经历，判断哪些内容有简历价值，并生成可直接写入中文简历的项目履历。这个 skill 的重点不是把项目说明改写成简历，而是先做简历价值判断，再按 {目标岗位方向} 产出克制、可信、可被面试追问的技术表达。

Inputs

支持以下输入，可能单独出现，也可能组合出现：

• 项目目录路径或本地代码仓库路径。
• README、docs、design、接口文档、配置文件、代码结构。
• 用户在项目中的实际工作内容。
• 用户额外补充经历：实习经历、论文项目、开源贡献、平台建设、功能开发、性能优化等。
• 目标岗位方向，例如 {目标岗位方向} 工程师、产品经理，或用户自定义方向。

Workflow

1. 确认 {目标岗位方向}。
   • 如果用户已说明目标岗位方向，直接使用。
   • 如果用户未说明，先问：这段项目经历希望侧重哪类岗位？例如后端工程师、AI Agent 工程师、算法工程师、云原生工程师、平台开发工程师、数据工程师、产品经理，或其他你指定的方向。
   • 未确认岗位方向时，不要生成最终简历版本。
2. 按场景渐进读取规则文件。
   • 核心必读（每次都读）：
     • references/resume_quality_rules.md：判断 bullet 是否高质量。
     • references/resume_risk_rules.md：避免编造指标、过度归因、泄露隐私。
   • 分析项目代码时读取：
     • references/project_signal_patterns.md：从代码和文档里找简历信号。
   • 有目标岗位方向时读取：
     • references/role_focus_map.md：按 {目标岗位方向} 选择表达重点。
   • 草拟 bullet 时读取：
     • references/resume_bullet_patterns.md：检查 bullet 结构要素。
     • references/resume_style_rules.md：控制投递稿格式、长度、措辞和量化占位。
   • 用户要求量化、项目材料含指标，或关键结果缺少数字时读取：
     • references/resume_quantification_rules.md：提取可核证数字，并处理占位符、AI 估算候选和用户确认。
   • 改写已有弱句时读取：
     • references/weak_vs_strong_bullets.md：参考反例和改法。
   • 需要整体导航时读取：
     • references/project-resume-guide.md：仅作为短导航摘要。
3. 读取和分析项目材料。
   • 项目目录存在时，优先用 rg --files 查看结构。
   • 优先读取 README、docs、design、接口文档、关键配置、依赖文件、服务入口、API/CLI 入口、测试文件、部署文件。
   • 依赖文件包括但不限于 package.json、pyproject.toml、requirements.txt、go.mod、pom.xml、Dockerfile、CI 配置。
   • 不允许直接根据 README 生成简历；README 只能作为项目背景证据，必须结合代码结构、实现痕迹或用户工作内容筛选简历价值。
4. 提炼并筛选项目内容。
   • 识别项目背景和目标、核心业务或技术问题、主要模块、技术栈、工程难点、可写入简历的技术亮点。
   • 对每个候选技术点判断：是否有代码实现、是否贴合目标岗位、是否能写成用户贡献、是否能支撑面试追问、是否需要用户确认。
   • 证据来源尽量记录到文件路径、模块名、函数名、配置项或用户原话；只有宽泛证据时标注为 inferred 或待确认。
   • 主动寻找可核证量化：线上指标、基准测试、实测结果、覆盖范围和代码可验证计数；每个数字同时记录证据与归属边界。
   • 先输出“项目简历价值判断”，再写简历 bullet。
5. 结合用户实际工作内容。
   • 用户明确说明负责内容时，以用户说明为准。
   • 代码推断与用户说明冲突时，优先采用用户说明，并列出需确认点。
   • 用户未说明工作内容时，可以把项目主要功能、模块设计、工程实现和优化工作作为候选素材，但必须标注贡献边界，不写成确定归属。
6. 生成并检查每条 bullet。
   • 每条 bullet 至少包含技术对象、技术动作、问题/目标、方法、结果中的两个以上要素。
   • 每个项目默认输出 2-4 条 bullet；每条 bullet 优先控制在 35-90 个中文字符。
   • 每条 bullet 必须经过质量检查：避免只罗列技术栈、只写完成某功能、只写参与项目、只写泛泛提升效率。
   • 避免使用“我”“本人”等第一人称；同一项目下 bullet 开头动词尽量不要重复。
   • 优先使用已确认指标；缺少线上数据时，可使用与岗位价值直接相关的代码可核证数字，不为量化而堆砌文件数、代码行数或依赖数。
   • 关键结果缺少数值时，与用户确认选择：保留 [待补充具体数据]，或生成明确标注为“AI 估算、待核验”的候选区间。
   • AI 估算值只能用于讨论、追问和数据收集提示，不能作为事实写入“可直接投递”版本；只有用户确认其符合真实经历后才能转为正式指标。
7. 输出最终结果。
   • 输出中文，除非用户要求其他语言。
   • 用户要求“直接给简历/投递版/简短版”时，优先输出“直接投递版”，并保留简短的需确认点和风险提醒。
   • 用户要求“分析/严格分析/帮我判断怎么写”时，输出“完整分析版”，必须包含可写点、不建议写点、需确认点、最终简历版本和表达风险提醒。

Default Rule When Work Scope Is Missing

当用户没有提供自己的工作内容时：

• 可以把项目中的主要功能、模块设计、工程实现、测试、部署、优化作为“候选素材”。
• 用“参与”“围绕”“实现了”“补充了”“构建了”“支持了”等稳妥动词。
• 对所有无法从代码或材料确认的归属、上线、规模、指标，写成“待用户确认”或 [待补充具体数据]。
• 不写“独立负责”“主导”“从 0 到 1”“上线生产环境”“提升 xx%”“服务百万用户”等强结论，除非用户明确提供证据。

Output Format

根据用户意图选择输出格式。

Direct Resume Format

当用户只需要可直接放进简历的版本时，使用紧凑格式：

## 项目经历（可直接投递）
**{项目名称}｜{技术栈}｜{角色/时间，如已提供}**
一句话概述：...

- ...
- ...
- ...

## 需确认/可量化补充
- ...

## 表达风险提醒
- ...

Full Analysis Format

当用户需要分析、筛选或多版本改写时，采用以下格式：

## 一、项目简历价值判断
### 适合写进简历的技术点
| 技术点 | 价值等级 | 适合岗位 | 证据来源 | 判断理由 |
| --- | --- | --- | --- | --- |

### 不建议重点写的内容
- ...

### 需要用户确认的信息
- ...

## 二、目标岗位方向
{目标岗位方向}

## 三、项目名称建议
...

## 四、项目一句话概述
...

## 五、可直接写入简历的项目经历
### 稳重正式版
- ...
- ...
- ...

### 更偏工程表达版
- ...
- ...
- ...

## 六、可补充量化数据的位置
- ...

## 七、表达风险提醒
- ...

Writing Constraints

• 写具体、克制、可信的中文技术简历语言。
• 突出个人贡献，不只介绍项目是什么。
• 技术栈只有和实现动作、技术对象或工程问题绑定时才写。
• 投递版每个项目默认 2-4 条 bullet，每条 bullet 优先控制在 35-90 个中文字符。
• 不使用“我”“本人”等第一人称；避免多条 bullet 连续使用相同开头动词。
• 避免“赋能”“闭环”“体系化”“多维度”“显著提升”“大幅优化”等空泛或过强表达。
• 不把普通 CRUD 包装成复杂系统设计。
• 不把第三方 API 简单调用写成算法或 Agent 能力。
• 不把 AI 估算、行业常见值或推测区间伪装成真实项目结果；投递稿中的每个数字必须可核证或经用户明确确认。
• 不泄露内部域名、token、账号、客户名或未公开项目代号。

Resources

• Read references/resume_quality_rules.md to judge whether candidate bullets are high quality.
• Read references/role_focus_map.md to tailor emphasis by {目标岗位方向}.
• Read references/project_signal_patterns.md to identify resume-worthy signals from code and docs.
• Read references/weak_vs_strong_bullets.md before rewriting weak bullets.
• Read references/resume_bullet_patterns.md when drafting or quality-checking bullet structures.
• Read references/resume_style_rules.md before producing final resume-ready wording.
• Read references/resume_quantification_rules.md when the user requests quantification, source materials contain metrics, or important results lack numbers.
• Read references/resume_risk_rules.md before final output to avoid overclaiming.
• Read references/project-resume-guide.md only as a short navigation summary if needed.