github-repo-search

SKILL.md

GitHub 开源项目搜索助手

用途

从用户自然语言需求出发，经过需求挖掘、检索词拆解、GitHub 检索、过滤分类、深度解读，最终产出结构化推荐结果。

目标不是"给很多链接"，而是"给用户可理解、可比较、可决策、可直接行动的候选仓库列表"。

适用范围（V1.1）

数据源：GitHub 公开仓库。

默认不授权（不使用用户 Token）。

默认硬过滤：stars >= 100、archived=false、is:public。

默认输出：单榜单（Top N），榜单内按"仓库归属类型"标注。

本流程默认不包含安装与落地实施（除非用户单独提出）。

配额说明（必须知晓）

未授权 Core API：60 次/小时。

Search API：10 次/分钟（独立于 Core 额度）。

需要在报告中注明检索时间与配额状态，避免结果不可复现。

工作流程

环节一：需求收敛（必须完成，不可跳过）

硬性门控：环节一是整个流程的前置条件。无论用户的需求描述多么清晰，都必须走完本环节并获得用户明确确认后，才能进入环节二。禁止根据用户的初始描述直接推断需求并开始检索。即使用户说"直接搜就行"，也要先输出需求摘要让用户确认。

第一步：需求挖掘与对齐

目标：把"我想看看 XX"转成可执行、可排序、可解释的检索目标。

需确认信息（最少）：

主题（如：agent 记忆、RAG、浏览器自动化）

数量（Top 10 / Top 20）

最低 stars（默认 100）

排序模式（必须二选一）：相关性优先 / 星标优先（默认：相关性优先）

目标形态（必须二选一或多选）：
可直接使用的产品 / 可二次开发的框架 / 资料清单/方法论

建议补充信息（可选）：

偏好技术栈（Python/TS/Go 等）

使用场景（学习、生产、对标）

排除项（教程仓库、归档仓库、纯论文复现等）

部署偏好（本地优先/云端优先/混合）

阶段输出（固定格式）：

核心诉求：
- 主题：xxx
- 数量：Top N
- 最低 stars：>= 100
- 排序模式：相关性优先 / 星标优先（默认：相关性优先）
- 目标形态：xxx
- 偏好：xxx（可空）
- 排除：xxx（可空）

向用户确认以上信息。用户明确确认后才能进入环节二，否则停在这里继续对齐。

环节二：检索执行（以下环节由模型自主执行，无需用户介入，直到环节四交付报告）

第二步：检索词拆解（5-10 组）

目标：平衡"召回率"和"相关性"，避免只靠单词硬搜导致偏题。

拆词规则：

每组 query 由以下维度组合：

核心词：用户目标词

同义词：替代表达（如 long-term memory / stateful memory）

场景词：coding、mcp、tool、platform、awesome、curated

技术词：agent、sdk、framework、database、os

排除思路：不在 query 里硬写过多负例，放到后续过滤阶段

产出格式：

Query-1: "xxx"
目的：高召回核心主题

Query-2: "xxx"
目的：补同义词盲区

第三步：执行检索与候选召回

执行原则：

每组 query 都执行检索（建议每组 30-50 条）。

合并结果形成候选池。

按 owner/repo 去重。

记录检索时间与 API 额度信息。

候选池字段（最少）：

owner/repo

stars

description

repo_url

archived

language

updated_at

topics

license

第四步：去重与硬过滤

硬过滤（默认）：

stars >= 100

archived = false

is:public

可选硬过滤（按需）：

fork = false

指定语言：language:xxx

更新时效：最近 6-12 个月

环节三：质量精炼

第五步：噪音剔除与相关性重排

目标：解决"命中 memory 但其实不是 agent memory"的噪音问题。

噪音剔除规则（示例）：

与主题无关的通用工程仓库（即使 stars 很高）

关键词误命中仓库（仅描述中偶然出现 memory/agent）

无实质内容或异常仓库

排序原则（V1.1）：

star 不再作为主排序，只作为召回门槛之一。
建议综合排序权重：

需求相关性：35%

场景适用性：30%

活跃度（更新时效）：15%

工程成熟度（文档/示例/可维护）：15%

stars：5%

第六步：仓库归属类型分类（必须）

目标：让用户一眼看懂"这个仓库到底是什么角色"，避免把框架、应用、目录混为一谈。

推荐类型字典：

通用框架层

应用产品层（可直接使用）

记忆层/上下文基础设施

MCP 服务层

目录清单层（awesome/curated）

垂直场景方案层

方法论/研究层

第七步：深读与项目介绍撰写（必须）

目标：不是"仓库简介复述"，而是输出"对用户有决策价值"的详细介绍。

深读最低要求：

每个入选仓库至少查看：

README 核心定位段

快速开始/功能章节标题

近期维护信号（更新时间、Issue/PR 活跃）

项目介绍写作要求（固定）：

"项目介绍"必须包含两部分并写细：

这是什么：它在系统架构中的角色和边界

为什么推荐：它在用户当前目标下的价值（不是泛泛优点）

可补充：

典型适用场景（1-2 条）

限制或不适用场景（1 条）

环节四：交付与迭代

第八步：单榜生成与报告交付（最终）

交付结构（固定）：

需求摘要

检索词清单（5-10 组 + 目的）

筛选与重排规则（明确写出）

结果总览（原始召回/去重后/过滤后）

Top N 单榜（表格）

结论与下一步建议

Top N 表格字段（固定）：

仓库
星标
仓库归属类型
项目介绍（是什么 + 推荐理由）
其它信息补充
链接

"其它信息补充"建议内容：

语言 / License / 最近更新时间

上手复杂度（低/中/高）

风险提示（若有）

第九步：用户确认与迭代（可选）

迭代触发条件：

用户反馈"太泛/太窄/不够准/解释不够细"。

迭代动作：

调整检索词（增加场景词或同义词）

调整 stars 门槛（100 -> 200/500）

增加限定（语言/方向/更新时间）

调整类型权重（例如优先应用层或优先框架层）

默认参数（V1.1）

最低 stars：100

默认输出：Top 10

默认过滤：archived=false

默认必须分类：是

默认项目介绍粒度：详细（至少"是什么 + 为什么推荐"）

质量检查清单（交付前自检）

是否完成需求对齐并明确"目标形态"

是否有 5-10 组 query 且每组有目的

是否记录了检索时间与配额状态

是否执行了去重、硬过滤和噪音剔除

是否完成仓库归属类型分类

是否每个推荐都有详细项目介绍（不是一句话）

是否使用固定表格字段交付

是否避免把安装实施混入本流程