I use Claude Code and OpenClaw a lot.

Claude Code is where I spend focused engineering time: inside a repository, changing code, reading tests, opening PRs, fixing the thing in front of me.

OpenClaw is different. It is closer to a personal operating system for agents. It talks to Telegram, my browser, files, cron jobs, local tools, accounting systems, and all the messy glue around real life.

Both are useful. Both have skills. And right now the annoying part is that skills do not travel well enough between them.

That feels like the wrong abstraction boundary.

Skills are not tool configuration

A good skill is not just a command wrapper.

It is procedural memory.

It says:

• how this project deploys
• what traps to avoid
• where the source of truth lives
• what order to do things in
• what must be verified before saying “done”
• what style the output should have

That knowledge should not belong to Claude Code or OpenClaw. It should belong to the work.

If the skill is about a project, it should live with the project.

If the skill is about my blog, my accounting, or my home automation, it should live in my personal agent workspace.

If the skill is generally useful, it should be published somewhere others can install it.

But the core workflow should not have to be rewritten every time I use a different agent runtime.

The shape I want

The simplest version is just this:

skill-name/
  SKILL.md
  scripts/
  references/
  assets/

SKILL.md contains the instructions. Scripts contain deterministic helpers. References contain long docs that should only be loaded when needed. Assets contain templates or files the agent may use.

This is already close to how Claude Code skills work, and it is close enough to how OpenClaw skills work that the overlap is more interesting than the differences.

So I do not want a grand new standard.

I want a portable subset.

Three kinds of skills

I think skills naturally fall into three buckets.

1. Public skills

These are generic and safe to share.

Examples:

• review a GitHub PR
• publish a Hugo blog post
• inspect a Rails Hotwire app
• process receipts
• extract frames from a video

They must not contain secrets, private paths, internal URLs, or “works only on my laptop” assumptions.

These belong in a marketplace or public repository.

2. Project skills

These should be committed to the repository.

Examples:

• how to deploy this service
• how to run the test suite correctly
• how to cut a release
• how to debug production incidents
• how to update generated API clients

This is the most underrated category.

Every mature project has tribal knowledge. Usually it lives in Slack, in one senior engineer’s head, or in a README nobody trusts. A project-local skill is a better home for that knowledge because it is written directly for an agent that will actually perform the workflow.

The skill travels with the code.

3. Personal skills

These are mine.

They know about my Obsidian vault, my accounting setup, my home automation, my blog repository, my local tools, my preferences.

They are not meant to be public. Some may contain private assumptions. Some may call OpenClaw-specific tools like messaging, reminders, or node control.

That is fine. Not everything needs to be portable.

The important thing is to know which category a skill belongs to.

The rule: core workflow first, adapter second

The mistake would be to write every skill as “call tool X with parameters Y”.

That makes the skill brittle and runtime-specific.

Better:

1. describe the workflow in agent-neutral terms
2. keep deterministic operations in scripts
3. put runtime-specific behavior behind small adapter notes

For example:

When publishing the post:

1. Create the Hugo markdown file.
2. Use a timestamp safely in the past, because Hugo skips future posts.
3. Run the local build.
4. Commit the result.
5. Push only after explicit confirmation.

In Claude Code: use shell commands inside the repository.
In OpenClaw: use the gateway/browser/message tools only when needed.

The skill should teach the agent what “done” means. The runtime can decide how to execute.

What I want from interop

I want one source of truth and thin installation targets.

Something like:

~/agent-skills/
  public/
  project/
  personal/

Then a small sync tool can install them where each agent expects them:

skillsync install ~/agent-skills/public ~/.claude/skills
skillsync install ~/agent-skills/personal ~/.openclaw/workspace/skills
skillsync validate ~/agent-skills
skillsync package ~/agent-skills/public/hugo-publisher

The sync tool should be boring:

• validate front matter
• reject secrets before packaging
• check broken relative links
• warn about runtime-specific tools
• copy or symlink skills into the right place
• package marketplace-compatible archives

No magic. Just hygiene.

Why this matters

Agents are getting better very quickly, but the bottleneck is often not model intelligence.

The bottleneck is context.

Not “more tokens” context. Operational context.

The little things:

• this command must be run from that directory
• this deployment takes ten minutes and lies about being finished
• this project uses make test, but only after generating fixtures
• this blog needs a past UTC timestamp or Hugo silently skips the post
• this API returns 200 even when the operation failed

That is the stuff that makes agents useful in real work.

And that knowledge should be durable, versioned, reviewable, and portable.

A skill is a pretty good unit for that.

My current opinion

Skills should live as close as possible to the thing they describe.

Project workflow? Put it in the repo.

Personal workflow? Put it in the personal workspace.

Reusable workflow? Publish it.

Agent-specific instructions are allowed, but they should be adapters, not the core.

If we get this right, Claude Code, OpenClaw, and whatever comes next can share the same procedural memory instead of each building its own little island.

That is the interop I actually want.

Living in Germany with financial ties to Ukraine means three bank accounts, two countries, two currencies, and a lot of monthly bookkeeping nobody wants to do.

For years I’ve tracked every transaction in plain text files — think of it as a spreadsheet, but stored in simple text that I can search, version, and back up like any other document. The system works great. The data entry? Not so much.

Every month: log into three banks, download statements, match each transaction to a category, update the books, file expense reports. An hour of tedious work that I kept postponing until the weekend.

So I automated the whole thing with an AI assistant.

What It Does Now

Every night at 10 PM, the AI:

1. Connects to all three banks and downloads the latest transactions
2. Categorizes each transaction — groceries, insurance, school fees, subscriptions — using rules I’ve taught it over time
3. Saves everything to my accounting files and backs them up
4. Sends me a summary on Discord: balances, new transactions, anything it couldn’t categorize

When it finds a new merchant it hasn’t seen before, it flags it. I reply with the category — “that’s a pharmacy” — and it remembers forever.

The Expense Report Part

Here’s what I’m most proud of. Some of my bank charges are business-related and need to be filed as expense reports. Cloud services, work tools, that kind of thing.

The AI now does this automatically:

1. Sees the charge on my bank statement
2. Looks up the amount in local currency
3. Creates an expense claim in the accounting software
4. Done

What used to be: download statement → open accounting app → fill in the form → save → forget for three months and do them all at once. Now it just happens.

What Surprised Me

Teaching is faster than doing. The first month, I had to categorize about 30 merchants. The second month, maybe 5 new ones. By the third month, almost everything is automatic. Each correction makes the system smarter.

The AI handles the boring parts, not the decisions. It doesn’t decide how to categorize a new restaurant. It asks me. It doesn’t file expense claims without permission. It asks first. But it never forgets to download statements, never fat-fingers an amount, and never procrastinates until Sunday evening.

Three banks, two countries, one conversation. German bank, PayPal, Ukrainian bank — the AI talks to all three using their respective interfaces. I just see the summary.

The Monthly Effort Now

Before: ~1 hour of manual bookkeeping per month, usually done reluctantly.

Now: maybe 5 minutes categorizing a few new merchants in a chat message. Everything else runs on autopilot.

The books are always up to date. Expense claims get filed on time. And I stopped dreading the last Saturday of the month.

If you’re curious about the technical setup: the system uses ledger-cli for accounting, connects to German banks via the FinTS protocol, and talks to Manager.io for company expense claims. The AI orchestration runs on OpenClaw. Everything is version-controlled in Git.

I’ve been managing an SRE team at Billie for about 15 months. A month ago, I set up an AI assistant. It’s an open-source gateway called OpenClaw that connects Claude to my tools, and I talk to it through Telegram.

Let me just walk you through last Wednesday.

Before my first meeting, the assistant checked my inbox. Found an invoice from my old tax advisor, a service I’d already cancelled. It drafted a reply asking about formal termination steps and sent it. The email bounced because of a wrong reply-to address. It caught that, resent. By lunch, the advisor had replied with three PDFs to sign. I signed them, the assistant sent them back. Done. That whole thing would’ve sat in my inbox for a week if I’m honest.

Between meetings, I needed to contact my daughter’s English teacher about a bad test score. I emailed the wrong teacher. Turns out there’s an “Elab” teacher and a regular English teacher at her school, and I mixed them up. The assistant dug through my inbox, found the right name from an old email, drafted an apology to teacher #1, wrote a proper message to teacher #2, CC’d my wife. Two emails, right tone, maybe five minutes total.

In the afternoon I had an ADR review at work. The assistant didn’t help with that. It was a room full of engineers debating tradeoffs, and my actual challenge was figuring out when to drive the conversation and when to shut up and let someone else present. That’s a leadership problem. There’s no API for it.

After work, I’d noticed a new community center opening near my apartment while out walking. The assistant looked up their website, I wrote an intro email offering IT help as a neighbor.

Evening: LinkedIn post about a Claude Code plugin. Some journaling about how the day went. Set a reminder to try meditation the next morning.

Tax paperwork, parenting logistics, architecture reviews, community outreach, writing, self-reflection. One Telegram chat, one day.

What I think after a month

The value is in not switching contexts. Each individual thing the assistant did was small. Draft an email, search an inbox, look up a website. But I didn’t bounce between seven apps and three mental modes to get it all done. It happened in one thread, and that thread has memory.

The boring stuff actually gets done now. I still read every email before it goes out. I still decide everything. But the distance between “I should handle this” and “it’s handled” got very short. That tax thing is a perfect example. It’s not hard. It’s not important enough to do right now. So it festers. Except this time it didn’t.

Where it matters most, it’s useless. The ADR meeting, the 1:1s with my reports, the gut feeling that someone on the team is burning out. That’s me. AI clears the admin noise so I can spend more time on those things. It doesn’t make me better at them.

Work and life are in the same stream. My daughter’s teacher and my ADR review happened in the same chat, same afternoon. I know some people find that messy. For me it means fewer things slip through because everything lives in one place.

I don’t have conclusions yet. It’s been a month. I have no productivity metrics, no hours-saved calculations. I just notice that things that used to linger are getting done. Whether that’s genuinely useful or I’m just building a new dependency, I honestly don’t know. Check back in six months.