When you work with Infrahub, you’ll eventually need to build schemas, write Generators, create Transformations, and more. Normally that means knowing the platform well or spending a fair amount of time going through the docs, especially if you’re doing anything for the first time.
A learning curve isn’t unique to Infrahub. Whatever tool you work with, there’s usually something new to understand before you can use it properly. Lessening that learning curve is exactly what AI skills are meant to solve, and Infrahub has its own set of custom Skills for teaching your AI coding assistant.
Without Infrahub Skills, if I wanted to build something in Infrahub using an AI assistant (Claude Code, for example), I’d have to write out the whole context myself every time. I’d need to explain what a schema looks like, how attributes and relationships are structured, what namespaces are, how object files work, how to write a Jinja2 Transformation, and so on. Or I could clone some existing schemas and point the assistant to them, hoping it picks up the right patterns from there.
The result is a long prompt full of rules and examples. If I want to reuse it, I copy and paste it every time. If I want to share it with someone else on my team, I have to hand them the same prompt and hope they keep it updated when things change. It works but it doesn’t scale well and it eats up a lot of context it doesn’t need to.
What are AI skills?
Anthropic introduced agent skills in October 2025. A skill is a set of instructions your AI assistant can load on demand, built around Markdown files where you declare your conventions and rules instead of stuffing them into a prompt every time. You can also add extra files alongside it, like Python scripts for validation, so the assistant has everything it needs without you repeating yourself.
The other benefit is that skills only load when they’re actually needed, so they don’t take up your context window the whole time. And since they’re just files, you can version control them, share them with your team, and keep everyone on the same copy.
Infrahub built on top of the AI skill concept generally and put together its own set of Infrahub Skills, covering schemas, objects, menus, checks, Generators, and Transformations, along with others for auditing, analysis, data import, and learning Infrahub concepts. These Skills are what we’ll use throughout this post.
In the rest of this post, we’ll install Infrahub Skills, then work with an AI coding assistant (Claude Code) to build a schema and load some objects. Along the way, you’ll see when a Skill gets picked up and how Infrahub-specific details, like branches and Proposed Changes, get handled automatically.
Before getting started with Infrahub Skills
This post assumes you’re somewhat familiar with Infrahub already. We won’t go deep into things like how to install it, schemas, or infrahubctl, since those are already covered in many of my previous posts and the documentation extensively. The focus here is on the Skills themselves. With that out of the way, here’s what you’ll need before getting started:
- A running Infrahub instance (version 1.11.3 used in this post)
- Python 3.12 or 3.13
infrahubctl, installed viauv add 'infrahub-sdk[ctl]'- Claude Code or any other AI coding assistant that supports AI skills
I’ll go through this part quickly, showing the commands to install Infrahub, clone the repo, and bring it up with Docker Compose.
git clone https://github.com/opsmill/infrahub.git cd infrahub docker compose up -d
Alternatively, you can use the documented install method, which avoids cloning the full source repo.
curl https://infrahub.opsmill.io -o docker-compose.yml docker compose up -d
Then go to localhost:8000 and log in with admin / infrahub.
Next, we’ll install infrahubctl, the CLI for interacting with your Infrahub instance. We need it here because it’s what the Skills use, through Claude, to load the schemas and objects we’ll be generating later in this post.
Before installing it, create a project folder. This is where we’ll run most of the commands for the rest of this post, so it’s worth keeping everything in one place. The name of the project folder can be anything.
mkdir infrahub-skills cd infrahub-skills
uv add 'infrahub-sdk[ctl]' or pip install 'infrahub-sdk[ctl]'
Installing the Infrahub Skills
With Infrahub and infrahubctl in place, the next step is to install the Infrahub Skills. The npx installer detects which AI tools you have configured and installs the Skills in the correct format for each one automatically.
npx skills add opsmill/infrahub-skills
Note: npx comes bundled with Node.js, so if you have Node and npm installed, you already have it. If not, the easiest way to get it is by installing nvm first, then using it to install Node.js.
When you run the command, you’ll get a few prompts along the way: which Skills to install, which AI agent to install them for, whether to install at the project or global level, and whether to symlink or copy the files. Pick the options that match your setup. The full instructions on how to install Infrahub Skills can be found in the documentation.
Once installed, you can ask Claude directly what Skills it has access to for the project, something like:
What Infrahub skills do you have access to for this project?
You should see a response listing the Infrahub Skills that were installed, such as infrahub-managing-schemas, infrahub-managing-objects, and infrahub-common. If they show up, the Skills were picked up correctly, and we can move on.
So far, we’ve installed Infrahub itself and brought it up with Docker Compose, installed infrahubctl so we can load schemas and objects into it, and installed the Infrahub Skills so Claude knows how to work with the platform correctly. At this point, we have everything in place to actually start building something.
Building a schema using the Schema Manager Skill
Instead of us defining the schema ourselves, let’s have Claude (or any other AI coding assistant) do it for us. We’ll ask it to create a simple schema with:
- A Device with a hostname, vendor, model, and role
- A Site with a name and location
- A relationship connecting the two
A schema in Infrahub defines the structure of your data, the node types, their attributes, relationships, and things like namespaces, unique fields, and display labels. Getting this right is important, since the schema is what everything else, such as objects, Generators, Transformations, and checks, ends up building on.
This is where the benefit of Infrahub Skills really shows. Instead of looking all of this up or learning it through trial and error, the infrahub-managing-schemas Skill already knows these conventions and applies them correctly from the start.
Here’s the prompt I used:
Create an Infrahub schema with a Device node (hostname, vendor, model, role) and a Site node (name, location), with a relationship between them.
Claude picks up on this and loads the infrahub-managing-schemas Skill automatically, since the request matches what that Skill covers. You don’t need to tell it which Skill to use. It generated the following schema file (under schemas/dcim-site.yml).
# yaml-language-server: $schema=https://schema.infrahub.app/infrahub/schema/latest.json version: "1.0" nodes: - name: Site namespace: Location description: A physical site where devices are located. human_friendly_id: - name__value display_label: name__value attributes: - name: name kind: Text unique: true order_weight: 1000 - name: location kind: Text optional: true order_weight: 1100 relationships: - name: devices peer: DcimDevice kind: Generic cardinality: many identifier: "site__devices" order_weight: 900 - name: Device namespace: Dcim description: A network device. human_friendly_id: - hostname__value display_label: hostname__value attributes: - name: hostname kind: Text unique: true order_weight: 1000 - name: vendor kind: Text optional: true order_weight: 1100 - name: model kind: Text optional: true order_weight: 1200 - name: role kind: Text optional: true order_weight: 1300 relationships: - name: site peer: LocationSite kind: Generic cardinality: one optional: false identifier: "site__devices" order_weight: 900
You can load the schema into Infrahub using a branch, but the branch needs to exist. First, create the branch, then load the schema into it.
infrahubctl branch create first Branch 'first' created successfully (18da6b34-4b72-85d2-385a-c513e9f57ad5).
infrahubctl schema load --branch first schemas/dcim-site.yml schema 'schemas/dcim-site.yml' loaded successfully 1 schema processed in 6.508 seconds.
What stands out here is that I didn’t have to know the exact Infrahub schema syntax to get this. I described the nodes and the relationship in plain language, and Claude used the Skill to generate a schema that follows the correct structure, naming conventions, and even things like human_friendly_id and display_label, which I wouldn’t have thought to add myself as a beginner.
This is the real benefit of AI skills, especially since these ones are built and maintained by the Infrahub team. Instead of me learning the schema format from scratch or copying an example and hoping it’s still valid, the Skills already know the conventions and apply them correctly, straight from the people who built the platform. And because it’s using a branch, I can review and test it before it touches anything else in Infrahub.
That said, using a Skill doesn’t mean you can skip learning Infrahub itself. You still need to understand what a schema is, what a namespace does, and why you’d use a branch in the first place, so you can tell whether what the Skill produces actually makes sense for your use case. Skills remove the need to memorize exact syntax and conventions, not the need to understand the platform.
Using the Infrahub template
So far, we’ve been working with just a schema file sitting in a plain folder, meaning a schemas/ directory with a single YAML file in it and nothing else around it. That works fine for a quick test, but it could be set up better for working with Infrahub long-term.
Currently, there’s no .infrahub.yml file, and no structure for objects, Generators, or Transformations. In practice, schemas, objects, and automation could all live in the same directory, depending on how you set it up.
Infrahub provides a template for setting up a proper repository, so let’s try that next and see how the Skills behave in a more realistic setup.
The template uses copier, which scaffolds out a full repo structure, schemas, objects, Generators, Transformations, scripts, menus, and even a test setup, so everything is wired up correctly from the start instead of you creating these folders and config files by hand.
uv tool run --from 'copier' copier copy https://github.com/opsmill/infrahub-template infrahub-skills
This walks you through a few prompts asking what you want to enable from the list of objects, Generators, Transformations, and so on.
uv tool run --from 'copier' copier copy https://github.com/opsmill/infrahub-template infrahub-skills Installed 21 packages in 8ms 🎤 The name for your new Infrahub repository. This will be used as the package name. infrahub-skills 🎤 Getting started? Answer yes to use a recommended starter configuration (objects enabled) and skip the remaining questions. No 🎤 Enable support for Infrahub object files. Yes 🎤 Enable support for Infrahub data generators. Generators are plugins that create objects based on input data in Infrahub. Yes 🎤 Enable support for Infrahub data transforms. A Transformation is a generic plugin to transform a dataset into a different format to simplify its ingestion by third-party systems. Yes 🎤 Include a 'scripts/' directory for custom automation scripts that interact with the Infrahub API. Yes 🎤 Include a 'menus/' directory and configuration to define custom navigation menus in the Infrahub UI. Yes 🎤 Set up a Python testing environment with pytest for integration testing your schemas and data. Yes 🎤 Initialize the repository as an installable Python package (with pyproject.toml). Yes
I said yes to most of them just to have the full structure available. Once done, it creates a repo with everything already scaffolded.
This time, I gave Claude a similar prompt as before: create a Device and Site schema with a relationship. But I also told it to start Infrahub and load the schema into a new branch called v1. I deliberately asked for v1 as the branch name, knowing Infrahub requires branch names to be at least three characters. I wanted to see how Claude Code would handle it.
Create an Infrahub schema with a Device node (hostname, vendor, model, role) and a Site node (name, location), with a relationship between them. Also starts the infrahub instance and load the schema into a new branch called v1.
Here’s a trimmed version of what Claude did, skipping the shell command noise and just keeping the important bits.
● Skill(infrahub-managing-schemas) Successfully loaded skill · 4 tools allowed No containers running. Starting Infrahub in the background while I write the schema. ● Write(schemas/dcim.yml) Wrote 75 lines to schemas/dcim.yml Infrahub is up. Creating branch v1, then checking and loading the schema on it. Infrahub won't accept v1 as a branch name because it requires at least 3 characters. · Which branch name should I use? → schema-v1 I wrote the schema, started Infrahub, and loaded it into a new branch. Infrahub rejected the name v1 because branch names need at least 3 characters, so the branch is schema-v1, as you chose. The schema is only on schema-v1. When you're happy with it, open a proposed change in the UI to merge it into main.
I didn’t run Docker Compose myself this time, and I didn’t run infrahubctl either. Claude managed all of it on its own, spinning up Infrahub, writing the schema, creating the branch, and loading it in. When Infrahub rejected v1 as the branch name, Claude caught the error, asked me what I wanted to use instead, and continued once I gave it a new name: schema-v1.
A few things worth pointing out from this run. Claude picked a dropdown with fixed values for role (core, distribution, access, firewall) instead of plain text like our earlier example—a reasonable call on its own.
It also correctly flagged that the schema only exists on the schema-v1 branch and should go through a Proposed Change for review before merging into main. That’s exactly the kind of Infrahub-specific workflow knowledge the Skill is meant to provide.
Adding objects using the Object Manager Skill
Now that we have the schema in place, let’s add some objects to it, but instead of writing the object files ourselves, we’ll let Claude generate them for us.
Can you now create a site called HQ in London and add two access switches? They are all C9300 Cisco switches. Do this by creating an object file/files. Add them to the same branch as before.
Here’s a trimmed version of the output.
● Skill(infrahub-managing-objects) Successfully loaded skill · 4 tools allowed I created the HQ site in London and two Cisco C9300 access switches, and loaded them onto the schema-v1 branch. A query on that branch shows both switches linked to HQ, and HQ lists 2 devices. Files: - objects/01_sites.yml creates the site HQ with location London. - objects/02_devices.yml creates hq-acc-sw01 and hq-acc-sw02, each with vendor Cisco, model C9300, role access and site HQ. The number prefixes make the site load before the devices that point to it. You didn't give hostnames, so I made up hq-acc-sw01 and hq-acc-sw02. To load the same files again: infrahubctl object load --branch schema-v1 objects/01_sites.yml objects/02_devices.yml
A couple of things stand out from this run. Claude loaded infrahub-managing-objects this time instead of the Schema Manager Skill, since the request was about creating data, not structure. And since we didn’t give it hostnames, it made a reasonable naming choice (hq-acc-sw01, hq-acc-sw02) instead of asking or guessing something odd.
At this point, we have a working schema and some real objects loaded against it, entirely from plain language prompts. From here, the same approach extends to the rest of the lifecycle.
You could ask Claude to extend the schema itself, adding an Interface node connected to Device, or a Circuit and Provider to model connectivity between sites, and then load more objects against the updated model, with additional devices, interfaces, or circuits to flesh out the topology.
Learning with the Concept Tutor Skill
So far, every Skill we’ve used has been about producing something—a schema or a set of objects, for example. Next, let’s look at a Skill that helps you learn Infrahub concepts as you work, using your own repository and instance.
The infrahub-teaching-concepts Skill is different from the others covered so far. Instead of building schemas, objects, or Transformations, it teaches Infrahub concepts such as branches, Proposed Changes, schema, GraphQL, and more, using your own repository and instance rather than generic examples. It’s meant to be useful alongside whichever other Skills you’re using, since it can step in any time you want to understand something rather than just build it.
To see it in action, I asked Claude a learning-oriented question:
I’m new to Infrahub. Can you walk me through what a proposed change is, how it differs from just merging a branch directly, and quiz me on it after?
This triggered the Concept Tutor Skill correctly.
● Skill(infrahub-teaching-concepts) Successfully loaded skill · 4 tools allowed I'll teach this through your own schema-v1 branch, so the proposed change we look at will contain your HQ site and switches. First, a few quick questions so I can pitch the explanation at the right level. 1. Background: have you used Git with pull requests or merge requests (GitHub or GitLab)? 2. When you did code reviews or change approvals before, what happened between "I made a change" and "the change is live"? 3. Guess: if someone merged schema-v1 straight into main right now, what could go wrong that a review step might have caught? One setup question: can I create a small .infrahub-learning/ folder in this repo, to hold the lesson and a progress file so a future session can pick up where we stopped? If you'd rather keep the repo clean, I'll keep everything in chat. Once you answer, I'll explain proposed changes using your branch, set you a short hands-on task, and then quiz you.
Claude offered to teach the concept using our own schema-v1 branch, so the explanation would be grounded in the actual Proposed Change we’d create from it, rather than a generic example. It also asked a few background questions first to pitch the explanation at the right level, and offered to save progress in an .infrahub-learning/ folder so a future session could pick up where the lesson left off.
The Concept Tutor Skill is useful to keep in mind for any Infrahub project going forward, especially if you’re newer to the platform and want explanations grounded in your own setup rather than documentation examples.
How to explore Infrahub Skills in more detail
To see Infrahub Skills in action, check out the technical demo on the OpsMill YouTube channel. It covers more than what we did in this post. The demo builds a schema with devices, interfaces, circuits, and providers, generates menus, and loads objects, all from plain language prompts. It then creates a Jinja2 Transformation that renders a device config and connects a Git repository so artifacts are generated in Infrahub.
For installation options and the full list of Skills available, check the documentation.
And if you run into something that doesn’t work as expected, or want to see a new Skill added, open an issue or a PR on the Infrahub Skills GitHub repository.
