Eleven agents modelled on real project roles take your work from requirement to production release. You approve what matters.
Every name’s initials spell its role. Every robot wears something its job needs. Ten work inside a project with David; Greg looks after all the projects from the workspace.
Runs the team. Reads your request, picks the right activity, assigns the work, holds every approval gate and reports back.
Turns SOWs, workshop notes, screenshots and plain requests into stories with testable acceptance criteria. The only agent who writes stories to PROD.
Design authority for the whole project. Plans every build, signs off every change, keeps the decision log and watches platform health.
Reads everything: your instance, documents and code. Any teammate can call on him at any time for facts and evidence.
Builds stories in the right scope and update set on DEV, inside the plan you approved. Asks before anything outside it.
Writes test scripts and runs them on DEV, again on TEST / Stage after every promotion, and on PROD when you allow. ATF when your project enables it.
The independent challenger. Reviews plans and builds for security, privacy, governance, notifications and downstream effects.
Promotes update sets to TEST and Stage, and plans production releases with prerequisites, manual steps, order, tests and rollback.
Produces engagement decks, technical and functional documents, workbooks and process diagrams in your templates.
Remembers every project. Captures lessons learnt and answers “have we done this before?” from past projects and instance records.
Looks after the whole portfolio from the workspace folder: lists projects, creates and registers them, sets status and dates, and points you to the right project folder. Never touches an instance.
You talk to David, the Delivery Manager. He turns your request into a plan and runs the team.
In plain words, or drop in a SOW, screenshot, transcript or story number.
Finds the project and instances, checks the project is active, and works out what you want.
Chooses one or more of 18 delivery activities and plans who does what, in order or in parallel.
Agents hand off, consult each other and run review loops. Every step is saved to the project folder.
You approve the plan, then the result, then every release. Nothing leaves DEV without your OK.
Drafts 6 stories from section 4 of the SOW
Reads the SOW and what already exists on the instance
Checks feasibility on the platform
“Story 3 is two things. Split it.”
Splits story 3: 7 stories, drafts saved
Approve creating the stories on acme (PROD)
Creates the 7 stories on PROD
With your comments per story. Barbara revises, Sandra re-checks feasibility, Thomas re-reads if scope moved. Then back to you.
Plans the build: scope, update sets, 2 flows, a catalog item
Reviews the plan for risk and notifications
“Reuse the HR catalog.” Then approve the plan
Builds every story on DEV inside the plan
Review: 2 findings, Su Do fixes them
Writes 14 test scripts and runs them on DEV: 1 defect
Fixes the defect, Harley Quinn retests: all pass
With your comments on the design. Sandra revises, Rachel re-reviews risk, Su Do re-checks effort. Then back to you.
Su Do never improvises. David asks you first; if the design changes, Sandra updates the plan before building resumes.
Approve the DEV results (project setting: on DEV or on TEST / Stage)
Moves stories to Ready for Testing on PROD
UAT: “Label should say Submit request.” Fixed, accepted
Promotes the update sets to TEST and Stage
Re-runs all 14 test scripts on TEST / Stage: pass
Production release plan: prerequisites, steps, order, tests, rollback
Approve the plan, run the PROD promotion (or hand it to Robert), choose the PROD test mode
Re-runs tests on PROD as you allowed; lessons learnt captured
Defect: Thomas triages, Su Do fixes, Harley Quinn retests. Design issue: Sandra. Wrong requirement: Barbara.
Real defects go to Su Do to fix and retest. New or changed scope: Barbara and Sandra assess the impact first.
Su Do fixes on DEV, Harley Quinn retests, Robert re-promotes, Harley Quinn re-runs on TEST / Stage.
Plan: Robert revises with your comments, Rachel re-checks rollback. PROD test fails: roll back per plan, Thomas finds the cause.
Each activity is led by the agent who owns it on a real project. David picks one, or chains several.
Sandra’s build plan comes to you first. Inside it the team builds, tests and fixes on DEV without asking at every step.
You approve the build and test results, every promotion to TEST / Stage, and the production release plan.
Barbara writes stories and Agile records to PROD. Robert promotes to PROD only when you hand a release over. Harley Quinn creates test records on PROD only in full mode.
David sends your exact words and the current files to the agent who owns the step. They revise, reviewers re-check, and it comes back to you.
A project marked not active is off limits to every agent unless you allow it in that conversation.
Sign-in stays with the ServiceNow MCP plugin. No passwords, cookies or tokens are stored or asked for.
A saying we borrowed from a manager we were lucky to work with. Do not build for things that have not happened and are not likely to. David, Sandra and Rachel sort every risk and every review finding into one of three buckets, and say which in one sentence.
Likely, or serious if it happens: security, data loss, compliance, production impact, a failing acceptance criterion. Dealt with before the next gate.
Unlikely and not severe today. Nothing is built for it. It goes on the project’s risk watchlist with the signal that would make us act, and who watches for it.
Small and understood. One line saying why, and we move on.
Every project starts with an empty risks/watchlist.md. Risks we let come closer wait there with their signal; David checks the signals in every status report, and when one fires the risk moves to Act now. No gold plating for improbable events, on the customer’s time and money.
| Setting | Values | What it does |
|---|---|---|
| approval_stage | dev (default) or test_stage | Where you approve the build and test results: on DEV before UAT, or later in TEST / Stage. |
| atf_enabled | false (default) or true | Whether Harley Quinn also creates ATF tests. Without it she writes and runs test scripts. |
| prod_test_mode | ask (default), off, read_only, full | How tests run on PROD after go-live. With ask, David asks you at every production promotion. |
| Story instance | PROD (default) | Where stories and Agile records live, unless you say otherwise. |
| Build target | DEV | Where Su Do builds and Harley Quinn first tests. |
Connections, sign-in, update sets and all instance actions go through it. Install it first.
Work from the terminal, the desktop app or your IDE. Each project gets its own folder, settings and history.
Every step is logged, so the companion timecard plugin can build your weekly cards from real evidence.
One workspace folder holds every project. Open Claude Code in a project folder for delivery work, or in the workspace folder for the portfolio. Everything else is internal: David and Greg load the 18 activities themselves.
David Milestone’s desk. One project per session: its instances, settings, approvals and write gate apply here, and other projects’ folders are off limits.
Greg Middlenote’s desk. Projects, status and dates, lessons across customers, the standards and lessons sites. Nothing is changed in ServiceNow from here.
/servicenow-ai-delivery:setup-global-workspaceOnce per machine. Creates the delivery workspace: the registry, the project folders and the shared rules. Run it again later and it only offers to refresh the shared rules.
/servicenow-ai-delivery:start-workIn a project folder. David takes any delivery request from here: stories, plans, builds, tests, releases, reports, documents. Used elsewhere, he tells you which folder to open.
/servicenow-ai-delivery:manage-projectsIn the workspace folder. Greg lists and creates projects, sets their status, finds lessons across projects and runs the standards and lessons sites. Used in a project, he points you to start-work.
ServiceNow AI Delivery is in beta in the WojasShop beta catalog. It needs the ServiceNow MCP plugin from the same catalog.
claude plugin marketplace add WojasShop/claude-plugins-beta/plugin install servicenow@wojasshop-beta/plugin install servicenow-ai-delivery@wojasshop-beta