oss-contribution-hunterlisted

## 何时使用 当用户想**主动发现**值得投入的开源贡献机会，而不是已经盯着某个具体 issue 时使用。典型请求： > 「在热门 AI 仓库里帮我找几个 help-wanted 的 issue。」 > 「在 langchain-ai/langchain 里找适合快速 PR 的 bug 修复。」 > 「给最近 GitHub trending 的项目生成一份贡献档案。」 核心价值是把「海量 issue」筛成「易合并 × 有影响力 × 当前工具能搞定」的少数高价值目标，并附上可直接执行的修复策略与置信分。 **不该用于：** - 用户已锁定单个 issue、只想直接动手写代码——直接进编码流程，别再走发现/评分。 - 没有 `gh` CLI 也没有联网搜索的离线环境——本技能的发现与提取依赖它们，缺失时如实说明而非编造仓库/issue。 - 为「刷 PR 数量」而非真实价值地批量灌水——评分阶段就应淘汰低价值/纯水改动。 - 想要保证 PR 一定被合并——能否合并是维护者裁量，本技能只提升命中率，不做承诺。 ## 步骤 四阶段协议，逐阶段收敛： **阶段 1 — 仓库发现** 用 `WebSearch` 或 `gh api` 找热门仓库，筛选条件： - Stars > 1000； - 近期活跃（24 小时内有 push）； - 主题相关（AI / Agentic / Web3 / Tooling，或用户指定方向）。 **阶段 2 — issue 提取** 按标签拉取候选 issue，优先标签：`help wanted` / `good first issue` / `bug` / `v1` / `roadmap`。 ```bash gh issue list --repo owner/repo --label "help wanted" --limit 10 ``` **阶段 3 — 可行性分析**（这是「贡献档案」区别于盲目挑活的关键） 对每个候选 issue 评四个维度： 1. **可复现性**：是否有复现代码片段 / 最小复现？无复现的 bug 优先级降低。 2. **影响力**：影响多少用户？是核心路径还是边缘场景？ 3. **可合并性**：看近期 PR 历史——维护者是否会**快速合并社区 PR**？长期无人 review 的仓库谨慎投入。 4. **复杂度**：当前工具/上下文窗口能否独立解决？避开需要大量领域上下文或私有环境的 issue。 **阶段 4 — 产出贡献档案（Dossier）** 为人类生成结构化报告，每个目标含： - **项目名 & Stars**； - **issue 链接 & 描述**； - **根因分析**（基于实际读码，而非臆测）； - **建议修复策略**； - **置信分（1-10）**——综合上面四维的总评。 ## 指令 给 Agent 的执行纪律： - **顺序调用、礼貌限速**：`gh`/搜索逐个发起，确认上一次返回再发下一次，避免触发速率限制。 - **只引用真实返回**：仓库、issue、PR 历史都必须来自本次工具调用结果；拿不到就标「未取得」，**不要编造**。 - **可合并性靠证据**：用 `gh pr list --repo owner/repo --state merged --limit 20` 看维护者最近的合并节奏与社区 PR 占比，再下判断。 - **根因要读码**：根因分析前用 `gh`/clone 读相关源码与复现，置信分需与「是否真的定位到根因」