In this series
- Why I modernized my homelab instead of upgrading it
- Making a homelab repository agent-friendly (this post)
Before an agent could work safely on the homelab, the repository needed to make the paved path—and its stopping points—visible.
In Part I, I decided to rebuild the homelab with Amp. However, before I trusted it with Kubernetes, I wanted a much safer place to start: this blog.
My prompt was: “Design an orb based blog writing and preview system which I can see posts live on the right hand side in the Portal, and publish when I say yes.” I wanted Amp to set everything up, show me the result and wait before publishing. That sounded simple. It turns out the repository first needed to explain how I actually work.
Start with a repeatable setup
Amp works in an isolated Orb, not on my laptop. Therefore, I pinned the tools and kept dependencies in lockfiles so every new Orb could build the blog the same way. I also put the common commands in the root Justfile. Now “run the checks” means just check, instead of a collection of commands I may or may not remember after six months.
This helped me too! A setup that is easy for Amp is usually easier for future Vincent.
Tell Amp when to stop
Next I added AGENTS.md files beside the code. They contain practical rules: beta is not production, a deployment does not include a DNS change, and inspecting a database does not mean writing to it. Checks that only need the repository run in the normal sandbox. Tasks that need my real cluster use a constrained runner inside my home network and an explicit Kubernetes context.
Those rules matter because this is not a demo cluster. It contains services and family data that I do not want an enthusiastic agent to “fix” unexpectedly.
The funniest test came when I told Amp to ship the blog and then wondered why nothing happened. It was waiting for the exact publication confirmation that I had required. I was annoyed for about ten seconds. Then I was very happy that it had listened!
Keep the useful procedures
Some jobs have too many important steps to remember, especially beta verification and production promotion. I recorded those as Agent Skills. Amp can follow the same reviewed sequence each time and stop if the image, health check or data check is wrong. The Skill describes the job; it does not give permission to run it.
I still steer the work as it happens. While reviewing the first post in the live Portal, I commented: “Assume one? It doesn’t feel direct and clear.” Amp rewrote the sentence. Later, a LAN runner could safely perform read-only beta checks, but the repository rules did not permit it. I changed that specific rule rather than asking Amp to ignore all the rules.
There are still limits. Production needs my approval, secrets stay outside Git and not every application has equal test coverage. However, Amp can now investigate a problem, make a change and show me the checks without guessing what command to run next. More importantly, it knows when it must wait for me . With that in place, I was ready to let it help rebuild K3s.