contributor

# /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 之后再写“被项目采用”。