SkillHub 缺口侦察兵

要解决的具体问题

很多人在 SkillHub 上发布过几个技能，但很快会陷入一个困境：下一个做什么，完全靠灵光一现。这种随机性导致两个问题：一是选题容易重复，二是容易错过真正有价值的空白领域。

更关键的认知反直觉是：很多在 GitHub 上拥有数千 Star 的开源项目，在 SkillHub 上根本没有对应的技能，或者只有一个面向开发者的低质量版本——这不是普通人能直接用的东西。换句话说，生态缺口是真实存在的，而填补这些缺口的人，往往就是普通用户自己。

核心能力与工作流程

这个技能把"找选题"变成了一套可复用的侦察流程，核心分为六个步骤：

1. 定扫描面：从效率、媒体、生活、AI、安全隐私、学习等类别中，每次挑选 4-6 类开扫，避免总是扫同一批。
2. 抓真实数据：使用 GitHub MCP 工具 search_repositories，按关键词而非 topic 过滤，拉取真实项目数据，例如 clipboard manager stars:>3000。
3. 交叉核对：这是最关键的一步——对每个候选项目，绝不靠记忆猜，而是用 SkillHub CLI 真跑搜索，记录返回的可装技能 slug 和描述。
4. 分级判定：按"普通人能不能用"分为三档：🔴 缺口（高优先）、🟡 低质相似（中优先）、🟢 已覆盖（跳过）。特别注意：像 clipboard 里的 xclip 这种开发者工具，不能当"已覆盖"误杀。
5. 评分推送：对每个 🔴/🟡 候选按"有趣 × 有用 × 普通人可用性 × 可做成 skill 的可行性"打分，挑 Top 5-8 推送。
6. 下游闭环：用户选定后，依次加载 need-to-skill-flow、skill-charter-audit、skillhub-publisher 三个技能，走完整的创建-审查-发布流程。

适用边界与注意点

不适用场景：纯开发者向的深度技术库盘点、源码级分析。这个技能的判定标准始终是"普通人能不能用"，而不是"技术上有多硬核"。

必须避免的反模式：

• ❌ 靠记忆猜 SkillHub 有没有对应技能 → 必须真跑 skillhub search
• ❌ 只推高星开发者工具（如 yt-dlp 命令行本身）→ 必须评估"包装成普通人能用"的角度
• ❌ 把需自托管服务器的项目当零门槛推送，除非用户明确要求进阶

验证闸门：宣布侦察完成前，至少有一个候选真实跑过 GitHub 搜索和 SkillHub search，且每个 🔴/🟡 都标注了 SkillHub 真实返回的 slug 或"搜不到"。

自治边界：扫描、核对、推送都是只读、本地、无副作用的动作，默认自动档；但"发布到 SkillHub"属于对外公开动作，需要用户确认后才执行。