GitHub Workflows Turned My README into a Living Homepage
Bruce Hart
I thought GitHub Actions would be overkill for a profile README. I was wrong.
I finally added a proper README.md to my GitHub profile, and my first workflow now keeps it fresh by polling my blog RSS feeds on a cron schedule. It is one of those small automations that seems trivial until you run it for a week and realize you changed your default behavior.
I am using gautamkrishnar/blog-post-workflow, with a workflow that runs every six hours and writes both blog posts and news items into the README.
Source workflow: https://github.com/brucehart/brucehart/blob/main/.github/workflows/update-readme-feeds.yml
A profile README is a product surface, not a static bio
The first mindset shift for me was treating the profile page less like a one-time about page and more like a living feed.
If someone lands on your profile and your latest work is current, your page does distribution for free. If the page is stale, even active projects can look abandoned.
My workflow currently does two feed passes:
- blog posts from
https://bhart.org/rss.xml - news items from
https://bhart.org/news-rss.xml
Both write to README.md, each with its own marker and post count. It is simple plumbing, but the outcome is real: the profile reflects what I am actually shipping right now.
Cron plus RSS is the most underrated personal automation stack
This setup reminded me how much leverage you get from old, boring standards.
RSS gives you a durable source of truth. Cron gives you reliable polling. GitHub Actions gives you hosted execution and commit permissions. You do not need a custom backend to get useful automation running.
That stack is probably overlooked because it feels unglamorous. But for personal systems, boring primitives are exactly what you want. They survive API churn, they are inspectable, and they fail in understandable ways.
Your first workflow should be a thin wrapper, not a platform
I was tempted to overdesign this on day one. Better metadata parser, custom renderer, maybe dedupe logic beyond what the action already supports.
Instead, I kept it narrow:
- scheduled trigger:
0 */6 * * * - manual trigger:
workflow_dispatch - action reuse instead of custom code
- explicit commit identity for the update step
That choice mattered. I shipped it quickly, learned the failure modes, and now I can decide where custom logic is actually worth it.
A practical rule I am adopting: treat each workflow as a single-purpose robot with one clear output. If you cannot describe the output in one sentence, split the workflow.
What this makes me want to automate next
After seeing this work, I have a longer list of things I want to try:
- nightly link rollups from bookmarks into a markdown digest
- weekly project heartbeat sections for active repos
- automatic changelog snippets from merged PR titles
- lightweight status pages generated from repo activity
I do not think the goal is maximal automation. The goal is removing repetitive update chores so the public artifacts stay accurate without constant manual cleanup.
Building your own workflow starts with one artifact
If you are new to Workflows, my suggestion is to anchor on a single file you care about, then ask one question: what source should keep this file fresh?
From there, define three things:
- Trigger cadence
- Source of truth
- Output location
That is enough to get something real into production. You can add validation, notifications, and guardrails later once the baseline loop proves useful.
I am still early here, but this first setup changed my mental model. GitHub Workflows are not just CI for code. They are a lightweight automation runtime for your public presence and personal ops.
If you have examples of clever personal workflows, send them my way. I am collecting ideas for the next round.