In a previous post I described handing management of my homelab over to Claude Cowork, checking for software updates, validating config changes, and rolling back when something goes wrong. That’s the day-to-day loop. What I haven’t written about yet is the layer underneath it: a custom “skill” I built that gives Claude a written memory of how my homelab actually works, so it stops re-learning the same lessons the hard way.

What a skill actually is

A skill is just a file, mostly plain markdown, that Claude reads before doing a certain kind of task. Think of it as a runbook, except it’s written for an AI instead of for a person joining the team. You tell Claude when to load it (“before touching this project” or “before editing this config”) and what’s in it, and it uses that as context for the work instead of starting from a blank slate every time.

One reason skills are important: Claude starts from zero every time

This is the part that isn’t obvious if you haven’t spent time thinking about how these tools actually work under the hood. Every new session starts with far less understanding of what’s going on than you’d assume from talking to it. There’s no persistent memory of your specific setup carrying over on its own from one conversation to the next.

It’s a bit like the difference between asking a baker to make a cake and asking someone who has never baked before to do it. The experienced baker needs almost no instruction, they already carry all the context. The person who has never done it needs the recipe, the technique, and probably a few warnings about what goes wrong if you skip a step. Claude, at the start of a new session, is a lot closer to that second person than people tend to assume.

Here’s the mechanical reason why: every request sent to Claude, or any LLM, has to include all of the relevant context for that conversation, every time. There’s no running memory sitting in the background filling in gaps on its own (caching aside, that’s a separate detail and doesn’t change the basic point).

It’s not only new sessions either. Context can also thin out mid-session, once a conversation runs long enough that older parts get compacted to make room for new ones. Either way, the specific details I’d rather not have to repeat, or worse, have quietly dropped partway through a long working session, are exactly what a skill is meant to protect against. I built my home lab skill because I wanted my home lab’s context encoded somewhere durable that I could call on whenever I needed it, rather than trusting that a given session would still have all of it in view the next time I needed something done. Additionally, keeping the home lab context in a file ensures I can call upon the information during any session, whether I started it manually or through a scheduled task.

How I actually built it

Rather than write the skill file by hand, I built it conversationally. I opened a chat with Claude and set the expectation up front: “In this session I am going to describe to you how my home lab is setup. What the major components are, how to access them, and then build out some of the major components involved. The intent in the end is to build out a skill you can use to help me manage my home lab.”

From there I just talked it through, the same way I’d walk a new hire through the environment on their first day:

• I described my Proxmox cluster, two nodes plus a quorum device running on a small always-on Pi, and that Claude could reach everything over SSH through the macOS shell MCP, with the Proxmox CLI tools available on either cluster member.
• I explained that once a VM is found, it’s reachable the same way over SSH, and that every VM is provisioned through cloud-init.
• I walked through the k3s cluster: how to access it, and specifically how to upgrade it.
• I pointed out that GitLab is reachable the same way, through the same MCP using glab, and that a specific repository, flux-learning, is what actually manages the software running in k3s.
• I spelled out the upgrade procedure I wanted followed exactly: check whether a Helm chart update requires any configuration changes first. If it does, stop and flag it for me rather than guess. If it doesn’t, upgrade one patch release at a time, confirming the service is still available at each step before moving to the next.
• I flagged the components that need extra care, especially the CSI drivers that connect to TrueNAS for storage, and made clear that TrueNAS itself is the single most important system in the whole environment. If anything is going to get careful treatment, it’s that.

That one conversation became the seed of the skill file. Claude turned what I described into the actual reference document, and I’ve refined it since as new gotchas turn up.

That’s how I ended up with the specific rules that are actually in the file today, things like:

• Which SSH key is used for which generation of hosts, and the rule to always verify the actual key fingerprint on the target host rather than trusting a file that maps hosts to key names. This is important because some of my VMs run older operating systems while others run newer versions. The newer versions want ed25519 keys instead of the older RSA based keys.
• The fact that I run two separate Kubernetes clusters, not one, and which one a given service actually lives in.
• Conventions for how my reverse proxy is configured, including a couple of gotchas that produce confusing, silent failures if you don’t know to look for them.
• A blunt reminder, based on real experience, to verify before “correcting” anything that looks like it doesn’t match the rest of the fleet.

None of this is exotic. It’s the accumulated scar tissue of a home lab that’s grown over time and has a few intentional exceptions mixed in with the accidents.

Don’t forget that AI is not human

In this post I have used words like “learn” and “remember” and it’s tempting to picture Claude as something quietly sitting there, mulling things over between conversations. That’s not what’s happening. Claude isn’t awake on a Sunday afternoon wondering how my cluster is doing. It’s a tool that responds to events and nothing more. Something triggers it, a message I send, a scheduled Cowork job kicking off, a webhook firing, and it processes that one event using whatever context comes along with it. Except when a task requires waking up later to check on results, when that request finishes, there’s no computation left running in the background, no thinking happening, no waiting around.

The state does exist though, in various forms, that’s the whole point of the skill file and the rest of the memory system, it just doesn’t live inside Claude the way it would in something with a continuous inner life. It lives externally, in files, in memory during a session, and gets handed back in as part of the context on the next request. So there is an ongoing record of what’s been learned, it’s just sitting in storage rather than being actively thought about while nothing is happening. The difference matters: nothing is being pondered between sessions, but the accumulated understanding hasn’t gone anywhere either, it’s just waiting to be read back in.

I don’t think this makes it less useful. If anything, it makes it easier to reason about. A tool that reacts predictably to whatever input and context it’s given is simpler to trust than one you’ve started imagining has moods, motivations, or a life going on when you’re not looking. It’s not a coworker quietly thinking about my proxy server in the background, it’s closer to a very capable specialist who shows up completely for exactly as long as the job takes, reads the notes that were left for them, does the work, and then is gone until the next event calls them back.

One practical consequence of all this, outside of whatever a skill or the broader memory system supplies: two separate chat windows, with no shared skill or memory feeding them the same context, can end up behaving quite differently from each other, even contradicting one another, on what looks like the same question. It’s not being inconsistent in the way a person with a bad memory might be, there’s no single Claude comparing notes with itself in the background. Each window is only as good as the context it happens to be carrying, and if that context differs, the answers reasonably can too. That’s actually another argument for skills and memory being worth the effort, they’re what make behavior consistent across sessions, and even across different people on the same team, rather than leaving it to whatever context each conversation happened to accumulate on its own.

There is an advanced edge case where you can train a model further with your specific data, but that’s beyond what most people would ever need to do.

In general

Claude handles the ongoing maintenance loop. The skill is more like giving Claude the notes I’d hand a new person if they were about to touch this infrastructure for the first time, so it doesn’t have to relearn the same lessons I already paid for. I expect this file to keep growing as new gotchas turn up, which is really just the normal cost of running anything for long enough.

This post was coauthored with Claude. If you have any thoughts or feel I got anything wrong, let me know in the comments.