القائمة
帮助用户搜索和筛选 GitHub 开源项目，输出结构化推荐报告。当用户说"帮我找开源项目"、"搜一下GitHub上有什么"、"找找XX方向的仓库"、"开源项目推荐"、"github搜索"、"/github-search"时触发。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | github-repo-search |
| description | 帮助用户搜索和筛选 GitHub 开源项目，输出结构化推荐报告。当用户说"帮我找开源项目"、"搜一下GitHub上有什么"、"找找XX方向的仓库"、"开源项目推荐"、"github搜索"、"/github-search"时触发。 |
从用户自然语言需求出发，经过需求挖掘、检索词拆解、GitHub 检索、过滤分类、深度解读，最终产出结构化推荐结果。
目标不是"给很多链接"，而是"给用户可理解、可比较、可决策、可直接行动的候选仓库列表"。
stars >= 100、archived=false、is:public。60 次/小时。10 次/分钟（独立于 Core 额度）。硬性门控：环节一是整个流程的前置条件。无论用户的需求描述多么清晰，都必须走完本环节并获得用户明确确认后，才能进入环节二。禁止根据用户的初始描述直接推断需求并开始检索。即使用户说"直接搜就行"，也要先输出需求摘要让用户确认。
目标：把"我想看看 XX"转成可执行、可排序、可解释的检索目标。
需确认信息（最少）：
相关性优先 / 星标优先（默认：相关性优先）可直接使用的产品 / 可二次开发的框架 / 资料清单/方法论建议补充信息（可选）：
阶段输出（固定格式）：
核心诉求：
- 主题：xxx
- 数量：Top N
- 最低 stars：>= 100
- 排序模式：相关性优先 / 星标优先（默认：相关性优先）
- 目标形态：xxx
- 偏好：xxx（可空）
- 排除：xxx（可空）
向用户确认以上信息。用户明确确认后才能进入环节二，否则停在这里继续对齐。
目标：平衡"召回率"和"相关性"，避免只靠单词硬搜导致偏题。
拆词规则：
每组 query 由以下维度组合：
产出格式：
Query-1: "xxx"
目的：高召回核心主题
Query-2: "xxx"
目的：补同义词盲区
执行原则：
owner/repo 去重。候选池字段（最少）：
owner/repostarsdescriptionrepo_urlarchivedlanguageupdated_attopicslicense硬过滤（默认）：
stars >= 100archived = falseis:public可选硬过滤（按需）：
fork = falselanguage:xxx目标：解决"命中 memory 但其实不是 agent memory"的噪音问题。
噪音剔除规则（示例）：
排序原则（V1.1）：
star 不再作为主排序，只作为召回门槛之一。
建议综合排序权重：
目标：让用户一眼看懂"这个仓库到底是什么角色"，避免把框架、应用、目录混为一谈。
推荐类型字典：
目标：不是"仓库简介复述"，而是输出"对用户有决策价值"的详细介绍。
深读最低要求：
每个入选仓库至少查看：
项目介绍写作要求（固定）：
"项目介绍"必须包含两部分并写细：
可补充：
交付结构（固定）：
Top N 表格字段（固定）：
| 仓库 | 星标 | 仓库归属类型 | 项目介绍（是什么 + 推荐理由） | 其它信息补充 | 链接 |
|---|
"其它信息补充"建议内容：
迭代触发条件：
用户反馈"太泛/太窄/不够准/解释不够细"。
迭代动作：
100Top 10archived=falseIssue 池全生命周期管理（开发范式 v1 规划段）：记 issue 入池+关联检查、合并同源需求、讨论拆解（引导讲出真需求）、转成可开工 task 或滚动 plan、拆不动就 pending。复杂 plan 的框架计划正文流程已内置（原 plan-report 并入 references/plan-writing.md）。当用户说"记个 issue""新增/汇总 issue""拆 issue / 拆解
把用户的模糊诉求、粗糙 goal、handoff prompt 或任务想法收敛成 AI 可以自主执行且可验收的 goal。用于用户要求写 goal、优化 goal、制定交给 AI/subagent/Codex 执行的目标、明确 scope/non-goals/success criteria/verification/stop conditions，或需要把“今天做完、尽量优化、帮我研究并执行”等不清晰请求变成可执行任务契约时。
帮助梳理一份"框架计划报告"(项目 v1.0 计划、版本路线、阶段方案等)。通过"摸现实 → 定文档类型 → 搭骨架 → 填内容 → 统一结构 → 语言精修 → 自检" 7 步引导,产出"讲为什么做 / 做到什么程度算完 / 分几步走"的框架计划,而不是功能清单或技术方案。当用户说"写计划报告"、"项目计划"、"框架计划"、"v1.0 计划"、"版本路线"、"阶段方案"、"plan-report"、"/plan-report"时触发。
陪伴型 AI 人设生成与优化流程。当用户想给 Hermes Agent（或任意 AI 陪伴角色）做一个"有感情、聊久不掉、像真人"的人设时使用。通过"定调子 → 名字 → 外形 → 性格 → 背景 → 关系 → 说话节奏 → 生成 SOUL.md → 迭代"的结构化对话，从一句模糊想法（如"我想要个JK女友""年上男友""高冷御姐"）产出可直接贴进 Hermes SOUL.md 的第一人称人设文本。支持女友/男友/各种气质的陪伴角色，并让用户选择"一句一句发"还是"整段说"的输出风格。当用户说"做个人设/捏个AI女友男友/给Hermes弄个角色/优化人设/换个人设"时触发。
PRD + 可执行测试用例双文档一体化协作。与用户共同写并迭代。理解需求后自主读代码再写；故事驱动 + 分阶段单点确认；每个 PRD 产出 PRD-MD 与 测试用例-MD（给 AI 的事实源）+ 两份套模板的 review HTML（给人查阅，与 MD 严格 1:1）。触发：梳理/撰写/完善 PRD、需求文档、用户故事、验收标准、测试用例、测试基准、测试方案。
系统化学习材料生成器。给一个新领域/技术/概念，AI 自主调研、搭体系、产出 HTML 学习材料（含骨架/案例/工程化/争议+盲区）。当用户说"我要学 X / 帮我系统拆解 X / 我想吃透 X 这个领域 / 给我整理 X 的全貌 / 深度调研 X 给我系统讲讲 / 把 X 搞透"时触发。不适用于"X 行不行/为什么 Y"（用 long-research）、"X 有哪些好玩案例"（用 case-radar 给散点）、"把这堆素材整理成 HTML"（用 readable-output 处理已有素材）、文章写作（用 writing-assistant）、设计稿（用 design-exploration）。