Object Creator
Overview
Expert guidance for creating Infrahub object (data) files.
Objects are YAML files that populate schema nodes with actual
infrastructure data -- devices, locations, organizations,
modules, and more.
Project Context
Existing schema files:
!find . -name "*.yml" -path "*/schemas/*" -o -name "*schema*" -name "*.yml" 2>/dev/null | head -10
Existing object files:
!find . -name "*.yml" -path "*/objects/*" 2>/dev/null | head -20
If invoked with arguments (e.g., /infrahub:managing-objects DcimDevice spine-01),
use the first argument as the kind and remaining arguments as object details.
When to Use
- Creating new data files for infrastructure objects
- Populating devices, locations, organizations, or other schema nodes
- Setting up hierarchical data (location trees, tenant groups)
- Referencing related objects across files
- Managing component children (interfaces, modules)
- Organizing object files for correct load order
Rule Categories
| Priority |
Category |
Prefix |
Description |
| CRITICAL |
File Format |
format- |
apiVersion, kind, spec structure |
| CRITICAL |
Value Mapping |
value- |
Attributes, dropdowns, references |
| HIGH |
Children |
children- |
Hierarchy/component nesting |
| MEDIUM |
Range |
range- |
Sequential interface expansion |
| MEDIUM |
Organization |
organization- |
Naming, load order, multi-doc |
| LOW |
Patterns |
patterns- |
Flat lists, devices, git repos |
Object File Basics
---
apiVersion: infrahub.app/v1
kind: Object
spec:
kind: <NodeKind> # Schema node kind (e.g., DcimDellServer)
data:
- <attribute>: <value> # List of object instances
apiVersion, kind: Object, spec.kind, and spec.data
are always required. Each spec block targets a single
node kind.
Workflow
Follow these steps when creating object data files:
- Read the schema — Identify the target node kind,
its attributes, relationships, and whether it has
component children or hierarchy parents.
- Plan the file structure — Read
rules/format-structure.md
for the required YAML structure and
rules/organization-load-order.md
for file naming and load order conventions.
- Map attribute values — Set each attribute using
the correct value format. Read
rules/value-attributes.md
for attribute mapping and
rules/value-relationships.md
for relationship references.
- Handle children — If the node has component
children or hierarchy nesting, read
rules/children-components.md
and rules/children-hierarchy.md.
- Validate — Check YAML syntax and ensure
referenced objects exist or are defined in earlier
load-order files.
Supporting References
1---2name: infrahub-managing-objects3description: Creates and manages Infrahub object data YAML files for populating infrastructure instances — devices, locations, organizations, and modules. TRIGGER when: creating device instances, populating data files, defining locations or organizations, adding infrastructure objects. DO NOT TRIGGER when: designing schemas, writing Python checks/generators, querying live data.4---56# Object Creator78## Overview910Expert guidance for creating Infrahub object (data) files.11Objects are YAML files that populate schema nodes with actual12infrastructure data -- devices, locations, organizations,13modules, and more.1415## Project Context1617Existing schema files:18!`find . -name "*.yml" -path "*/schemas/*" -o -name "*schema*" -name "*.yml" 2>/dev/null | head -10`1920Existing object files:21!`find . -name "*.yml" -path "*/objects/*" 2>/dev/null | head -20`2223If invoked with arguments (e.g., `/infrahub:managing-objects DcimDevice spine-01`),24use the first argument as the kind and remaining arguments as object details.2526## When to Use2728- Creating new data files for infrastructure objects29- Populating devices, locations, organizations, or other schema nodes30- Setting up hierarchical data (location trees, tenant groups)31- Referencing related objects across files32- Managing component children (interfaces, modules)33- Organizing object files for correct load order3435## Rule Categories3637| Priority | Category | Prefix | Description |38| -------- | -------- | ------ | ----------- |39| CRITICAL | File Format | `format-` | apiVersion, kind, spec structure |40| CRITICAL | Value Mapping | `value-` | Attributes, dropdowns, references |41| HIGH | Children | `children-` | Hierarchy/component nesting |42| MEDIUM | Range | `range-` | Sequential interface expansion |43| MEDIUM | Organization | `organization-` | Naming, load order, multi-doc |44| LOW | Patterns | `patterns-` | Flat lists, devices, git repos |4546## Object File Basics4748```yaml49---50apiVersion: infrahub.app/v151kind: Object52spec:53 kind: <NodeKind> # Schema node kind (e.g., DcimDellServer)54 data:55 - <attribute>: <value> # List of object instances56```5758`apiVersion`, `kind: Object`, `spec.kind`, and `spec.data`59are always required. Each `spec` block targets a single60node kind.6162## Workflow6364Follow these steps when creating object data files:65661. **Read the schema** — Identify the target node kind,67 its attributes, relationships, and whether it has68 component children or hierarchy parents.692. **Plan the file structure** — Read70 [rules/format-structure.md](./rules/format-structure.md)71 for the required YAML structure and72 [rules/organization-load-order.md](./rules/organization-load-order.md)73 for file naming and load order conventions.743. **Map attribute values** — Set each attribute using75 the correct value format. Read76 [rules/value-attributes.md](./rules/value-attributes.md)77 for attribute mapping and78 [rules/value-relationships.md](./rules/value-relationships.md)79 for relationship references.804. **Handle children** — If the node has component81 children or hierarchy nesting, read82 [rules/children-components.md](./rules/children-components.md)83 and [rules/children-hierarchy.md](./rules/children-hierarchy.md).845. **Validate** — Check YAML syntax and ensure85 referenced objects exist or are defined in earlier86 load-order files.8788## Supporting References8990- **[reference.md](./reference.md)** -- Object file format91 specification92- **[examples.md](./examples.md)** -- 15 complete object93 patterns from production repos94- **[../infrahub-common/infrahub-yml-reference.md](../infrahub-common/infrahub-yml-reference.md)**95 -- .infrahub.yml project configuration96- **[../infrahub-common/rules/](../infrahub-common/rules/)** -- Shared rules97 (git integration, caching) across all skills98- **[../infrahub-managing-schemas/SKILL.md](../infrahub-managing-schemas/SKILL.md)**99 -- Schema definitions these objects conform to100- **[rules/](./rules/)** -- Individual rules by category101 prefix
opsmill