Disclosure: I work for Apollo Automation. Some of the skills below automate work on our repos.
I’m not a developer. I can read code and I know my way around a terminal, but I don’t write software for a living. What I do is ship firmware, documentation, and Home Assistant setups, and I lean on Claude Code to do a lot of the actual coding for me.
The problem with that, early on, was that I kept explaining the same things over and over. Here’s how we publish the wiki. Here’s the voice I write in. Don’t put a co-author line on my commits. Every session started with the same setup talk before any real work happened.
So I stopped, and wrote it down instead. The result is a repo I just made public: claude-code-setup. It’s the skills and the memory pattern I’ve built up, cleaned of anything private, MIT licensed. Two parts are worth explaining.
Skills are workflows written down once
A skill is a folder with one SKILL.md file. It has a name, a description that tells Claude when to use it, and then the actual steps. When a task matches the description, Claude loads the skill and follows it. That’s the whole trick. Instead of re-explaining the wiki publish chain every time, I wrote it once, and now “ship it” runs the branch, the PR, the merge, the sync, and the live-deploy check on its own.
There are eleven in the repo. apollo-docs does that publish chain. ha-debug works backward from a Home Assistant symptom, like a notification that fired when it shouldn’t have. The two newest are ha-automations and ha-dashboards, added the same day this post went up: Claude mined a month of our old sessions for every correction I’d made and folded them in. Things like aliases on every automation step so the trace reads like a sentence, and putting a preview card next to the original so I can compare live before anything gets replaced. writing-voice is my prose rules, which is what caught the AI-sounding phrases in this very post before it went out. apollo-yaml walks a firmware change through one of our device repos. The rest cover blog posts, filing pull requests, end-of-session cleanup, and teaching the setup something new after I correct it.
None of these needed me to know how to code. They needed me to know how I work, and to write that down clearly.
The memory pattern is the part worth stealing
Claude Code can keep a persistent memory, but the obvious way to do it is one big file, and one big file rots. I use a folder of small notes instead, one fact per file, each tagged with what kind of fact it is.
A single MEMORY.md index sits next to those notes and loads at the start of every session. It’s one line per note: a title, a link, and a short hook. The index tells Claude what exists. The individual notes hold the detail and only get pulled in when they’re relevant, so the running context stays small.
The facts fall into four kinds. Who I am, like my GitHub handle and how commits should be signed. Feedback, meaning a correction with the reason attached so the same mistake doesn’t come back. Project notes for ongoing work I can’t reconstruct from the code. And plain references to external docs. Notes link to each other, and when one turns out wrong I delete the file instead of editing around it. The repo has a sanitized memory-example/ folder with one note of each kind so you can see the shape.
If you want it
It’s on GitHub, MIT. Copy any skill folder into your own ~/.claude/skills/, change the description so it fires on your work, and swap my project details for yours. The memory pattern you can take as-is, since it doesn’t depend on any particular project. The Apollo-named skills point at our public repos and are there as real working examples. I took coworkers’ names out but left the mechanics.
You don’t have to be a developer for this to be worth doing. If anything it matters more when you’re not, because the setup is what lets you hand off the parts you’d otherwise be stuck on.