메뉴
解读用户粘贴的 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명령은 한 줄로 유지됩니다. 복사하기 전에 가로로 스크롤해 전체 내용을 확인하세요.
로컬 사본을 원하시나요? 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/ 目录，除非用户指定其他路径