github-star-manager

GitHub Star Manager

Introduction

An update tracking and synchronization tool focused on GitHub starred projects. Automatically detects whether projects you have starred have new versions, new releases, or important commit changes, and generates structured update reports.

Core Features: Provides an HTML visual Dashboard to quickly browse all starred projects.

When to Use

This skill is triggered in the following scenarios:

The user needs toautomatically discover and star GitHub projects from content
The user needs totrack updates to GitHub starred projects
The user needs tomonitor version releases of dependency libraries
The user needs toview project activity and health
The user needs tomanage a large number of starred repositories
The user needs toquickly browse and filter starred projects
The user needs togenerate visual reports for projects

Module Description

This skill contains two modules:

Module	Trigger Method	Function
Conversation Module	Conversation Trigger	Extract projects from content and star them
Script Module	Command Line/Scheduled Task	Sync, Dashboard, Tracking, Batch Management

Core Features

1. Conversation Module: Automatic Discovery and Starring

Automatically extracts GitHub repository references from various content sources and stars them on your GitHub account.

Supported Trigger Methods:

"Analyze this article and star the projects in it"
"Find GitHub projects from this screenshot and star them"
"Star all GitHub projects mentioned in [content]"

Workflow:

Content Extraction and Context Analysis
- Text/URL: Use WebFetch to obtain article content and parse GitHub URLs
- Screenshot/Image: Use image analysis MCP to extract text and identify project references
- Comments/replies are also extraction sources: the owner/repo full name personally provided by the author in the comments is the highest-priority evidence, taking precedence over all heuristic disambiguation
Repository Discovery and Intelligent Matching
- Fuzzy verbal clue inference (when the content hasno** GitHub URL and only scattered clues verbally described by the user)**]: When the user describes a project in natural language (such as "ascll simulation art console", "updated around August 24", "ID may contain skent"), GitHub on-site search usually returns 0 hits (keywords contain OCR noise, usernames are truncated by spelling errors, no complete owner/repo). Follow three steps of reasoning to anchor the unique candidate:
  1. Decompose clues into enumerable fields: ① Topic keywords (what the project does—in this example "ascii simulation art console", which can be split into ascii + simulation + art + console); ② Creation/update time window ("around August 24" → created:2026-08-20..2026-08-28); ③ Username/owner fragment ("skent" → search skent to find candidate owner skent、Skentir、skent259 , etc.); ④ Other corroborating evidence ("recently updated", "MIT license", etc. can be added --sort=updated、license filter）
  2. GitHub Search API multi-condition narrowing: use gh api search/repositories?q=<关键词>+created:<date-range> to get ≤30 candidates. If zero hits, relax the date by ±3 days and try again; if still zero hits, switch to a keyword subset (first search only simulation + art) and let the noise filter remove them, then gradually tighten.The combination order of single-field multi-keyword OR / multi-field AND determines recall: coarse first, then fine(first use OR to make candidates broader, then use AND to tighten), avoiding starting with ascii+simulation+art+console concatenated into a long string that triggers 0 hits
  3. Disambiguate candidates to a unique one: run the same evidence chain as "same-name candidate disambiguation" on the candidate list—personally taught full name > semantic anchoring > derivative exclusion > creation time match > Star order of magnitude (for reference only). In this scenario there is no personally taught/screenshot evidence, so the focus is: ① created_at falls within the time window stated by the user (error ±3 days); ② description contains clue keywords (any of "ascii"/"simulation"/"art"/"console"); ③ the owner name contains the candidate user fragment (Skent*、skent* any prefix). If all three are satisfied, it can be determined as unique, and the confidence is reflected to the user
  - Usage constraints: ① Do not treat the "username fragment" as the "full owner"—it is only used for owner candidate enumeration and does not participate in the final determination; ② The time window is more important than keywords—recent project keywords are noisy, and time is a more stable anchor; ③ If a candidate hits but created_at deviates from the user's statement by more than ±5 days, either relax/tighten the window and verify with the user, or give up. Actual counterexample: directly searching ascii simulation art console within the date range around August 24 yielded 0 hits in GitHub site search, but after breaking it down into three parts—"topic + time window + user fragment"—the API search uniquely hit—this is the necessity evidence for this rule
- Direct match: a complete GitHub URL found in the content
- Partial URL completion: when the owner is determined but the name is truncated (e.g. mcncarl/jianyi…), list repositories under that owner (gh api users/OWNER/repos), and complete by name prefix + description semantic matching (actual test: jianyi…→jianying-headless, yichen…→yichen-skills)
- Owner spelling correction: when the owner read directly from a screenshot returns 404, first suspect OCR misreading rather than the repository not existing—search by repo name to lock onto the real one, and cross-verify using the star order of magnitude and the number in the screenshot sidebar (actual test: screenshot misread webadderalorg→real identity webadderallorg/Recordly, 30.9k⭐ and the sidebar's 20.1k are of the same order of magnitude, confirming it)
- Social account name ↔ GitHub owner cross-verification: a blogger's nickname often has a derivative relationship with the owner name and can serve as medium-priority corroborating evidence (actual test: Douyin "耳朵"→erduo1998-cell, "姚老师"→yaojingang, "文森特"→Vincentwei1021), but it does not determine the conclusion on its own
- Renamed repository identification: when the old name in the content returns 404, check whether gh api repos/旧名 returns 301/new full_name—the GitHub API automatically redirects renamed repositories, and the returned full_name is the new name; if the new repository is already in the library, treat it as the same project and skip it (actual test: erduo-hyperframes-broll → erduo-broll-loop-engineering)
- Search by name: when only the project name is available, use gh search repos
- Same-name candidate disambiguation (social content often gives only the project name, and same-name candidates are mostly fork/repost/derivative projects).Evidence priority: full name given directly by the source > semantic comparison > exclusion rules > version trail; the order of magnitude of Star count is only a reference signal and never conclusive on its own——A real counterexample: the Leonxlnx version of taste-skill with the same name has 89k ⭐, two orders of magnitude higher than the target senlindesign version (366⭐). Only by semantics ("Reverse-engineer any website's design taste" matches the tastelab page in the post) + the full name given directly by the author in the comments was the senlindesign version pinned down:
  1. Evidence given directly by the source: the full owner/repo name given by the author/in the comments is taken directly, skipping the remaining disambiguation
  2. Semantic anchoring: do not compare only the project name text—compare the functional scenarios shown in the content with the description of each candidate repository one by one (e.g. the "single-color print aesthetic" post ↔ "One-ink editorial print"; "screenshot of a video with embedded English subtitles" ↔ "preserve the video's embedded subtitles, precisely capture frames to generate a long image"; "reverse-engineer website design taste" ↔ "reverse-engineer any website's design taste")
  3. Derivative repository exclusion: directly exclude those whose name has -lite/-editor/-skills and other suffixes, or whose description describes itself as "based on upstream/fork adapted/covers the half the original repo doesn't do"
  4. Version cross-check: when the content mentions a version number (e.g. "upgraded to 2.0"), check the candidate repository's releases/tags; the original repository should have a corresponding version trail
  5. Star count order of magnitude (reference only): in most cases the original repository is 1–2 orders of magnitude higher than forks/reposts (mono-color-skill 3250 vs 0~3; native-subtitle-quote-image 795 vs 5/7), but a same-name high-star similar project can overturn this at any time—when a high-star candidate conflicts with directly-given/semantic evidence, the latter prevails
- When candidates still cannot be uniquely determined: do not guess the star, list the candidates and the basis for judgment for the user to confirm
- Context relevance verification: check whether topics, description, and tech stack match
Check whether already Starred
```
gh api user/starred/owner/repo 2>/dev/null
```
HTTP 204 = already starred, 404 = not starred.
Star repository gh repo star subcommand does not exist in some gh versions (e.g. 2.83.0 reports unknown command); use the API uniformly, which is idempotent and available across versions:
```
gh api -X PUT user/starred/owner/repo
```
After success, use the GET from step 3 to read back; only 204 counts as complete, do not rely on the PUT exit code. For batch tasks (multiple repositories extracted from one piece of content), loop through "check duplicate→star→read back"; a single repository failure does not block the rest, and finally summarize success/skipped/failure per step 5.
Generate report
- List of newly starred repositories
- Already starred repositories (skipped)
- Repositories requiring manual confirmation

2. Update tracking

Version detection: detect the project's new Releases and Tags
Activity monitoring: track recent Commit activity
Change summary: use AI to summarize version changes

4. Intelligent analysis

Project summary: automatically generate a description of the project's core functionality
Value assessment: analyze how well the project matches your areas of interest (high/medium/low)
Health metrics: project maintenance status, Stars growth trend

5. HTML visualization Dashboard

Information-dense cards: Show more items on one screen
Color-coded status: Active/recently updated/long inactive at a glance
Filter and search: Filter by status, value, keyword
Expand details: Click a card to view more information

Dependencies

System dependencies

Dependency	Installation method
Python 3.8+	macOS: `brew install python3`Linux: `sudo apt-get install python3`

Python packages

Package name	Purpose	Install command
`requests`	HTTP requests, calls GitHub API	`pip install requests`
`python-dotenv`	Load configuration from .env file	`pip install python-dotenv`
`openai`	AI summary generation (optional)	`pip install openai`

Dependency package files

pip install -r assets/requirements.txt

Usage

1. Environment preparation

Method 1: Use .env configuration file (recommended)

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

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

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

Method 2: Environment variables

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

How to get a GitHub PAT

Visit https://github.com/settings/tokens
Click "Generate new token (classic)"
Select permissions:
- public_repo(access public repositories)
- If you need to access private Stars, check repo
After generating, copy the token (it is only shown once!)

Token role：

No Token: 60 requests/hour rate limit
With Token: 5000 requests/hour rate limit

2. Start the Dashboard (recommended)

# 导出数据并打开 Dashboard
# 产物固定落在技能目录 output/ 下（绝对路径，与当前工作目录无关），脚本结束时会打印完整路径
python scripts/main.py --export --user 你的用户名
open skills/github-star-manager/output/dashboard.html

First-time use instructions: If dashboard.html does not exist, the system will automatically copy one from assets/dashboard.example.html .

Dashboard features:

📊 Overview: total projects, active this week, new versions
🔍 Filter: filter by status (active/recently updated/long inactive), value (high/medium)
🔎 Search: search by project name, description, tags
📦 Cards: display project name, description, language, tags, Stars, update time, value assessment
🖱️ Click a card: expand detailed information (creation time, Forks, Issues, reason for bookmarking)
🔗 Quick jump: click the GitHub icon to go directly to the project

3. First sync (establish baseline)

python scripts/main.py --init --user 你的用户名 --limit 50

The first run saves a snapshot of all Stars as the baseline for subsequent comparisons.

4. Check for updates

python scripts/main.py --check --user 你的用户名

Compare with the last snapshot and generate an update report.

5. Generate a full report

python scripts/main.py --report --user 你的用户名 --days 7

Generate a full report including project summaries and update status.

6. Run regularly (recommended)

# 每周检查一次
python scripts/main.py --check --user 你的用户名 --weekly

Configuration and customization

Configuration files

This skill uses the following configuration files:

File	Purpose
`assets/categories.yaml`	Category definitions and keyword rules
`assets/tags.json`	Tag management and alias configuration
`assets/.env.example`	Environment variable template

On first run, the configuration files are automatically copied to the ~/.github-star-manager/ directory.

Use cases

Developers: keep up with version updates of dependency libraries
Tech enthusiasts: track the latest developments in AI/open source
Project managers: monitor the progress of competitors or related projects

Differences from other skills

Feature	github-star-manager	repo-research
Focus	Star project discovery + management + tracking	In-depth research on a single repository
Output	Dashboard + change summary	Architecture analysis, code explanation
Purpose	Daily subscription updates	One-time in-depth research

Reporting format specification

When a GitHub Star sync task needs to report, use the followingfixed format：

⭐ GitHub Stars 同步报告 — YYYY-MM-DD HH:MM

总项目数: XXX 个（±Y）

---

**🔄 仓库转移**（同一项目，owner/name 变了）
- ~~旧路径~~ → **新路径**（⭐ N）

**➕ 新增 Star (N)**
- 项目名（⭐ N）
  描述（如果有）

**➖ 取消 Star (N)**
- 项目名

---

**📊 汇总**
- 新增: X 个
- 取消: Y 个
- 转移: Z 个
- 当前总数: XXX

Rules:

When there are no changes, remain completely silent, do not send any messages
List additions and removals separately, with clear emoji distinctions
Put repository transfers at the very front (because they are easily overlooked)
Have a summary line at the end for quick scanning

Reference documents

SKILL-GUIDE.md - Skill development guide
AGENTS.md - Project collaboration specification