Use when authoring a complete, coordinated IFC model from scratch and you need the correct build order, or when an IFC file you produced is rejected, opens empty in a viewer, or loses its elements, properties or geometry downstream. Prevents adding elements before the project skeleton exists, skipping units or representation contexts, wiring the spatial tree with the wrong relationship, attaching geometry with no context, and declaring a model done without validating it. Covers the end-to-end authoring sequence (version and MVD decision, STEP header, IfcProject, units, representation contexts, owner history, spatial tree, elements, geometry, placement, properties, materials, classifications), which syntax and impl skill owns each step, the IFC2x3 versus IFC4 versus IFC4.3 differences that change the build, and the self-check before delivery. Keywords: IFC model authoring, build a complete IFC file, IfcProject setup, IfcUnitAssignment, IfcGeometricRepresentationContext, spatial structure, IfcRelAggregates, Ifc
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
Use when authoring a complete, coordinated IFC model from scratch and you need the correct build order, or when an IFC file you produced is rejected, opens empty in a viewer, or loses its elements, properties or geometry downstream. Prevents adding elements before the project skeleton exists, skipping units or representation contexts, wiring the spatial tree with the wrong relationship, attaching geometry with no context, and declaring a model done without validating it. Covers the end-to-end authoring sequence (version and MVD decision, STEP header, IfcProject, units, representation contexts, owner history, spatial tree, elements, geometry, placement, properties, materials, classifications), which syntax and impl skill owns each step, the IFC2x3 versus IFC4 versus IFC4.3 differences that change the build, and the self-check before delivery. Keywords: IFC model authoring, build a complete IFC file, IfcProject setup, IfcUnitAssignment, IfcGeometricRepresentationContext, spatial structure, IfcRelAggregates, IfcRelContainedInSpatialStructure, model build order, orchestration workflow, "IFC file opens empty", "viewer shows nothing", "elements missing after export", "model rejected by validator", how do I create an IFC file, what order to build an IFC model, IFC authoring checklist.
license
MIT
compatibility
Designed for Claude Code. Requires IFC IFC2x3,IFC4,IFC4.3.
metadata
{"author":"OpenAEC-Foundation","version":"1.0"}
IFC Model Author
This is an orchestration skill. It defines the order in which an IFC model is
built and names the syntax, impl and errors skill that owns each step. It does
not re-teach those skills: it sequences them.
ALWAYS author an IFC model in dependency order: a step depends on every step
above it. NEVER add an element before the project skeleton (project, units,
contexts, spatial tree) exists, because an element with no spatial parent and
no representation context is invisible to every downstream consumer.
Steps 0 to 6 are the mandatory skeleton: nothing in steps 7 to 11 is valid
without them. Steps 8 to 11 repeat per element.
Version differences that change the build
Concern
IFC2x3
IFC4
IFC4.3
FILE_SCHEMA token
IFC2X3
IFC4
IFC4X3_ADD2
IfcRoot.OwnerHistory
mandatory
optional
optional
Element supertype
IfcBuildingElement
IfcBuildingElement
IfcBuiltElement
Tessellated geometry
not available
available
available
Top spatial container
IfcBuilding
IfcBuilding
IfcFacility / IfcBuilding
ALWAYS instantiate concrete subtypes (IfcWall, IfcSlab). NEVER instantiate
the abstract supertype. See ifc-errors-version-mismatch for the rename detail.
Decision Trees
Step 0 : version and MVD before any entity
What does the model contain ?
+-- infrastructure (road, rail, bridge, alignment, earthworks)
| -> IFC4.3 (token IFC4X3_ADD2). No earlier schema has these entities.
+-- a building, and the receiver is modern openBIM software
| -> IFC4 (token IFC4). The safe default for building models.
+-- a building, and the receiver is an IFC2x3-only tool
-> IFC2x3 (token IFC2X3). Accept the limits: no tessellation.
Which MVD does the deliverable target ?
+-- coordination / clash / viewing -> Reference View (IFC4)
+-- full round-trip / re-editing -> Design Transfer View (IFC4)
+-- IFC2x3 deliverable -> Coordination View 2.0
-> record the chosen MVD in FILE_DESCRIPTION as the ViewDefinition string.
-> see ifc-core-mvd and ifc-impl-mvd-export for MVD-conformant export.
The version and MVD are fixed BEFORE step 1. NEVER revisit them mid-build:
changing schema after elements exist forces a full migration.
Build-order dependency check
About to author entity X. Is every prerequisite present ?
IfcUnitAssignment requires IfcProject
IfcGeometricRepresentationContext requires IfcProject
IfcSite requires IfcProject + IfcRelAggregates
IfcBuildingStorey requires IfcBuilding (or IfcFacility in IFC4.3)
any IfcElement requires a spatial container to contain it
IfcShapeRepresentation requires an IfcGeometricRepresentationContext
IfcLocalPlacement requires the parent placement (or none for the site)
IfcRelDefinesByProperties requires the element it defines
IfcRelAssociatesMaterial requires the element it associates
prerequisite missing -> author the prerequisite first. NEVER forward-reference
a skeleton entity that does not exist yet.
Self-check before declaring the model done
Run ifc-agents-file-validator. Confirm every answer is YES :
[ ] FILE_SCHEMA token matches every entity used (ifc-errors-version-mismatch)
[ ] exactly one IfcProject, and it has a Name (WHERE rule HasName)
[ ] IfcUnitAssignment present, one unit per unit type (ifc-syntax-units)
[ ] at least one IfcGeometricRepresentationContext (ifc-syntax-geometry-representations)
[ ] spatial tree complete, wired with IfcRelAggregates (ifc-errors-spatial-structure)
[ ] every element contained exactly once (ifc-errors-spatial-structure)
[ ] every GlobalId present and unique (ifc-errors-schema-validation)
[ ] every #id reference resolves (ifc-errors-broken-references)
[ ] geometry sits in a declared context (ifc-errors-geometry-issues)
[ ] no abstract entity instantiated (ifc-errors-schema-validation)
any NO -> fix before delivery. NEVER declare a model done on an unrun check.
Patterns
Pattern 1 : fix version and MVD before authoring anything
The schema version and the MVD target are project-level decisions. They
determine the FILE_SCHEMA token, which entities are legal, whether
tessellation is available, and what the ViewDefinition string says.
ALWAYS complete step 0 before step 1. NEVER start writing entities and decide
the version later: every entity name and attribute layout depends on the
schema. Changing schema after elements exist is a migration, not an edit (see
ifc-impl-version-migration).
Pattern 2 : the mandatory skeleton precedes every element
An IFC file is not "configured" like software; its skeleton is the minimum
structure every valid model needs before any element can exist:
Exactly one IfcProject. IfcProject has no explicit attributes of its
own; it inherits from IfcRoot and IfcContext. The HasName WHERE rule
makes Name mandatory.
One IfcUnitAssignment, referenced by IfcProject.UnitsInContext, declaring
exactly one unit per unit type (length, area, volume, plane angle). A model
with no units is ambiguous by 1000x (see ifc-errors-property-set-mistakes).
At least one IfcGeometricRepresentationContext with ContextType set to
'Model' and CoordinateSpaceDimension of 3, referenced by
IfcProject.RepresentationContexts. Sub-contexts (Body, Axis,
FootPrint) are IfcGeometricRepresentationSubContext instances.
An IfcOwnerHistory: mandatory in IFC2x3, optional in IFC4 and IFC4.3 but
expected by many importers.
ALWAYS author the skeleton top-down: project, then units and contexts, then the
spatial tree. NEVER attach an element to a half-built skeleton.
Pattern 3 : two relationships, two jobs
The spatial tree and element containment use different relationships. Confusing
them is the most common authoring fault.
IfcRelAggregates builds the spatial hierarchy itself:
IfcProject aggregates IfcSite, IfcSite aggregates IfcBuilding or
IfcFacility, that aggregates IfcBuildingStorey or IfcFacilityPart, that
aggregates IfcSpace. Attributes: RelatingObject (the whole),
RelatedObjects (the parts).
IfcRelContainedInSpatialStructure places a physical element into one spatial
level. Attributes: RelatingStructure (one IfcSpatialElement),
RelatedElements (a set of IfcProduct). WHERE rule WR31: a spatial element
is never a RelatedElement here; spatial nesting uses IfcRelAggregates.
ALWAYS contain every physical element exactly once with
IfcRelContainedInSpatialStructure. NEVER use IfcRelAggregates to put a wall
on a storey, and NEVER use IfcRelContainedInSpatialStructure to nest storeys.
In IFC4.3 the spatial tree can use IfcFacility and IfcFacilityPart;
IfcBuilding and IfcBuildingStorey are re-parented under them.
Pattern 4 : geometry and placement attach per element
Each element repeats the same four-part attachment:
IfcProduct.Representation points to one IfcProductDefinitionShape.
The shape holds one or more IfcShapeRepresentation. Each has a
RepresentationIdentifier (Body, Axis, FootPrint) and a
RepresentationType (SweptSolid, Brep, Tessellation, and others).
IfcShapeRepresentation.ContextOfItems MUST point to an
IfcGeometricRepresentationContext (or a sub-context). The WHERE rule
requires the context to be a geometric representation context.
IfcProduct.ObjectPlacement points to an IfcLocalPlacement, chained to the
parent placement through PlacementRelTo. The site placement has no parent.
ALWAYS put geometry items in a declared context and chain the placement to the
spatial parent. NEVER emit geometry with no context: a viewer cannot scale or
position it (see ifc-errors-geometry-issues).
Pattern 5 : semantic enrichment is the last layer
Properties, quantities, materials and classifications attach to elements that
already exist, are placed and have geometry:
IfcPropertySet linked by IfcRelDefinesByProperties.
IfcElementQuantity linked by IfcRelDefinesByProperties.
IfcMaterial and the layer, profile and constituent set families linked by
IfcRelAssociatesMaterial.
IfcClassificationReference linked by IfcRelAssociatesClassification.
ALWAYS enrich after the element, its placement and its geometry exist. See
ifc-impl-data-enrichment for the enrichment workflow and
ifc-errors-property-set-mistakes for the reserved Pset_ prefix and
type-versus-occurrence traps.
Pattern 6 : self-validate before delivery
A model is done only when it passes validation, not when the last element is
written. Run ifc-agents-file-validator and the self-check decision tree above.
ALWAYS validate before declaring the model done. NEVER deliver a model on the
assumption that "it opened in one viewer": a viewer is lenient, the
buildingSMART validation pipeline is not (see ifc-core-validation).
Reference Links
references/methods.md : the full step-by-step authoring procedure, the
owning-skill map, and the version-specific build differences.
references/examples.md : a minimal valid IFC4 file built in sequence, and
the per-element repeat block.
references/anti-patterns.md : every authoring-orchestration failure mode.
Cross-references:
ifc-impl-authoring-file : the hands-on file-authoring workflow.
ifc-impl-spatial-decomposition : building the spatial tree correctly.
