技能介绍

要解决什么问题

在 GitHub 赏金、Grant 和托管平台（如 Algora、UbiquityOS）上接单，常见痛点不是「找不到 issue」，而是投入大量开发后 PR 无人审、合并了也拿不到钱，以及评论/认领方式触发维护者反感和账号屏蔽。资料里记录的广撒网阶段是 393 个 PR、18 次合并、到账 $0；失败模式包括维护者长期不活跃、未等确认就开发、同仓库批量评论、赏金已过期仍接单等。

技能如何工作

技能把流程拆成扫描 → 评估 → 认领 → 开发 → PR → 付款跟踪，并强调「先验证能付钱，再写代码」。

定时扫描：bounty_scanner.sh 用 gh search issues 与 Algora 页面抓取；结果写入 data/bounty-scan-results.md，data/bounty-known-issues.txt 去重；monitor.py、PR review 与 Gmail USDT 通知由 Cron 轮询。
优先级与过滤：按金额、竞争度（评论数）、维护者活跃度打分；v7.4 起认领前跑 payment_checker.py，确认 USDT(TRC20)/RTC 与钱包配置；低于阈值（如 USDT >$10）可跳过。
开发与隔离：v3.0 分阶段子代理（多阶段、短超时）+ 进度持久化；bounty 仓库 clone 到 skills/github-bounty-hunter/workspaces/ 下，避免污染主工作区；QMD 索引、Git 同步与 STRUCTURE_AUDIT_REPORT.md 结构审计。
全自动策略（可选）：评分 >50 可自动认领并顺序开发提交 PR，仅在缺凭证、付费服务或不可恢复错误时打断用户。
经验沉淀：.learnings/ 记录失败案例（如 homelab-stack、coolify 屏蔽、Claim Issue #2129）；5 条强制规则（网络、支付、Claim 时效、同时开放 PR 数量、金额阈值）与防屏蔽规则（禁用 /attempt、同仓最多 2 个 issue 评论、真人化评论、先 PR 再说明）。

适用边界与注意点

这不是「保证收益」工具：文档中的预期收益表标明为历史推算，实际到账以平台为准；RustChain、homelab-stack 等被标为低优先级或应跳过。全自动模式会改变人机确认边界，涉及 GitHub 账号信誉与平台 ToS，需自行评估。敏感信息应走环境变量或 secrets/，不要硬编码钱包；Claim Issue 需单独、简洁、勿在非 Claim 场景贴地址。