Today I’m taking you on a field trip on how I built my first two custom slash commands for Claude Code.

I apparently slept under a rock regarding custom slash commands since they’ve been available for a long time. Boris Cherny mentioned them in a video I linked earlier, which made me aware.

The first custom command I wrote last week is named /make-ci-happy. It’s a simple prompt that informs the agent how to run all the tests on Ci locally. It also gives guardrails on what to fix and escalate back to me. Because this isn’t Claude’s standard behavior, it became a repetitive task I had to carefully repeat every time before committing. It’s of course highly tailored to this repository, so it’s a custom / command only available here. It’s an elegant system to have slash commands available on your machine, or only per repository.

So this is nice and helps me every day a little bit. But I wanted to see how far I can take this. I’m getting nearer to the public release of my TreeOS open source software. It’s written in Go and compiles to a binary for macOS and Linux. It has a self-update mechanism built in. Most mechanisms use a JSON on a server, which the binary queries. It’s better to control this JSON and not rely on the GitHub releases page. My repository’s source code isn’t ready, and I haven’t settled on a license. Still, I want to test the update mechanism first. This is possible via a second public repository and some GitHub Actions magic. It builds the release in one repository but pushes the artifacts to another. At the same time, the JSON needs to be updated, which lies in a different repository. For new stable releases I want to adapt the JSON and add a blog post. If this sounds complicated, it is. The perfect problem to automate via custom slash commands.

The best way to build custom slash commands is to ask Claude Code to build them. Ask it to read the documentation first, because the knowledge about slash commands isn’t in the model. I named this command /treeos-release to create a namespace for my custom commands and made it available on my whole system. The paths to the needed repositories are hardcoded inside the script.

You might think this isn’t proper engineering with hardwiring it to one system. Probably you’re right. Since I don’t see the need to run the script elsewhere than on my computer, it’s fine for now. One of the main advantages of working with Coding Agents is everything can be more fluid and brittle in the beginning. I can make it more stable later, if needed.

Thee Result? Within a few minutes, I had a script. It didn’t work correctly. I reported this to Claude, who fixed it. On the second try, I shipped the first beta to the public repository. Yay!

Upon closer inspection, it fell apart again. For further testing, I continued creating a stable release on top of the beta release. This failed, and it turned out the first invocation of the slash command hadn’t used the created script at all. Claude Code had done it all by itself! We modified it together and added the following warning:

In short, it needed a few more repetitions until I was happy with the script. I ended up splitting it into multiple scripts, because making Claude Code patiently wait for CI is hard. Overall, it’s an interesting work style, because Claude can finish the work of a half-baked script if needed. This allows iterative improvement of the script while continuing with the main work.

I highly recommend custom slash commands. It’s a well-thought-out system that integrates nicely into Claude Code. Creating and debugging the slash commands are easy. Start with your most repetitive tasks, ensuring every command runs a main script to increase result consistency.

You could argue that these scripts lock you into Claude Code versus other coding agents. While that is true, I don’t think it will be challenging for any other agent to copy my existing code/commands to their system, as long as the systems are similar.

Ultimately, Claude Code is a motivated but average developer. Like most average developers I’ve worked with, including myself, they usually need a few attempts to get it right.

Oh, and regarding the first binary of TreeOS visible above: It would probably work on your machine, but I haven’t created concise documentation for Mac or Linux, so I can’t recommend it. If you’re interested, reply to this email and I’ll add you to the early alpha testers. 👊

Home servers are back and many cloud computing offerings are a complete rip-off: DHH discovered the same seismic changes this year, and he’s a genius marketer.

David Heinemeier Hansson, or DHH in short, must live in the same social media bubble as I do, our most important topics overlap this year: home servers are on the cusp of becoming a serious alternative to cloud offerings and the cloud is turning into an expensive joke. Also, like me, he holds a serious grudge against Apple. #fuckapple

It used to be that home servers were kind of a joke. That’s because all home computers were a joke. Intel dominated the scene with no real competition. SSDs were tiny or nonexistent. This made computers and notebooks were power-hungry, hot, and slooow. The M-series CPUs from Apple are not even 5 years old. Also only in the last 5 years AMD got their shit together and started shipping serious consumer CPUs.

So you could have a home server, but they were slow machines. Plus, your internet connection was also slow. Most people had asynchronous DSL connections with maybe okayish download speeds and totally underpowered upload speeds. Accessing your server from the outside was a pain in the ass. I remember running Plex on my home server 10 years ago and watching a video on my mobile phone, in bad resolution. I don’t remember the bigger bottleneck: the slow CPU transcoding or my slow upload speed.

Back to 2025, this has changed dramatically. Many homes upgraded to fiber connections, providing fast up- and download speeds. Well-manufactured mini PCs are available cheaply. While Mac minis can be a valid option for fast compute, AMD has gotten serious about this niche with their AI 395+ flagship CPU with integrated graphics and 128GB of shared RAM. These machines are not a joke anymore. If your use cases require a lot of RAM, like local LLM inference, going back to the edge aka your home becomes an interesting alternative.

And then we haven’t started talking about sovereignty and independence from unpredictable vendors or countries…

I wholeheartedly recommend DHH’s full talk, it’s a very energetic fuck you to the “modern stack” in general and Apple in particular.

I’ll start a weekly newsletter called “The Liquid Engineer” next week. What does it mean and what will it cover? Read on or subscribe here if you’re sold already… 😂

❓What’s the meaning behind the name?

🫠 Liquid. Why is software called software? The term was coined in the mid-1900s in contrast to hardware, which is quite hard to change. So softness is related to the changeability and updateability of the code. Fun fact: This also explains the term firmware, the low-level software layer that controls hardware. It’s a special kind of software that’s a bit harder: firm.

Today, software encompasses a huge bandwidth of softness. You can still buy software on CDs and DVDs, especially games. This code never changes. You have apps on your computer or phone updated weekly or monthly. And you’re interacting with server-side software via your browser or app, updated 10s, 100s, or 1000s of times a day, e.g. on Google’s, Meta’s or Netflix’s servers.

So software is becoming more and more fluid, it is becoming liquid. But software is only one of the many interesting fields of engineering, and the same applies to almost all other fields. Zara, the fashion brand, produces clothes in Europe to speed up cycle phases and react quicker to demands and trends. Just to make one example, more to come in the newsletter.

⚙️ Engineer: Engineering is a huge part of my life. I always liked to create things. Engineering sounds like a very lonely job in front of the computer. Actually it’s a team activity involving a lot of communication with the team and customers. There is always the same process behind it, from building Lego to engineering huge software projects. It can be broken down into three steps:

💡 It starts with thinking about a possible solution to a hopefully real problem. This involves seeing the problem, identifying it as solvable with current technologies, and imagining a solution.

💪 Then comes the act of building, be it with tools and hands or a keyboard and computer. For most of us, it’s more rewarding to build with our hands. This is the addictive fun part, because you can get absurd amounts of flow state out of it.

🧐 Next is the testing phase, where we assess our solution. It’s never perfect, triggering the next thinking phase. And so the cycle continues.

Repeating this cycle leads to more sophisticated solutions. The time it takes to go through one full cycle has a huge impact on the quality of the solution.

❓What’s the newsletter about?

Now comes the confusing part: It will be about 3D printing! It’s a magical technology that makes mechanical engineering much more like software. It’s also a great visualization of how software principles spread into our everyday world.

Subscribe here, if you haven’t already!

Yes, I’m out, too. After over thirteen years at XING. What. A. Ride! Grab a coffee, this deserves a longer-than-usual goodbye post.

Back then in 2011, StudiVZ was dying, and almost everybody questioned my job choice. Thanks to Jochen Kramer for coaching me before the interview, explaining the XING culture and giving me confidence that this is the right fit. And thanks to Alexander Greim for hiring me and being my boss for the first 10 years.

📱 XING iOS App

We built and grew the XING iOS app from an agency-built dumpster fire to the most used contact point for the XING B2C brand. In just a few years, we built a great XING Mobile Team. The most fun team I ever worked with. Sorry, other teams. Despite building 3 products with the mobile web app, Android and iOS native apps, there was healthy competition and high respect for the others’ work. We helped each other when we broke the live environment again and celebrated our successes together.

Many engineers opposed native apps in the early years. Distributing software via app stores was wrong and archaic, killing the open web. The programming language Objective-C with all these brackets, really? With HTML5 just around the corner, it was also a totally useless effort to build this. The web would catch up anyway, and soon.

Turns out, there’s a difference between the most beautiful technology and what customers like to use. After years building frontend technologies, it’s still hard to explain why the web has such a cool tech stack yet makes it really hard to build beautiful products. But no flamewar today, please.

Also, it turned out it wasn’t a zero-sum game with only one winner. Mobile took the brand to places it could not go before. Mobile traffic peaks are usually right in the morning, in bed, at the breakfast table, during commute. The biggest peak is in the evening, on the couch, where you might be reading this post. A desktop experience couldn’t reach most users there. We extended the interaction time with the social network XING, benefiting the whole product.

🎨 XING Design System

Both my kids were born while I worked at XING. I couldn’t have picked a better employer for this time. Taking 6 months and then two years later 8 months of parental leave to share the care work with my wife? Coming back part-time after that? As a team leader? This was all not a problem at XING in 2016.

Fast forward to today, even 9 years later this feels like science fiction and voodoo and witchery altogether for most companies in Germany. While it’s gotten better for individual contributor roles, for leadership roles it’s still the simplest method to terminate even the most promising interviews: Just ask for part-time options. Try it if you want to get out of one early. It’s a topic for another post, but it illustrates the limited understanding of leadership in Germany where the leader is judged by the hours he contributes.

The design system team was a great chance to leave my iOS bubble and understand web and Android better. It was also my first leadership experience leading people on a technology they understand more than I. While this was scary at first, jumping over that cliff helped me become a more flexible leader. I could sense the team’s needs and adapt my style.

The promise of a design system is to hide platform differences and complexities, allowing a feature team to design once and build on all platforms easily. From a brand perspective, a strong corporate design and identity (CI & CD) are essential to stand out in the social media jungle.

Building this internal service team for all XING teams was fulfilling, despite more internal communication and stakeholder management than I would have ever expected. Creating consistency and a clear brand means fewer choices and less custom solutions. I hope nobody is still grumpy at me for some unpopular decisions back then.

🧮 XING Data Team

After ensuring each UI element, like a job recommendation, looked and felt the best it possibly could for years, the data team was a welcome break. Learning what made a recommendation climb to the top position was astonishing and underwhelming at the same time. There are no magic tricks in Data Science, just very solid engineering. I added more leadership styles to my skill set, including my favorite “I have no friggin idea what you’re doing, but keep explaining.”

🤔 What’s next?

So what’s next? I’m not looking for a new team yet. I have a few experiments planned, that I feel I need to do in the next months. Like my first weekly newsletter. Subscribe to the Liquid Engineer. It’s about how new technology hypes are born in general and 3D printing in specific. Your last chance to be someone who liked 3D printing before it was cool! 😎

I’m open for lunch or beers, just ping me!

KPIs are a business tool, only for the 9-5 grind? I thought so, too. Today, I love how they can create focus, also in the personal space. You can even communicate dependencies of goals clearly. I’ll use how I got into running last year as an example.

The obvious main KPI for the sport of running is to measure the distance each run and increase a bit each time. As a consequence, you will burn more calories and improve your fitness. Agreed, this sounds boring. When I started running, I chose 6 kilometers as my first goal distance. This was my thinking, put into a KPI:

🏃 KPI Attempt #1:
📈 Increase kilometers running per run from 6k to 10k over 3 months.

It’s boring because it often doesn’t reflect reality. We’re not machines that can output a few hundred more meters each run. Treating ourselves like that won’t get us the results we want.

It didn’t work at all. It was too much for my out-of-shape body, and I got severe headaches after each run. Instead of increasing my distance weekly, I found excuses not to start running. Instead of a trackable and empowering goal, I became demotivated.

I changed my running approach. Instead of focusing on kilometers, I focused on consistency first. Here, leading and lagging KPIs come into play. They capture a connection between indicators. Progress on the leading one will eventually move the lagging one:

🏃 KPI Attempt #2:
🔁 Leading KPI: Run weekly for 20 minutes for the next 3 months.
📈 Lagging KPI: Run 6k per week.

This became a better motivator. I felt good about running each week, even though the distances were short. It started to be fun! A bit later, I had enough energy to increase the distance.

After a year of running, I’ve made it a habit. I’m no longer tracking consistency because I want to run each week anyways. I am finally back at my initial KPI of increasing the distance. After all, our body is a bit like a machine, just a more complicated one…

Here’s what I learned:

💡 Start with one simple KPI. Treat it as a starting point and evolve it.
💡 KPIs need to work for you, too! Otherwise, they become a demotivator.
💡 If you can’t see progress on a KPI, consider adding a leading KPI.

After more than 12 years of working in software engineering, I decided I cannot live without my own blog anymore.

So here it is, let’s see where this goes.