Track AI System Prompt Changes

Build a GitHub Actions job that snapshots an AI prompt and builds an Atom feed

Introduction

30 Second Summary

The AI assistants people use every day run on a written set of instructions, and those instructions get rewritten quietly. Anthropic publishes its own set, so anyone watching closely can read exactly what changed.

In this project, you will build a small repo that downloads those published pages on a schedule and saves a snapshot whenever the wording moves. You will then turn that history into an Atom feed you can subscribe to in any reader.

What You'll Build

You will open your reader, spot a fresh entry the day a system prompt changes, and click straight through to the lines that moved.

By the end of this project, you'll have:

A GitHub repository holding a snapshot of a published system prompt, with every earlier version still readable in its history.
A GitHub Actions workflow that wakes up on a schedule, fetches the page, and commits only when the text is different from last time.
A live feed URL you can paste into any reader, with one entry per change and a link to the diff highlighted line by line.
Secret Mission: Track a second published prompt page in the same repo, so one workflow watches both and each page gets its own snapshot file.

Are there any prerequisites?

You need a GitHub account and Git installed on your laptop. Every page this project fetches is public, so there are no API keys and no costs to worry about.

Before We Start

Before you touch a terminal, lock in what you're building and why it matters. You're about to set up a repo that quietly watches a published AI system prompt and tells you the moment its wording changes.

Fetch the Published System Prompt

Your tools are ready and you've picked a published system prompt page to track. To spot a change later, you need a copy of today's wording sitting on your own machine.

Those pages render as a styled web page in your browser, and the same page is also served as raw Markdown. Plain text is what makes a change readable line by line later on.

In this step, get ready to:

Add .md to the end of your chosen system prompt URL.
Download that page into a project folder with curl.
Read the whole prompt as plain text on your own machine.

Make a home for your snapshot

Everything in this project lives in one folder, so your downloaded prompt is easy to find and easy to turn into a repo later.

Return to your terminal.
Move to your Desktop by running this command:

cd ~/Desktop

Create your project folder and move into it by running these commands:

mkdir prompt-watch
cd prompt-watch

Your terminal prompt now ends with prompt-watch, so every command from here lands inside that folder.

Download the prompt as markdown

Every page on the docs site has a plain text twin. Add .md to the end of the URL and the server hands back raw Markdown instead of the styled page.

Take the system prompt URL you picked earlier and add .md to the end of it.
Download that Markdown into your folder by running this command:

curl -L -o system-prompt.md [[PROMPT_URL="https://platform.claude.com/docs/en/release-notes/system-prompts/claude-fable-5-1.md"]]

What does this command do?

-L follows the redirect if the docs site points your URL somewhere else.
-o system-prompt.md saves the response into a file instead of printing it to your terminal.
The .md on the end of the URL is what makes the server return Markdown rather than a web page.

Confirm the file landed by running this command:

ls

You should see system-prompt.md listed in the output.

Nothing downloaded?

If ls shows no file, check that the URL you entered ends in .md with no stray spaces.
If the file exists but is only a line or two long, the URL most likely pointed at a page that does not exist, so the server returned an error page instead of the prompt.
My curl download saved an almost empty file instead of the system prompt. What should I check?

Read the prompt you just downloaded

Before you open it, make a guess. Is a production system prompt a couple of paragraphs, or pages of instructions?

Print the whole file into your terminal by running this command:

cat system-prompt.md

Text scrolls past for pages. Scroll back up and you can read the exact instructions the model is handed, as plain text.

Why save Markdown instead of the web page?

The web page is wrapped in navigation, styling, and scripts that change for reasons that have nothing to do with the prompt.

Markdown is only the words. That means a single reworded sentence shows up as a single changed line later, instead of drowning in noise.

You now have today's wording saved as a file you can read. Next up, you'll put it under version control on GitHub so every future copy has something to be compared against.

Create Your Repository and Commit the First Snapshot

You've got the full system prompt sitting on your machine as plain Markdown.

A single file has no memory. The next time you download the page, the new wording lands on top of the old wording and the old version is gone forever.

That's what Git is for. In this step you'll put the snapshot in a repository, commit it as version one, and push it to GitHub so every future version stacks up next to it.

In this step, get ready to:

Set up a project folder and turn it into a Git repository.
Commit your downloaded snapshot as the first version.
Push it to a new GitHub repository and read the commit on the repo page.

Set up a project folder for your snapshots

Git tracks a whole folder, not a loose file. Your snapshot needs a home before it can have a history.

Move to your Desktop by running this command:

cd ~/Desktop

List what's on your Desktop by running:

ls

You should see the .md file you downloaded in the last step listed in the output.

Record the file name you see: the .md file you downloaded.

Create your project folder, move the snapshot into it, and step inside by running these commands:

mkdir system-prompt-watch
mv [[SNAPSHOT_FILE="the .md file you downloaded"]] system-prompt-watch/prompt.md
cd system-prompt-watch

Why rename the file to prompt.md?

Every later step overwrites this same file with a freshly downloaded copy.

A short, fixed name means the script you write next always knows where to write, and Git always compares the new text against the old text in one place.

Confirm the snapshot landed in the right place by running:

ls

The output is a single line: prompt.md.

Don't see your downloaded file?

Your terminal may have saved it into a different folder than your Desktop. Re-run the download command from the last step while you are inside your Desktop folder.

If the move command complains that the file is missing, check the spelling of the file name against what ls printed.

My terminal cannot find the file I downloaded with curl. How do I work out where it went?

Turn the folder into a Git repository and commit your snapshot

Right now the folder is just files on a disk. A repository remembers every version of everything inside it.

Start tracking the folder by running this command:

git init

Stage your snapshot for its first commit by running:

git add prompt.md

Write that version into history by running:

git commit -m "Add first snapshot of the system prompt"

What do these three commands do?

git init creates a hidden .git folder that stores the history.
git add chooses which files go into the next version.
git commit freezes those files as a version, labelled with the message you passed.

Read back your history by running:

git log --oneline

You get one line: a short commit ID followed by your message. That line is version one of the prompt.

Git says there is nothing to commit?

You are probably in the wrong folder. Run pwd and check the path ends in system-prompt-watch.

If the folder is right, run the git add command again before committing.

My git commit is not saving my file. What should I check?

Create the GitHub repository and push your snapshot

Your history lives on one laptop right now. GitHub gives it a remote home, a page you can read, and later a machine that can run your fetch script for you.

Open https://github.com/new in your browser.
Enter system-prompt-watch in the **Repository name** field.
Select the Public visibility option.
Leave the Add a README file checkbox unticked.
Click Create repository.

Why public, and why no README?

Public repositories get free scheduled automation, which is what keeps this tracker running for nothing later on.

Leaving the README unticked keeps the new repository completely empty. Your first commit then becomes its history, with nothing to reconcile.

Git will ask you to sign in

The first time you push, Git asks for your GitHub username and a password, or opens a browser window to sign you in.

Your account password will not work at that prompt. Paste a personal access token instead, which you can create at github.com/settings/tokens.

Point your local repository at the GitHub one by running this command:

git remote add origin https://github.com/[[GITHUB_USERNAME="your GitHub username"]]/system-prompt-watch.git

Name your branch main to match what GitHub expects by running:

git branch -M main

Before you push, what do you think your empty repository page will show once this finishes?

Send your commit up to GitHub by running:

git push -u origin main

Switch back to your repository page in the browser and refresh it.

The page now lists prompt.md with your commit message beside it. Click the file to read the whole system prompt rendered on GitHub.

Push rejected, or the sign-in prompt keeps coming back?

A rejected push usually means the repository was not empty. Delete it and create it again with the README checkbox unticked.

A repeating sign-in prompt usually means the token you pasted lacks repository write access. Create a new token with that permission and push again.

My git push to a brand new GitHub repository is failing. How do I fix it?

Version one of the prompt is safe, dated, and readable from anywhere. Next up, you'll write a script that refetches the page and commits only when the wording has actually moved.

Write the Fetch Script

Your snapshot is safely committed on GitHub, but it only records what the page said on the day you downloaded it.

Repeating that download by hand is the part that falls apart. You need a script that fetches the page and then works out whether anything actually moved before it touches the history.

A script that commits on every run would bury you in identical entries. The point of this project is a history where every commit means the wording genuinely changed.

In this step, get ready to:

Write a fetch script that downloads the prompt page and overwrites your snapshot.
Add a check so the script commits only when the content changed.
Run the script twice and confirm the second run leaves your commit history alone.

Create the fetch script and download the page

Your script runs from inside your repository folder. That's where your snapshot lives, and where Git keeps its history.

Confirm you're in your repository folder by running this command:

pwd

The path printed should end with your repository's name.

Create the empty script file by running this command:

touch fetch.sh

Confirm the file exists by running this command:

ls

You should see fetch.sh listed next to your snapshot file.

Open fetch.sh in the same text editor you used to read your snapshot in Step 1.
Add the download logic by copying this code into the file:

#!/bin/bash

# The published prompt page, with .md on the end so it comes back as plain Markdown
URL=[[PROMPT_URL="your chosen system prompt .md URL"]]

# Overwrite the local snapshot with the latest version of the page
curl -sL "$URL" -o prompt.md

What does this code do?

URL holds the address of the prompt page you chose, with .md on the end so the page comes back as plain Markdown.
curl -sL downloads quietly and follows any redirect the site sends.
-o prompt.md writes the download straight into the snapshot file, replacing whatever was there before.
If you saved your snapshot under a different name in Step 2, change prompt.md to match that name.

Save fetch.sh.

Before you run it, what do you think Git will say about your snapshot file once the download finishes?

Run your script by running this command:

bash fetch.sh

See what Git noticed by running this command:

git status --short

You should see a single line for fetch.sh, marked as untracked. Your snapshot isn't listed, because the fresh download is identical to the version you already committed.

Snapshot file looks empty?

curl writes whatever the server hands back, so a wrong address leaves you with an empty or very small file.

Check that the address in your URL line ends with .md, then run the script again.

Why did my curl download come back empty?

Commit only when the snapshot changed

Git already knows whether a file's contents moved. You can ask it that question directly and let the answer decide whether your script commits.

In fetch.sh, add the following code below the curl line:

# Stage every change in the folder so git can compare it against the last commit
git add -A

# git diff --cached --quiet succeeds when nothing is staged, so commit only when it fails
if git diff --cached --quiet; then
  echo "No change since the last snapshot."
else
  git commit -m "Update snapshot"
fi

What does this code do?

git add -A stages every change in the folder, including files Git has never seen before.
git diff --cached --quiet inspects what is staged. It succeeds when nothing is staged and fails when something is.
The if prints a message when there is nothing new and commits when there is, so your history only grows on real changes.

Save fetch.sh.

Your snapshot hasn't changed since the last run, but something else in the folder has. Do you think this run will make a commit?

Run the finished script by running this command:

bash fetch.sh

Git makes a commit, and the output names fetch.sh as the file it recorded. The snapshot was identical, and the script itself was new to Git, so there was a real change to capture.

Script stopped with a syntax error?

Bash is strict about the shape of an if block.

Check that your if line ends with the word then, and that the block closes with fi on its own line.

Why is my bash if statement throwing a syntax error?

✔️ Awesome, I've got everything!

Great, double check you've saved fetch.sh.

ⓧ I'd like to double check the full code

#!/bin/bash

# The published prompt page, with .md on the end so it comes back as plain Markdown
URL=[[PROMPT_URL="your chosen system prompt .md URL"]]

# Overwrite the local snapshot with the latest version of the page
curl -sL "$URL" -o prompt.md

# Stage every change in the folder so git can compare it against the last commit
git add -A

# git diff --cached --quiet succeeds when nothing is staged, so commit only when it fails
if git diff --cached --quiet; then
  echo "No change since the last snapshot."
else
  git commit -m "Update snapshot"
fi

Run the script twice and check the log

The real test is the boring run. When nothing on the page has moved, your history should not move either.

Count the commits you have so far by running this command:

git log --oneline

You should see two commits, your first snapshot and the one your script just made.

Nothing in the folder has changed since that run. Do you think the log will grow if you run the script again?

Run the script a second time by running this command:

bash fetch.sh

You should see No change since the last snapshot. and no commit output at all.

Check the history again by running this command:

git log --oneline

The log still shows the same two commits. Your script now writes to the history only when the wording genuinely changes.

Send your new commit to GitHub by running this command:

git push

Switch back to your repository page on GitHub.
Click the commit count shown above your file list.

Your script's commit sits at the top of the list, above the snapshot commit you made by hand.

Getting a commit on every run?

git add -A stages everything in the folder, so a stray backup file your editor leaves behind counts as a change.

Check which file the last commit picked up:

git log --stat -1

Why does my script commit every time even though the file is identical?

Your script now keeps the history honest, but it still waits for you to run it. Next up, you'll hand it to GitHub Actions so it checks the page on a schedule without you.

Automate Fetching with GitHub Actions

Your fetch script already does the whole job. You proved that by running it twice and watching the second run leave your commit log alone.

There is one catch. The script only runs when you remember to open a terminal and run it yourself.

That is what GitHub Actions is for. It runs a script for you on GitHub's own machines, on a schedule you set.

In this step, get ready to:

Write a workflow that runs fetch.sh on a schedule.
Trigger that workflow by hand from the Actions tab.
Confirm the run finishes with a green checkmark.

Create the workflow file

GitHub only looks in one place for workflows. Any file inside .github/workflows that ends in .yml gets picked up automatically.

Switch back to the terminal window where you ran fetch.sh, inside your repository folder.
Create the workflow folder and an empty workflow file by running these commands:

mkdir -p .github/workflows
touch .github/workflows/fetch.yml

Confirm the file exists by running:

ls .github/workflows

You should see fetch.yml in the output.

Tell the workflow when to run

A workflow file is YAML. It states when the job runs, what the job is allowed to do, and which commands to execute.

Open .github/workflows/fetch.yml in the same editor you used to write fetch.sh.
Set up the schedule, the permissions, and the job by pasting in this code:

name: Fetch system prompt

on:
  schedule:
    - cron: "0 9 * * *"
  workflow_dispatch:

permissions:
  contents: write

jobs:
  fetch:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - name: Set the commit author
        run: |
          git config user.name "fetch bot"
          git config user.email "fetch-bot@users.noreply.github.com"
      - name: Run the fetch script
        run: bash fetch.sh
      - name: Push any new commit
        run: git push

What does this workflow do?

The schedule trigger runs the job every day at 09:00 UTC.
The workflow_dispatch trigger adds a Run workflow button so you can start it yourself.
The permissions block hands the run write access to your repository. Without it, the push at the end is rejected.
The checkout step copies your repository onto GitHub's machine, so fetch.sh is there to run.
The last two steps run your script and push whatever commit it made.

Save .github/workflows/fetch.yml.
Send the workflow to GitHub by running these commands:

git add .github/workflows/fetch.yml
git commit -m "Add scheduled fetch workflow"
git push

Open your repository page on GitHub in your browser.
Click the Actions tab at the top of the repo.

Your workflow is now listed in the left sidebar as Fetch system prompt.

Nothing listed in the Actions tab?

Check the path is exactly .github/workflows/fetch.yml. GitHub ignores workflow files kept anywhere else.
Check the push landed by looking for the file on your repo's code page.
YAML is indentation sensitive, so a stray space can stop the file loading.

My workflow file is pushed but it is not showing up in the Actions tab.

✔️ Awesome, I've got everything!

Great, double check you saved .github/workflows/fetch.yml before moving on.

ⓧ I'd like to double check the full code

Here is the whole workflow file. Compare it line by line against yours.

name: Fetch system prompt

on:
  schedule:
    - cron: "0 9 * * *"
  workflow_dispatch:

permissions:
  contents: write

jobs:
  fetch:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - name: Set the commit author
        run: |
          git config user.name "fetch bot"
          git config user.email "fetch-bot@users.noreply.github.com"
      - name: Run the fetch script
        run: bash fetch.sh
      - name: Push any new commit
        run: git push

Trigger the run by hand

Scheduled runs sit in a queue on GitHub's shared machines, so they often start several minutes late. Triggering by hand gives you an answer now.

Click Fetch system prompt in the left sidebar of the Actions tab.
Click the Run workflow dropdown on the right of the page.

Before you start it, make a prediction. Your snapshot has not changed since your last local run, so do you expect this run to add a new commit?

Click the green Run workflow button.
Refresh the page after a few seconds.

A new run appears at the top of the list. It shows a yellow dot while it works, then a green checkmark when it finishes.

Click the run title to open it.
Click the fetch job in the left sidebar to read the logs.

The Push any new commit step reports that there is nothing to push. The published page had not changed, so your script made no commit.

Why a green run with no commit is the right answer

Green means the job ran end to end without an error. It does not mean the prompt changed.

A commit only appears on the days the wording actually moves. That silence is the whole point of the script.

Run finished red?

Open the failed step and read the last line of its log first.
A failure on the push step usually means the permissions block is missing or misspelled.
A failure on the script step usually means fetch.sh was never committed to the repository.

My workflow run failed. Help me read the log and find the broken step.

Your snapshot now refreshes itself whether you are watching or not. Next up, you'll change a line in the snapshot and read the diff GitHub draws for you.

See a Change in the Diff View

Your workflow now runs on its own schedule and commits without you. The one thing you still have not seen is what a real change actually looks like when it lands.

Anthropic might not touch that page for weeks. Waiting for a real edit is a slow way to find out whether your tracker is worth subscribing to.

So you will fake one. Edit a single sentence in your stored snapshot, push it, and let GitHub show you exactly which lines moved.

In this step, get ready to:

Change one sentence in your stored snapshot file.
Commit the edit and push it to your repository.
Read the line by line diff for that commit.

Change one sentence in your snapshot

Your snapshot is the file fetch.sh overwrites on every run. Editing it by hand creates the same shape of change Anthropic would make by rewording a paragraph.

Switch back to the terminal you used earlier.
Confirm you are sitting inside your repo folder by running this command:

git status

You should see your branch name and a message saying your working tree is clean.

Open your Markdown snapshot file in the editor you read it in earlier.

You are looking at the exact text fetch.sh downloaded and committed for you.

Change a few words in any one sentence so it reads differently.
Save the file.

Before you run the next command, how many lines do you expect Git to report as changed when you only touched a few words?

See what your local repo picked up by running this command:

git diff

The whole old sentence appears once with a minus sign in front of it. Your new version appears right underneath with a plus sign.

Why the whole line changes

Git compares files one line at a time. A single reworded phrase counts as one line removed and one line added.

That is exactly what makes this useful for prompt tracking. You get the old wording and the new wording side by side, in full.

No output from the diff?

Your editor may not have written the change to disk yet, so save the file and run the command again.

You may also be in a different folder from your repo. Check the folder name in your terminal prompt before retrying.

Why does git diff show me nothing?

Commit and push the test edit

Your scheduled workflow commits straight to the repo on GitHub, so the remote can be ahead of your laptop. Pulling first brings the two back in step.

Bring down any commits your workflow made by running this command:

git pull

Record your edit and send it up by running these commands:

git add .
git commit -m "Test edit: reword one sentence"
git push

What does this do?

git add . stages your edited snapshot so it is included in the next commit.

The commit message is what you will hunt for in the history in a moment, so it is worth making it obvious.

Read the terminal output and confirm Git reports one file changed, then finishes the push without an error.

Push rejected?

Your workflow probably committed on the remote after you pulled. Run the pull command again, then push a second time.

Why is my push being rejected?

Read the diff on GitHub

The terminal view is fine for one file on your own machine. The version you will actually use week to week is the rendered one in the browser.

Open your repository page on GitHub in your browser.
Open the commit history using the link above the file list.

Before you click into your commit, do you think the page will show you the whole file or only the part you touched?

Select the commit carrying your test edit message.

You get only the neighbourhood of your edit, with a few unchanged lines above and below for context. The old sentence sits in red, your new sentence in green directly beneath it.

Can't find your commit?

Refresh the page. A push that finished seconds ago will not appear in a tab you loaded before it.

Check that the branch selector on the repo page matches the branch you pushed to.

Where did my commit go?

What happens to your test edit next

The next scheduled run downloads the real page again and overwrites your reworded sentence.

That restore is a genuine content change, so it earns its own commit and its own diff. Your history stays honest without you tidying anything up.

You can now see every change as a set of moved lines. Next up, you will turn that commit history into a feed you can subscribe to in a reader.

Publish an Atom Feed with GitHub Pages

Your repo now holds a full history of the prompt, and GitHub renders each change as a line by line diff.

Right now you only find out about a change by going and looking. A feed flips that around, so a new version arrives in your reader without you checking.

In this step you'll turn the commit log into an Atom feed and put it online with GitHub Pages.

In this step, get ready to:

Generate an Atom feed from your commit history.
Publish the feed with GitHub Pages.
Subscribe to the feed and see one entry per change.

Turn your commit log into an Atom feed

What is an Atom feed?

An Atom feed is an XML file listing dated entries, one per thing that happened.

Readers poll that file and show you what is new since last time. Your commit history is already a dated list of changes, so it maps onto the format almost directly.

Switch back to the terminal in your repo folder from earlier.
Create the feed script by running this command:

touch make-feed.sh

Confirm the file exists by running:

ls

You should see make-feed.sh listed next to fetch.sh and your snapshot file.

Open make-feed.sh in the editor you used for fetch.sh.
Describe the feed itself by pasting this into make-feed.sh:

#!/bin/bash

# The file whose history becomes the feed
SNAPSHOT=[[SNAPSHOT_FILE="your snapshot file name"]]

# Where the feed and its commits live once they are published
FEED_URL="https://[[GITHUB_USERNAME="your github username"]].github.io/[[REPO_NAME="your repo name"]]/feed.xml"
REPO_URL="https://github.com/[[GITHUB_USERNAME="your github username"]]/[[REPO_NAME="your repo name"]]"

# Open the Atom document and describe the feed itself
cat > feed.xml <<EOF
<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
  <title>System prompt changes</title>
  <id>$FEED_URL</id>
  <link href="$FEED_URL" rel="self"/>
  <updated>$(date -u +%Y-%m-%dT%H:%M:%SZ)</updated>
EOF

What does this code do?

SNAPSHOT holds the name of the file you are tracking, so the script reads the right history.
FEED_URL is the address the feed will live at once it is published, which readers use to identify it.
cat > feed.xml starts a fresh file every run, so the feed is rebuilt from scratch each time.
The date call stamps the feed with the moment you generated it, in the format Atom expects.

Save make-feed.sh.
Generate the feed so far and read it back by running these commands:

bash make-feed.sh
cat feed.xml

You should see the opening of an Atom document, stamped with the current time. It has no entries and no closing tag yet, which is exactly what the next chunk adds.

Seeing an empty file or a syntax error?

Check that the last line of the file is EOF on its own with no spaces in front of it. An indented closing marker leaves the here-document open and the shell never writes the file.

Still stuck? Why is my bash heredoc not writing the file?

Add one entry per commit by pasting this at the bottom of make-feed.sh:

# One entry for every commit that changed the snapshot file
git log --format="%H|%aI|%s" -- "$SNAPSHOT" | while IFS="|" read -r hash when subject; do
  cat >> feed.xml <<EOF
  <entry>
    <title>$subject</title>
    <id>urn:sha1:$hash</id>
    <updated>$when</updated>
    <link href="$REPO_URL/commit/$hash"/>
  </entry>
EOF
done

# Close the document so the XML is well formed
echo "</feed>" >> feed.xml

What does this code do?

git log --format="%H|%aI|%s" prints one line per commit with the hash, the date and the message, split by pipes.
-- "$SNAPSHOT" limits the history to commits that touched your snapshot file, so unrelated commits stay out of the feed.
The while loop reads those three fields into variables and appends one entry for each commit.
The commit hash doubles as the entry ID, so a reader shows each change once and never repeats it.

Before you run this, how many entries do you expect? Count the commits you have made that touched your snapshot file.

Save make-feed.sh.
Rebuild the feed and count its entries by running these commands:

bash make-feed.sh
grep -c "<entry>" feed.xml

The number should match your snapshot commits, including the first one and the sentence you edited by hand.

Counted 0 entries?

The name in SNAPSHOT has to match the committed file exactly, including its extension.

Run git log --oneline to see the file names your commits actually touched.

Still empty? Why does git log return nothing for my file path?

✔️ Awesome, I've got everything!

Great, double check you've saved make-feed.sh.

ⓧ I'd like to double check the full code

Scroll up and confirm both chunks are in the file, in this order:

The shebang, the SNAPSHOT and URL settings, and the cat > feed.xml block that opens the document.
The git log loop that appends entries, followed by the echo line that closes the feed.

Publish the feed with GitHub Pages

A feed is only useful once a reader can reach it over the internet. GitHub Pages serves files straight out of your repository at a public address.

Send the script and the feed to GitHub by running these commands:

git add make-feed.sh feed.xml
git commit -m "Add Atom feed"
git push

Refresh your repository page on GitHub. You should see feed.xml and make-feed.sh in the file list.

Push rejected?

Your scheduled workflow may have committed since your last pull. Run git pull to bring those commits down, then push again.

Different error? Why was my git push rejected?

Click **Settings** in the top row of tabs on your repository page.
Click Pages in the left sidebar, under Code, planning, and automation.
Under Build and deployment, set Source to Deploy from a branch.
Select main in the branch dropdown menu.
Leave the folder dropdown menu on /, the root of your repository.
Click Save.
Open the **Actions** tab and wait for the Pages deployment run to finish.

Return to the Pages settings page. It now shows the public address your site is live at.

Why your scheduled runs won't republish the page

Commits pushed by a GitHub Actions workflow that uses the GITHUB_TOKEN do not trigger a GitHub Pages build.

Your workflow keeps collecting snapshots either way. The published feed refreshes when you rerun make-feed.sh and push it yourself.

Open your feed in a reader

Before you open the address, what do you expect to see? Decide whether the browser will show raw tags or a formatted page.

Open your published feed by pasting this address into your browser:

https://[[GITHUB_USERNAME="your github username"]].github.io/[[REPO_NAME="your repo name"]]/feed.xml

Most browsers show the raw markup, so you should see your <entry> tags with a commit message and a date in each one.

Copy that address from your browser's URL bar.
Open your feed reader.
Paste the address wherever your reader asks for a feed URL to subscribe.

Your reader lists one entry per change, newest first. The sentence you edited by hand appears as its own entry, right where you made it.

Getting a 404 at the feed address?

The first deployment takes a minute or two. Check the Actions tab and wait for the Pages run to go green before reloading.

Also confirm feed.xml is visible on your repository page. Pages only serves files that are committed to the branch you selected.

Still a 404? Why is my GitHub Pages URL returning 404?

Secret mission

Track Every Published Prompt at Once

Your repo watches one page. Anthropic publishes several, and the one you are not watching is the one that changes. Turn your single-URL fetch into a list-driven loop so every prompt you care about gets its own snapshot and its own history.

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. Everything you built here sits on GitHub's free tier for public repositories, so nothing keeps billing you.

Resources you used:

Your GitHub repository, holding the Markdown snapshot, fetch.sh, the feed script, feed.xml, and the full commit history.
The scheduled GitHub Actions workflow at .github/workflows/fetch.yml.
Your GitHub Pages site serving feed.xml.
The local copy of the repository on your machine.

Keep everything running

No action needed. Choose this if you're still actively building, or if you want the workflow to carry on collecting versions while you're not looking.

Leave .github/workflows/fetch.yml on its schedule so new snapshots keep landing as commits.
Leave your Pages site published so your reader keeps picking up new entries from feed.xml.

What stays on your machine

Git and curl stay installed on your laptop. Both are general purpose tools you'll use again, so there's no reason to remove them.

Pause - I'll come back to this later

Stop the scheduled runs and take the feed off the public web, while keeping every snapshot and commit you've collected so far.

Open .github/workflows/fetch.yml in your editor.
Delete the schedule trigger, leaving workflow_dispatch in place so you can still run it by hand later.
Save the file.
Stop the scheduled runs by running these commands:

git add .github/workflows/fetch.yml
git commit -m "Pause scheduled fetches"
git push

Your feed stays readable by anyone until you turn Pages off too.

Open your repository on GitHub.
Click the Settings tab.
Click Pages in the left sidebar.
Set the branch selector to None, then save so feed.xml stops being served publicly.

Delete - I don't want to use this again

Remove all project resources and start fresh. This wipes the snapshots, the commit history, and the feed.

Open your repository on GitHub.
Click the Settings tab.
Scroll to the Danger Zone at the bottom of the page.
Click Delete this repository.
Type the repository name when prompted to confirm.

Deleting the repository takes the scheduled workflow and the Pages site with it. There is nothing left running on GitHub afterwards.

Remove your local copy on macOS or Linux by running this command:

rm -rf [[REPO_PATH="path to your repository folder"]]

Remove your local copy on Windows by running this command:

rmdir /s /q [[REPO_PATH="path to your repository folder"]]

Confirm the folder is gone by running ls in the folder that used to contain it.

Nice Work!

Nice Work

Nice work! You've built a repository that watches a published AI system prompt and turns every wording change into a subscribable feed.

The workflow keeps running on its schedule while you get on with other things.

You've learned how to:

Download a published page as plain Markdown with curl and store it as a snapshot you can compare against later.
Write fetch.sh so it commits only when the text actually changed, then read the resulting diff on GitHub line by line.
Put the whole thing on autopilot with a scheduled GitHub Actions workflow, and publish feed.xml as an Atom feed through GitHub Pages.
Secret Mission: You took on the optional challenge and pushed your tracking repo past what the steps asked for.

Ready to quiz yourself?