用途：面向创始人或开发者关系（DevRel）人员，从仓库的 GitHub Discussions 中找出反复出现的困惑点，按紧急程度排序，并起草实际的文档修复与内容选题。它不逐条总结讨论，而是按主题聚类、分类、打分，输出可立即执行的结构化行动项。
主要能力：读取工作目录中的 discussions_raw.json，解析 meta 与 discussions 数组；检查 low_signal 字段，若为 true 则输出低信号警告并停止分析。将讨论按底层概念聚类，每个聚类至少 2 条讨论才算模式，记录 cluster_label、discussion_numbers、逐字引用的 representative_quote 和 primary_source_url。为每个聚类分类为 docs_gap、content_opportunity 或 both。按频率、互动、时效、未回答加分和清晰度加权计算 priority_score（四舍五入为整数）。每节最多输出 7 项，按分数降序排列。
使用方式：若 discussions_raw.json 不存在，需先运行 python scripts/fetch_discussions.py --repo owner/repo --output discussions_raw.json，然后停止等待。分析前会播报讨论数量、仓库和模式。输出前读取 references/scoring-guide.md 与 references/output-format.md。报告顶部包含 Run Summary（仓库、分析日期、分析讨论数、历史天数、聚类数、模式）。最终将完整 Markdown 报告写入 devrel-backlog.md，并播报文档缺口与内容机会数量。
输出规则：每项必须包含 source_url 和逐字 evidence_quote；文档缺口需写出可直接复制的 Draft FAQ / Doc Update Markdown 片段；内容机会需给出推荐角度与 3-4 点大纲；若聚类中多数讨论未回答，必须加 URGENT 徽章。禁止使用 delve、testament、comprehensive、leverage、seamless、in conclusion、it is worth noting 等词，不得声称任何内容表现结果（如 SEO 排名、互动率）。若某节少于 3 项，需提示可放宽筛选条件。
适用场景：仓库社区讨论中反复出现配置、认证、使用方式等困惑，需要快速定位文档缺口并规划教程、博客或 FAQ 选题时。
限制：依赖预先抓取的 discussions_raw.json；低信号（合格讨论少于 5 条）时不进行分析；聚类需至少 2 条讨论；评分公式与输出格式依赖 references 目录下的参考文件；具体抓取脚本参数、评分细节和输出模板以资料中提及的参考文件为准，暂未提供完整内容。