Why I built servicenow-skills

I built servicenow-skills because I was tired.

Not burned-out tired — the other kind. The kind where you open the ServiceNow UI for the fourteenth time that week to make the same three clicks across three instances, and something in your head goes “no, this ends today.”

The thing I kept doing by hand

It’s always the small stuff that gets you. I don’t mind doing hard work. What I mind is doing the same five-minute task every day for a month because there’s no better option.

For me that was configuration. Business rules, script includes, catalog items, the client scripts that sit underneath them. The platform gives you a form to fill in. That form is the same every time. The values I type into it live in my head. The thing I build with those values is, at best, version-controlled in an update set that lives on one specific instance and has to be carried across to the others.

I know people who are perfectly happy with this. I am not one of those people. (I don’t think I ever was. I just didn’t have a good enough excuse to do something about it.)

Why the existing tooling wasn’t enough

ServiceNow isn’t hostile to people who want to work from code. There’s a CLI. There’s an SDK. There are APIs. There are whole frameworks for building applications on the platform. None of that is the problem.

The problem is that none of it gets you out of having to know the whole platform to do one small thing. If I want to create a business rule, I need to know the sys_script table schema, which fields matter, which ones the API will silently ignore on write (yes, that’s a thing), and what I’m supposed to do when I try to create the same rule twice without ending up with two copies of it.

That knowledge isn’t secret. It’s just scattered. And every new person — every new agent, if I’m being honest — re-discovers it the hard way.

Which is also why this felt worth building now. If I can write the scattered parts down once, in a shape an agent can actually pick up and use, the cost of doing things the right way drops to almost nothing. Two years ago I couldn’t have said that.

The first thing I built

The first version was almost embarrassingly small. A TypeScript file describing a script include, a function that took that file and pushed it up against a real instance, and a test that ran the whole thing against a dev box to make sure nothing exploded.

That was it. One artifact type. No abstractions. No manifests. No skills. Just: “here is a thing I want, go make it exist.”

It worked on the first try, and I remember sitting there staring at the terminal thinking wait, is that it? And then immediately: if this works for script includes, it’ll work for everything.

The rest of the project is what happens when you take that moment seriously.

The bar I set

Before I’d let myself call any of this “done”, I wrote down what done had to look like. Three things:

1. I should describe an artifact once and have it work across instances — first run, tenth run, hundredth run — without me thinking about update sets.
2. I should be able to test it in CI, against a real instance, without babysitting.
3. An AI pairing with me on this should make the experience better, not worse. Not a babysitting job. Not a wrong-answer machine. Something that actually helps.

I’m not at done yet. But I’m closer than I was the day I opened the UI for the fourteenth time that week, and honestly that’s all I was asking for.

-D