From Spec to Deployed: How Itential’s Builder Skills Use Spec-Driven Development to Build Automation

Quick Summary

Itential’s Agentic Builder Skills for Claude Code let engineers build, deploy, and manage automation assets directly inside the Itential Platform from a plain-language spec file – no manual task wiring required. One install delivers 13 skills, 5 agents, and a plugin connecting Claude Code to your Itential environment, supporting workflows, FlowAgents, command templates, IAG services, Python scripts, Ansible playbooks, and more. In the demo covered here, a complete 10-task DNS provisioning workflow with an Operations Manager form was deployed in under 20 minutes from a single spec.

There’s a moment every automation engineer knows well. You’ve finished a discovery session, you understand exactly what the workflow needs to do: the entry points, the error handling, the integrations, the form fields. And now you have to go build it. Not design it. Build it. Task by task, adapter by adapter, variable by variable.

That translation layer – from “here’s what it needs to do” to “here’s a working automation” – is where most of the time goes. And it’s not the interesting part.

The interesting part is the logic. The use case. The outcome. Itential’s new Agentic Builder Skills for Claude Code are designed to give you that part back.

Introducing the Itential Agentic Builder Skills

The Itential Agentic Builder Skills are a set of Claude Code skills published to the Claude Marketplace that give AI coding agents the ability to build, deploy, and manage assets directly inside the Itential Platform, using nothing but a natural language spec.

Install them into your Claude Code environment and you get access to a full toolkit: a builder agent, a spec creation skill, a FlowAgent builder, adapters for device and config inventory, and more. One install adds 13 skills, 5 agents, and a plugin that connects Claude Code to your Itential environment via your service account credentials.

The skills support building a wide range of platform assets:

• Workflows
• FlowAgents (AI agents embedded in the platform)
• Command templates
• Configuration Manager assets
• Configuration templates
• Lifecycle Manager assets
• IAG services
• Python scripts
• Ansible playbooks integrated through the Itential Automation Gateway

That’s not a future roadmap item. That’s what’s available now, from the Itential Builder Skills GitHub repo.

What Is Spec-Driven Development?

Spec-Driven Development (SDD) is a shift in how you approach building automation. Instead of starting with the platform and wiring tasks together, you start with a document, a spec, that describes what the automation needs to do in plain language.

The idea is simple: focus on the what, not the how. Define your use case, including the entry point, the inputs, the workflow logic, the expected outcomes, and the error handling, then let the AI handle the translation into working platform assets.

A spec isn’t code. It’s not a flowchart. It’s a structured description of intent. It can be written as a markdown document, a bulleted list, a UML diagram, or even a hand-drawn workflow on a whiteboard photographed and described in text. The format is flexible. What matters is that it captures what you’re trying to build with enough clarity that an AI agent can execute against it.

This matters because it changes where automation engineers spend their time. Discovery, logic design, and validation are where expertise actually lives. The Builder Skills take the mechanical construction work off your plate.

What Goes in a Spec?

For the demo in this post, a simple DNS A record provisioning workflow was built against Infoblox. The spec covered:

• Entry point: An Operations Manager form with a manual trigger. No legacy wrapper. Named “DNS A Record Simple.”
• Form fields: Hostname, zone, IP version, TTL, and a dropdown of FQDN values pulled dynamically from the Infoblox adapter. Each field defined with its key, label, data type, required flag, default value, and any validations.
• Workflow logic: Accept the form inputs, merge the FQDN variables, build the A record body, create the A record in Infoblox, extract the record reference, build and send a confirmation email, handle errors with a warning variable.
• Project membership: Assign the project owner to the UI user account. Add the solutions engineers group as editors.
• Platform assets to create: One project, one workflow with named tasks, one Operations Manager form tied to the workflow trigger.

That’s it. Written in natural language. No JSON schema, no adapter configuration, no task wiring in the UI. Claude Code reads the spec, authenticates to the platform using your .env credentials, bootstraps the workspace, and starts building.

Demo: Building a DNS A Record Provisioning Workflow from a Single Spec File

Here’s exactly what the demo shows and why it matters.

The use case is a DNS A record provisioning flow against Infoblox. Simple on purpose. The goal isn’t to show the most complex thing the Builder Skills can do. It’s to show the full motion from spec to deployed asset in a single pass.

After installing the Builder Skills and adding the .env file with platform credentials, the builder agent was launched with a single prompt pointing to the spec file. While the spec walkthrough was still in progress, Claude Code was already working in the background.

By the time the walkthrough finished, it was done.

Here’s what got deployed in under 20 minutes from launching the agent:

• A project named “DNS A Record Provisioning Simple”
• A 10-task workflow: merge FQDN variables – build A record body – create the record via the Infoblox adapter – extract the reference – send a confirmation email – handle errors
• An Operations Manager automation with a manual form trigger, named exactly as specified in the spec

The platform was refreshed, the project was there. Operations Manager showed the entry. The form appeared with the correct fields including the dynamic FQDN dropdown populated from Infoblox. Filled it in, launched it, and got an email confirmation within seconds: record provisioned, IP address, DNS view, full Infoblox record reference.

Zero UI time building the automation. All of it from a spec.

How Do You Create the Spec?

This is the question that comes up most often, and it’s also where the Builder Skills story gets more interesting: you don’t have to write the spec by hand.

The Builder Skills include a spec creation skill and a solution architect agent. You can pass Claude Code a set of bullet points describing your use case, a UML diagram, a draw.io file, or even a rough workflow sketch – the spec skill formalizes it into a structured spec, and the solution architect agent validates feasibility and refines the design before the builder runs.

The full motion looks like this:

1. Describe your use case in whatever format makes sense: bullets, diagrams, narrative
2. Use the spec creation skill to formalize it into a structured spec
3. Run the solution architect agent to validate feasibility and refine the design
4. Launch the builder agent against the spec
5. Review and validate what was deployed in the platform

The discovery and design work you were already doing is still yours. The Builder Skills just eliminate everything between the design and the deployed asset.

Why This Changes the Automation Engineering Motion

This isn’t a shortcut that produces low-quality automation. The workflow that came out of the spec had proper error handling, correct adapter configuration against Infoblox, and task naming that matched the spec exactly. It was production-ready to be reviewed and validated – not a prototype to be thrown away.

What it changes is where engineers focus. If your job is to build automation, a significant portion of your time has always gone to construction: wiring tasks, configuring adapters, setting up form fields. That work doesn’t require your expertise. It just requires your time.

SDD shifts that. The expertise goes into the spec. The construction is handled by the agent.

And because the spec is a document, it becomes the design artifact too. It doubles as your as-built documentation. The Builder Skills can generate solution design documents from it as well, so the paper trail that usually lags behind the work is built into the process.

What gets built doesn’t land in a folder on someone’s laptop. It lands in the Itential Platform – centralized, secured, and immediately subject to the same enterprise controls already in place: IDP and SSO integration, role-based access control, and a consistent exposure pattern through Operations Manager so every automation is surfaced the same way regardless of who built it or when.

That’s the difference between automation that works and automation that scales. The Builder Skills handle the construction. The platform handles everything that makes it enterprise-ready.

What’s Possible from Here

The DNS A record example is deliberately simple. A simple use case runs in under 20 minutes and proves the motion works.

But a spec doesn’t have to describe one workflow. It can describe an entire project: multiple workflows, multiple form entries, multiple components that work together as a single automation product. You can build a spec for provisioning an EC2 instance, attaching a VPC, creating a certificate, and standing up a service – all in one pass.

The constraint isn’t the platform. The constraint is the quality and completeness of the spec. That’s a design problem, which is exactly the kind of problem automation engineers are good at.

Beyond workflows, the Builder Skills also include a dedicated FlowAgent builder. If your use case calls for an AI agent embedded in the platform rather than a traditional workflow, the same spec-driven approach applies.

Key Takeaways

• Spec-driven development separates automation design from automation construction. The spec defines intent; the Builder Skills handle the build.
• The Itential Agentic Builder Skills are Claude Code skills available via the Claude Marketplace and the Itential GitHub repo.
• One install delivers 13 skills, 5 agents, and a platform plugin covering a wide range of deployable asset types.
• A spec can be written as markdown, bullet points, a UML diagram, or any structured description of intent — and can itself be generated by the spec creation skill.
• Assets deployed are production-ready for review and validation, not prototypes, and the spec doubles as as-built documentation.

Get Started

The Itential Agentic Builder Skills are available now on the Claude Marketplace and directly from the Itential Builder Skills GitHub repo. The repo includes example specs to get you started – you don’t need to build your first spec from scratch. Watch the full DNS Automation Workflow demo here or below to see how Itential Builder Skills build spec-driven automation workflows in minutes.

If you’re already building automation on the Itential Platform and want to see what this looks like in your environment, talk to the team.