Build with AI
You can describe the network you want to model in your own terms and have your assistant build the Infrahub resources that represent it — the schema that models your network, the automation that acts on your data as it changes, and the queries that answer questions about it.
Use this path to prototype a use case before you have learned Infrahub's schema model, to ship schema, Generators, and checks faster on an implementation you already run, or to answer a question about your live infrastructure without going through an engineer.
This is the recommended way to build an Infrahub implementation. You can also do each of these tasks by hand, and the sections below link the instructions for doing that.
What your assistant needs to know​
Building an Infrahub implementation means turning your network design into a data model, populating that model with your data, and building the checks, Generators, Transformations, and other automation that operate on it. With an AI-first approach you describe the requirements and the business logic, and your assistant writes those resources, applying Infrahub's schema rules, file formats, and development conventions as it goes.
That takes two kinds of context — Infrahub's conventions, and the state of your own instance. Each comes from a different tool:
- Infrahub Skills contain Infrahub's data model, conventions, and workflow patterns. Your assistant loads them and applies that knowledge as you create schemas, objects, checks, Generators, Transformations, imports, menus, and other Infrahub resources.
- The Infrahub MCP server connects your AI assistant to a running Infrahub instance, where it can discover your schema, query your data, make changes on isolated branches, and open Proposed Changes for review.
You can use either on its own. Together, your assistant has both the Infrahub-specific knowledge for how to build and the instance-specific context for what you have already built. Working with an LLM and neither tool installed is also a legitimate setup — see Set up your AI assistant for what you keep and what you give up, alongside the installation steps for both tools.
Start with what you want to build​
The starting point is your network design, in the terms your team already uses for it.
You might describe a fabric with spine and leaf devices, the relationships between them, the addressing you need to allocate, and the configurations you eventually want to generate. Your assistant reads the Infrahub Skills for the conventions that turn those requirements into Infrahub resources — schema structures, relationships, queries, Python or Jinja2 code, and .infrahub.yml registrations.
For a well-scoped task, describe what you want and let your assistant select the appropriate skill. For a larger implementation, Spec-Driven Development works through the requirements and the implementation plan before any files are generated: you review the plan, adjust the design, and then have the assistant build the individual components. See Work with your assistant to choose between them by the size and complexity of the change.
You can learn Infrahub while working with your own network model: inspect what the assistant produces, ask why it chose a particular relationship or attribute type, and refine the implementation as your requirements evolve.
What you can build​
Model your network​
Describe the domain you need to represent — devices, locations, circuits, services, routing, or another part of your network — and your assistant can create or extend an Infrahub schema.
Your assistant reads the Schema Manager skill for Infrahub's conventions on node and attribute names, attribute types, relationships, generics, human-friendly IDs, display labels, Profiles, and Object Templates, and applies them to the schema it writes. You can then validate that schema before loading it into Infrahub. See Build your schema.
Bring in existing data​
When your network data is already held in spreadsheets, exports, or another source of truth, your assistant can map it into your Infrahub model.
Working from the Data Importer skill, your assistant takes CSV or TSV data, inspects your Infrahub schema, maps columns to the appropriate attributes and relationships, generates object files in the correct load order, and validates and loads them on a dedicated branch. Where a source field has no destination in your schema, your assistant reports the gap for you to resolve instead of choosing one silently. See Import data from CSV.
When you are creating objects from a description rather than from a file, your assistant can produce the same object-file format using the Object Manager skill, with references and load order handled for you.
Build automation from your data​
You can have your assistant build the automation that runs as your modeled data changes. For example, ask it to:
- create BGP sessions from a topology design;
- generate devices, interfaces, and IP addresses from a fabric definition;
- render device configurations from Infrahub data;
- build a validation check for a network design rule.
Each component has a skill carrying its Infrahub-specific patterns. For a Generator, your assistant uses the Generator Manager to write the GraphQL query, the Python Generator, and the registration needed to derive infrastructure objects from a design and keep them synchronized as that design evolves. Your assistant works the same way from the Transform Manager for Transformations and the Check Manager for checks. For the same work done by hand, see Build a generator, Write a Jinja2 Transformation, and Build a check.
Ask questions about your live network data​
With the MCP server connected, your AI assistant can answer questions about the data in a running instance:
- Which services depend on this circuit?
- Which devices are missing a platform?
- Which objects depend on this prefix?
- Where does realized state differ from the design?
The MCP server exposes your schema and data through structured tools, so your assistant can discover the kinds and relationships that actually exist instead of relying on assumptions about your model. For cross-node analysis, dependency and change-impact questions, drift analysis, and data-quality audits, your assistant uses the Data Analyzer skill, which needs the MCP connection to reach live data. See Analyze your data.
Maintain and improve your implementation​
Once an implementation is running, you can use your assistant to audit it, shape its navigation, diagnose problems, and report what you find.
With the Repo Auditor, your assistant reviews schema files, object files, Python components, .infrahub.yml registrations, and project structure against Infrahub conventions, and reports what should be corrected and why. With the Menu Manager, it can build navigation around the way different people use your data.
When a deployment is misbehaving, your assistant reads the Diagnostics Collector and runs infrahub-collect to gather the support bundle OpsMill needs. With the Diagnostics Analyzer, it triages a bundle you have already collected — tracebacks across the service logs, the incidents they correlate into, and any match against known issues in opsmill/infrahub.
To report a bug or request a feature, your assistant uses the Issue Reporter to work out which opsmill/infrahub-* repository it belongs in, search for existing duplicates, and draft the issue for your review — see How do I get help with Infrahub?. Where a skill's own guidance was missing or unclear enough to cost you repeated retries, it can use the Skill Gap Reporter to report that friction against the skill itself.
Where to start​
| You want to | Documentation | Skill reference |
|---|---|---|
| Model a domain, and plan the migration when you change it later | Build your schema | Schema Manager |
| Get data you already have into Infrahub | Import data from CSV, Load data using YAML file | Data Importer, Object Manager |
| Generate objects from a design, render configuration, enforce a rule on every change | Build a generator, Write a Jinja2 Transformation, Build a check | Generator Manager, Transform Manager, Check Manager |
| Ask questions about live infrastructure | Analyze your data | Data Analyzer |
| Organize the web interface | Menu customization | Menu Manager |
| Check a repository against Infrahub conventions | infrahub.yml configuration | Repo Auditor |
| Get help with a deployment that is misbehaving, or file an issue | Getting help | Diagnostics Collector, Issue Reporter |
How Infrahub Skills and MCP work together​
| Infrahub Skills | Infrahub MCP server | |
|---|---|---|
| What your assistant can use | Infrahub conventions, patterns, examples, and development workflows | Your live Infrahub schema and data, plus tools to query and change them |
| Where it works | Your project and its files | A running Infrahub instance |
| Use it when | You are building or modifying schemas, objects, checks, Generators, Transformations, imports, or other project resources | You need to inspect, analyze, or change data in the instance you are connected to |
Use both when your assistant needs to apply Infrahub conventions while also understanding the schema and data that already exist in your environment.
Most Infrahub Skills work without the MCP server. The Data Analyzer is the exception, because the data it analyzes is live. With MCP connected, your assistant also has instance context in other development workflows, where that context is useful.
How changes made through MCP are reviewed​
Changes made through the MCP server reach the default branch the way every other change does: on a branch, through a Proposed Change you review and merge.
When the MCP server makes its first write, it creates a session branch. Additional writes in the same session stay on that branch. Session branches are named mcp/session-{date}-{hex} by default, and the pattern is configurable. When the work is ready, your assistant can call propose_changes to open a Proposed Change against the default branch.
You review the diff and any configured checks in Infrahub before merging. The MCP server has no tool that merges a branch, so changes made through it do not reach the default branch until a person merges them.
How much access the server has is yours to set. In a read-only deployment, the write tools are not offered to your assistant and GraphQL mutations are rejected. For a multi-user deployment, you choose how identity is established at the MCP and Infrahub layers — the default is a shared set of credentials, so a deployment several people connect to is worth configuring deliberately. See MCP authentication for the options.
Review what your assistant produces​
Your assistant applies Infrahub conventions and runs the validation appropriate to a task. Whether the result represents the network you intended to model is yours to decide.
A schema can pass infrahubctl schema check and still model the wrong relationship for your design. An imported object file can be structurally valid while containing a source mapping you do not want. Review the model, the generated automation, and the data changes with the same attention you would give code or infrastructure changes produced by another engineer.
Where a requirement should apply consistently, use Infrahub's validation mechanisms. Your assistant can answer "Which devices violate this naming convention?" for the data you have now. Where that rule should hold for every future change, the Check Manager turns it into a check that runs as part of your Proposed Change workflow.
In this section​
- Set up your AI assistant — Install the Infrahub Skills, connect the MCP server, and choose the combination that fits how you work
- Work with your assistant — Decide when to describe a change directly and when to plan it first, and what to check in what your assistant produces