How SoulBit AI writes this blog

Until this fall I wrote every post on this blog myself. Each post took me hours of finding out what had changed and testing with my own tools, and on top of that WordPress took time: keeping the site up to date by hand and fine-tuning it. Those were the reasons to look for another solution. Since 11 October 2026 soulbit.nl runs as a static site, and AI assistants write the posts. I read every post and publish it myself.

After the switch, SoulBit AI went through the posts I had written earlier: against the current documentation of Microsoft and Apple, with sources, and almost all of them in the style and structure of the new posts. That is why those posts now carry the SoulBit AI label too.

Updated on 27 October 2026: Anthropic now calls routines “scheduled tasks”, and a few sentences now say more precisely what the documentation says and what my own test showed.

In this blog post you read why this works for me and how it is set up: the hosting, how I keep the site secure, the rules the AI follows, how a post comes about, the dashboard for my own posts, and what building, testing and steering took in the first week.

Why this works for me

The routines follow my field for me: every week a change in Intune, Entra ID, Defender, Windows or at Apple reaches me as a post. Because I read and check every post, I keep up as well. So the blog is not only something for readers, but also a way to keep my own knowledge current.

For a post about a new feature I test it in my own test tenant, among other things for the screenshots. Setting that up helps me configure the feature myself and understand right away how it works. That may well be the most valuable part to me: the AI does the research, and I learn from checking it and setting it up.

What is SoulBit AI?

SoulBit AI is the name under which AI assistants write on this site. They work in a copy of the site’s source code: they read the documentation of Microsoft and Apple, write a post in Markdown and offer it as a pull request in GitHub. Posts with that label are drafted by AI; I check them and remain responsible for the content.

What do you need?

• A Claude subscription with scheduled tasks, formerly called routines: Pro, Max, Team or Enterprise. I use Claude Code, Anthropic’s coding agent. Routines are a research preview; behavior and limits can change.
• A GitHub repository with the site, with the Claude GitHub App on it if a routine has to respond to events in GitHub.
• A cloud environment whose network access allows the domains of your sources. The default list mainly covers package sources and domains for development work.
• Hosting that serves static files and allows uploads with a key.

From WordPress to a static site

I chose a static site: plain HTML files, built from Markdown in the repository, without PHP or a database on the server. The site is on ordinary web hosting, and the files get there over an encrypted connection with a key.

The switch was quick: the build and the move happened on the same day. WordPress stayed on the server for a while afterwards, so I could go back, and has since been removed. The existing posts kept their address, and most WordPress addresses that went away redirect.

How I keep the site secure

A static site has little attack surface: no database, no sign-in page for visitors, no plugins and no forms. What remains is mostly in the path to the hosting, the code that builds the site and the dashboard I sign in to myself.

• The key stays outside the AI. The key for the upload is stored as a secret in GitHub Actions. An AI session does not need it and never reads it; that is a fixed rule. After a merge, GitHub builds the site and puts the files on the hosting with that key.
• Building and uploading are separate. The build runs without secrets, and the upload runs no code from a pull request.
• A code review and a red team test from time to time. I have the AI review the code and attack the site the way an attacker would. One such test already found a weak spot in the way of uploading, and it was closed right away.
• Monthly maintenance. A routine proposes updates of the components every month and checks them for known vulnerabilities; I merge them myself.

The rules are in the repository

Every session starts with an empty context window. What the AI needs to know is therefore in files in the repository: CLAUDE.md is loaded at the start of every session, and the skills tell the AI which other files to read.

• CLAUDE.md with thirteen fixed rules: never publish on its own, an official source for every fact, no data of clients, no passwords or keys.
• Skills in .claude/skills/: a fixed way of working per kind of task, such as a new post or a maintenance round. The full text of a skill is only loaded when it is used.
• A style guide, a post format and a short report of every run that opened a pull request, in docs/run-log/. That report is the memory between runs.

Most of the work was not in the code, but in the steering. Every correction I gave had to end up in a file; an agreement that only exists in a conversation is not seen by the next run. That is how rules were added about writing style, framing and how a session reads websites. According to the documentation these files are context and not enforced configuration, and instructions are followed more consistently the more concrete and shorter they are. That is why the rules are short and numbered.

💡 Between 11 and 17 October 2026 there were 110 pull requests, of which 84 were merged. That gives an idea of how much steering a setup like this takes in the first week.

How a post comes about

The work runs in routines: a saved prompt with a repository and connections, which starts on a schedule, through an API call or on an event in GitHub.

1. A new post, weekly for now. The routine picks a topic, first from the topics I have lined up, and reads the sources.
2. The fact check. A separate subagent holds every statement against the source. It works in its own context window and does not see the writer’s conversation. Since 13 October it also looks at the post as a whole: does the introduction promise more than the sources?
3. The pull request. The post goes on its own branch, with the sources, the findings of the fact check, open questions and a preview of the site.
4. Maintenance, monthly. All posts were already checked when they were written or when the site was built, so this round is pure maintenance. Another routine holds up to six published posts against the current documentation every month, the ones not checked for the longest first, and opens a pull request for at most two posts that need revising; the rest follows in a next round.

A dashboard for my own posts

I also wanted to be able to write posts myself and give the AI assignments, without working in GitHub. Because the site is static, a dashboard cannot be a program on the server. So I chose a CMS that works with GitHub directly from the browser and needs no server of its own.

Everything I save in the dashboard becomes a branch and pull request of its own; publishing is merging that pull request. With one button I mark a draft ready for review, and that starts a routine that reviews the draft or carries out an assignment. If the dashboard ever fails, I can simply edit the posts in GitHub itself.

Testing: what I ran into

Every pull request that changes the site gets a preview, so I see a post the way it will be published. On top of that I tested the connections myself, and three things went differently than I expected:

• Network access. The first scheduled run could not open the documentation of Microsoft and Apple. A routine only fetches web pages from the domains the cloud environment allows. After adding those domains, the first post came the same day.
• A draft did not start a routine. The dashboard opens every pull request as a draft first. In my test on 13 October the routine did not start on it; only when the pull request became ready for review did it run, within half a minute. The documentation offers an “Is draft” filter for this; my routines now start on ready for review.
• A connection was missing in a routine. Writing together in a shared document worked in a normal session, but in my routine the AI did not get the tools of that document connector. I now only do that in a session I am part of.

I also had the first post read by another AI model. The main findings were about framing, not about facts: the introduction promised more than the sources. That is why the fact check now also looks at the post as a whole.

I publish myself

The AI may never merge on its own, that is a fixed rule; a post goes online when I merge the pull request. I read the post in the preview, ask for changes if needed and answer the open questions. That also works as a filter: of the sixteen pull requests with a new post from the first week, I published eleven and closed five, for example because I preferred to update an existing post rather than put a new one next to it.

Wrapping up

The AI writes, finds the sources and has every post checked; I decide what goes online. The rules, the ways of working and the log are in the repository, so every run starts with the same instructions and I can read back the work of every run.