/github-star-manager

name: github-star-manager
homepage: https://github.com/cat-xierluo/legal-skills
author: 杨卫薪律师（微信ywxlaw）
version: "0.8.7"
license: MIT
description: GitHub Star 项目管理工具，支持从内容自动发现并 Star 项目，同步追踪更新，生成可视化 Dashboard

GitHub Star 管理器 (GitHub Star Manager)

简介

专注于 GitHub Star 项目的更新追踪与同步工具。自动检测您 Star 的项目是否有新版本、新 Release、重要 Commit 变化，并生成结构化的更新报告。

**核心特色**: 提供 HTML 可视化 Dashboard，快速浏览所有 Star 项目。

何时使用

本技能在以下场景下触发：

• 用户需要**从内容中自动发现并 Star GitHub 项目**
• 用户需要**追踪 GitHub Star 项目的更新**
• 用户需要**监控依赖库的版本发布**
• 用户需要**查看项目活跃度和健康度**
• 用户需要**管理大量 starred 仓库**
• 用户需要**快速浏览和筛选 Star 项目**
• 用户需要**生成项目的可视化报告**

模块说明

本技能包含两个模块：

| 模块 | 触发方式 | 功能 | |------|----------|------| | **对话模块** | 对话触发 | 从内容提取项目并 Star | | **脚本模块** | 命令行/定时任务 | 同步、Dashboard、追踪、批量管理 |

核心功能

1. 对话模块：自动发现并 Star

从各种内容来源中自动提取 GitHub 仓库引用，并在你的 GitHub 账户上 star 它们。

**支持的触发方式：**

• "分析这篇文章并 star 里面的项目"
• "从这张截图里找 GitHub 项目并 star"
• "Star [内容] 中提到的所有 GitHub 项目"

**工作流程：**

1. **内容提取与上下文分析**

• 文字/URL：使用 WebFetch 获取文章内容，解析 GitHub URL
• 截图/图片：使用图片分析 MCP 提取文字并识别项目引用
• 评论区/回复也是提取源：作者在评论区亲授的 `owner/repo` 全称是最高优先级证据，优先于一切启发式消歧

2. **仓库发现与智能匹配**

• **模糊口述线索推理（内容里**没有** GitHub URL、只有用户口述的零散线索时）**：当用户以自然语言描述项目（如"ascll simulation art console"、"8 月 24 号左右更新的"、"ID 可能含 skent"），GitHub 站内搜索通常 0 命中（关键词含 OCR 噪声、用户名被拼写截断、无完整 owner/repo）。走三步推理锚定唯一候选：

1. **拆解线索为可枚举字段**：① 主题关键词（项目做什么——本例"ascii simulation art console"，可拆 ascii + simulation + art + console）；② 创建/更新时间窗口（"8 月 24 号左右"→ `created:2026-08-20..2026-08-28`）；③ 用户名/owner 片段（"skent"→ 搜索 `skent` 找到候选 owner `skent`、`Skentir`、`skent259` 等）；④ 其它旁证（"近期更新"、"MIT 协议"等可加 `--sort=updated`、license filter） 2. **GitHub Search API 多条件缩范围**：用 `gh api search/repositories?q=<关键词>+created:<date-range>` 拿到 ≤30 条候选。若零命中放宽日期±3 天再试；若仍零命中改用关键词子集（先只搜 `simulation + art`）让噪声筛过滤掉，再逐步加严。**单字段多关键词 OR / 多字段 AND 的组合顺序决定召回：先粗后细**（先 OR 让候选宽一点，再用 AND 紧），避免一开始就用 `ascii+simulation+art+console` 拼长串触发 0 命中 3. **候选消歧到唯一**：在候选列表上跑与"同名候选消歧"相同的证据链——**亲授全称 > 语义锚定 > 衍生排除 > 创建时间匹配 > Star 数量级（仅参考）**。本场景无亲授/截图，所以重点是：① `created_at` 落在用户口述的时间窗口内（误差 ±3 天）；② `description` 含线索关键词（"ascii"/"simulation"/"art"/"console"任一）；③ owner 名含候选用户片段（`Skent*`、`skent*` 任一前缀）。三条都满足即可定为唯一，置信度反映给用户

• **使用约束**：① 不要把"用户名片段"当成"完整 owner"——它只用于 owner 候选枚举，不参与最终判定；② 时间窗口比关键词更重要——近期项目关键词噪声大，时间是更稳的锚；③ 候选命中但 `created_at` 偏离用户口述超 ±5 天，要么放宽/收严窗口与用户核对，要么放弃。实测反例：直接搜 `ascii simulation art console` 在 8 月 24 号前后日期范围内 GitHub 站内搜索 0 命中，但按"主题 + 时间窗口 + 用户片段"三段拆解后 API 检索唯一命中——这就是本规则的必要性证据
• 直接匹配：内容中找到的完整 GitHub URL
• 半截 URL 补全：owner 确定而 name 截断（如 `mcncarl/jianyi…`）时，列该 owner 名下仓库（`gh api users/OWNER/repos`），按名称前缀 + description 语义匹配补全（实测：jianyi…→jianying-headless，yichen…→yichen-skills）
• owner 拼写修正：截图直读的 owner 404 时先怀疑 OCR 误读而非仓库不存在——按 repo 名搜索锁定真身，用星数量级与截图侧栏数字互证（实测：截图误读 `webadderalorg`→真身 `webadderallorg/Recordly`，30.9k⭐ 与侧栏 20.1k 同量级确认）
• 社交账号名 ↔ GitHub owner 互证：博主昵称与 owner 名常有派生关系，可作中优先级佐证（实测：抖音"耳朵"→erduo1998-cell、"姚老师"→yaojingang、"文森特"→Vincentwei1021），但不单独定论
• 改名仓库识别：内容中的旧名 404 时，查 `gh api repos/旧名` 是否返回 301/新 full_name——GitHub API 对改名仓库自动重定向，返回的 full_name 即新名；若新仓库已在库则视为同一项目跳过（实测：erduo-hyperframes-broll → erduo-broll-loop-engineering）
• 按名称搜索：当只有项目名时使用 `gh search repos`
• 同名候选消歧（社交内容常只给项目名，同名候选多为 fork/搬运/衍生项目）。**证据优先级：来源亲授全称 > 语义比对 > 排除规则 > 版本轨迹；Star 数量级只是参考信号，永不单独定论**——实测反例：taste-skill 同名的 Leonxlnx 版 8.9 万⭐比目标 senlindesign 版（366⭐）高两个数量级，靠语义（"Reverse-engineer any website's design taste" 与帖内 tastelab 页面吻合）+ 作者评论区亲授全称才锁定 senlindesign 版：

1. **来源亲授证据**：作者/评论区给出的 owner/repo 全称直接采信，跳过其余消歧 2. **语义锚定**：不要只比对项目名文字——把内容展示的功能场景与各候选仓库 description 逐一比对（如"单色印刷审美"帖 ↔ "One-ink editorial print"；"英文内嵌字幕视频截图" ↔ "保留视频内嵌字幕，精确取帧生成长图"；"逆向网站设计品味" ↔ "reverse-engineer any website's design taste"） 3. **衍生仓库排除**：name 带 `-lite`/`-editor`/`-skills` 等后缀、description 自述"基于上游/fork 适配/补原仓库不做的半边"的直接排除 4. **版本交叉核对**：内容提到版本号（如"升级到 2.0"）时，查候选仓库 releases/tags，原仓库应存在对应版本轨迹 5. **Star 数量级（仅参考）**：多数情况下原仓库比 fork/搬运高 1–2 个数量级（mono-color-skill 3250 vs 0~3；native-subtitle-quote-image 795 vs 5/7），但同名高星同类项目随时可能推翻它——高星候选与亲授/语义证据冲突时，以后者为准

• 候选仍无法唯一确定时：不凭猜测 star，列出候选与判断依据请用户确认
• 上下文相关性验证：检查 topics、description、技术栈是否匹配
• **截图/视频帧输入专用**：OCR 直读的 owner/repo 404 时**不**判定"找不到"，按 [`references/owner-repo-disambiguation.md`](references/owner-repo-disambiguation.md) 的 7 条视觉消歧规则重新尝试（字母形态漂移、整 owner 错读、README 迁移公告、截图只露目录名、跨项目互引等）

3. **检查是否已 Star**

   gh api user/starred/owner/repo 2>/dev/null

HTTP 204 = 已 star，404 = 未 star。

4. **Star 仓库** `gh repo star` 子命令在部分 gh 版本不存在（如 2.83.0 报 unknown command），统一用 API，幂等且跨版本可用：

   gh api -X PUT user/starred/owner/repo

成功后用第 3 步的 GET 回读，204 才算完成，不要以 PUT 退出码为准。 批量任务（一次内容提取出多个仓库）时循环执行"查重→star→回读"，单个仓库失败不阻断其余，最后按第 5 步汇总成功/跳过/失败。

5. **生成报告**

• 新 star 的仓库列表
• 已 star 的仓库（跳过）
• 需人工确认的仓库

2. 更新追踪

• **版本检测**：检测项目的新 Release 和 Tag
• **活跃度监控**：追踪最近的 Commit 活跃度
• **变更摘要**：使用 AI 总结版本变更内容

4. 智能分析

• **项目摘要**：自动生成项目核心功能说明
• **价值评估**：分析项目与您的关注领域匹配度（高/中/低）
• **健康度指标**：项目维护状态、Stars 增长趋势

5. HTML 可视化 Dashboard

• **信息密集卡片**：一屏展示更多项目
• **颜色编码状态**：活跃/近期更新/长期未更一目了然
• **筛选与搜索**：按状态、价值、关键词过滤
• **展开详情**：点击卡片查看更多信息

依赖

系统依赖

| 依赖 | 安装方式 | |------|----------| | Python 3.9+ | macOS: `brew install python3`<br>Linux: `sudo apt-get install python3` |

Python 包

| 包名 | 用途 | 安装命令 | |------|------|----------| | `requests` | HTTP 请求，调用 GitHub API | `pip install requests` | | `pyyaml` | 分类配置解析（必需） | `pip install pyyaml` | | `python-dotenv` | 从 .env 文件加载配置 | `pip install python-dotenv` | | `openai` | AI 摘要生成（可选，未安装时自动降级） | `pip install openai` |

依赖包文件

pip install -r assets/requirements.txt

使用方法

1. 环境准备

方式 1：使用 .env 配置文件（推荐）

# 1. 复制示例配置文件
cp assets/.env.example assets/.env

# 2. 编辑 .env 文件，填入你的 API 密钥
# GITHUB_PAT=ghp_xxxxxxxxxxxxxxxxx
# OPENAI_API_KEY=sk-xxxxxxxxxxxx

# 3. 安装依赖
pip install -r assets/requirements.txt

方式 2：环境变量

# 直接设置环境变量
export GITHUB_PAT="你的_github_pat_token"
export OPENAI_API_KEY="你的_openai_api_key"

#