Why I wanted to do this

There’s a common misconception about static websites, which is that “static” means dead and unchangeable. But when combined with CI/CD, they can achieve things many people wouldn’t expect.

I wanted to do one thing: to automatically update a certain field on this website every week, without me having to manually write anything. My motivations were twofold:

  • The first was purely to test how far static deployments like GitHub Pages can go with automation. From data scraping, calling LLMs, to finally committing to the repo to trigger deployment, the entire chain can be completed within GitHub Actions, without any backend servers. This in itself is very interesting.

  • The second was practicality: GitHub Trending is an information source I believe is currently underutilized. Run it once a week for the top 15, filter out irrelevant ones with keywords, and then let the LLM summarize the rest for me, automatically publishing it to the website. This way, I don’t have to actively track it every week; the information will come to my website on its own.

Technical Details

The starting point was finding a clean RSS feed. GitHub officially doesn’t provide an RSS feed for Trending, but someone created one: mshibanami/GitHubTrendingRSS. It updates daily, and the weekly report URL format looks like this:

https://mshibanami.github.io/GitHubTrendingRSS/weekly/all.xml

With the RSS feed, the pipeline structure became clear:

  1. Fetch Data: Use feedparser to parse the RSS and retrieve the top 15 entries.
  2. Initial Filtering: Filter by keywords (gemini, claude, gpt, llm, ai, etc.) to remove repositories irrelevant to the personal website’s theme.
  3. Content Generation: Send the filtered repositories to Gemini 2.5 Flash in one go, asking it to use a single prompt to generate both a Traditional Chinese introduction for each project and a set of tags for the entire batch.
  4. Write & Deploy: Save the generated markdown to content/news/, then git push, triggering the existing Hugo deploy workflow.

The entire process is housed in GitHub Actions, scheduled to run every Sunday at 12:30 PM Taiwan time. There are no continuously running servers, and costs are almost zero (the cost for Gemini API at this usage level is negligible).

Reflection: Partnering with Claude

This entire system was built by me, in partnership with Claude.

I started with only a very rough idea: “I want to scrape GitHub Trending every week and have an LLM summarize it for me.” As for how to parse RSS, how to write GitHub Actions YAML, where to set the cron timezone, why GITHUB_TOKEN can’t trigger other workflows… I knew these details existed, but I didn’t particularly want to delve deep into them.

The result was: I focused on “what this thing should do,” and Claude was responsible for “how to make this thing work.”

It’s not that details aren’t important. But at this point, I believe that having the idea and knowing something is broadly feasible is more valuable than figuring out all the details yourself.

Here’s a simple test: If you can clearly state, “I want X, and this can probably be achieved through A → B → C,” then you’re already in a position to make it happen, whether by doing it yourself, hiring someone, or collaborating with AI.

Before AI, this idea might have remained in the “idea” stage because I didn’t want to spend time researching feedparser documentation or GitHub Actions permission settings. Now it’s actually running, and I understand the entire pipeline. Even if something goes wrong, I can pinpoint which section has the issue.

This is the smoothest mode of “collaborating with AI” I’ve experienced so far: you provide the direction, and it makes that direction into something operational.