解读用户粘贴的 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/ 目录，除非用户指定其他路径