hisn00w /great-resume：简历提升
把用户做过的事情翻译成招聘方容易理解、可以继续追问、也能由证据支撑的表达。简历提升是岗位定位和证据组织，不是虚构头衔、公司、项目、技术栈或数据。
工作流程
- 先确认目标岗位、岗位描述、求职渠道和用户希望突出的方向。
- 读取现有简历、项目说明、作品集、公开仓库、
/contributor证据卡或用户提供的截图；跨 Skill、存在冲突或包含强主张时，按 主张—证据账本 创建或更新事实基线；涉及商业分析、策略运营、经营复盘或 AI 产品化经历时，额外按 商业分析证据工作流 区分结果性质、个人动作和可追问证据。材料不足时先基于已有事实给初稿，并列出最多 5 个关键待补项。 - 输出 1—3 个岗位定位，区分稳妥版和进取版；进取版必须说明需要补充的证据。
- 按“动作 → 系统能力 → 业务价值 → 结果证据 → 个人边界”重写经历和项目要点。
- 生成简历摘要、Boss 直聘/微信 HR 短开场白，以及一版稍完整的自我介绍。
- 用“原始说法—建议写法—事实证据—个人边界—风险/待确认”审计每个强主张；使用账本时同步更新候选表述、确认状态和可展开的面试细节。
表达边界
- 正式职位、公司、时间和教育背景保持真实。
- 只有能说明决策、交付和结果时，才使用“主导”“负责人”“Owner”等强动词。
- 没有可靠数字时使用可核验的定性结果，不编造百分比、用户量、延迟或排名。
- 对没有直接负责的内容明确写“团队负责”或“待确认”，不替用户冒领。
- 用户要求制作 HTML/PDF 文件、复刻 ASu 同款或选择简历模板时，转入
/make-resume模式；用户要求记录投递和 Offer 时，转入/offer模式。 - 收到
/contributor的 PR 清单时，把 typo、README、格式修复等小贡献总结为“跨项目文档质量治理、开发者体验优化和开源协作闭环”；保留真实链接，未合并的 PR 写成“协作中”。
默认输出
除非用户只要其中一项，否则按以下顺序交付：
- 一句话岗位定位；
- 简历顶部摘要；
- 2—4 条项目/经历改写；
- HR 开场白短版和完整但简洁版；
- 证据补强清单与可能追问。
组合使用 /contributor 或 /make-resume 时，同时交付更新后的主张—证据账本；只生成简单短文案时不强制创建。
Boss 直聘或微信开场白默认控制在约 80—160 字，先说身份和方向，再说一个真实成果，最后邀请继续交流。