| name | github-issue-briefing |
| description | 从 GitHub Issues 收集用户反馈并生成简报。抓取 higress-group/himarket 的 issues，按类型分类、去重（排除已处理的重复内容），生成包含趋势分析和优先级建议的简报。当用户想了解社区反馈、issue 概况、用户需求趋势时使用此 skill。 |
GitHub Issue 反馈简报
从 higress-group/himarket 仓库收集 GitHub Issues，整理为结构化简报，并提供优先级建议。
前置条件
gh CLI 已安装并完成认证（gh auth status 验证）- 对
higress-group/himarket 仓库有读取权限
工作流程
步骤 1：确定参数
使用 AskUserQuestion 询问用户（如未通过参数指定）：
- 时间范围：最近 7 天 / 30 天 / 90 天 / 自定义天数（默认 7 天）
- 是否包含 PR：默认仅 Issue，不含 PR
将用户选择的天数记为 $DAYS。
步骤 2：抓取数据
依次执行以下命令，收集 open 和 recently closed 的 issues：
gh issue list --repo higress-group/himarket \
--state open --limit 50 \
--json number,title,labels,createdAt,updatedAt,author,body,comments,url
gh issue list --repo higress-group/himarket \
--state closed --limit 50 \
--json number,title,labels,createdAt,closedAt,updatedAt,author,body,comments,url
步骤 3：过滤与分类
时间过滤： 只保留 createdAt 在最近 $DAYS 天内的 open issues 作为主要分析对象。
按类型分类（基于 labels 和内容关键词判断）：
| 类别 | 识别方式 |
|---|
| Bug Report | label 包含 bug，或标题/内容含 [Bug]、报错、异常、crash、error、fix |
| Feature Request | label 包含 enhancement/feature，或标题/内容含 [Feature]、建议、希望、支持 |
| Question | label 包含 question/help，或标题/内容含 如何、怎么、how to、? |
| Documentation | label 包含 documentation/docs |
| 其他 | 不符合以上分类的 |
步骤 4：去重处理
对 open issues 进行去重，标记以下情况：
- 已有关闭的同类 issue：在 closed issues 中搜索标题相似度高的（关键词重叠 ≥ 50%），标记为"历史已处理"
- open issues 之间重复：多个 open issue 描述同一问题，合并为一条并注明重复 issue 编号
- 判断依据：标题关键词匹配 + 问题描述核心内容对比
去重结果中标注：
[新] - 全新的反馈[重复-已关闭 #N] - 与已关闭的 #N 相似，可能需要确认是否复现[重复-open #N] - 与 open 的 #N 是同一问题
步骤 5：生成简报
按以下模板生成简报内容：
# HiMarket 社区 Issue 简报
> 统计周期：YYYY-MM-DD ~ YYYY-MM-DD
> 数据来源：https://github.com/higress-group/himarket/issues
> 生成时间：YYYY-MM-DD HH:MM
## 概览
| 指标 | 数量 |
|------|------|
| 周期内新增 open issues | N |
| 其中去重后有效 issues | N |
| Bug Report | N |
| Feature Request | N |
| Question / 咨询 | N |
| 其他 | N |
## 🔴 Bug 报告
### 高优先级
> 影响核心功能、有多人反馈、或影响面广的 bug
| # | 标题 | 报告者 | 日期 | 状态 |
|---|------|--------|------|------|
| #N | 标题 | @user | YYYY-MM-DD | [新] |
### 一般 Bug
| # | 标题 | 报告者 | 日期 | 状态 |
|---|------|--------|------|------|
| #N | 标题 | @user | YYYY-MM-DD | [新] |
## 💡 功能请求
### 高票需求
> 多人请求或与项目方向一致的需求
| # | 标题 | 报告者 | 日期 | 👍 | 状态 |
|---|------|--------|------|----|------|
| #N | 标题 | @user | YYYY-MM-DD | N | [新] |
### 其他需求
| # | 标题 | 报告者 | 日期 | 状态 |
|---|------|--------|------|------|
| #N | 标题 | @user | YYYY-MM-DD | [新] |
## ❓ 问题与咨询
| # | 标题 | 报告者 | 日期 | 已回复 |
|---|------|--------|------|--------|
| #N | 标题 | @user | YYYY-MM-DD | ✅/❌ |
## 🔁 去重记录
以下 issue 与历史已关闭或其他 open issue 存在重复：
| 当前 Issue | 重复类型 | 关联 Issue | 说明 |
|------------|----------|------------|------|
| #N | 已关闭重复 | #M | 简述相似点 |
| #N | open 重复 | #M | 简述相似点 |
## 📊 趋势分析
- **最活跃领域**：哪个模块/功能收到最多反馈
- **反馈趋势**：与前一周期相比，issue 数量是上升还是下降（如有数据）
- **社区活跃度**：新贡献者数量、issue 回复率
## 🎯 建议与优先级
### 建议立即处理
1. **#N - 标题**：原因说明（如影响核心流程、多人反馈）
### 建议近期规划
1. **#N - 标题**：原因说明（如社区呼声高、实现成本低）
### 建议长期关注
1. **#N - 标题**：原因说明（如方向性需求、需要架构调整）
### 可关闭/归档
1. **#N - 标题**：原因说明（如与已关闭 issue 重复、已过时）
步骤 6：输出
- 终端输出：直接在对话中展示完整简报
- 保存文件：将简报保存到
reports/issue-briefing-YYYY-MM-DD.md（相对项目根目录）
mkdir -p reports
告知用户文件保存路径。
优先级判断依据
按以下维度综合评估 issue 优先级：
| 维度 | 高优 | 低优 |
|---|
| 影响面 | 核心功能 / 大量用户 | 边缘功能 / 个例 |
| 反馈量 | 多人反馈相同问题 | 单人反馈 |
| 严重度 | 崩溃/数据丢失/安全 | UI 瑕疵/体验优化 |
| 实现成本 | 已有方案 / 改动小 | 需大规模重构 |
| 👍 反应数 | reactions 数量多 | 无反应 |
| 与路线图一致性 | 符合项目方向 | 偏离主线 |
注意事项
- Issue body 可能很长，分析时关注标题、前 500 字和 labels
gh 命令的 --json 输出可能很大，用 jq 提取必要字段- 若 issue 数量超过 200，提醒用户缩小时间范围
- 简报中的 issue 链接使用完整 URL 格式便于点击
- 去重判断宜宽松，宁可标记再让用户确认，不要遗漏
- 中英文 issue 都需要处理，分类时兼顾两种语言的关键词
