How I build with Claude Code: skills and agents

I have used AI coding tools every day for a while now, and I’ll admit the “it writes code faster” part stopped being interesting months ago. What changed my work this autumn is something else: several sessions doing different jobs in different places, handing work to each other, and all of them stopping at the same door, which is me.

Here is one week of that, 22 to 26 September 2026, with the parts I liked and the parts I would never hand over.

How it’s set up

Every project I work on has its own long-running session in its own folder. It knows the code, reads the notes from earlier days and follows the rules I have written down for that project. When a job would flood it with noise (reading a 57-page PDF, checking the law in ten countries) it sends a sub-agent, which works on the side and comes back with a short report. Repeated jobs live in skills, which are just written procedures the session follows when I type a command.

And anything that leaves my laptop needs my yes. Deploys, posts, messages to people. That rule turned out to matter more than any of the clever parts.

I wrote the rules before the prompt

I want two articles a month on my site, and I really don’t want to publish SEO filler. So before asking for a single draft I wrote down what an article has to be: built on something I actually did, facts taken from the source and not from other blogs, and nothing goes live until I’ve read it.

Then I turned that into a skill. When I type /blog-clanok, the session takes the next topic from my list, reads the code of the project the topic is about, checks the facts, looks at what already ranks for it and writes a draft that stays hidden on the live site. The skill reads my rules every single time, which is more than I can say for myself.

The research agent was fast, and wrong once

For a piece on e-invoicing mandates across the EU I needed the current status in ten countries. These dates have moved several times, so memory was useless and one search was never going to be enough.

The sub-agent came back with a table, more than twenty source links and, the part I liked best, a list of what it wasn’t sure about. Spain’s implementing order still a draft. The Dutch plan not yet law. Two Romanian sources saying opposite things.

It also got Slovakia wrong. It wrote that e-invoices are required “between VAT payers”. I had read the Slovak tax authority’s FAQ from start to finish earlier that day, and it says the buyer can be any business, VAT-registered or not. Small detail, big difference for a store that sells to sole traders. The article follows the FAQ. I still treat an agent’s table as a very good first draft of the truth.

Then one session sent a bug to another

While reading that same FAQ, the session noticed something about a module I had built in August for a client’s PrestaShop store. The module addressed e-invoices by the buyer’s VAT number. Slovak rules use the tax number instead, written as 0245:DIČ. Its design notes also had a ten-day deadline for issuing invoices, copied from an old draft of the law. The final rule is fifteen.

The fix belonged in another repository, where a different session was already working on that store. So the first session sent it a message: the three problems, the link to the FAQ, the exact places in the document that back each one, and that project’s rules, including “don’t deploy”.

Later that day the other session reported back. Version 0.4.2, 49 unit tests green. The ID now comes from the tax number, a missing tax number blocks sending (instead of quietly falling back to the VAT number, which is what I’d have worried about) and sole traders without a VAT number are treated as business customers.

And it pushed back twice. First it asked whether I was sure the FAQ was the latest version, because the footer said August and I had cited September. Fair question. The PDF’s metadata said it was created on 11 September, so we were both right in a way. Then it refused to quietly implement one case, domestic versus foreign buyers, and listed it as an open question for me instead.

That second part is what I’d want from a human colleague too.

Where I don’t let go

Plenty of that week was not delegated, and it wasn’t an accident.

Nothing public goes out without me reading it first. When the session updated my LinkedIn profile it spotted two defaults that would have announced the change to my whole network and replaced my headline, and it turned both off before saving.

Deploys were blocked by Claude Code’s permission check at first, and I ran them by hand until I trusted the build and the checks around it. Then I allowed that one command explicitly. No message to a client or a former colleague is ever sent by an agent. A client’s name doesn’t appear in an article until the client says yes. And anything about tax law ends with “ask your accountant”, because I’m an engineer, not a tax adviser.

If you want to try this

Write your rules down before you write a prompt. Send research somewhere else and ask for its doubts, not just its answers. Check the one fact that really matters yourself. Let each session own its own code and expect tests and questions back. And keep your own yes in front of everything you can’t undo.

This article was drafted by the same session from what happened that week, and I read and edited it before it went out. If you’re thinking about putting AI into your own product with boundaries like these, here is what I have shipped so far.

How I build with Claude Code: skills, sub-agents and sessions that talk to each other