Building ServiceNow skills for Claude
What I learned building Claude Code skills for ServiceNow development — encoding hard-won knowledge about the snc CLI and the platform's quirks into reusable context.
ServiceNow is one of those platforms where the gap between “I know what I want to build” and “I know exactly how to build it” is wide. The platform is vast. The CLI tooling is powerful but underdocumented. And there are dozens of situations where the obvious approach — using the standard Table API — silently fails or gives you the wrong result.
I’ve been building ServiceNow things for a while. I know where the sharp edges are. The question was whether I could encode that knowledge in a way that makes AI-assisted development actually reliable.
What skills are
Claude Code supports skills — markdown files that give the agent structured, domain-specific knowledge before it starts working. Think of them as persistent context that loads automatically when you need it. Instead of rediscovering the same platform quirks every session, you write them down once and the agent just knows.
For ServiceNow, the knowledge worth encoding falls into a few clear buckets: how to query and manipulate records via the snc CLI, how to build configuration artifacts like business rules and catalog items, how to write and run ATF tests, and how to work around the places where the standard APIs fall short.
The snc CLI is more interesting than it looks
The ServiceNow CLI (snc) is the foundation. It handles authentication, record operations, schema discovery, and update set management. Used well, it can drive almost the entire development workflow without touching the browser.
The interesting thing is what happens when you start hitting the edges. The Table API is great for most things, but there are fields it silently ignores on write, records it won’t let you delete, and operations that require running server-side code instead of REST calls. The pattern I kept coming back to was: when the standard path doesn’t work, write a Scripted REST endpoint that does the operation via GlideRecord, register it as a custom CLI command, and call it like any other snc subcommand.
snc custom create-client-script --data '{"cat_item": "...", "script": "..."}'That pattern — extending the CLI with your own endpoints — turns out to be surprisingly general. Once you have a working endpoint for one problem, adding the next one is fast.
What I didn’t build (yet)
The skills cover the mechanics. What they don’t fully capture yet is the judgment layer — knowing when a business rule is the right choice versus a flow action, or when to scope something to global versus an application scope. That knowledge is harder to encode because it depends on context that varies by project.
That’s the part I’m still working on. The mechanical knowledge — how to call the API, what params to pass, what the workarounds are — is teachable. The architectural judgment is what takes years.
For now, having the mechanics right means spending less time debugging platform behavior and more time thinking about what I’m actually building. That’s a good trade.