lovits /contributor：先把绿点刷起来
完成这条流水线：
/contributor → /asu → /resume → /offer
不用一上来重构 Kubernetes。一个 typo、一处坏链接、一次 README 修正，都可以是开源生涯的里程碑式开端。
默认玩法
先问目标公司、岗位和 GitHub 用户名；用户没给技术栈时也可以直接从文档贡献开始。根据目标选择一种模式：
- 极速刷绿版：优先 typo、标点、Markdown、formatting、坏链接和 README 小修；
- 岗位匹配版：优先目标公司的项目、目标岗位常用技术栈，以及测试、示例和小 bug；
- 混合版：先用小 PR 建立手感，再补一条能在面试里展开的技术贡献。
用户不指定时默认混合版。
自动贡献工作流
- 在 GitHub 搜索近期仍有提交或 PR 活动的项目，优先
good first issue、help wanted和贡献规则简单的仓库。 - 扫描 README、docs、注释和 Markdown，寻找 typo、标点、格式、坏链接、错误示例或缺失说明；顺手搜索现有 issue/PR，避免撞车。
- 快速看一遍
CONTRIBUTING和仓库里的代理说明。问题客观存在、项目没禁止这类 PR，就可以开工，不为一个错字写 RFC。 - fork 仓库，创建独立 branch，完成最小改动；能跑测试、lint 或链接检查就跑，纯文档小修至少检查 diff 和 Markdown。
- commit、push 并提交 PR。用户说“自动做”“直接提”或指定了数量，就视为已授权这批贡献一路执行；否则在 push 前展示一次 diff。
- 继续跟踪 CI 和 review，处理简单反馈。PR 合并后立即生成
/asu素材；关闭或未合并的 PR 也记录为“开源协作中”，但不写成“已被采用”。
可以连续处理多个项目。每个 PR 只解决一个清楚的小问题，标题和正文按目标仓库的语言写，不把同一段模板无脑群发。
PR 怎么写
PR 本体保持短小正常，默认包含：
- 改了什么；
- 为什么改；
- 怎么检查的；
- 关联 issue（如果有）。
真正的酥化留到 /asu：外部项目看到的是清楚的贡献，HR 看到的是“跨仓库文档质量治理与开发者体验优化”。
合并后交给 /asu
为每个 PR 整理：
- 仓库、PR 链接和合并时间；
- 原问题与实际改动；
- 使用的语言、工具和验证方式；
- review/CI 结果；
- 可写进简历的结果数字，例如仓库数、合并 PR 数、修复项数。
然后直接产出这段交接提示：
用 /asu 把下面的 GitHub 贡献酥化成适合【目标岗位】的项目经历、2—3 条简历要点和 HR 开场白。可以突出跨项目协作、文档质量、开发者体验、问题发现与闭环能力，但保留真实 PR 链接和合并状态。
最后一道边界
没 merge 就写“已提交/协作中”，merge 之后再写“被项目采用”。