/github-weekly-trending

name: github-weekly-trending
description: 解读用户粘贴的 GitHub 每周 Trending 或开源项目榜单内容，基于用户提供的候选项目、项目 README、GitHub 项目页和 DeepWiki 生成适合公众号发布的 Markdown 文章，并输出到当前项目 markdown 目录。用于 GitHub 周榜解读、每周开源热点、热门开源项目分析、公众号开源项目推荐。

GitHub 每周热门项目解读

目标

读取用户粘贴的 GitHub Trending 周榜或开源项目榜单内容，筛选值得关注的开源项目，先建立可验证的项目事实卡，再生成适合公众号发布的中文 Markdown 文章。

工作流：

`用户粘贴榜单内容 -> README / GitHub 项目页 -> DeepWiki -> 项目事实卡 -> 公众号文章 -> 当前项目 markdown 目录 -> 事实校验`

触发条件

用户询问以下内容时使用本技能：

• GitHub 每周热门项目
• GitHub Trending 周榜解读
• 每周开源热点分析
• 热门开源项目介绍
• 公众号开源项目推荐文章
• 本周值得关注的开源项目

数据来源优先级

| 来源 | 用途 | 可靠性要求 | | --- | --- | --- | | 用户粘贴的榜单内容 | 获取候选项目、语言、本周热度、简介、用户关注点 | 必须记录用户提供内容的时间和可解析字段 | | 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/` 目录。如用户指定路径或文件名，按用户要求执行。

操作步骤

Step 1 - 解析用户粘贴的榜单内容

不要主动访问 `https://github.com/trending?since=weekly&spoken_language_code=` 获取榜单。以用户粘贴的内容作为候选项目输入。

内部记录：

• 处理时间和时区
• 输入来源、原始 URL、榜单类型、语言过滤或日期等来源元数据只用于事实校验，不写入最终文章，除非用户明确要求展示
• 若来源元数据缺失，只在内部事实卡中记为未知；最终文章不要写“用户未提供”等过程性表述

从用户粘贴内容中解析候选项目：

• 项目名称：`owner/repo`
• 项目简介
• 主要语言
• 当前 stars
• 用户粘贴内容中展示的本周新增 stars 或热度指标
• 仓库地址

当用户只提供 `owner/repo` 或类似 `owner / repo` 的项目名时，自动补齐：

• 标准项目名：去掉 `/` 两侧空格，规范为 `owner/repo`
• GitHub 仓库地址：`https://github.com/owner/repo`
• DeepWiki MCP `repoName` 参数：使用同一个标准项目名 `owner/repo`

示例：用户提供 `microsoft / markitdown` 时，记录项目名为 `microsoft/markitdown`，仓库地址为 `https://github.com/microsoft/markitdown`，并在 DeepWiki MCP 中使用 `repoName: "microsoft/markitdown"`。

注意：“本周新增 stars”或热度指标以用户粘贴内容为准，不等同于完整历史审计数据。

如果用户粘贴内容无法解析出足够候选项目，先向用户请求补充榜单内容。不要自行抓取 GitHub Trending 页面替代用户输入。

Step 2 - 筛选项目

默认选择 3 个主项目深度解读。用户指定数量时按用户要求执行。

优先选择：

• 周榜排名靠前
• 用户粘贴内容中本周新增 stars 或热度指标明显
• README 和文档信息充分
• 有清晰使用场景
• 对中文开发者或中国技术社区有参考价值

谨慎选择：

• 刚初始化、代码和文档很少的项目
• 没有 license 的项目
• README 只有愿景、缺少可验证功能的项目
• 主要信息来自营销页面而非代码或文档的项目

可以增加 2-5 个“简短观察”项目，但不要把每个项目都写成完整深度分析。

Step 3 - 获取 README 和项目基础信息

优先通过 GitHub 仓库页识别默认分支和 README 文件。

README fallback 顺序：

1. GitHub 仓库首页渲染 README 2. `https://raw.githubusercontent.com/{owner}/{repo}/{default_branch}/README.md` 3. `README.rst`、`README.adoc`、`README.txt` 4. 仓库中的 `docs/` 或 README 指向的官方文档

同时记录：

• License
• 最近 release 或 tag
• 最近提交活跃度
• open issues / pull requests 的大致状态
• 官方文档地址，若存在

Step 4 - 使用 DeepWiki 辅助理解

对每个主项目使用 DeepWiki MCP：

• `read_wiki_structure`：先查看可用文档结构
• `read_wiki_contents`：读取项目整体说明
• `ask_question`：针对架构、核心模块、实现机制、适用场景提问

建议提问：

• 这个项目的核心架构是什么？
• 主要模块如何协作？
• 它解决的核心技术问题是什么？
• 和常见同类方案相比，设计差异在哪里？
• 有哪些适合从代码或文档中验证的最佳实践？

DeepWiki 结论必须和 README、代码结构或官方文档交叉检查。不要仅凭 DeepWiki 写企业采用、商业化、融资、性能 benchmark。

Step 5 - 建立项目事实卡

写文章前，先为每个主项目建立事实卡。事实卡可以不出现在最终文章中，但文章必须基于事实卡生成。

每张事实卡包含：

• 仓库：`[owner/repo](https://github.com/owner/repo)`
• 官方一句话定位
• 主要语言
• stars 和用户粘贴内容中的本周新增 stars 或热度指标
• license
• 最近 release / 活跃度摘要
• 核心能力：3-5 条，必须来自 README 或官方文档
• 架构摘要：来自 DeepWiki，并和仓库资料交叉验证
• 适用场景：区分事实和推断
• 已验证来源链接
• 不确定信息：明确列出，不得在正文中扩写成事实

Step 6 - 生成文章

文章结构：

# 主标题：项目名或本周趋势 + 核心价值

> 副标题：一句话说明本周看点

## 导言

## 本周趋势总览

## 一图看懂本周热点

## 项目一：owner/repo

### 项目定位
### 核心能力
### 架构或工作流图
### 为什么会火
### 适用场景
### 局限与风险

## 项目二：owner/repo

...

## 其他值得关注的项目

## 总结

## 参考资料

导言只保留面向读者的文章信息：

• `处理时间：YYYY-MM-DD HH:MM:SS 时区`
• 紧接 1-2 段本周趋势判断，例如“本周榜单的核心信号很明确：...”。

导言不要写输入来源、榜单原始 URL、榜单日期范围、语言过滤条件等过程性字段，除非用户明确要求。

最终文章全文禁止出现以下过程性表述或同类变体：

• “用户粘贴内容显示”
• “用户粘贴”
• “用户未提供”
• “用户粘贴周榜”
• “本文的候选项目只来自... ”
• “没有主动抓取... ”
• “按原样记录”

需要表达热度来源时，改写为面向读者的自然表述，例如“本周榜单热度为 ...”“榜单数据显示 ...”“当前 GitHub 页面显示 ...”。

每个主项目必须包含：

• 项目定位：2-3 句话说明它解决什么问题，基于 README 或官方文档
• 核心能力：表格列出 3-5 个主要功能，只写可验证能力
• 架构或工作流图：优先使用 Mermaid，基于 README、官方文档、DeepWiki 交叉验证后的模块关系绘制；信息不足时省略
• 为什么会火：结合榜单热度表现、技术趋势、开发者痛点分析，并明确区分事实和推断
• 适用场景：给出 2-3 个具体场景；若是推断，使用“适合用于”，不要写成“已经用于”
• 局限与风险：项目成熟度、文档完整度、生态依赖、license 或运维风险

图表规则

用 Mermaid 或 SVG 增强可读性，但不要为了装饰强行加图。默认优先使用 Mermaid，因为 Markdown 可维护、便于公众号二次编辑。

建议包含：

• 1 张“本周热点总览”图：展示候选项目 -> 筛选维度 -> 主项目 -> 简短观察项目。
• 每个主项目最多 1 张架构或工作流图：展示输入、核心模块、输出、外部依赖。
• 复杂竞品对比可以用 Mermaid quadrantChart、flowchart 或简洁表格，不要重复表达同一信息。

Mermaid 使用规则：

• 使用 `flowchart LR` 或 `flowchart TD` 表达流程、架构、模块关系。
• 使用简短节点文本，避免长句挤压版面。
• 节点内容必须来自 README、官方文档、代码结构或 DeepWiki 交叉验证结果。
• 对推断关系使用节点或图标题标注“推断”，不要画成确定事实。

SVG 使用规则：

• 仅当用户要求可直接发布的视觉图，或 Mermaid 无法表达清楚时使用内联 SVG。
• SVG 必须简洁、可复制到 Markdown，不依赖外部图片资源。
• 不要使用复杂渐变、装饰性图形或无法在公众号编辑器稳定显示的效果。

示例 Mermaid：

flowchart LR
  Input[本周榜单] --> Filter[筛选: 热度 / 文档 / 场景]
  Filter --> Main[3 个主项目深度解读]
  Filter --> Brief[2-5 个简短观察]
  Main --> Verify[README / GitHub / DeepWiki 交叉验证]
  Verify --> Article[Markdown 文章]

以下模块仅在有可靠来源时添加：

• 真实采用案例
• 竞品性能对比
• 可运行代码示例
• 创始团队或背后公司动机

如果没有可靠公开来源，写“未找到可靠公开来源”，不要补写。

竞品对比规则

竞品对比只比较可验证维度：

• 官方定位
• 核心功能
• 主要语言
• 部署方式
• License
• GitHub 活跃度
• 生态成熟度的可观察指标，例如 release、插件、文档、社区讨论

不要写无来源支持的性能结论。不要使用“全面领先”“碾压”“业界最佳”等不可验证表达。

代码示例规则

优先引用 README 或官方文档中的最小示例。

分级处理：

• 已本地运行：说明运行环境和结果
• 未本地运行但来自官方文档：标注“基于官方文档示例整理”
• 自行整理的伪代码或概念示例：明确标注“示意代码”

不要为了满足格式强行给每个项目写代码示例。

写作风格

• 面向有基础技术认知的中文开发者
• 专业、直接、避免夸张营销语
• 短句为主，少用长从句
• 多解释“为什么值得关注”，少堆功能清单
• 标题使用 `##` 和 `###`，避免超过 3 级标题
• 表格保持简洁，列数不要过多
• 事实和推断分开表达

质量校验

提交前逐项检查：

• [ ] 记录了处理时间、时区和用户粘贴内容中的来源信息
• [ ] 未主动抓取 GitHub Trending 页面作为候选项目来源
• [ ] 所有仓库地址可访问
• [ ] stars、license、语言信息来自 GitHub 当前页面或用户粘贴内容，并区分来源
• [ ] README / 官方文档链接可访问
• [ ] DeepWiki 结论没有被单独用作商业采用或性能事实
• [ ] 公司采用案例、benchmark、融资、团队动机都有可靠来源；否则删除或标注未知
• [ ] 竞品对比只包含可验证维度
• [ ] 代码示例标注了来源和验证状态
• [ ] Mermaid 或 SVG 图表只表达已验证事实或明确标注的推断，节点文本简短可读
• [ ] Markdown 标题层级、表格、链接格式正确
• [ ] 输出文件位于当前项目 `markdown/` 目录，除非用户指定其他路径
• [ ] 全文默认 3000-6000 字；若超过，优先压缩项目数量和重复背景介绍

失败和不确定情况

• 如果用户没有粘贴榜单内容，向用户请求输入，不要自行抓取 Trending 页面。
• 如果用户粘贴内容缺少 stars、本周新增 stars、语言等字段，可以用 GitHub 仓库页补充当前字段；缺少