メニュー
解读用户粘贴的 GitHub 每周 Trending 或开源项目榜单内容，基于用户提供的候选项目、项目 README、GitHub 项目页和 DeepWiki 生成适合公众号发布的 Markdown 文章，并输出到当前项目 markdown 目录。用于 GitHub 周榜解读、每周开源热点、热门开源项目分析、公众号开源项目推荐。
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/digoal/blog --skill github-weekly-trendingコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
深度思考分析解答任何领域的棘手问题。当用户提出的问题具备以下任一特征时必须触发此 skill：(1) 涉及多个领域（如"AI 对就业的影响"涉及技术、经济、社会学、哲学）；(2) 涉及争议性观点或对立立场（如"比特币是不是泡沫"）；(3) 需要严谨论证、权威数据支撑、第一性原理推理（如"为什么中国新能源车销量这么猛"）；(4) 用户明确要求深度分析、多视角交叉验证、给出适用边界和证伪/证明手段。即便用户没有点名"深度分析"，只要问题本身具备跨学科、权衡性、需多专家视角的特征，都应触发本 skill，而不是给出浅尝辄止的单线回答。本 skill 不适用于闲聊、事实查询、明确要求简短回复的场景。
对任何领域的棘手问题进行深度思考分析,先识别问题所属领域并按需调度多位领域专家并行作答, 之后由事实核查员和红队做克制的事实审计与对抗性反驳,最后整合为面向小白的第一人称终稿。 适用:用户抛出一个跨领域/有深度的真实问题,希望听到多位专家的视角、看到观点的边界与证伪条件, 并得到一气呵成、通俗有据的最终文章。不适用:简单事实查询、纯情绪吐槽、不要求证据的随口一问。
召唤多领域专家智能体，对任何棘手、跨学科、有争议或开放性的问题做并行深度分析，再经过一轮克制的事实核查与红队反驳，最后由一个"干净大脑"的终稿撰写者把所有内容无缝重写成一篇第一人称、面向小白、图文并茂、有人味、留有证伪空间的深度长文。触发条件：用户提出任何值得深挖的复杂问题，尤其是跨领域、需要多方视角、需要权威数据支撑的问题；提到"帮我深度分析"、"多专家视角"、"专家怎么看"、"这个问题涉及哪些领域"、"帮我搞清楚 XX 到底是怎么回事"、"用第一性原理分析一下"、"这个观点站得住脚吗"、"帮我论证一下"、"multi-expert-analyzer2"，或者只是抛出一个开放性问题如"为什么 XX 会发生"、"如何看待 XX 现象"、"XX 到底靠不靠谱"。即使用户没有明确说"专家"或"深度分析"这几个字，只要问题本身跨越多个专业领域、需要审慎论证而非泛泛而谈，也应使用本 skill。本 skill 与仓库中其他类似名称的技能（如 multi-expert-analyzer、multi-expert-analyzer1）相互独立，不共享模板或输出结构，请完全按照本文件的流程执行。
SOC 職業分類に基づく
SKILL.md を表示中
| name | github-weekly-trending |
| description | 解读用户粘贴的 GitHub 每周 Trending 或开源项目榜单内容，基于用户提供的候选项目、项目 README、GitHub 项目页和 DeepWiki 生成适合公众号发布的 Markdown 文章，并输出到当前项目 markdown 目录。用于 GitHub 周榜解读、每周开源热点、热门开源项目分析、公众号开源项目推荐。 |
读取用户粘贴的 GitHub Trending 周榜或开源项目榜单内容，筛选值得关注的开源项目，先建立可验证的项目事实卡，再生成适合公众号发布的中文 Markdown 文章。
工作流：
用户粘贴榜单内容 -> README / GitHub 项目页 -> DeepWiki -> 项目事实卡 -> 公众号文章 -> 当前项目 markdown 目录 -> 事实校验
用户询问以下内容时使用本技能：
| 来源 | 用途 | 可靠性要求 |
|---|---|---|
| 用户粘贴的榜单内容 | 获取候选项目、语言、本周热度、简介、用户关注点 | 必须记录用户提供内容的时间和可解析字段 |
| GitHub 仓库页 | stars、license、默认分支、release、issue、贡献活跃度 | 以页面当前展示为准 |
| README / 官方文档 | 项目定位、核心能力、安装方式、官方示例 | 项目功能事实的主要来源 |
| DeepWiki MCP | 架构、代码组织、模块关系、实现机制 | 用于辅助理解，不单独作为商业采用或性能结论来源 |
| 官方博客 / 官方案例 / release note | 采用案例、路线图、重要变更 | 有明确链接才可引用 |
禁止把未验证信息写成事实。尤其不要编造公司采用案例、benchmark 结果、创始团队动机、融资信息、客户信息、性能优劣。
默认输出 Markdown 文件：
markdown/github-weekly-trending-YYYY-WW.md
其中 YYYY 为年份，WW 为 ISO 周数，例如 2026-W15。
在当前项目根目录下创建或复用 markdown/ 目录。如用户指定路径或文件名，按用户要求执行。
不要主动访问 https://github.com/trending?since=weekly&spoken_language_code= 获取榜单。以用户粘贴的内容作为候选项目输入。
内部记录：
从用户粘贴内容中解析候选项目：
owner/repo当用户只提供 owner/repo 或类似 owner / repo 的项目名时，自动补齐：
/ 两侧空格，规范为 owner/repohttps://github.com/owner/reporepoName 参数：使用同一个标准项目名 owner/repo示例：用户提供 microsoft / markitdown 时，记录项目名为 microsoft/markitdown，仓库地址为 https://github.com/microsoft/markitdown，并在 DeepWiki MCP 中使用 repoName: "microsoft/markitdown"。
注意：“本周新增 stars”或热度指标以用户粘贴内容为准，不等同于完整历史审计数据。
如果用户粘贴内容无法解析出足够候选项目，先向用户请求补充榜单内容。不要自行抓取 GitHub Trending 页面替代用户输入。
默认选择 3 个主项目深度解读。用户指定数量时按用户要求执行。
优先选择：
谨慎选择：
可以增加 2-5 个“简短观察”项目，但不要把每个项目都写成完整深度分析。
优先通过 GitHub 仓库页识别默认分支和 README 文件。
README fallback 顺序：
https://raw.githubusercontent.com/{owner}/{repo}/{default_branch}/README.mdREADME.rst、README.adoc、README.txtdocs/ 或 README 指向的官方文档同时记录：
对每个主项目使用 DeepWiki MCP：
read_wiki_structure：先查看可用文档结构read_wiki_contents：读取项目整体说明ask_question：针对架构、核心模块、实现机制、适用场景提问建议提问：
DeepWiki 结论必须和 README、代码结构或官方文档交叉检查。不要仅凭 DeepWiki 写企业采用、商业化、融资、性能 benchmark。
写文章前，先为每个主项目建立事实卡。事实卡可以不出现在最终文章中，但文章必须基于事实卡生成。
每张事实卡包含：
[owner/repo](https://github.com/owner/repo)文章结构：
# 主标题：项目名或本周趋势 + 核心价值
> 副标题：一句话说明本周看点
## 导言
## 本周趋势总览
## 一图看懂本周热点
## 项目一：owner/repo
### 项目定位
### 核心能力
### 架构或工作流图
### 为什么会火
### 适用场景
### 局限与风险
## 项目二：owner/repo
...
## 其他值得关注的项目
## 总结
## 参考资料
导言只保留面向读者的文章信息：
处理时间：YYYY-MM-DD HH:MM:SS 时区导言不要写输入来源、榜单原始 URL、榜单日期范围、语言过滤条件等过程性字段，除非用户明确要求。
最终文章全文禁止出现以下过程性表述或同类变体：
需要表达热度来源时，改写为面向读者的自然表述，例如“本周榜单热度为 ...”“榜单数据显示 ...”“当前 GitHub 页面显示 ...”。
每个主项目必须包含：
用 Mermaid 或 SVG 增强可读性，但不要为了装饰强行加图。默认优先使用 Mermaid，因为 Markdown 可维护、便于公众号二次编辑。
建议包含：
Mermaid 使用规则：
flowchart LR 或 flowchart TD 表达流程、架构、模块关系。SVG 使用规则：
示例 Mermaid：
flowchart LR
Input[本周榜单] --> Filter[筛选: 热度 / 文档 / 场景]
Filter --> Main[3 个主项目深度解读]
Filter --> Brief[2-5 个简短观察]
Main --> Verify[README / GitHub / DeepWiki 交叉验证]
Verify --> Article[Markdown 文章]
以下模块仅在有可靠来源时添加：
如果没有可靠公开来源，写“未找到可靠公开来源”，不要补写。
竞品对比只比较可验证维度：
不要写无来源支持的性能结论。不要使用“全面领先”“碾压”“业界最佳”等不可验证表达。
优先引用 README 或官方文档中的最小示例。
分级处理：
不要为了满足格式强行给每个项目写代码示例。
## 和 ###，避免超过 3 级标题提交前逐项检查：
markdown/ 目录，除非用户指定其他路径