/contributor：做真实的开源贡献

完成这条流水线：

/contributor → /asu → /resume → /offer

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

默认玩法

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

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

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

贡献工作流

1. 在 GitHub 搜索近期仍有提交或 PR 活动的项目，优先 good first issue、help wanted 和贡献规则清楚的仓库；此阶段只读，不 fork、不 push。
2. 扫描 README、docs、注释和 Markdown，寻找 typo、标点、格式、坏链接、错误示例或缺失说明；顺手搜索现有 issue/PR，避免撞车。
3. 快速看一遍 CONTRIBUTING 和仓库里的代理说明；如果规则明确禁止 typo-only、drive-by documentation 或当前拟议的 PR 类型，直接标记为 ineligible 并丢弃，不进入待确认候选清单。如果规则要求先 claim issue、取得 maintainer approval 或先开 issue，则标记为 ineligible（待满足前置条件），在条件满足前不创建分支或 patch；满足条件本身如需外部写操作，也必须按第 5 步逐项确认。否则形成候选清单，写明目标仓库、问题、拟修改文件、验证方式和潜在影响。
4. 每个候选在准备本地改动或 patch 前，都从当前上游基线创建独立专用分支；不得修改默认分支，也不得把下一份补丁堆叠到已有 PR 分支。随后在该分支上实际应用拟议的最小改动或 patch，再运行可用的测试、lint 或链接检查；纯文档小修至少检查 diff 和 Markdown，然后把完整 diff 展示给用户。
5. fork、push、提交 PR 都是外部写操作。必须在执行前明确列出目标仓库、GitHub 账号、分支、文件和将产生的动作；首次提交 PR 时还必须展示拟议的完整标题和正文，以及完整代码 diff，并逐个等待用户确认。“找 N 个”“自动做”或“直接提”只授权准备候选和本地 diff，不授权批量写入。
6. 每次只执行一个已确认的 PR。提交后可以自动只读跟踪 CI 和 review。处理已有 PR 的 CI 或 review 代码反馈时，必须在该 PR 现有分支上继续工作，不得重新从上游基线创建分支或另开 PR；先说明要更新的 PR、分支、文件和 commit/push/PR 更新动作，应用补丁并展示更新后的完整 diff，再逐项等待新的明确确认。若只需评论或回复，先展示将发布的准确文本及其目标；若只需解决 thread，先列出将解决的 PR、thread 链接或文件行号和讨论摘要。以上任何外部写操作在未取得新的明确确认前都只记录建议、不执行。PR 合并后生成 /asu 素材，关闭或未合并的 PR 记录为“开源协作中”，不写成“已被采用”。

可以连续准备多个项目，但外部写操作必须逐个确认。每个 PR 只解决一个清楚的小问题，标题和正文按目标仓库的语言写，不把同一段模板无脑群发。

持续运行模式

当用户要求每天、每周或定期执行开源贡献 routine 时，把 /contributor 作为可由宿主调度器重复调用的工作流，而不是在 skill 内实现定时器。Codex Automation、cron 或其他 agent scheduler 负责唤醒；本 skill 只定义每次运行的行为与交接格式。

每次运行按以下顺序执行：

1. 先只读检查已有 PR 的 CI、review、评论和合并状态。简单反馈可以整理成修复方案，但评论、commit、push、解决 thread 等外部写操作仍按贡献工作流第 5—6 步逐项确认。
2. 已有 PR 尚未合并不阻塞探索新机会。按用户的目标岗位、技术栈和仓库赛道轮换候选，避免长期集中在同一组织或同一类型的小修。
3. 默认准备最多 2 个彼此独立、可验证的候选和本地 diff。数量不是 KPI；候选含糊、已被认领、存在重复 PR、需要大范围设计或无法合理验证时，可以只准备 1 个或 0 个。
4. 除 CONTRIBUTING 和代理说明外，主动检查 AGENTS.md、AI_POLICY.md、issue 认领状态、open/closed PR 和近期主分支，记录适用的人工审批或披露要求。
5. 为每个候选单独给出仓库、问题、分支、文件、完整 diff、验证结果、PR 标题和正文，等待用户逐个确认后再执行任何外部写操作。
6. 结束时输出日报：已有 PR 状态、检查过的仓库与候选、准备或提交的 PR、验证结果、未继续的原因，以及可选的时间或上下文消耗估算。

持续运行模式不得因为设定了目标数量而降低质量门槛，也不得演变成批量扫描、自动群发或绕过仓库贡献政策。需要配置宿主调度器时，读取 每日 routine 示例，按用户目标替换其中的岗位、赛道、数量和时间；不要声称 skill 自身会在后台运行。

PR 怎么写

PR 本体保持短小正常，默认包含：

• 改了什么；
• 为什么改；
• 怎么检查的；
• 关联 issue（如果有）。

真正的酥化留到 /asu：外部项目看到的是清楚的贡献，HR 看到的是“跨仓库文档质量治理与开发者体验优化”。

合并后交给 /asu

为每个 PR 整理：

• 仓库、PR 链接和合并时间；
• 原问题与实际改动；
• 使用的语言、工具和验证方式；
• review/CI 结果；
• 可写进简历的结果数字，例如仓库数、合并 PR 数、修复项数。

然后直接产出这段交接提示：

用 /asu 把下面的 GitHub 贡献酥化成适合【目标岗位】的项目经历、2—3 条简历要点和 HR 开场白。可以突出跨项目协作、文档质量、开发者体验、问题发现与闭环能力，但保留真实 PR 链接和合并状态。

用户准备继续使用 /asu、/resume 或 /asu-resume 时，同时按 主张—证据账本 新增一条记录：原始事实保存实际修改，证据保存 PR 链接、review/CI 和合并状态，个人边界写明文档、测试、代码或其他真实贡献范围。未合并 PR 的状态保持“待确认”或候选表述“协作中”。

最后一道边界

没 merge 就写“已提交/协作中”，merge 之后再写“被项目采用”。