Use when producing, reading, or extracting COBie facility-management handover data from an IFC model: mapping COBie worksheets to IFC entities, deciding which records belong in COBie scope, choosing between the IFC STEP exchange and the spreadsheet form, or extracting a COBie subset from a full design model. Prevents treating COBie as a geometry format, inventing IFC entity names for COBie records, mapping a Component to a type instead of an occurrence, and exporting parametric geometry into an FM handover. Covers COBie as the Basic FM Handover MVD subset, the worksheet to IFC entity map, the IFC2x3 and IFC4 bindings, and the STEP versus spreadsheet exchange. Keywords: COBie, FM handover, facility management handover, Basic FM Handover MVD, asset management data, IfcSpace, IfcZone, IfcSystem, IfcTask, IfcDocumentReference, IfcConstructionResource, COBie spreadsheet, COBie worksheet, component versus type, asset register from IFC, handover data, how do I export COBie, what is COBie, COBie data missing, non-gra
Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.
Quelldateien prüfen
Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Ein direkter Befehl überspringt den Prüf-Prompt. Prüfen Sie die Quelle, bevor Sie ihn ausführen.
Use when producing, reading, or extracting COBie facility-management handover data from an IFC model: mapping COBie worksheets to IFC entities, deciding which records belong in COBie scope, choosing between the IFC STEP exchange and the spreadsheet form, or extracting a COBie subset from a full design model. Prevents treating COBie as a geometry format, inventing IFC entity names for COBie records, mapping a Component to a type instead of an occurrence, and exporting parametric geometry into an FM handover. Covers COBie as the Basic FM Handover MVD subset, the worksheet to IFC entity map, the IFC2x3 and IFC4 bindings, and the STEP versus spreadsheet exchange. Keywords: COBie, FM handover, facility management handover, Basic FM Handover MVD, asset management data, IfcSpace, IfcZone, IfcSystem, IfcTask, IfcDocumentReference, IfcConstructionResource, COBie spreadsheet, COBie worksheet, component versus type, asset register from IFC, handover data, how do I export COBie, what is COBie, COBie data missing, non-graphic data exchange, "COBie sheet is empty", "COBie components map to wrong type", "FM data not coming through", "asset register has no equipment", how do I get asset data out of an IFC model, what goes in a COBie handover.
license
MIT
compatibility
Designed for Claude Code. Requires IFC IFC2x3,IFC4,IFC4.3.
metadata
{"author":"OpenAEC-Foundation","version":"1.0"}
IFC and COBie
COBie (Construction-Operations Building Information Exchange) is the
facility-management handover dataset: the non-graphic data an owner needs
to populate a maintenance and asset-management system. In IFC terms COBie
is a MODEL VIEW DEFINITION SUBSET, realised as the Basic FM Handover View.
It captures spaces, zones, components, types, systems, spares, resources,
jobs, documents, and attributes. It is NOT a geometry format.
This skill covers the COBie worksheet to IFC entity map, the IFC2x3 and
IFC4 bindings, the STEP versus spreadsheet exchange forms, and extracting a
COBie subset from a full model.
Verified against the buildingSMART MVD database and the IFC 4.3.2
specification (ISO 16739-1:2024). The Basic FM Handover View is verified as
an IFC2x3 TC1 MVD with status Final. COBie applies to IFC2x3, IFC4, IFC4.3.
IfcRelConnectsElements and the IfcRelConnects family
all
Spare
IfcConstructionProductResource
all
Resource
IfcConstructionResource subtypes
all
Job
IfcTask
TaskTime, PredefinedType are IFC4 additions
Document
IfcDocumentInformation and IfcDocumentReference
all
Attribute
IfcPropertySet and IfcProperty
all
Coordinate
ObjectPlacement on the spatial or component entity
all
Full attribute signatures and the relationships that wire these together
are in references/methods.md.
COBie versions and IFC bindings
COBie release
IFC binding
MVD
COBie 2.26
IFC2x3 TC1
Basic FM Handover View (status Final)
COBie 2.4
IFC4
FM Handover, produced by the buildingSMART MVD support group
The buildingSMART MVD database enumerates the Basic FM Handover View on
IFC2x3 TC1. buildingSMART runs the COBie Certified Professional programme,
aligned with ISO 19650. ALWAYS bind a COBie export to the schema named in
FILE_SCHEMA; NEVER mix IFC2x3 and IFC4 entity sets in one file.
The two exchange forms
IFC STEP physical file or ifcXML: the full-fidelity exchange, used for
large projects and when the COBie data must round-trip with the model.
The COBie spreadsheet (one tab per worksheet): the lightweight exchange,
used for small projects and human review. National codes of practice
govern the spreadsheet layout (for example BS 1192-4 in the UK).
Both forms carry the SAME data. The spreadsheet is a projection of the IFC
entities, NOT a different dataset.
Decision Trees
Is this data in COBie scope?
What kind of data is it?
|
+- Managed physical asset (equipment, fixture, furniture) that the
| owner maintains
| -> in scope. Component (IfcElement) + Type (IfcElementType).
|
+- Space, floor, zone, or facility the asset sits in
| -> in scope. Spatial backbone.
|
+- Maintenance job, spare part, resource, document, contact
| -> in scope. Job / Spare / Resource / Document / Contact.
|
+- Detailed parametric geometry, structural analysis, fabrication
| detail, construction sequencing geometry
-> NOT in scope. COBie carries non-graphic FM data only.
A wall's exact swept-solid profile is NEVER COBie data. The wall as a
maintainable Component, with its Type and attributes, IS.
Which IFC entity for a COBie record?
Which COBie worksheet is the record on?
|
+- Component -> an IfcElement OCCURRENCE (the placed instance)
+- Type -> an IfcElementType (shared definition)
+- Space -> IfcSpace ; Floor -> IfcBuildingStorey
+- Zone -> IfcZone, members assigned by IfcRelAssignsToGroup
+- System -> IfcSystem, members assigned by IfcRelAssignsToGroup
+- Job -> IfcTask, operating on products via IfcRelAssignsToProcess
+- Document -> IfcDocumentInformation + IfcDocumentReference,
| associated by IfcRelAssociatesDocument
+- Attribute -> an IfcProperty inside an IfcPropertySet
+- Spare -> IfcConstructionProductResource
+- Resource -> an IfcConstructionResource subtype
NEVER map a Component to a type object. A Component is a placed occurrence;
its shared data lives on the linked Type. See the occurrence-versus-type
split below.
STEP or ifcXML or spreadsheet?
What is the consumer?
|
+- Another IFC-aware tool, or the data must round-trip with the
| model
| -> IFC STEP physical file (.ifc) or ifcXML (.ifcXML).
|
+- A human reviewer, a small project, or a CAFM import that
| expects tabular input
-> the COBie spreadsheet (one tab per worksheet).
ALWAYS keep the IFC file authoritative. The spreadsheet is generated FROM
the IFC entities; edits made only in the spreadsheet drift from the model.
Component or Type for shared data?
Does the data value vary per placed instance?
|
+- Yes (asset tag, serial number, install date, barcode,
| warranty start)
| -> the Component occurrence (IfcElement).
|
+- No (manufacturer, model number, nominal length, expected life,
replacement cost)
-> the Type (IfcElementType), shared by every Component of
that type.
This mirrors the COBie split: the Type worksheet holds the catalogue data,
the Component worksheet holds the per-instance data. See
ifc-impl-data-enrichment for the attachment mechanics.
Patterns
Every snippet uses STEP physical file syntax. $ marks an unset optional
attribute. Full verified signatures are in references/methods.md;
complete instances are in references/examples.md.
Pattern: the spatial backbone
COBie Facility, Floor, and Space are the IFC spatial structure: an
IfcBuilding decomposed into IfcBuildingStorey, decomposed into
IfcSpace, all wired by IfcRelAggregates.
IfcRelAssignsToGroup carries the members in RelatedObjects and the zone
in RelatingGroup. A zone member is ALWAYS an IfcSpace, IfcZone, or
IfcSpatialZone per the IfcZoneWHERE rule.
Pattern: Component and Type
A COBie Component is an IfcElement occurrence; its COBie Type is an
IfcElementType. The two are linked by IfcRelDefinesByType.
Catalogue data (manufacturer, model) goes on the Type; per-instance data
(the Tag asset id) goes on the Component. NEVER place an asset tag on the
shared Type.
Pattern: System grouping
A COBie System groups the components that work together (an HVAC system, a
lighting circuit). IfcSystem members are assigned by
IfcRelAssignsToGroup.
IfcDocumentReference carries either a Name OR a ReferencedDocument,
never both (the WR1 constraint). Here ReferencedDocument is set, so
Name is $; the human-readable title lives on the
IfcDocumentInformation. See ifc-syntax-classifications for the related
external-reference pattern.
Pattern: extracting a COBie subset
COBie export is a SUBSET extraction from a full model. ALWAYS:
Keep the spatial backbone (IfcProject, IfcSite, IfcBuilding,
IfcBuildingStorey, IfcSpace).
Keep the maintainable components and their types; drop elements with no
FM relevance.
Keep the FM property sets (Pset_*Common, Pset_ManufacturerTypeInformation
and similar); drop analysis and fabrication property sets.
Drop or simplify geometry: COBie needs placement and identity, not
parametric detail.
Keep IfcSystem, IfcZone, IfcTask, document and contact data.
The result conforms to the Basic FM Handover MVD. See ifc-impl-mvd-export
for the general MVD-subset mechanics and ifc-core-mvd for the MVD model.
Anti-Patterns
Full detail with the failure mechanism is in references/anti-patterns.md.
The ones that matter most:
Treating COBie as a geometry format and exporting parametric solids.
COBie carries non-graphic FM data only.
Inventing an IfcCobie* entity. COBie data ALWAYS lives in standard IFC
entities; there is no COBie-specific schema.
Mapping a Component to a type object. A Component is a placed occurrence;
the Type is the shared IfcElementType.
Putting per-instance data (asset tag, serial number) on the Type. The
Type holds catalogue data shared by every occurrence.
Mixing IFC2x3 and IFC4 entity forms in one COBie file. Bind to the single
schema in FILE_SCHEMA.
Editing the COBie spreadsheet in isolation. The IFC model stays
authoritative; spreadsheet-only edits drift from the model.
Reference Links
This skill
references/methods.md: every COBie-relevant IFC entity with attribute
signatures, the relationships that wire them, and version notes.
references/examples.md: verified STEP physical file instances per COBie
worksheet.
references/anti-patterns.md: COBie export failure modes and root causes.
Related skills
ifc-core-mvd: the Model View Definition model and the four MVDs.
ifc-impl-mvd-export: extracting any MVD subset from a full model.
ifc-impl-property-extraction: reading the property sets COBie carries.
ifc-impl-data-enrichment: attaching the FM property sets COBie needs.
ifc-impl-spatial-decomposition: the Facility, Floor, Space backbone.
