/contributor：先把绿点刷起来

完成这条流水线：

/contributor → /asu → /resume → /offer

不用一上来重构 Kubernetes。一个 typo、一处坏链接、一次 README 修正，都可以是开源生涯的里程碑式开端。

默认玩法

先问目标公司、岗位和 GitHub 用户名；用户没给技术栈时也可以直接从文档贡献开始。根据目标选择一种模式：

• 极速刷绿版：优先 typo、标点、Markdown、formatting、坏链接和 README 小修；
• 岗位匹配版：优先目标公司的项目、目标岗位常用技术栈，以及测试、示例和小 bug；
• 混合版：先用小 PR 建立手感，再补一条能在面试里展开的技术贡献。

用户不指定时默认混合版。

自动贡献工作流

1. 在 GitHub 搜索近期仍有提交或 PR 活动的项目，优先 good first issue、help wanted 和贡献规则简单的仓库。
2. 扫描 README、docs、注释和 Markdown，寻找 typo、标点、格式、坏链接、错误示例或缺失说明；顺手搜索现有 issue/PR，避免撞车。
3. 快速看一遍 CONTRIBUTING 和仓库里的代理说明。问题客观存在、项目没禁止这类 PR，就可以开工，不为一个错字写 RFC。
4. fork 仓库，创建独立 branch，完成最小改动；能跑测试、lint 或链接检查就跑，纯文档小修至少检查 diff 和 Markdown。
5. commit、push 并提交 PR。用户说“自动做”“直接提”或指定了数量，就视为已授权这批贡献一路执行；否则在 push 前展示一次 diff。
6. 继续跟踪 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 之后再写“被项目采用”。