How Claude Is Automating My Weekly Life: Three GitHub Repos as Exhibits

Part of My Weekends Used to Be a Manual Chore

I'm pretty involved in my church.  Some of what I do is to manage the website and the TV screens in the foyer.  Every week, same drill. Hunt down the YouTube link for the sermon. Open my notes, copy the title, copy the scripture reference. Log into Drupal, create a new node, paste it all in, map the fields, save. Then rebuild the weekly events slide — pull the Google Doc, grab the calendar block, format it into HTML, push it live. And then do it all again next Sunday. And the Sunday after that.

It wasn't hard work. But it was always-there work — the low-stakes, high-repetition kind that quietly eats your weekend mornings. The kind of task that feels beneath automating because "it only takes fifteen minutes." Then you do the math: fifteen minutes every single week is thirteen hours a year of copy-pasting scripture references. Yikes.

So I started building with Claude. Not chatting with it. Building with it — as a software author. The kind of partner who writes the Python, designs the GitHub Actions YAML, figures out the Drupal field-mapping, and ships working code end to end. The result: three open-source repos that have quietly taken over my weekly cadence. Let me walk you through how they work, what Claude actually built, and why I think this pattern matters well beyond Sunday mornings.

The Setup: Free GitHub Actions, Plain Python, Zero Runtime Cost

Before we dive into the individual repos, a quick note on the infrastructure — because this is part of what makes the approach accessible. All three automations run on free GitHub Actions cron jobs. No server to maintain. No paid cloud function. No Zapier subscription. GitHub's free tier supports scheduled workflows on public repos, and each of these takes full advantage of that.

The language is plain Python. No fancy frameworks, no AI at runtime. Claude is the author and maintainer of every script — it wrote the code, it wrote the workflow YAML, it reasoned through the edge cases. But when the cron fires at 9am on Thursday, it's just a Python process doing IMAP calls, regex parsing, and HTTP requests. The AI involvement is entirely up-front, in the authorship phase. Not at runtime. This is a really important distinction, and it's worth pausing on: Claude built the automation; Claude does not run the automation. That boundary matters for both cost and reliability.

This pattern — AI-authored, deterministic-at-runtime — is increasingly how serious automation gets built. Developers in coding communities have noticed that the trick to making Claude genuinely useful across a full project is giving it complete context up front, so it can reason about all the moving parts at once.  These three repos embody that idea exactly. Claude understood the full pipeline — data source to CMS output — before writing a single line.

Repo 1: sunday-message — The Sermon Slide Ships Thursday at 9am

The first repo, sunday-message, fires every Thursday at 9am Eastern. Its job is simple: read a weekly email, extract the upcoming sermon's title and Scripture reference, update a website, and commit the change. By 9am Thursday, the Sunday message page is already live — four days before the service. That's the part I love.  Our TV's in the foyer display the main page from the site automatically - job done.

Here's what Claude had to figure out to make this work reliably:

• IMAP email access in Python. Connecting to the inbox, finding the right message, reading the body programmatically. Not hard once you've done it, but a steep first time.
• Quote normalization in regex. Sermon titles in email copy show up with inconsistent quotation marks. Curly/smart quotes (" ") and straight quotes (") both appear depending on who typed the email and what device they used. Claude wrote regex patterns that handle both, so the title parse never trips on a typographic quirk.
• Scripture references with book prefixes. A reference like "1 Corinthians 13:4-7" is non-trivial to regex, because the book name starts with a digit. The pattern has to anchor on that digit, capture the full book name, and handle the chapter-and-verse range correctly. Claude got this on the first pass.
• Comment-anchored HTML placeholders. Instead of search-and-replace, the HTML uses comment markers as insertion points (<!-- SERMON_TITLE --> style). The Python finds those anchors and slots the new content between them. The surrounding HTML never gets accidentally mangled.
• Automated git commit and push. The workflow commits the changed HTML and pushes it back, which triggers the static site to rebuild and redeploy. The site updates itself.

The whole script, the YAML, the placeholder structure — all authored by Claude. This is the kind of project that would have taken a capable developer several focused hours to build from scratch. IMAP alone has a steep learning curve, and getting the regex edge cases right would probably need a few debugging sessions. Claude knocked it out cleanly.

Repo 2: sunday-calendar — The Events Slide Ships Friday at 10pm

The second repo, sunday-calendar, fires every Friday at 10pm Eastern. Its job: pull a Google Doc named for the upcoming Sunday, extract the week's events, and render an HTML slide with a background image. By Saturday morning, the events slide is staged and ready to go.  It's pulled to the foyer TV's the same way.

The challenges here are different from repo 1:

• Google Drive API authentication. Service account credentials, OAuth scope config, the actual Drive API calls to locate and read a document by name. Claude handled the full auth setup, not just the API calls.
• Dynamic document naming. The doc is named for the upcoming Sunday's date, so the script has to first calculate "what Sunday is next week" and build the correct title before it can find the doc.
• Dash-variant regex. Here's a fun one. The events are formatted with dash separators, but human typists use three different characters interchangeably: a hyphen-minus (-), an en dash (–), and an em dash (—). Claude's regex normalizes all three, so the parser never misses an entry because someone used an em dash instead of a hyphen. That's exactly the kind of detail that breaks naive scripts in week three.
• HTML slide rendering with a background image. The extracted events get rendered into a styled HTML page built to display on a screen during the service. Claude wrote the layout and the CSS, not just the data extraction.
• Conditional commit logic. This is the detail I want to highlight, because it separates a professional automation from a naive one. The script only commits and pushes if the content has actually changed since the last run. If the doc hasn't been updated, the workflow exits cleanly without creating a meaningless Git commit. The repo history stays meaningful.

That conditional commit reflects a level of design thinking that's easy to skip when you're building quickly. Claude included it unprompted, as part of the end-to-end solution. That's the kind of thing I want from a software author.

Repo 3: sunday-video — The Sermon Node Creates Itself on Sunday at 10am

The third repo, sunday-video, is the most technically sophisticated of the bunch. It fires Sunday at 10am Eastern — right around the time the livestream begins — and creates a complete Drupal 10 sermon node with zero manual input.

The challenge: real-world timing uncertainty. The sermon may not be live on YouTube at exactly 10am. The stream might start a few minutes late. A naive automation would fail silently and you'd have no sermon page on Monday. Claude's fix is a polling loop:

• YouTube polling with yt-dlp. The script polls the channel up to five times on a 60-second interval, looking for the new video. If the stream isn't live yet, it waits and retries. If it finds the video in the retry window, great — it proceeds. Otherwise it exits with a clear failure signal so you know to check.
• BeautifulSoup scraping for metadata. Once the video is found, the script scrapes the sunday-sermon page (above) to extract the sermon title and scripture reference. BeautifulSoup handles the HTML parsing cleanly.
• Drupal 10 JSON:API with HTTP Basic Auth. Creating a content node via Drupal's JSON:API requires correct field-mapping for the specific content type, proper auth headers, and well-formed JSON payloads. Claude mapped every field for the sermon content type, including the embedded video and metadata fields. If you've ever fought Drupal's JSON:API, you know this is not nothing.
• Speaker UUID lookup. Drupal stores entity references by UUID, not by name. The script looks up the speaker's UUID dynamically before building the node payload. That means the automation works correctly even when different speakers preach in different weeks.

The end result: by 10am Sunday, the sermon node exists in Drupal with the correct title, scripture, speaker, and embedded video — all sourced and created automatically while the service is actively happening. The before-and-after is stark. Sunday morning used to mean a post-service scramble to find the YouTube link, extract the metadata from notes, log into Drupal, and manually build the node. Now it's done before the final hymn.

The Meta Layer: This Blog Post Is the Same Pattern

There's one more layer worth naming, because it makes the point cleaner than any analogy could: this blog post itself is an exhibit of the same architecture.

It was produced by a Claude skill called /drupal-blog. That skill researches the topic using Firecrawl web scraping, drafts the post, humanizes the language, fact-checks claims against the sources, re-writes it using my defined "tone", generates a hero image via OpenAI, and publishes directly to Drupal via JSON:API — the same endpoint sunday-video uses to create sermon nodes. Different content type. Identical pattern.

The community building in this space has noticed that the Claude-plus-GitHub pattern is becoming genuinely powerful. Developers are using Claude to author agents that push code, open pull requests, and kick off review workflows automatically.  The through-line is always the same: Claude authors the logic once, and then deterministic code runs it forever at zero marginal cost.

Claude Code's docs describe routines as a way to automate recurring work — the kind of tasks that happen on a schedule and follow predictable steps.  That's exactly what these three repos represent. Recurring work, predictable steps, now delegated entirely to code Claude wrote.

What This Actually Changes (and What It Doesn't)

It's worth being precise about what automation like this does and doesn't do. These three repos don't replace judgment. They don't decide what the sermon topic should be, or which events belong on the calendar, or whether a particular video should be featured. All of those decisions remain human. What the repos replace is the mechanical execution that comes after the decisions are made — the copy-pasting, the node creation, the slide updating, the commit-and-push cycle.

That boundary — human judgment in, mechanical execution out — is where AI automation currently shines. The research on AI-assisted automation consistently shows the highest-value applications are the ones that eliminate repetitive, low-variance tasks while leaving context-and-judgment work to humans.^[6] In my opinion, that's the sweet spot. And it's reachable today, with tools you already have.

On the practical question of cost: all three repos run entirely on GitHub Actions' free tier. The Python dependencies (yt-dlp, BeautifulSoup, the Google Drive client library, the requests library for Drupal's JSON:API) are standard open-source packages. No subscription. No server. No ongoing infrastructure cost. The only investment was the time Claude spent writing the code, and across all three repos that was a matter of focused hours, not days.

How to Think About Building Your Own Version

If you're an AI-curious reader and you're wondering whether something similar could work for your weekly repetitive tasks, the answer is almost certainly yes — provided your tasks have a few properties:

• They happen on a schedule. Cron automation needs predictable timing. If the task happens "whenever," you'll need a different trigger model.
• The inputs come from a consistent source. All three repos read from well-defined sources: an email inbox, a Google Doc with a naming convention, a YouTube channel. "Check wherever the data might be" is much harder to automate than "check this specific place."
• The output is structured and repeatable. Creating a Drupal node, updating an HTML file, committing to a repo — these outputs all have known schemas. Automation works best when you can describe exactly what "done" looks like.
• Failure modes are acceptable or monitorable. The retry loop in sunday-video is a good example of explicitly handling a known failure mode. Build in logging, and you'll know when something goes wrong before anyone else does.

Here's the best tip I can give you: start with the simplest version of your task. Describe it to Claude in full — the data source, the transformation, the output, the edge cases you've already hit. Let Claude author the Python and the GitHub Actions YAML. Run it manually a few times before you trust the cron. Then let it go.

The Automation Already Shipped

Thursday at 9am, the sermon slide is live. Friday at 10pm, the events calendar is updated. Sunday at 10am, the sermon node creates itself in Drupal. And on Sunday morning, I'm actually listening to the sermon — because the mechanical work is already done.

Three repos, three free cron jobs, plain Python, and a Claude instance that wrote every line.  That's the whole pitch: the cost of automating something you do every week is now low enough that not automating it is the more expensive choice.

If you want to poke at the repos directly, they're all public on GitHub: sunday-message, sunday-calendar, and sunday-video. The code is the documentation. Claude can explain any of it — and can probably adapt it to your use case faster than you'd expect. We're in this together.