Earl Duque
Administrator
Options
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
2 hours ago
Build Anywhere: Claude Code + ServiceNow SDK
This is a series of short episodes (around three minutes each) that walk you through building native ServiceNow apps from your terminal using Claude Code and the ServiceNow SDK. Each episode covers one focused topic, from initial setup through deploying real applications and building custom tooling. You can watch the videos or just read through everything right here on this page.
Table of Contents
- Group 0: Intro
- Group 1: Getting Started
- Group 2: Core Workflow
- Group 3: Git + Deploy
- Group 4: Custom Tooling + Automation
- Group 5: Leveling Up
Group 0: Introduction
Intro video
I'm Earl Duque, Developer Advocate at ServiceNow. This series is about building native ServiceNow apps from your terminal using the ServiceNow SDK and Claude Code.
If you've been building ServiceNow apps the traditional way (Studio, the browser, clicking through forms), this series is for you. We're going from zero to deploying real apps, all from your local machine, all through code.
Here's the big picture: ServiceNow open-sourced a set of build skills that let coding agents like Claude Code create native ServiceNow apps the way a ServiceNow developer would. Your agent knows what platform objects to build, how to structure a scoped app, and how to follow ServiceNow best practices. You write prompts, Claude Code writes the app, and the SDK deploys it straight to your instance.
THE TRADITIONAL WAY THE NEW WAY
┌───────────────────┐ ┌───────────────────┐
│ Open browser │ │ Open terminal │
│ Log into instance│ │ Write a prompt │
│ Open Studio │ │ Claude Code + │
│ Click through │ │ SDK handles │
│ forms │ │ the rest │
│ Configure in UI │ │ Deploy from CLI │
└───────────────────┘ └───────────────────┘
The flow works like this: you prompt Claude Code, the build skills tell it how ServiceNow works, the SDK compiles and deploys the result as a native scoped app on your instance.
┌─────┐ ┌──────────────────────────┐ ┌─────┐ ┌────────────┐
│ │ │ Claude Code │ │ │ │ │
│ You ├───>│ ├───>│ SDK ├───>│ ServiceNow │
│ │ │ ┌───────────────────┐ │ │ │ │ Instance │
└─────┘ │ │ ServiceNow │ │ └─────┘ │ │
prompt │ │ Build Skills │ │ build │ Native │
│ │ │ │ + deploy │ Scoped │
│ │ - Best practices │ │ │ App │
│ │ - Platform rules │ │ │ │
│ │ - App structure │ │ └────────────┘
│ └───────────────────┘ │
└──────────────────────────┘
Across the episodes, we cover:
- Setting up your environment
- The SDK project structure
- How to write good prompts
- When to use plan mode
- Git workflows
- Deploying your app
- Building custom slash commands
- Agent orchestration
SERIES ROADMAP
Getting Started Core Workflow
├─ Claude Code setup ├─ GDD/PRD to start
├─ ServiceNow SDK ├─ CLAUDE.md + context
├─ SDK vs Studio ├─ Skills
├─ Dev environment ├─ Writing good prompts
├─ Credentials ├─ Plan mode
└─ Project structure └─ Debugging
Git + Deploy Custom Tooling
├─ Branches ├─ Slash commands
├─ Work trees ├─ Issue finder
├─ Commit + push ├─ Issue interview
└─ SDK build + deploy └─ Agent teams
Leveling Up
├─ Agent orchestration
├─ Release notes + Teams
└─ Prototype to production
Each episode is about three minutes. Short, focused, and practical. Watch them in order or jump to whatever's relevant to you right now. And if I miss a topic, let me know in the comments and I'll add an episode.
EPISODE FORMAT
┌────────────────────────────┐
│ ~ 3 minutes each │
│ Focused on one topic │
│ Practical, not theory │
│ Watch in order or jump │
│ to what you need │
│ Request topics anytime │
└────────────────────────────┘
Group 1: Getting Started
What is Claude Code and how to install it
Claude Code is an AI coding agent built by Anthropic that lives in your terminal. It's not autocomplete. You give it instructions in plain language, and it reads your repo, runs commands, edits files, and follows multi-step plans. Think of it as a junior dev who's very fast, very thorough, and never gets tired.
CLAUDE CODE
┌─────────────────────────────────────────┐
│ │
│ AI coding agent from Anthropic │
│ │
│ - Reads your entire repo │
│ - Runs commands │
│ - Edits files │
│ - Follows multi-step instructions │
│ - Writes platform-native code │
│ │
└─────────────────────────────────────────┘
You've got several options for where to run it:
- Terminal CLI (the original)
- VS Code extension
- JetBrains plugin
- Desktop app for Mac and Windows
- Web version at
claude.ai/code
WHERE CLAUDE CODE RUNS
┌──────────┐ ┌──────────┐ ┌──────────┐
│ Terminal │ │ VS Code │ │JetBrains │
│ CLI │ │Extension │ │ Plugin │
└──────────┘ └──────────┘ └──────────┘
┌──────────┐ ┌────────────────────────┐
│ Desktop │ │ Web (claude.ai/code) │
│ App │ │ │
└──────────┘ └────────────────────────┘
Why should you care as a ServiceNow dev? Because when you pair Claude Code with the SDK's build skills, it behaves like a ServiceNow developer. It knows how to scaffold tables, write business rules, structure scoped apps, all following platform best practices. We dig into those skills in a later episode.
Installing Claude Code
The recommended path is the native installer. No Node.js required, and it self-updates in the background.
- Mac/Linux:
curl -fsSL https://claude.ai/install.sh | bash - Windows (PowerShell):
irm https://claude.ai/install.ps1 | iex
If you already have Node.js on your machine, npm install -g @anthropic-ai/claude-code still works but is deprecated. Native is simpler and what Anthropic recommends going forward.
INSTALL CLAUDE CODE
Native (recommended)
┌─────────────────────────────────────────┐
│ Mac/Linux: │
│ curl -fsSL https://claude.ai/ │
│ install.sh | bash │
│ │
│ Windows (PowerShell): │
│ irm https://claude.ai/ │
│ install.ps1 | iex │
│ │
│ No Node.js needed. Self-updates. │
└─────────────────────────────────────────┘
npm (deprecated, still works)
┌─────────────────────────────────────────┐
│ npm install -g @anthropic-ai/claude-code│
│ │
│ Requires Node.js 18+ │
└─────────────────────────────────────────┘
First run
Once installed, cd into your project directory, type claude, and it'll walk you through authentication. You'll need a Pro, Max, Team, or Enterprise account. After that, you're good to go.
FIRST RUN
$ cd your-project/
$ claude
┌─────────────────────────────────────────┐
│ 1. Authenticate via browser │
│ (Pro, Max, Team, or Enterprise) │
│ │
│ 2. Start prompting │
│ "Build me a scoped app that..." │
└─────────────────────────────────────────┘
Quick note on models: Claude Code runs on Opus and Sonnet. We'll cover when to pick which in a dedicated episode.
And here's the key difference between Claude Code and a typical autocomplete tool:
AUTOCOMPLETE AGENT
┌────────────────────┐ ┌────────────────────┐
│ Suggests the next │ │ Reads your whole │
│ line of code │ │ project │
│ │ │ │
│ You drive │ │ Follows multi-step │
│ │ │ instructions │
│ One suggestion │ │ │
│ at a time │ │ Edits files, runs │
│ │ │ commands, builds │
└────────────────────┘ └────────────────────┘
What is the ServiceNow SDK
The ServiceNow SDK is how you build scoped apps without ever opening a browser. It's a command-line toolkit (the package is @Servicenow/sdk, and you typically run it with now-sdk) that lets you create, build, and deploy scoped applications from your local machine.
You write code in Fluent, which is ServiceNow's own code framework for defining platform metadata. The output is native code: tables, business rules, script includes, flows. All of it compiles down to the same scoped app you'd get if you built it in ServiceNow Studio.
Why Fluent matters: because you're writing in a language the platform already understands, there's no translation layer that breaks things. The code you write maps directly to the metadata ServiceNow expects. If you've ever had a deployment go sideways because some import didn't map correctly, you probably appreciate that directness.
What the SDK gives you out of the box:
- A project structure with Fluent source files
- ATF tests generated alongside your app (optional)
- A readiness scan that runs during build
- A deploy command that pushes the finished app straight to your instance's sandbox
WHAT THE SDK GIVES YOU
┌─────────────────────────────────────────┐
│ │
│ - Fluent source code (platform-native) │
│ - Scoped app structure │
│ - ATF tests generated automatically │
│ - Readiness scan during build │
│ - Deploy straight to your instance │
│ │
└─────────────────────────────────────────┘
When you initialize an SDK project, you'll see a folder structure that looks like any modern dev project:
your-app/
├─ src/
│ ├─ tables/
│ ├─ business-rules/
│ ├─ script-includes/
│ └─ ...
├─ package.json
├─ now.config.json
└─ .claude/
└─ skills/
├─ business-rule/
├─ client-script/
├─ script-include/
└─ ...
There's a src/ directory for your Fluent code, a package.json, a now.config.json for your instance settings, and a .claude/skills/ directory (more on that in the skills episode).
The build and deploy flow is straightforward:
┌───────────┐ ┌───────────────┐ ┌──────────────────┐
│ Local │ │ now-sdk │ │ ServiceNow │
│ Repo ├────>│ build + ├────>│ Instance │
│ │ │ deploy │ │ │
│ Fluent │ │ │ │ Native Scoped │
│ source │ │ ATF tests │ │ App in your │
│ code │ │ + readiness │ │ sandbox │
│ │ │ scan │ │ │
└───────────┘ └───────────────┘ └──────────────────┘
The "Build Anywhere" part: the SDK isn't locked to one tool. It works with Claude Code, Cursor, Windsurf, OpenAI Codex, Antigravity, Cowork. Whatever coding agent or editor you prefer, the SDK plugs in. This series focuses on Claude Code because that's my daily driver, but the skills and project structure carry over.
BUILD ANYWHERE
┌───────────────┐ ┌───────────────┐ ┌───────────────┐
│ Claude Code │ │ Cursor │ │ Windsurf │
└───────────────┘ └───────────────┘ └───────────────┘
┌───────────────┐ ┌───────────────┐ ┌───────────────┐
│ OpenAI Codex │ │ Antigravity │ │ Cowork │
└───────────────┘ └───────────────┘ └───────────────┘
Same SDK. Same skills. Same output.
What you need to get started:
- A ServiceNow instance running Zurich or later (or a free PDI)
- Node.js installed on your machine
- The SDK package installed:
npm install -g @Servicenow/sdk
GETTING STARTED CHECKLIST
┌─────────────────────────────────────────┐
│ │
│ 1. ServiceNow instance (Zurich+) │
│ or a free PDI │
│ │
│ 2. Node.js installed │
│ │
│ 3. @servicenow/sdk installed │
│ npm install -g @servicenow/sdk │
│ │
└─────────────────────────────────────────┘
The SDK also comes bundled with build skills that teach your coding agent how ServiceNow works. They're what make Claude Code (or whichever tool you use) actually good at building platform-native apps. Without them, your agent is guessing. With them, it knows the rules. We cover those in a dedicated episode.
SDK vs Studio: why switch?
ServiceNow Studio isn't going anywhere. But if you've been curious why devs are moving to the SDK, here's the honest breakdown.
Studio is great at what it does. If you're doing config-first work, laying out forms, building flows in Flow Designer with the visual canvas, or you've got team members who don't live in code, ServiceNow Studio is the right tool. It's visual, it's accessible, and it's been the default.
The SDK gives you something different: local development, git-native version control, and the ability to pair with AI coding agents that can read your entire project, follow multi-step instructions, and write platform-native code. Every change is diffable, reviewable, and lives in your editor of choice.
STUDIO WORKFLOW SDK WORKFLOW
┌────────────────────┐ ┌────────────────────┐
│ Open browser │ │ Open terminal │
│ Log into instance │ │ Write code locally │
│ Use visual tools │ │ Git version control│
│ Flow Designer │ │ AI agent assists │
│ Form layouts │ │ Diffable changes │
│ Config-first │ │ Code-first │
└────────────────────┘ └────────────────────┘
The output is the same. Both paths produce a scoped application. A scoped app built with the SDK and a scoped app built in Studio are the same artifact on the platform. Same tables, same business rules, same everything (mostly). The only difference is how you got there.
STUDIO SDK
┌──────────┐ ┌──────────────┐
│ Visual │ │ Fluent code │
│ tools + │ │ + AI agent │
│ browser │ │ + terminal │
└─────┬────┘ └──────┬───────┘
│ │
└──────────┐ ┌──────────────┘
│ │
v v
┌──────────────┐
│ Scoped │
│ Application│
│ (same │
│ artifact) │
└──────────────┘
The honest trade-off: branch management from external tools is limited right now. If you need branching workflows, you'll want to use Source Control inside ServiceNow Studio or manage branches through GitHub directly. That's a known constraint today, and it's good to know now rather than have you hit it mid-project.
┌─────────────────────────────────────────────┐
│ │
│ HONEST TRADE-OFF │
│ │
│ Branch management from external tools │
│ is limited today. │
│ │
│ For branching workflows: │
│ - Use Source Control in Studio │
│ - Or manage branches via Git/GitHub │
│ │
│ This is a real constraint. │
│ Plan around it. │
│ │
└─────────────────────────────────────────────┘
When to pick which:
- Pick SDK when: building from scratch, working with an AI coding agent, you want git-native version control, code-first development
- Pick Studio when: quick form tweak, one-off flow update, config-first work, team members who prefer visual tools, you need branching workflows today
PICK SDK WHEN... PICK STUDIO WHEN...
┌────────────────────┐ ┌────────────────────┐
│ │ │ │
│ Building from │ │ Quick form tweak │
│ scratch │ │ │
│ │ │ One-off flow update │
│ Working with an │ │ │
│ AI coding agent │ │ Config-first work │
│ │ │ │
│ Want git-native │ │ Team members who │
│ version control │ │ prefer visual │
│ │ │ tools │
│ Code-first │ │ │
│ development │ │ Need branching │
│ │ │ workflows today │
└────────────────────┘ └────────────────────┘
If you're not sure, try both on a small project and see which one clicks. You can always switch. The platform doesn't care how the app got there.
Your local dev environment setup
Coming soon, I'm making these videos in batches.
Getting started with SDK from scratch
Coming soon, I'm making these videos in batches.
Getting started with SDK from Build Agent
You don't have to start your SDK project from a blank folder. ServiceNow's Build Agent can scaffold the whole thing for you, and then you hand it off to Claude Code.
Build Agent is ServiceNow's in-platform AI. You describe what you want in natural language, and it generates a full app skeleton: data model, tables, relationships, roles, navigation, the works. It's like having someone set up the foundation so you can jump straight into the interesting parts.
Why use it as a starting point? Because going from zero to a running app structure takes time, even with the SDK. Build Agent gives you that structure in minutes.
- Tables with fields already defined
- Roles already scoped
- Navigation already wired
- App scope and metadata set up
TWO WAYS TO START YOUR SDK PROJECT
From Scratch From Build Agent
┌────────────────────┐ ┌────────────────────┐
│ now-sdk create │ │ Describe your app │
│ Empty project │ │ Build Agent │
│ You build │ │ scaffolds it │
│ everything │ │ Pull to local │
│ │ │ Iterate with │
│ │ │ Claude Code │
└────────────────────┘ └────────────────────┘
BUILD AGENT GENERATES
prompt
│
v
┌─────────────────────────────────────────┐
│ │
│ Data model (tables + fields) │
│ Relationships between tables │
│ Roles and permissions │
│ Navigation modules │
│ App scope and metadata │
│ │
└─────────────────────────────────────────┘
Free calls: Customer instances now get 100 free Build Agent calls (up from 25). PDIs get 25 (up from 10). That's a lot more runway to experiment, especially on a personal developer instance where you're just learning the workflow.
FREE BUILD AGENT CALLS
┌─────────────────────────────────────────┐
│ │
│ Customer instances: 100 (was 25) │
│ PDIs: 25 (was 10) │
│ │
│ More room to experiment │
│ │
└─────────────────────────────────────────┘
The actual flow:
- Open Build Agent in your instance (it's inside ServiceNow Studio now)
- Describe your app in plain language
- Let it run, then review what it generated (check the tables, roles, fields)
- Pull that project into the SDK on your local machine by hooking up source control from within Build Agent (not Studio)
- Open it in Claude Code and iterate: add business rules, refine the data model, build out the UI
BUILD AGENT HANDOFF
┌────────────┐ ┌─────────────┐ ┌──────────────┐
│ Build │ │ SDK pull │ │ Claude Code │
│ Agent │ │ to local │ │ iterates │
│ ├───>│ machine ├───>│ │
│ In your │ │ │ │ Add rules │
│ instance │ │ Review the │ │ Refine model │
│ │ │ scaffold │ │ Build UI │
└────────────┘ └─────────────┘ └──────────────┘
One tip: the more descriptive your prompt, the better the scaffold. "Build me a task tracker" gets you something generic. Spelling out what kind of tasks you're tracking, who's going to use it, what should be tracked for each item, how roles should be defined, what interface you want... that gets you something you can actually work with. We go deeper on this in the GDD/PRD episode.
GENERIC PROMPT
┌─────────────────────────────────────────┐
│ "Build me a task tracker" │
└─────────────────────────────────────────┘
Generic scaffold
DESCRIPTIVE PROMPT
┌─────────────────────────────────────────┐
│ "Build me an IT asset tracking app │
│ with tables for hardware assets, │
│ software licenses, and vendor │
│ contacts, with roles for asset │
│ managers and read-only viewers" │
└─────────────────────────────────────────┘
Usable scaffold
Setting up your credentials
If you've looked up how to set up credentials for ServiceNow development, you've probably seen a long walkthrough about creating a fine-grained personal access token in GitHub, saving it in a credential record inside your instance, and hooking that up to Source Control. Here's the gotcha: that whole process is for ServiceNow Studio. If you're building directly with the SDK, you don't need any of that.
THE CREDENTIAL GOTCHA
┌─────────────────────────────────────────┐
│ │
│ GitHub token + credential record │
│ + Source Control config │
│ │
│ That's for STUDIO. │
│ │
│ If you're building with the SDK, │
│ you don't need any of it. │
│ │
└─────────────────────────────────────────┘
Let me say it again because this trips people up. If you are building and deploying from the SDK, the only authentication you need is what now-sdk asks you for. That's it.
When you run now-sdk deploy for the first time, it'll prompt you for:
- Your instance URL
- Your username
- Your password
The SDK stores those credentials locally so you don't have to re-enter them every time you build. That's the whole setup. No GitHub tokens. No credential records in your instance. No Source Control configuration.
SDK AUTHENTICATION
$ now-sdk deploy
┌─────────────────────────────────────────┐
│ │
│ Prompts you for: │
│ 1. Instance URL │
│ 2. Username │
│ 3. Password │
│ │
│ Stored locally. Enter once. │
│ │
└─────────────────────────────────────────┘
Where people get confused is they find the official docs or community posts about credentials, follow all the steps for the GitHub token and the credential record, and then wonder why it was so complicated. It wasn't complicated for them. They were following instructions meant for a different workflow.
If you do want to use Source Control inside Studio (maybe you're collaborating with someone who works in Studio, or you want to push your app to a GitHub repo through the platform), then yes, you'll need that GitHub token and credential record setup. But that's a Studio feature, not an SDK requirement.
WHO NEEDS WHAT
Building with SDK only:
┌────────────────────────────────┐
│ now-sdk deploy credentials │
│ (instance URL + login) │
│ That's all. │
└────────────────────────────────┘
Using Studio Source Control:
┌────────────────────────────────┐
│ GitHub personal access token │
│ ServiceNow credential record │
│ Source Control configuration │
└────────────────────────────────┘
Your checklist:
- Run
now-sdk deploy - Enter your instance URL, username, and password when prompted
- Confirm the deploy lands on your instance (check Studio's app list to verify)
SDK CREDENTIAL SETUP
┌─────────────────────────────────────────┐
│ │
│ 1. Run: now-sdk deploy │
│ │
│ 2. Enter instance URL, username, │
│ password when prompted │
│ │
│ 3. Confirm app lands on your instance │
│ (check Studio app list) │
│ │
│ Done. │
│ │
└─────────────────────────────────────────┘
If your deploy fails after you've already authenticated, double-check two things:
- Is your instance URL correct and spelled right?
- Does your user account have the right roles to install applications?
Those are the two things that actually go wrong with SDK auth. Not tokens. Not credential records. Just URL and permissions.
DEPLOY FAILING? CHECK THESE
┌─────────────────────────────────────────┐
│ │
│ 1. Instance URL │
│ Is it spelled correctly? │
│ Include the full URL. │
│ │
│ 2. User permissions │
│ Does your account have the roles │
│ to install applications? │
│ │
│ NOT tokens. NOT credential records. │
│ Just URL and permissions. │
│ │
└─────────────────────────────────────────┘
Reading and understanding the SDK project structure
Coming soon, I'm making these videos in batches.
Group 2: Core Workflow
This is where the real building starts. The setup episodes got your tools and credentials in place. Now it's about how you actually work with Claude Code day to day: what you feed it, how you prompt it, and the patterns that separate a frustrating session from a productive one.
GDD or PRD to start
The single biggest upgrade to your output isn't a better prompt. It's having a document to prompt against.
Claude Code (or any coding agent) is only as good as the context you give it. A three-line prompt gets you a three-line-quality app. Something like "build me a task tracker" and you'll get a generic shell that doesn't match anything you actually need. But hand it a document that describes your users, your data model, and your business rules, and the agent has something real to work with.
That document goes by different names depending on your background:
- GDD (Game Design Document) if you come from gaming
- PRD (Product Requirements Document) if you come from product teams
Same idea: describe what you're building, who it's for, and how it should behave before you start writing code.
For a ServiceNow app, here's what to include:
- Purpose: One paragraph on what the app does and why it exists
- Users and roles: Who interacts with this app and what permissions do they need?
- Key tables and fields: Your data model, relationships between tables
- Business rules or flows: What the app enforces
- Integrations: External APIs, notifications, anything the app talks to
PRD SKELETON
┌─────────────────────────────────────────┐
│ │
│ PURPOSE │
│ What the app does and why │
│ │
│ USERS AND ROLES │
│ Who uses it, what permissions │
│ │
│ DATA MODEL │
│ Tables, fields, relationships │
│ │
│ BUSINESS RULES │
│ What the app enforces │
│ │
│ INTEGRATIONS │
│ External APIs, notifications │
│ │
└─────────────────────────────────────────┘
You don't need a 30-page spec. A solid one-to-two-page doc covers most apps. If you're the only developer, a bulleted outline might be enough. The point is to think through the structure before you start telling your agent to build it. I actually have AI interview me about what I want and have it build the PRD for me.
Here's the workflow I use: drop the PRD into the root of your repo, then reference it in your CLAUDE.md file so Claude Code loads it as context automatically. Every prompt you write after that is grounded in that document. Claude Code knows the tables, the roles, the rules. It's not guessing.
┌──────────┐ ┌──────────────┐ ┌──────────────┐
│ Write │ │ Drop in │ │ Prompt │
│ your ├────>│ repo root ├────>│ Claude Code │
│ PRD │ │ │ │ │
└──────────┘ │ Reference │ │ Every │
│ in │ │ prompt is │
│ CLAUDE.md │ │ grounded │
└──────────────┘ └──────────────┘
PRD.md --> CLAUDE.md says "read PRD.md" --> context
So now your prompt becomes something like: Build the app described in PRD.md, starting with the core tables and the business rules. You're way more likely to get something you can actually use.
BAD PROMPT
┌─────────────────────────────────────────┐
│ "Build me an incident management app" │
└─────────────────────────────────────────┘
GROUNDED PROMPT
┌─────────────────────────────────────────┐
│ "Build the app described in PRD.md, │
│ starting with the core tables and the │
│ assignment business rule" │
└─────────────────────────────────────────┘
This also saves you API calls. Descriptive prompts reduce back-and-forth. Fewer rounds of "no, I meant this" means fewer calls burned on clarification.
WITHOUT A PRD WITH A PRD
┌──────────────────┐ ┌──────────────────┐
│ Prompt 1: vague │ │ Prompt 1: clear │
│ "build a tracker"│ │ "build per PRD" │
│ │ │ │
│ Agent: "what │ │ Agent: builds │
│ kind of │ │ what you │
│ tracker?" │ │ described │
│ │ │ │
│ Prompt 2: more │ │ Prompt 2: next │
│ details │ │ feature │
│ │ │ │
│ Prompt 3: "no, │ │ │
│ I meant..." │ │ │
│ │ │ │
│ 5+ calls burned │ │ 2 calls, done │
└──────────────────┘ └──────────────────┘
We'll talk about CLAUDE.md in its own episode, but here's the preview: CLAUDE.md is the file that tells Claude Code about your project. When your PRD is referenced there, every conversation starts with that context already loaded. No copy-pasting. No repeating yourself.
Write the doc first. Prompt second. Your future self will thank you.
CLAUDE.md and project-level context files
Coming soon, I'm making these videos in batches.
Skills are the magic key for getting the SDK to just work
Skills are reusable markdown files that live in your .claude/skills/ directory. They give your coding agent specialized knowledge about how to build specific things on the ServiceNow platform. And they're the thing that makes the SDK actually feel like it knows what it's doing.
There are two ways skills work:
- Slash commands you call directly (like
/business-rule) - Auto-loaded by Claude Code when it detects that a skill is relevant to what you're building
You've probably already seen some built-in skills that ship with Claude Code:
BUILT INTO CLAUDE CODE
/simplify Review code for reuse + quality
/debug Help diagnose issues
/init Initialize a CLAUDE.md
/review Review a pull request
The ServiceNow SDK comes bundled with its own set of skills that cover the metadata types you work with every day. When you install the SDK into your repo, you'll see them all laid out under .claude/skills/:
your-app/
└─ .claude/
└─ skills/
├─ business-rule/
│ └─ SKILL.md
├─ client-script/
│ └─ SKILL.md
├─ script-include/
│ └─ SKILL.md
├─ ui-action/
│ └─ SKILL.md
├─ flow-designer/
│ └─ SKILL.md
├─ table/
│ └─ SKILL.md
└─ ...
Each SKILL.md file contains three layers of instruction:
- When to use: Tells Claude Code when this particular skill is relevant
- What to do: File structure, field mappings, metadata format
- Platform nuance: The stuff a ServiceNow developer would know, like when to use a Before vs After business rule, or when async makes sense
WHAT'S IN A SKILL.MD
┌──────────────────────────────────────┐
│ 1. WHEN TO USE │
│ "Use this skill when creating │
│ or modifying Business Rules" │
│ │
│ 2. WHAT TO DO │
│ File structure, field mappings, │
│ metadata format │
│ │
│ 3. PLATFORM NUANCE │
│ Before vs After │
│ Sync vs Async │
│ When to use Display rules │
│ GlideRecord patterns │
└──────────────────────────────────────┘
For the most part, you can just start prompting Claude Code to build your app and it'll load these skills automatically when it needs them. Or you can invoke them as a slash command directly if you want to be explicit about it.
TWO WAYS TO USE SKILLS
Auto-Load Slash Command
┌────────────────────┐ ┌────────────────────┐
│ │ │ │
│ "Build me a │ │ > /business-rule │
│ business rule │ │ │
│ that prevents │ │ Loads the skill │
│ duplicate │ │ immediately and │
│ inserts" │ │ follows its │
│ │ │ instructions │
│ Claude Code sees │ │ │
│ "business rule" │ │ │
│ and loads the │ │ │
│ skill on its own │ │ │
│ │ │ │
└────────────────────┘ └────────────────────┘
I've built ServiceNow apps with Claude Code both before these skills were open-sourced and after. The difference is real. These skills feel like the magic key to making the SDK just work. Since everything comes through the SDK, you can "Build Anywhere" because you're no longer tied to building apps solely within the platform.
How to write good prompts for Claude Code
Coming soon, I'm making these videos in batches.
When to use plan mode
Coming soon, I'm making these videos in batches.
Opus vs Sonnet (and cost/token awareness)
Coming soon, I'm making these videos in batches.
Plan tasks, then plan execution, then execute
Coming soon, I'm making these videos in batches.
Debugging with Claude Code
Coming soon, I'm making these videos in batches.
Group 3: Git + Deploy
Your app works locally. Now you need to get it version-controlled and onto an actual ServiceNow instance. This group covers the git workflow and the SDK's build and deploy commands.
Branches
Coming soon, I'm making these videos in batches.
Work trees
Coming soon, I'm making these videos in batches.
GitHub commit and push
Coming soon, I'm making these videos in batches.
SDK build + deploy
You've written the app. Time to ship it. The build and deploy flow comes down to two commands.
now-sdk buildcompiles your Fluent source into a deployable packagenow-sdk deploypushes that package to your instance
That's the core loop: write code, build, deploy, check.
BUILD AND DEPLOY
┌─────────────────────────────────────────┐
│ │
│ $ now-sdk build │
│ │
│ Compiles Fluent source │
│ Generates ATF tests │
│ Runs readiness scan │
│ │
│ $ now-sdk deploy │
│ │
│ Pushes package to your instance │
│ App appears in Studio │
│ │
└─────────────────────────────────────────┘
Here's what happens during now-sdk build:
- The SDK takes your Fluent source files and compiles them into the app artifacts your instance expects
- It generates ATF tests alongside those artifacts, so you've got test coverage from the start
- It runs a readiness scan, which catches common issues before you even try to deploy
If something's off, you'll know at build time, not after it's on your instance.
BUILD OUTPUT
Fluent source
│
v
┌──────────────────┐
│ App artifacts │
│ (tables, rules, │
│ scripts, flows) │
├──────────────────┤
│ ATF tests │
│ (auto-generated) │
├──────────────────┤
│ Readiness scan │
│ (issues caught │
│ before deploy) │
└──────────────────┘
On deploy, your app lands in your instance and shows up in ServiceNow Studio under your app list, just like any other scoped app. From the platform's perspective, there's nothing special about it. It's a native scoped application.
Post-deploy checklist:
- Open Studio, find your app, and confirm the scope and tables look right
- Click into a table or two and make sure the fields are there with the types you expected
- If your app includes agents, open AI Control Tower and confirm they're registered
- Create a test record and make sure rules fire as expected
POST-DEPLOY CHECKLIST
┌─────────────────────────────────────────┐
│ │
│ 1. Open Studio │
│ Find your app in the app list │
│ │
│ 2. Check scope and tables │
│ Verify the data model looks right │
│ │
│ 3. Open AI Control Tower │
│ Confirm agents are registered │
│ (if your app includes agents) │
│ │
│ 4. Sanity-check a record │
│ Create a test record, make sure │
│ rules fire as expected │
│ │
└─────────────────────────────────────────┘
If deploy fails, check these first:
- Credential mismatch: The most common cause. If you followed the credentials episode, you've already tested this. If you skipped ahead, go back to that episode and walk through the setup.
- Instance version: Your instance might not support the features your app uses.
- Scope conflict: Another app with the same scope already exists on the instance.
DEPLOY FAILED? CHECK THESE
┌─────────────────────────────────────────┐
│ │
│ 1. Credential mismatch │
│ Token in credential record must │
│ match token in your tool │
│ (see episode 1-7) │
│ │
│ 2. Instance version │
│ Does your instance support the │
│ features your app uses? │
│ │
│ 3. Scope conflict │
│ Another app with the same scope │
│ already exists on the instance │
│ │
└─────────────────────────────────────────┘
One thing worth being upfront about: full test pipelines from external IDEs are still evolving. Build and deploy from your terminal works great. But complex CI/CD workflows that run entirely outside the platform aren't fully there yet. I've had good success using branches within git in my terminal, though. This will get better, and I'll update the series when it does.
WHAT'S STILL EVOLVING
┌─────────────────────────────────────────┐
│ │
│ Works today: │
│ Build + deploy from your terminal │
│ │
│ Still in progress: │
│ Full CI/CD pipelines from │
│ external tools │
│ Branch management from │
│ outside the platform │
│ │
│ For branching: │
│ Use Source Control in Studio │
│ or GitHub directly │
│ │
└─────────────────────────────────────────┘
Group 4: Custom Tooling + Automation
Slash commands explained
Coming soon, I'm making these videos in batches.
Building your own slash commands from scratch
Coming soon, I'm making these videos in batches.
Issue finder command
Coming soon, I'm making these videos in batches.
Issue interview command
Coming soon, I'm making these videos in batches.
A command to tackle all issues with an agent team (and close them)
Coming soon, I'm making these videos in batches.
Group 5: Leveling Up
Move from vibe coding to agent orchestration
Coming soon, I'm making these videos in batches.
Use Claude Code for release notes and Teams messages
Coming soon, I'm making these videos in batches.
From prototype to production
Coming soon, I'm making these videos in batches.
- 208 Views
2 Comments
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
