Project Resume Writer

Project Resume Writer

根据项目目录、代码、技术文档、用户实际工作内容和补充经历，先判断简历价值与证据边界，再按目标岗位生成以下一种或两种产物：

1. 直接简历项目写法：篇幅受控、可复制进简历的项目概述与 bullet。
2. 项目亮点素材库：不受一页简历篇幅限制、可供后续筛选和面试展开的详细技术亮点清单。

不要把 README 直接改写成简历。项目能力、个人贡献、上线状态和业务结果是四类不同事实，必须分别核验。

Inputs

支持单独或组合使用以下材料：

• 项目目录或本地代码仓库。
• README、docs、design、接口文档、配置、测试、部署文件和运行结果。
• 用户在项目中的真实职责、成果和补充说明。
• 实习、论文、开源贡献、平台建设、功能开发、性能优化等经历。
• {目标岗位方向}，例如后端、AI Agent、算法、云原生、平台、数据、前端、全栈、DevOps/SRE、测试或产品。
• 用户期望的 {输出模式} 与 {条目数量}。

Required Decisions

正式草拟前必须确定：

1. {目标岗位方向}
2. {输出模式}：直接简历项目写法、项目亮点素材库，或用户明确要求的两者
3. {条目数量}：精确数量、大致范围，或由 Agent 按项目规模推荐

读取 references/output_mode_rules.md 处理模式判断、轻量规模扫描、条目数推荐和合并追问。

• 用户已明确的信息不要重复询问。
• 有项目路径但缺少数量时，先轻量查看项目规模，再给推荐值。
• 用户让 Agent 决定或要求直接生成时，采用规模对应的默认值并说明选择。
• 用户没有说明岗位时，把岗位、输出模式和条目数合并成一个简短问题。
• 没有确认岗位方向时，不生成最终可投递稿；可以先做只读项目扫描和规模建议。

Workflow

1. Resolve Mode, Count, and Role

按 references/output_mode_rules.md：

1. 从用户原话推断是否已经明确模式和数量。
2. 如果项目可读，做轻量规模扫描，不先进行完整分析。
3. 给出直接简历模式与素材库模式各自的建议条数。
4. 一次性补齐缺失的岗位、模式和数量。

完整分析版只是分析深度或外层呈现方式，不是第三种主输出模式。它可以包裹直接简历稿，也可以包裹素材库。

2. Read Rules Progressively

每次必读：

• references/resume_quality_rules.md
• references/resume_risk_rules.md
• references/output_mode_rules.md

分析代码时读取：

• references/project_signal_patterns.md

已知目标岗位时读取：

• references/role_focus_map.md

输出直接简历项目写法时读取：

• references/resume_bullet_patterns.md
• references/resume_style_rules.md

输出项目亮点素材库时读取：

• references/highlight_library_format.md

用户要求量化、材料含指标或关键结果缺少数字时读取：

• references/resume_quantification_rules.md

改写弱句时读取：

• references/weak_vs_strong_bullets.md

references/project-resume-guide.md 仅作为短导航，不替代任务相关规则。

3. Inspect Project Evidence

• 项目目录存在时，优先用 rg --files 查看结构。
• 优先读取 README、架构与设计文档、依赖文件、服务入口、API/CLI 入口、核心业务路径、配置、测试、部署和可观测性文件。
• 依赖文件包括但不限于 package.json、pyproject.toml、requirements.txt、go.mod、pom.xml、Dockerfile 和 CI 配置。
• 对关键能力继续追踪调用链、配置接线、状态流转、测试或运行证据，避免把只有接口、类名或规划文档的内容写成完整实现。
• 前后端或多服务项目需要检查关键契约和调用关系，不能只看单侧目录。

4. Build an Evidence Ledger

为候选技术点记录：

• 技术主题与解决的问题。
• 关键机制、模块和执行链路。
• 对目标岗位的价值。
• 文件、模块、类、函数、配置、测试、运行结果或用户原话。
• confirmed、code-verifiable、inferred、planned、blocked 或 unknown 状态。
• 个人贡献边界、上线边界、指标边界和敏感信息风险。

代码可以证明能力存在，通常不能证明由用户本人设计或完成。用户说明与代码推断冲突时，以用户说明为准，并列出需要确认的差异。

5. Select Distinct Signals

• 按岗位相关性、技术深度、证据强度、个人贡献可信度和可追问性排序。
• 合并同一机制的重复描述。
• 只有当问题、实现和面试展开均独立时，才把一个宽泛主题拆成多个条目。
• 不用普通 CRUD、框架名称、文件数量、代码行数或依赖数量凑条目。
• 请求数量超过可靠证据上限时，宁可少写并说明原因，也不编造或重复。

6. Draft for the Selected Mode

Direct Resume Project Mode

• 遵循 references/resume_style_rules.md。
• 输出用户指定或规模建议的 bullet 数量。
• 每条通常控制在 35-90 个中文字符，围绕一个主要贡献。
• 技术对象、动作、问题/目标、方法、结果至少具备两项。
• 若用户要求过多条目，把结果标为“候选 bullet 池”，并推荐其中最强的 3-6 条用于真实简历。

Project Highlight Library Mode

• 遵循 references/highlight_library_format.md。
• 输出用户指定或规模建议的编号亮点数量。
• 每项必须是独立技术主题，并提供详细机制、工程价值、证据、候选简历表达和面试展开。
• 不受 35-90 字限制；复杂的 Agent、RAG、记忆、Skill、Sandbox、Kubernetes、工作流、安全或可靠性机制应充分展开。
• 最后推荐最适合正式简历的 3-6 个亮点及可合并关系。

Both Modes

用户明确要求两者时：

1. 先生成项目亮点素材库。
2. 再从素材库中选择证据最强、最贴合岗位的内容。
3. 生成指定条数的直接简历项目写法。
4. 避免在两部分重复完整技术说明。

7. Handle Metrics

• 主动寻找监控、Benchmark、测试报告、正式文档、用户确认数据和代码可核证范围。
• 每个数字记录统计口径、证据与归属边界。
• 已确认指标可以进入正式表达。
• 代码可核证数字只能表达项目覆盖范围，不能冒充业务收益。
• AI 估算只能进入 AI 估算候选（待核验，禁止直接投递），用户确认前不得写入可直接投递稿。
• 缺少真实数字时，使用非数字结果或 [待补充具体数据]，不要为了量化堆砌无价值计数。

8. Final Review

输出前检查：

• 模式和条目数量是否符合约定。
• 每个条目是否独立、有证据且贴合岗位。
• 项目能力是否被误写成个人所有权。
• 已实现、部分接线、规划、阻塞和真实环境未验证是否分开。
• 技术名词是否通过实际机制展开，而不是堆栈罗列。
• 指标是否可核证，AI 估算是否被隔离。
• 是否泄露内部域名、凭证、账号、客户名或未公开代号。

Default Rule When Work Scope Is Missing

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

• 可以把模块设计、工程实现、测试、部署和优化作为候选素材。
• 素材库中明确标注“项目能力候选”，直接简历稿中使用“围绕”“参与”“实现”“补充”“构建”“支持”等克制表达。
• 无法确认的个人归属、上线、规模和结果标记为待确认。
• 不写“独立负责”“主导”“从 0 到 1”“生产上线”“提升 xx%”或“服务百万用户”，除非用户明确提供证据。

Output Contracts

Direct Resume Project Format

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

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

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

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

主条目数量必须与约定一致，除非可靠证据不足并已明确说明。

Project Highlight Library Format

# {项目名称}——项目亮点素材库

## 一、项目简历价值判断
...

## 二、项目定位
...

## 三、项目亮点素材库

### 1. {技术主题}
**亮点价值：** ...
**详细素材：** ...
**技术拆解：**
- ...
**代码证据：**
- ...
**可用于简历的素材表达：**
> ...
**面试可展开：**
- ...
**边界与待确认：**
- ...

## 四、正式简历优先选材建议
...

## 五、可补充的量化指标
...

## 六、不建议重点写的内容
...

## 七、当前验证状态与表达风险
...

详细规则以 references/highlight_library_format.md 为准。

Full Analysis Wrapper

当用户要求“严格分析”“先判断怎么写”或多版本对比时，可在目标产物外增加：

• 项目简历价值判断。
• 适合写与不建议重点写的内容。
• 证据来源、贡献边界和需要用户确认的信息。
• 项目名称、一句话概述和岗位适配建议。
• 可补充量化数据的位置与表达风险。

不要因为使用完整分析外层而忽略用户选择的主模式和条目数量。

Writing Constraints

• 输出中文，除非用户要求其他语言。
• 使用具体、克制、可信、可被面试追问的技术表达。
• 突出可确认的个人贡献，不只介绍项目是什么。
• 技术栈只有和技术对象、实现动作或工程问题绑定时才写。
• 避免“我”“本人”等第一人称，同组条目开头动词尽量不重复。
• 避免“赋能”“闭环”“体系化”“多维度”“显著提升”“大幅优化”等空泛或无证据的表达。
• 不把普通 CRUD 包装成复杂架构。
• 不把第三方 API 的简单调用写成自研算法、Agent 或基础设施能力。
• 不把估算、行业常见值或推测区间写成真实项目结果。

Resources

• references/output_mode_rules.md：双模式、规模判断、条目推荐与询问规则。
• references/highlight_library_format.md：项目亮点素材库的详细格式和质量标准。
• references/resume_quality_rules.md：候选内容与最终条目的质量判断。
• references/resume_risk_rules.md：归因、虚构、泄密和过强表达风险。
• references/project_signal_patterns.md：从代码和文档中识别简历信号。
• references/role_focus_map.md：按 {目标岗位方向} 调整重点。
• 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：短导航摘要。

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: oxygen914
• Source: oxygen914/project-resume-writer
• License: MIT

Install and usage instructions live in the source repository linked above.