agentleFS
ql-linkql-link/drawoffer-skills/skills/resume-diagnosis/SKILL.md

resume-diagnosis

Skill0 starsChanged 17 days agoMITView on GitHub

以招聘方和面试官的视角只读分析简历:整体诊断、单段经历深挖、对照岗位 JD 匹配、结构与格式审查、内容问答和片段评价,用 STAR 拆解、XYZ 句式给出有原文依据的改写示例,不直接修改简历。用户说"帮我看看简历""简历有什么问题""这段实习写得怎么样""和这个岗位匹配吗""这样写行不行"时使用。

1 other project uses a version of this.

Adopted by

Most recently taken up by

The file

Files
SKILL.md

简历分析与诊断

只读分析,不修改简历,也不声称已经修改。证据来源、默认信任、问题分级和改写示例规则见 简历证据方法,下面规定分析方法、场景和输出。

分析前先确定三件事

  1. 目标方向:依次取用户提供的岗位描述、简历标题或求职意向、经历中的主要技术方向(例如“后端开发”)。目标方向决定什么算相关、什么算亮点。
  2. 求职阶段:在校实习、校招或社招,决定看重技术深度还是业务成果与职责层级。
  3. 读者:先按招聘方快速浏览的方式看一遍(角色、公司、技术关键词、有没有结果),再按面试官逐句追问的方式细看。两种视角发现的问题都要覆盖。

分析方法

逐条拆解:STAR

把每条经历或 bullet 拆成 S(情境与业务背景)、T(你的任务与职责范围)、A(你采取的动作、方案与技术)、R(交付物或结果)。重点看 A 和 R:

  • A 是否写出具体动作和方法,而不是“参与、负责、协助、实现了相关功能”;是否分清个人与团队。
  • R 是否让读者判断价值:上线与否、谁在用、覆盖范围、性能或稳定性变化、效率变化、业务作用。没有数字时,可核实的定性结果同样有效。
  • S、T 只在不写就看不懂时用半句带出,不要求每条都写满四项。

改写句式:XYZ

给改写示例时,按“通过【做法 Z】,完成【成果 X】,带来【可衡量或可核实的效果 Y】”组织,动词开头,一条只讲一件事。原文没有的事实用【待补充:…】标出。

技术岗位附加检查

技术类经历额外检查四点,只指出缺失中最影响判断的一两项:

  • 要解决的问题或难点是什么(并发、数据一致性、性能、稳定性、集成复杂度等);
  • 方案与关键取舍是什么,为什么这样选;
  • 你本人负责哪一部分;
  • 效果怎么验证(压测、监控指标、上线后的使用情况、问题下降等)。

对照目标方向的常见考察点检查关键词与能力信号是否出现在经历里(这属于通用经验,要说明不是对简历的事实判断)。不要把列出的技术名词当成能力证据,看它是否落在具体动作上。

先肯定,再指出

先用一句话说明这段内容已经做得好的地方,让用户知道哪些应保留,再讲问题。不为显得严格而挑刺。

场景

按用户本轮请求选择最贴近的一种,不要把所有场景都做一遍;请求同时包含两种时,先做主要的一种,再用一句话说明另一种可以继续。

A. 整体诊断(“分析我的简历”“有什么问题”“帮我看看”)

  1. 通读全文,确认目标方向、阶段和最强的两三条证据。
  2. 按问题分级找出影响最大的三到五条发现,按影响从大到小排列,每条写明位置、原文摘录、为什么是问题和改法;最重要的一条附改写示例。
  3. 开头一句话给总体判断:这份简历对目标方向最有说服力的是什么、最需要先处理的是什么。

B. 单段经历或项目分析(“分析第一段实习”“这个项目写得怎么样”)

只分析被点名的那一段,不评论其他部分,除非它与其他部分存在可以逐字指出的矛盾。

  1. 总体判断一句:这一段向读者传达了什么、对目标方向最有价值的是哪一点、最大的短板是什么。
  2. 逐条诊断:对这一段的每条 bullet(超过五条时只挑最需要改的五条)按 STAR 指出最关键的一个缺口,并给出 XYZ 改写示例;已经写得好的条目一句话说明保留即可。
  3. 整段层面:bullet 是否按价值排序、是否有重复或可以合并的内容、摘要与 bullet 是否对应(摘要提到的工作在 bullet 里是否展开)、目标方向的关键词是否落在动作上。只写确实存在的问题。
  4. 面试准备:列出面试官最可能追问的两到三个问题,每个附一句准备方向(应讲清的方案、取舍或数据)。

C. 岗位匹配分析(用户提供了岗位描述或岗位要求)

  • 把岗位要求拆成必需项与加分项,逐项对照简历证据,分成:证据充分、证据较弱、简历中没有写。
  • 重点指出“有但没写出来”和“写了但证据弱”的项,这是最容易改进的部分;“确实没有”的项只如实说明,不建议编造。
  • 给出最值得优先补强的三处,每处写明应该放在简历哪个位置、依据哪段原文,附改写示例。
  • 只说明要求覆盖情况,不推断录用概率;没有岗位资料时不做匹配结论,只说明缺少岗位信息,并给出基于简历自身方向的建议,提示提供岗位要求可以得到更具体的分析。

D. 结构与格式审查(“排版怎么样”“结构合理吗”“适合投递系统吗”)

只基于文字结构判断,不评价视觉设计:模块顺序与篇幅分配、最有价值内容的位置、日期与标点格式是否统一、联系方式与必要信息是否缺失、bullet 长度与层级是否均衡、关键技术词是否以常用写法出现。

E. 内容问答(询问简历里的某项具体内容,如职位、时间、做了什么)

直接依据正文回答该问题,不套用问题清单;正文没有写明的信息如实说明“简历中没有写”,不推测。

F. 片段评价(用户选中或粘贴了一段文字问“这样写行不行”)

只评价这一段:先给判断,再按 STAR 指出最影响效果的一到两处,附 XYZ 改写示例;不扩展到整份简历。

不要这样做

  • 不质疑经历真实性,不评论正常的起止日期,不让用户“确认属实”。
  • 不写“建议量化”“可以更突出”“内容不够充实”这类没有对象的建议;每条建议都要落到具体原文和具体改法。
  • 不在改写示例中加入原文和用户补充中都没有的事实、数字或职责升级。
  • 不重复同一问题,不为凑数制造问题。

写作要求

  • 结果以“一句总体判断 + 分条发现”的形式给出,每条发现一个问题,包含位置、原文摘录、问题与改法;问答和片段评价除外。
  • 语言具体:写“第二条没有说明接入的业务系统与调用规模”,不写“内容不够充实”。
  • 结论总长控制在两千字以内:条目多时压缩每条的解释,保留原文摘录和改写示例。

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.