用途
github-activity 用于分析某个 GitHub 项目的近期活动，产出关于吞吐量、积压消耗速率和响应速度的简洁报告，并配有 matplotlib 图表。当用户调用 /github-activity 时使用该技能。
主要能力
- 抓取指定仓库在给定时间窗口内的 PR 与 issue 数据。
- 计算指标并生成图表，同时打印 JSON 摘要。
- 报告结构包括：TL;DR（2–3 条要点）、快照表格（Opened、Closed、Net、Open now、Median days to close、p90 days to close）、吞吐量图表及解读要点。
- 可选包含积压趋势（仅当有明显增长或下降趋势时）、最受关注的开放 issue（按 👍 反应排序，最多 3 条）以及后续建议（最多 3 条，仅在数据支持具体行动时给出）。
使用方式
- 解析目标仓库（owner/name）：优先使用用户传给 /github-activity 的参数；否则从当前目录的 origin remote 推断，命令为
gh repo view --json nameWithOwner -q .nameWithOwner；若都不行则询问用户。 - 解析时间窗口：默认最近 6 个月，可通过
--months N支持用户表述（如“last 3 months”“this year”）。 - 查询 Emacs 前景色（若本会话已知则复用）：
emacsclient --eval '(face-foreground (quote default))'，返回类似 "#eeffff" 的十六进制值，作为--fg传入。 - 运行分析器：
uv run --with matplotlib "$CLAUDE_PLUGIN_ROOT/skills/github-activity/analyze.py" \
--repo owner/name --months 6 --fg "#eeffff" --outdir /tmp
若 $CLAUDE_PLUGIN_ROOT 未设置，使用技能自身目录路径。
5. 读取 stdout 打印的 JSON，撰写报告，并将返回的每个图表路径作为 markdown 图片单独一行嵌入，例如：
报告撰写要点
- 结论先行：先给结论，再给证据，每张图表紧邻解读它的文字。
- TL;DR 置于最顶部，2–3 条要点，给出项目活跃/健康程度的判断、证明它的关键数字以及含义。
- 快照表格：指标为行，PRs 与 Issues 为两列，数值列右对齐；时间窗口写在表格上方的说明行，不作为表格行。最多加粗一两个单元格（通常是令人担忧的值），不要例行加粗，不要同时加粗好与坏的值，不使用颜色或 emoji。
- 吞吐量图表后紧跟 1–2 条解读要点，关注：接收量是否稳定或激增、关闭是否跟得上（净趋势）、PR 是否比 issue 更健康、稳定滴流还是集中清理（参考 busiest_weeks）。
- 积压部分仅在能提供信号（明显增长/下降趋势）时包含，否则跳过。
- 最受关注的开放 issue 为可选，取 top_open_issues 中按 👍 反应排序的前几条，最多 3 条，格式为
[#N](url) — title (👍 R, C comments)；列表为空则跳过。 - 后续建议为可选，最多 3 条，仅在数据支持具体行动时给出，须引用实际条目（如 oldest_open_issues / oldest_open_prs / top_open_issues 中的链接），优先高需求项而非仅陈旧项；项目健康时完全跳过，不要写通用填充内容。
- 优先使用具体数字而非形容词；不要倾倒原始 JSON；不要复述每个周值，概括形态即可；不要在下方逐字重复 TL;DR。
- 报告中每次提及 PR 或 issue 都要用分析器提供的 url 渲染为 markdown 链接
[#N](url)，不要留下裸 #N。
规则与限制
- 图表遵循 matplotlib 技能约定：透明背景、Emacs 前景色用于文字/边框/刻度、深色不透明图例框（facecolor='#1a1a2e'，labelcolor=FG）、隐藏上/右边框、细微网格；analyze.py 已处理这些，需传入真实的
--fg。 - 文件名带时间戳（脚本处理），绝不覆盖固定名称。
- 最后（当前）一周是不完整的，脚本会为其加阴影并标记
partial: true，不要将其与完整周直接对比，引用时说明“in-progress”。 - 若仓库在窗口内活动极少（PR/issue 很少），应如实说明并跳过会产生噪声的图表。
- 需要已认证的 gh 与 uv。若 gh 出现认证错误或仓库缺失，应直接呈现该错误而非猜测。