githubweekly: a Jekyll site that archives weekly GitHub picks

A publication, not a scraper

The itcoffee66/githubweekly repository is the source for a Chinese-language publication about trending GitHub projects. The description says it shares five popular projects every week, with video versions published on Bilibili and YouTube, and the search term to find it is the IT Coffee House channel name, which is the name of the channel behind it.

The important thing to understand is what the repository is not. There is no code here that queries GitHub, ranks repositories, or generates the issues. The trending projects are chosen by a person, and the repository is the publishing substrate: a Jekyll site, a numbered archive, and a feed.

That framing determines how you should read the project. If you wanted a tool that surfaces trending repositories, this is the wrong repository and the wrong idea. If you wanted to run a curated link blog with a static site, a versioned archive, and an RSS feed, this is a working example with a long archive behind it.

The top level entries confirm the Jekyll layout: _config.yml for the site configuration, _data/, _includes/, _layouts/, and _tabs/ for the theme structure, _weekly/ for the issues themselves, an index.html, an rss.xml, a Gemfile, assets/ and asset/ directories, and a CONTRIBUTING.md. The primary language is listed as HTML, and the last push to the repository was on 2026-07-31. The licence is not declared, which is worth knowing if you plan to reuse the content.

Every issue is a numbered Markdown file

The archive is the interesting engineering of the project, and it is completely plain.

Each issue is a single Markdown file in the _weekly/ directory, named after its issue number, and each has a matching HTML page on GitHub Pages. The README lists the links for both forms, and the pattern is completely consistent across the whole run:

_weekly/124.md
https://itcoffee66.github.io/githubweekly/124.html

The README's index currently runs from issue 124 at the top down to issue 96, which is twenty-nine consecutive issues. The titles are the giveaway about the subjects the channel covers, and they are almost entirely AI tooling: Kimi K3 at issue 124, long audio transcription and separation at 123, an AI job search assistant at 122, DeepSeek inference acceleration at 121, an agent video production system at 120, a production grade agent skill package at 119, a self hosted AI workspace at 118, an open source alternative to Claude Design at 117, an agent memory system at 116, and a desktop AI assistant at 115.

Earlier issues cover DeepSeek V4 and its terminal coding assistant, Warp open sourcing, Karpathy distilled Claude Code configurations, the open sourcing of Claude Code itself, and the fastest growing project in GitHub history at issue 110. The openclaw thread runs through several issues, including a Rust rewrite at 105 and an Alibaba alternative at 106, and there is an issue at 103 asking whether a 4000 line implementation of openclaw is usable, which is the kind of question the series exists to answer.

The naming convention matters more than it looks. Because the filename is the issue number and the page URL is the same number, a link to any past issue is stable and guessable, and an archive that is a directory of files is trivially greppable from a terminal.

RSS, and the parts a static site needs

The repository provides an RSS feed for the whole series, and the address is published:

https://itcoffee66.github.io/githubweekly/feed.xml

The stated purpose is that an RSS reader gives you a quick way to know the week's GitHub hot projects. For a publication that ships roughly once a week, a feed is the mechanism that makes it followable at all, and having it generated from the same source files as the pages means the two cannot drift apart.

The rss.xml file at the repository root is the counterpart to the feed URL, and it is the kind of hand-maintained feed file that a static site generator can leave alone entirely. In a Jekyll site the feed can be produced from the same collection the pages come from, which is the more common approach, and the presence of a top-level rss.xml next to index.html suggests the site works in the older style where the feed is a template in the site root.

The rest of the Jekyll scaffolding is the standard set. The _config.yml holds the site settings, _data/ holds the data files that the templates read, _includes/ and _layouts/ hold the template fragments, and _tabs/ holds the tab structure. The asset/ and assets/ directories both exist, which is a small inconsistency that usually means one holds theme files and the other holds images.

Running the site yourself

The repository does not document an install procedure in the README, so the practical steps come from the structure. The Gemfile at the top level is the dependency manifest, which for a Jekyll site means Ruby with a Gemfile listing the theme and the plugins.

The site is deployed to GitHub Pages, as the itcoffee66.github.io URL in every issue link makes clear, and the presence of a .github/ directory at the top level is where the deployment workflow would live. The index.html in the root is the landing page, and the past issues are listed from the README rather than from a separate archive page, which is a deliberate choice, since the README is the entry point for anyone arriving on GitHub rather than on the site.

If you want to run it locally, the usual Jekyll workflow applies: install the Ruby dependencies from the Gemfile, run the Jekyll development server from the repository root, and browse the issues at the /githubweekly/NNN path. The content itself lives in _weekly/, so adding a new issue is a matter of creating the next numbered Markdown file, and the README index is where the new entry is added by hand.

The CONTRIBUTING.md file is there for people who want to send in a project for consideration, which is the usual arrangement for a curated list: the curation is the community's contribution, and the writing and publishing are the maintainer's.

Why a static archive instead of a live tracker

The alternative to a curated static archive is a live aggregator, and the difference in approach is worth being clear about.

A live tracker queries GitHub's trending page or the search API on a schedule, ranks by stars gained or by commit velocity, and publishes a generated list. The advantage is that it is automatic and the output never goes stale, because it is regenerated. The disadvantage is that it is a ranking, and a ranking of a metric is not a recommendation. A repository can climb because it was reposted, or because a conference talk mentioned it, or because it is a list of lists.

The curated archive inverts that. Each issue is a snapshot with a human's judgement baked in, and it stays exactly as it was published. You can read issue 96 and see what was considered worth mentioning at that moment, which is a different and arguably more useful artefact than a list that could have been generated on any day.

The cost is obvious and worth stating. There is no automation here at all, so the site only updates when someone does the work, and there is no signal about whether a project mentioned in issue 100 turned out to matter. The series is a record of selections, and selections are a point of view.

The hybrid option is to automate the collection and keep the writing manual, which is what a lot of newsletter production pipelines do. The repository does not do that, and for a channel whose content is largely commentary on why a project matters rather than a bare link list, that seems like the right trade.

The two delivery channels, and what the repository does not do

The publication exists in three forms and the repository is only one of them. There is the website, the GitHub repository that holds the source, and the video versions on Bilibili and YouTube, where the channel is searchable as the IT Coffee House channel name.

That last part explains a lot about the content. The titles in the archive are not neutral link labels, they are video titles, which means each issue was written to be narrated. One title asks whether a 4000 line implementation of openclaw is usable, which is exactly the kind of question a host can ask on camera, and the article behind it is the written version of the same question. The repository therefore holds the script, not the analysis.

Two limitations are worth naming. The first is the licence. No licence is declared for the repository and there is no LICENSE file among the top level entries, which means the content has no stated reuse terms, so the content is not something to copy into your own publication without asking.

The second is the language. Every issue title, the site chrome, and the archive index are in Chinese. That is not an objection to the project, it is the project, but it does mean the audience is a Chinese-speaking one, and it means a reader who does not read Chinese is limited to the code structure, which here means the Jekyll layout and the archive conventions rather than the content.

Editorial conclusion

Adopt this repository if you want to publish a static, versioned archive of curated link posts with a feed, since the structure of numbered Markdown files plus a Jekyll layout is a workable template for that. Do not adopt it expecting a tool that finds trending projects by itself, because the curation is manual and nothing in the repository collects or ranks anything. Verify first that you are comfortable editing Chinese source content, since every issue and the site chrome are written in that language.

Frequently asked questions

Official sources

1. Issues
2. itcoffee66/githubweekly on GitHub
3. README