blog-post-workflow: an RSS action that writes your latest posts into a GitHub README

The problem: a profile README that goes stale the day after you write it

A GitHub profile README is a static file. Every time you publish a post, you either edit that file by hand or the list of posts at the top of your profile slowly drifts out of date. The same applies to a project README that carries a "writing" or "press" section.

blog-post-workflow targets that specific gap. It is a GitHub Action, not a service you host, and its job is narrow: read one or more RSS feeds, take the newest items, and write them into a README between two HTML comment markers. The README describes it as showing "your latest blog posts on your github profile or project readme", and the topics list on the repository points at the same idea from several angles: rss, rss-feed-urls, github-profile, profile-readme, wordpress, ghost, stackoverflow-activity, youtube.

The intended user is someone who already publishes somewhere that emits a feed. If your posts live only inside a platform with no RSS output, this action has nothing to read and the question of adopting it does not arise.

How the action rewrites your README between two comment markers

The mechanism is a marker replacement. You place `<!-- BLOG-POST-LIST:START -->` and `<!-- BLOG-POST-LIST:END -->` in your README, and the workflow replaces everything between them with the generated list. The README states this directly: "The workflow will replace this comment with the actual blog post list." Nothing outside the markers is touched, which is why the action can coexist with hand-written prose above and below the list.

The action is packaged as a JavaScript GitHub Action. The repository root contains `action.yml`, a `src/` directory, a bundled `dist/` directory, and `local-run.js`. The `package.json` build script uses esbuild to bundle `./src/blog-post-workflow.js` into `dist/blog-post-workflow.js` in ESM format, with a banner that recreates `require` through `createRequire`. That dist bundle is what the action actually executes when you reference `gautamkrishnar/blog-post-workflow@v1`.

The data flow is short. A scheduled workflow starts, checks out the repository, runs the action with a `feed_list` input, the action fetches each feed over HTTP, and the resulting list is committed back to the README. The README's own example workflow grants `contents: write`, which is the permission the commit step needs.

Install tutorial: a workflow file, a feed list, and write permissions

The README gives a numbered setup. You add the marker comments to your README, create `.github/workflows/blog-post-workflow.yml`, and commit. The example below is the README's own workflow, with the schedule, the manual trigger, and the permission block it documents.

name: Latest blog post workflow
on:
  schedule:
    - cron: '0 0 * * *'
  workflow_dispatch:
permissions:
  contents: write
jobs:
  update-readme-with-blog:
    name: Update this repo's README with latest blog posts
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4
      - name: Pull in dev.to posts
        uses: gautamkrishnar/blog-post-workflow@v1
        with:
          feed_list: "https://dev.to/feed/gautamkrishnar,https://www.gautamkrishnar.com/feed/"

The `feed_list` value is a comma-separated string of feed URLs. Replace both URLs with your own. The README points to a "popular sources" section for common feed URLs, which is where you should look before guessing at a platform's feed path.

One step is easy to miss. The README instructs you to open repository settings, go to Actions then General, and change "Workflow permissions" to "Read and write permissions". Without that, the action can fetch your feeds but the commit back to the README fails. The README also notes you can trigger the workflow manually through the Actions page instead of waiting for the cron.

The README offers three schedule suggestions rather than one: daily with `cron: '0 0 * * *'`, weekly with `cron: '0 0 * * 0'`, and monthly with `cron: '0 0 1 * *'`. It explicitly warns that running the workflow too frequently, hourly for example, "may be unnecessary unless you publish content very often".

Where it breaks: feed formats, cron granularity, and repositories you do not control

The dependency on RSS is a hard boundary, not a soft one. Any source that stops emitting a feed, changes its feed URL, or returns a format the parser does not handle will silently drop out of the list. The README's options table is the place to check what is configurable, and it is long, but the input surface is still a set of feed URLs and formatting options rather than a general scraping engine.

Cron granularity is the second constraint. GitHub's scheduled workflows are not precise timers, and the README's own guidance leans toward daily at most. If you expect a post to appear in your README within minutes of publishing, this is the wrong tool; a manual `workflow_dispatch` run is the intended escape hatch.

The third constraint is permissions. Writing to a README requires write access to the repository, which is why the example workflow carries `contents: write`. On a repository where you cannot change workflow permissions, or on a fork where the default token is read-only, the fetch succeeds and the write does not.

Finally, the licence is AGPL-3.0. For the common case of referencing the published action in a workflow file, that is the same posture as any other action you call. It matters more if you fork the source and redistribute a modified version, because the licence's network clause is broader than permissive licences. The repository ships a LICENSE file and a SECURITY.md, so read the former rather than assuming.

Alternatives: a self-hosted automation platform versus a repo-local action

The closest alternative pattern is a general automation platform such as n8n, which appears in the related searches for this project. The difference in approach is where the logic lives. n8n runs on infrastructure you provision, gives you a visual node graph, and can chain the RSS read into arbitrary downstream steps: posting to social accounts, writing to a database, sending a notification. blog-post-workflow runs inside GitHub's own runner, has no server to maintain, and can only do one thing, which is edit a file in the repository that triggered it.

That narrowness is the point. There is no node graph to debug, no credentials to rotate beyond the repository token, and no hosting bill. The cost is that anything beyond "fetch feeds, write README" requires a different tool.

If your goal is a profile that shows GitHub activity rather than blog posts, a project like Jamesgeorge007's activity readme generator solves a different problem: it reads your commit and contribution data rather than an external feed. The two can sit in the same README without conflict because they write between different markers.

Maintenance, releases, and what upgrading actually costs

The repository is not archived. Its last push was on 2026-08-10, and the most recent release, 1.9.7, was published the same day. Before that, 1.9.6 landed on 2026-04-16 and 1.9.5 on 2026-04-13, so the release cadence over the visible window is a few releases a year rather than continuous churn.

Upgrade cost is low by design. The README's example pins the action at `@v1`, a moving major tag, so minor releases arrive without a workflow edit. The trade-off is the usual one with floating tags: you get fixes without asking, and you also get behaviour changes without asking. Pinning to a full version such as `@1.9.7` trades that convenience for reproducibility.

The repository carries a `yarn.lock`, a `.nvmrc`, and a Husky `prepare` script, and the test suite runs Mocha with a local test server started through `start-server-and-test`. That layout suggests the maintainers test against a fixture server rather than live feeds, which is the right call for determinism but means feed-parsing edge cases from real-world sources are found in production, by users, not in CI.

Editorial conclusion

Adopt blog-post-workflow if your content already has an RSS feed and you want a profile README that updates without you touching it. Skip it if you have no feed, if you cannot grant the workflow write access to the repository, or if you need the action to run on a schedule tighter than GitHub's cron allows. Before trusting it, verify three things: that the repository's Actions permissions are set to Read and write, that your feed URLs are reachable from a GitHub runner, and that the comment markers in your README match exactly the strings the action looks for.

Frequently asked questions

Official sources

1. gautamkrishnar/blog-post-workflow on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases