star-history-chart
Add a self-hosted "Stargazers over time" chart to any GitHub repo's README. GitHub now restricts the stargazers endpoint to a repo's own admins/collaborators, so third-party live services (star-history free tier, starchart.cc) return "Requires authentication" for everyone. This generates a static, theme-aware SVG in-repo and auto-refreshes it weekly with a GitHub Action using the repo's own GITHUB_TOKEN. Use when the star chart in a README is broken, shows "Requires authentication", or you want a star history that never breaks.
- License 许可
- MIT
- 最近更新
- 2026-11-12
- Stars
- ★ 3.3w
- Forks
- 3.9k
01 前言 Front Matter
- name
- star-history-chart
- description
- Add a self-hosted "Stargazers over time" chart to any GitHub repo's README. GitHub now restricts the stargazers endpoint to a repo's own admins/collaborators, so third-party live services (star-history free tier, starchart.cc) return "Requires authentication" for everyone. This generates a static, theme-aware SVG in-repo and auto-refreshes it weekly with a GitHub Action using the repo's own GITHUB_TOKEN. Use when the star chart in a README is broken, shows "Requires authentication", or you want a star history that never breaks.
02 资源文件 2
- 资产文件assets/star-history.yml1.7 KB
- 脚本scripts/generate_star_history.py7.7 KB
03 SKILL.md 正文
Star History Chart (self-hosted, never breaks)
Add a "Stargazers over time" chart that renders from a static SVG committed to the repo and refreshes itself weekly — no external chart service, no broken images.
Why this exists
GitHub now restricts the /stargazers endpoint to a repository's own admins and
collaborators. Unauthenticated requests return {"message":"Requires authentication"}, which breaks every third-party live-chart service
(star-history.com free tier, starchart.cc, etc.) for all repos. The only
reliable fix is to generate the chart yourself with an authenticated token and
commit a static image. Inside GitHub Actions, the repo's own GITHUB_TOKEN can
read its own stargazers, so the whole thing runs with zero secrets to configure.
What this skill sets up
scripts/generate_star_history.py— fetches stargazers (authenticated), renders a clean, light/dark-adaptive SVG..github/workflows/star-history.yml— weekly cron + manual trigger that regenerates and commitsdocs/star-history.svg.- A README section pointing at the local SVG.
Workflow
Step 1: Copy the script and workflow into the repo
mkdir -p scripts .github/workflows docs
cp skills/git/star-history-chart/scripts/generate_star_history.py scripts/generate_star_history.py
cp skills/git/star-history-chart/assets/star-history.yml .github/workflows/star-history.yml
The script needs the
requestspackage:pip install requests. It resolves the repo fromSTAR_HISTORY_REPO, thenGITHUB_REPOSITORY(set automatically in Actions), then theorigingit remote — so no edits are required for it to work in a different repo.
Step 2: Generate the SVG once, locally
Use a token that can read the repo's stargazers (as owner/collaborator). The GitHub CLI provides one:
GITHUB_TOKEN=$(gh auth token) python scripts/generate_star_history.py
This writes docs/star-history.svg. For a repo with many thousands of stars the
first run paginates the whole stargazer list and can take a couple of minutes.
Verify it rendered (optional, macOS): qlmanage -t -s 800 -o . docs/star-history.svg
Step 3: Add it to the README
Add or replace the star chart section. Point the image at the local SVG. Set the link target to wherever you want clicks to go (the repo, a docs page, or your own site):
## Stargazers over time
[](https://github.com/OWNER/REPO/stargazers)
If replacing a broken star-history.com / starchart.cc embed, swap only the
image URL to docs/star-history.svg and keep or update the link target.
Step 4: Commit
git add scripts/generate_star_history.py .github/workflows/star-history.yml docs/star-history.svg README.md
git commit -m "feat(readme): self-hosted stargazers chart with weekly auto-refresh"
git push
Step 5: (Optional) Trigger the auto-refresh now
The workflow runs every Monday at 04:00 UTC. To refresh immediately without waiting: GitHub → Actions → "Update Star History" → Run workflow.
Customization
- Output path — set
STAR_HISTORY_OUTPUT(defaultdocs/star-history.svg). - Different repo — set
STAR_HISTORY_REPO=owner/name. - Colors / size — edit the
.line,.area,.dotCSS andWIDTH/HEIGHTconstants near the top ofgenerate_star_history.py. The chart is theme-aware via aprefers-color-scheme: darkblock, so it looks right in both GitHub light and dark modes. - Refresh cadence — edit the
cronexpression in the workflow.
Notes
- No secrets to add: the workflow uses the automatic
GITHUB_TOKEN. - Private repos work too, as long as the token can read the repo.
- The script uses only
requestsplus the Python standard library.
04 同仓库更多 Skills
wealthville-pool-scoring
Score DeFi liquidity pools before providing liquidity. Returns a 0-100 pool score and an Enter/Hold/Exit/Reduce/Avoid verdict with calibrated confidence for ~68,800 Solana pools and 575 EVM pools, plus a public miss-inclusive track record. Use when asked whether a pool is worth LPing into, which pools look best right now, or how accurate the scores have actually been.
technical-debt-auditor
Scans a codebase and produces a quantified technical debt report with a prioritized remediation plan. Analyzes dead code, TODO/FIXME/HACK markers, dependency staleness, complexity hotspots, code duplication signals, test coverage gaps, unused exports, and outdated patterns. Use this skill when the user asks to audit their codebase for tech debt, wants a health check of their code quality, says things like "where should I focus refactoring", "find code smells", "audit my codebase", "what technical debt do we have", "prioritize cleanup work", or asks about code quality metrics. Also trigger when the user mentions "code rot", "legacy cleanup", "refactoring priorities", or wants to understand the overall health of a project before a major effort. Trigger even if the user doesn't say "technical debt" explicitly — any request to systematically assess code quality and identify improvement priorities belongs here.
readonly-sql-guard
Make an agent's database access provably read-only. Use when an agent runs caller-supplied SQL against a production/ERP/analytics database (a "query" MCP tool, text-to-SQL, an admin console), or when reviewing DB-access code for write/DDL/side-effect/transaction-escape risks. Checks what a statement CALLS, not just its shape.
web-artifacts-builder
Suite of tools for creating elaborate, multi-component claude.ai HTML artifacts using modern frontend web technologies (React, Tailwind CSS, shadcn/ui). Use for complex artifacts requiring state management, routing, or shadcn/ui components - not for simple single-file HTML/JSX artifacts.
webapp-testing
Toolkit for interacting with and testing local web applications using Playwright. Supports verifying frontend functionality, debugging UI behavior, capturing browser screenshots, and viewing browser logs.
discernment-nudge
After you give a substantive answer or draft that the user may act on — advice or recommendations, drafted artifacts such as goals, plans, pitches, proposals, or emails, estimates or projections, analysis or interpretation of data, factual claims they may rely on, or a multi-step argument — invoke this skill BEFORE finalizing your reply and then, if it applies, append 2-3 short follow-up questions, each tied to something specific in what you just produced, that help the user check key facts, probe the reasoning or assumptions, and notice missing context. Do this at most once per conversation. Skip it when the user asked a trivial how-to or simple lookup, wants a purely educational explanation, asked you only to format, convert, or assemble a file from content they provided, is writing code they will run, is doing creative writing or casual chat, or already asked you to double-check, cite, or review — the skill file explains these boundaries and the exact output format.