Automating BIM Coordination and Clash Detection with Claude Code

How to use Claude Code skills to automate clash detection workflows, coordination reports, model audits, and issue tracking across BIM disciplines

BIM coordination is the backbone of every multidisciplinary construction project, yet it remains one of the most time-consuming and error-prone phases in the delivery pipeline. A typical coordination cycle involves exporting models, running clash detection in Navisworks or Solibri, manually reviewing hundreds (sometimes thousands) of clashes, categorizing them by severity, assigning them to the right discipline, drafting RFIs, and tracking resolution across multiple teams. Most of this work follows predictable patterns, which makes it a prime candidate for automation with Claude Code.

This guide covers twelve practical Claude Code skills that BIM coordinators and managers can build and reuse across projects. Each skill targets a specific bottleneck in the coordination workflow, from parsing raw clash reports to generating cross-discipline coordination matrices. No prior programming experience is required beyond basic comfort with the command line.

The Coordination Bottleneck in BIM Projects

Every BIM coordinator knows the drill. The structural engineer updates their model on Tuesday, the MEP team pushes a revision on Wednesday, and by Thursday morning you are staring at a Navisworks report with 1,400 new clashes. Half of them are duplicates. A quarter are pseudo-clashes caused by tolerance settings that are too tight. The remaining clashes need to be sorted by priority, assigned to the correct team, and tracked until resolution.

The manual version of this workflow typically looks like this:

Export federated models from each discipline into NWC or IFC format
Run clash detection in Navisworks Manage or Solibri Model Checker
Export clash reports as XML, HTML, or CSV
Review each clash to determine severity and responsible party
Create coordination issues in a tracker (BIM 360, Trimble Connect, or a spreadsheet)
Draft RFIs for clashes that need design clarification
Follow up with each discipline until all issues are resolved
Re-run the cycle until the model is coordination-complete

Steps 3 through 7 are where most of the manual labor lives. A coordinator might spend 4 to 6 hours per cycle just categorizing clashes and writing issue descriptions. On a large healthcare or infrastructure project with weekly coordination cycles, that adds up to hundreds of hours per year spent on work that follows rigid, repeatable logic.

Claude Code skills can automate the repeatable parts of this workflow while leaving the judgment calls (is this clash acceptable, does this need an RFI, should we escalate to the client) to the coordinator.

How Claude Code Skills Fit Into the BIM Coordination Workflow

A Claude Code “skill” is a reusable prompt definition stored in your project’s .claude/ directory. When you invoke a skill, Claude Code reads the relevant files in your project folder, follows the instructions defined in the skill, and produces the output you need. Skills can read XML and HTML files, parse CSV data, generate markdown reports, and even create structured JSON for integration with other tools.

For BIM coordination, the typical setup looks like this:

project-root/
├── .claude/
│   └── skills/
│       ├── clash-report-parser/
│       │   └── SKILL.md
│       ├── coordination-tracker/
│       │   └── SKILL.md
│       ├── model-audit/
│       │   └── SKILL.md
│       └── rfi-drafter/
│           └── SKILL.md
├── coordination/
│   ├── clash-reports/         # Raw exports from Navisworks/Solibri
│   ├── processed/             # Parsed and prioritized reports
│   ├── issues/                # Generated issue tracking files
│   └── rfis/                  # Draft RFI documents
└── models/
    ├── architecture.nwc
    ├── structural.nwc
    └── mep.nwc

Each skill targets one step in the coordination pipeline. You run them in sequence or individually depending on where you are in the cycle. The key advantage is consistency: every clash report gets parsed the same way, every issue description follows the same format, and every audit checklist covers the same criteria, regardless of which coordinator is running the process.

Skill: Automated Clash Report Parsing and Prioritization

Navisworks exports clash reports in XML format that contains detailed information about each clash, including the elements involved, their coordinates, the test name, and the clash status. The problem is that raw XML is not something you can hand to a project manager or discipline lead. You need a structured, prioritized summary.

Here is what a typical Navisworks clash report XML structure looks like:

<exchange>
  <batchtest name="MEP vs Structure" internal_id="1">
    <clashtests>
      <clashtest name="Ducts vs Beams" test_type="hard">
        <clashresults>
          <clashresult name="Clash1" status="new" distance="-0.150">
            <clashpoint x="45.230" y="12.450" z="3.200"/>
            <clashobject>
              <layer>Ductwork</layer>
              <itemname>Rectangular Duct 600x400</itemname>
            </clashobject>
            <clashobject>
              <layer>Structural Framing</layer>
              <itemname>W310x45 Steel Beam</itemname>
            </clashobject>
          </clashresult>
        </clashresults>
      </clashtest>
    </clashtests>
  </batchtest>
</exchange>

A Claude Code skill for parsing this report would include instructions to:

Read all XML files in the coordination/clash-reports/ directory
Extract the test name, clash name, status, penetration distance, coordinates, and involved elements
Categorize clashes by severity based on penetration depth (e.g., over 150mm = critical, 50-150mm = major, under 50mm = minor)
Group clashes by discipline pair (MEP vs Structure, Architecture vs MEP, etc.)
Remove duplicate clashes where the same two elements appear in multiple tests
Output a markdown summary table sorted by severity

The resulting output looks like this:

# Clash Report Summary - 2026-04-04

**Source:** MEP vs Structure batch test
**Total clashes:** 347
**After deduplication:** 198
**Critical (>150mm):** 23
**Major (50-150mm):** 67
**Minor (<50mm):** 108

## Critical Clashes

| # | Test | Elements | Penetration | Location (X,Y,Z) | Discipline |
|---|------|----------|-------------|-------------------|------------|
| 1 | Ducts vs Beams | Rect Duct 600x400 / W310x45 | -312mm | 45.2, 12.5, 3.2 | MEP → Structural |
| 2 | Pipes vs Columns | CW Pipe DN150 / Concrete Col 600x600 | -205mm | 23.1, 8.7, 6.1 | MEP → Structural |
| 3 | Cable Trays vs Beams | Tray 300W / W250x33 | -178mm | 67.4, 22.1, 3.0 | Electrical → Structural |

This skill alone can save 2 to 3 hours per coordination cycle on a mid-size project. The coordinator still reviews the critical clashes, but the sorting, deduplication, and formatting happen automatically.

Skill: Coordination Issue Tracker Generation

Once clashes are parsed and prioritized, the next step is converting them into actionable issues that can be assigned and tracked. This skill takes the processed clash data and generates structured issue entries.

The skill reads the parsed clash summary and generates an issue for each critical and major clash. Each issue includes:

A unique issue ID following the project’s numbering convention (e.g., COORD-2026-0147)
The clash source (test name and clash ID)
A plain-language description of the conflict
The responsible discipline based on the elements involved
A suggested resolution approach based on common patterns (e.g., “Lower duct routing by 200mm to clear beam flange” or “Relocate pipe run to avoid column zone”)
Priority level mapped from clash severity
A deadline based on the project’s coordination schedule

The output format can be adapted to whatever tracker your team uses. For teams using spreadsheets, the skill generates CSV. For BIM 360 or Trimble Connect, it can produce JSON in the platform’s import format. For simpler setups, a markdown table works well:

## Open Coordination Issues - 2026-04-04

| Issue ID | Description | Discipline | Priority | Due Date | Status |
|----------|-------------|------------|----------|----------|--------|
| COORD-2026-0147 | 600x400 duct intersects W310x45 beam at Level 3, Grid D-7. Penetration 312mm. | MEP Lead | Critical | 2026-04-11 | Open |
| COORD-2026-0148 | DN150 CW pipe passes through 600x600 concrete column at Level 6, Grid B-3. | MEP Lead | Critical | 2026-04-11 | Open |
| COORD-2026-0149 | 300W cable tray conflicts with W250x33 beam at Level 3, Grid F-12. | Electrical Lead | Critical | 2026-04-11 | Open |

The skill also maintains a running log of all issues across coordination cycles, so you can track resolution rates and identify disciplines or zones that consistently produce clashes.

Skill: Model Audit Checklist Automation

Before models even enter the clash detection pipeline, they should pass a quality gate. Poorly organized models generate noise in clash reports: elements on the wrong workset, incorrect naming conventions, elements modeled at the wrong LOD, or geometry that extends beyond the project boundary. A model audit skill catches these problems early.

The audit checklist skill reads an exported model summary (NWC metadata, IFC property sets, or a Revit schedule export) and checks against a configurable set of rules. Here is an example audit configuration:

# .claude/skills/model-audit/rules.yaml
naming_conventions:
  views:
    pattern: "^[A-Z]{2}-[A-Z]{3}-[0-9]{2}-.*$"
    example: "AR-PLN-01-Level 1 Floor Plan"
    description: "Discipline-Type-Number-Description"
  sheets:
    pattern: "^[A-Z][0-9]{3}$"
    example: "A101"
  families:
    prohibited_prefixes: ["Copy", "Family1", "Generic"]

workset_rules:
  required_worksets:
    - "AR_Walls"
    - "AR_Floors"
    - "AR_Ceilings"
    - "AR_Furniture"
    - "ST_Framing"
    - "ST_Foundations"
    - "ME_Ductwork"
    - "ME_Piping"
    - "EL_Lighting"
    - "EL_Power"
  elements_on_wrong_workset:
    check: true
    severity: warning

level_checks:
  required_levels:
    - name: "Level 0"
      elevation_range: [-0.5, 0.5]
    - name: "Level 1"
      elevation_range: [2.5, 4.5]
  orphan_elements:
    check: true
    description: "Elements not associated with any level"

geometry_checks:
  bounding_box:
    max_extent: 500  # meters from origin
    severity: error
  zero_volume_elements:
    check: true
    severity: warning

The skill produces an audit report for each model file:

# Model Audit Report - Architecture Model
**Date:** 2026-04-04
**File:** AR-Building-A.nwc

## Summary
- **Pass:** 12 checks
- **Warning:** 4 checks
- **Fail:** 2 checks

## Failed Checks

### Naming Convention - Views (FAIL)
- 7 views do not match pattern `[A-Z]{2}-[A-Z]{3}-[0-9]{2}-*`
- Examples: "Floor Plan Level 1", "Section AA", "3D View 1"
- **Action:** Rename views to follow project naming standard

### Geometry - Elements Beyond Bounding Box (FAIL)
- 3 elements located >500m from project origin
- Element IDs: 1045723, 1045724, 1045901
- **Action:** Move or delete stray geometry before next coordination export

## Warnings

### Workset Assignment (WARNING)
- 14 wall elements on "Workset1" instead of "AR_Walls"
- 6 furniture elements on "AR_Walls" instead of "AR_Furniture"

Running this audit before every coordination meeting ensures that the clash reports focus on real design conflicts instead of model hygiene issues.

Skill: Cross-Discipline Coordination Matrix Generator

A coordination matrix maps which disciplines need to coordinate with each other and defines the specific interfaces between them. Most BIM execution plans include a static coordination matrix that was written at the start of the project and never updated. A Claude Code skill can generate and maintain a living coordination matrix based on actual clash data.

The skill reads historical clash summaries and builds a matrix showing:

Which discipline pairs produce the most clashes
The typical clash zones (by level, grid, or building zone)
The average resolution time for each discipline pair
Trending data showing whether coordination is improving or degrading over time

The output format:

# Cross-Discipline Coordination Matrix
**Project:** Building A - Phase 2
**Period:** 2026-03-01 to 2026-04-04
**Cycles analyzed:** 5

## Clash Frequency Matrix

|                | Architecture | Structural | Mechanical | Electrical | Plumbing |
|----------------|:----------:|:----------:|:----------:|:----------:|:--------:|
| Architecture   |     -      |     12     |     34     |     18     |    8     |
| Structural     |     12     |      -     |     87     |     23     |    15    |
| Mechanical     |     34     |     87     |      -     |     45     |    31    |
| Electrical     |     18     |     23     |     45     |      -     |    9     |
| Plumbing       |      8     |     15     |     31     |      9     |    -     |

## Hot Zones (Top 5 by clash density)

| Zone | Level | Grid Range | Primary Conflict | Clashes |
|------|-------|------------|-------------------|---------|
| Mechanical Room | B1 | D3-E5 | MEP routing density | 134 |
| Main Corridor L3 | 3 | A1-A12 | Duct/beam clearance | 89 |
| Riser Shaft | All | C7 | Pipe/cable stacking | 67 |
| Lobby Ceiling | 1 | B2-C4 | Sprinkler/lighting | 45 |
| Plant Room | Roof | F1-F4 | Equipment clearance | 38 |

## Trend (last 5 cycles)

| Cycle Date | Total Clashes | Critical | Resolved | Resolution Rate |
|------------|:------------:|:--------:|:--------:|:--------------:|
| 2026-03-07 | 412 | 45 | - | - |
| 2026-03-14 | 387 | 38 | 289 | 70% |
| 2026-03-21 | 298 | 22 | 341 | 88% |
| 2026-03-28 | 245 | 15 | 276 | 92% |
| 2026-04-04 | 198 | 12 | 231 | 94% |

This matrix becomes a powerful communication tool in coordination meetings. Instead of reviewing every clash, the team can focus on the hot zones and the discipline pairs with the highest conflict rates.

Skill: RFI Drafting from Clash Detection Results

Some clashes cannot be resolved by the coordination team alone. When a duct cannot be rerouted without affecting the design intent, or when a structural beam conflicts with an architectural feature, the issue needs to go back to the designer as a formal Request for Information (RFI). Writing RFIs is tedious because each one requires a clear description of the problem, relevant model references, and a specific question for the designer.

A Claude Code skill for RFI drafting reads the critical clashes that have been flagged as “needs design input” and generates draft RFIs:

# RFI-2026-0034

**Project:** Building A - Phase 2
**Date:** 2026-04-04
**From:** BIM Coordination Team
**To:** Structural Engineer (Smith & Associates)
**Subject:** Beam-Duct Conflict at Level 3, Grid D-7

## Description

During the coordination review on 2026-04-04, a hard clash was identified between a 600mm x 400mm rectangular supply duct (MEP model) and a W310x45 steel beam (structural model) at Level 3, Grid intersection D-7.

The duct runs east-west at an elevation of 3,200mm AFL. The bottom flange of the beam sits at 3,050mm AFL, creating a 312mm penetration. The duct serves the main supply run for the east wing and cannot be lowered without reducing the clear ceiling height below the 2,700mm minimum specified in the architectural design.

## Question

Can the beam at Grid D-7 be raised by 400mm, or can a web opening be provided to allow the duct to pass through? If neither option is feasible, please advise on an alternative structural solution that maintains the required ceiling clearance.

## Attachments

- Clash screenshot: `coordination/screenshots/CLASH-2026-0147.png`
- Navisworks viewpoint: `coordination/viewpoints/VP-D7-L3.nwd`
- Relevant drawings: S-301 (Structural Framing Level 3), M-301 (Mechanical Layout Level 3)

The coordinator reviews each draft, adjusts the wording if needed, and sends it through the project’s formal RFI process. Even if every RFI needs light editing, starting from a structured draft rather than a blank page saves significant time.

Skill: LOD Verification and Compliance Checking

Level of Development (LOD) requirements vary by project phase and discipline. A model element at LOD 300 should include accurate size, shape, location, and orientation, while LOD 200 only requires approximate geometry. When models arrive for coordination, verifying that elements meet the required LOD for the current phase prevents wasted effort on clashes involving placeholder geometry.

The LOD verification skill reads the project’s BIM execution plan (or a separate LOD matrix) and compares it against the properties available in the exported model data. For IFC exports, this means checking property sets. For Revit exports, it means checking parameter completeness.

The skill checks:

Geometric completeness: Are elements modeled with actual dimensions, or are they generic placeholders?
Parameter population: Do elements have the required parameters filled in for the current phase? For example, at LOD 350, mechanical equipment should have weight, connection sizes, and clearance zones defined.
Assembly detail: Are compound elements (curtain walls, composite floors) modeled with their actual sub-components, or are they simplified single-layer representations?
Manufacturer data: For LOD 400, are manufacturer-specific models used instead of generic families?

# LOD Compliance Report - MEP Model
**Required LOD:** 350 (Design Development)
**Date:** 2026-04-04

## Compliance Summary

| Category | Total Elements | Compliant | Non-Compliant | Rate |
|----------|:-------------:|:---------:|:-------------:|:----:|
| Ductwork | 342 | 338 | 4 | 99% |
| Piping | 567 | 512 | 55 | 90% |
| Equipment | 45 | 31 | 14 | 69% |
| Electrical | 234 | 201 | 33 | 86% |

## Non-Compliant Elements (Equipment)

| Element | Current LOD | Issue | Required Action |
|---------|:-----------:|-------|-----------------|
| AHU-01 | 200 | Generic placeholder, no connection points | Replace with manufacturer model |
| Chiller-02 | 200 | Missing weight and clearance parameters | Update parameters from spec |
| Pump Set P-04 | 300 | Connections modeled but no maintenance clearance | Add clearance zones per manufacturer data |

This report gives discipline leads a clear list of elements that need attention before the next coordination round.

Skill: BIM Execution Plan Template Generator

Every project needs a BIM Execution Plan (BEP), and writing one from scratch is both tedious and error-prone. A Claude Code skill can generate a project-specific BEP template based on inputs like project type, size, disciplines involved, and the client’s BIM requirements.

The skill prompts for key project parameters and generates a structured document covering:

Project information: Name, location, phases, key dates
Team directory: Discipline leads, BIM managers, contact information
Software and versions: Revit version, Navisworks version, IFC export settings
Model management: File naming conventions, folder structure, exchange formats, coordination schedule
LOD matrix: Required LOD per discipline per project phase
Coordination procedures: Clash detection frequency, review meeting cadence, issue resolution workflow
Deliverables: Model milestones, submission requirements, as-built standards

The generated template follows ISO 19650 structure or the project’s specific requirements (US National BIM Standard, UK BIM Framework, Singapore BIM Guide, etc.). The coordinator fills in the project-specific details, but the structure, boilerplate text, and standard tables are pre-populated.

This is particularly valuable for firms that run multiple projects simultaneously. Instead of copying and adapting a BEP from a previous project (and inevitably leaving outdated references), the skill generates a clean template every time.

Working with IFC Files and Open BIM Workflows

Not every project uses Navisworks. Open BIM workflows rely on IFC (Industry Foundation Classes) as the exchange format, with tools like Solibri, BIMcollab, or open-source viewers like BIM Vision and IfcOpenShell for coordination. Claude Code can work with IFC data in several ways.

IFC-SPF text parsing: IFC files in STEP Physical File format are plain text. While they are verbose and not designed for human reading, Claude Code can parse them to extract entity relationships, property sets, and spatial containment hierarchies. For example, extracting all IfcDuctSegment entities with their associated IfcPropertySet values to check parameter completeness.

IFC-JSON and IFC-CSV: Tools like IfcOpenShell can convert IFC files to JSON or CSV, which are much easier for Claude Code to process. A preprocessing step using IfcOpenShell’s Python API can extract the data you need:

import ifcopenshell
import json

model = ifcopenshell.open("architecture.ifc")
elements = []

for element in model.by_type("IfcWall"):
    props = {}
    for definition in element.IsDefinedBy:
        if definition.is_a("IfcRelDefinesByProperties"):
            pset = definition.RelatingPropertyDefinition
            if pset.is_a("IfcPropertySet"):
                for prop in pset.HasProperties:
                    if prop.is_a("IfcPropertySingleValue"):
                        props[prop.Name] = str(prop.NominalValue)
    elements.append({
        "id": element.GlobalId,
        "name": element.Name,
        "type": element.ObjectType,
        "properties": props
    })

with open("walls_export.json", "w") as f:
    json.dump(elements, f, indent=2)

Once the IFC data is in JSON or CSV format, all of the skills described above (clash parsing, model auditing, LOD checking) work the same way. The coordination workflow is tool-agnostic; only the data extraction step changes.

BCF (BIM Collaboration Format): For teams using BCF-based coordination (BIMcollab, Solibri, Tekla BIMsight), Claude Code can read and generate BCF XML files. BCF topics map directly to coordination issues, so the issue tracker skill can output BCF-compatible files that import directly into the team’s BCF manager.

Integrating Claude Code with Project Management Tools

Coordination data is only useful if it reaches the right people. Most project teams track issues in platforms like Autodesk Construction Cloud, Trimble Connect, Procore, or even Jira and Monday.com. Claude Code skills can generate output in formats that these platforms accept.

CSV/Excel import: Most platforms support bulk issue import via CSV. The coordination issue tracker skill can output CSV with columns mapped to the platform’s import template. For Autodesk Construction Cloud, that means columns for Title, Description, Assigned To, Due Date, Priority, Location, and Status.

JSON/API payloads: For teams with API access to their project management platform, Claude Code can generate JSON payloads that match the platform’s API schema. A wrapper script can then POST these payloads to create issues automatically. This works well with Procore’s REST API, Trimble Connect’s API, or Jira’s issue creation endpoint.

Webhook triggers: For fully automated pipelines, you can set up a workflow where dropping a new clash report into the coordination/clash-reports/ folder triggers Claude Code to parse it, generate issues, and push them to the project management platform via API. Tools like n8n or Make (formerly Integromat) can orchestrate this trigger.

The level of integration depends on your team’s technical comfort. Starting with CSV exports that you manually import is perfectly fine. You can automate further as the workflow matures.

Setting Up a Team-Wide BIM Coordination Skill Library

Individual skills are useful, but the real value comes when your entire BIM coordination team shares a standardized skill library. Here is how to set that up.

Step 1: Create a shared repository. Set up a Git repository (GitHub, GitLab, or Azure DevOps) that contains your skill definitions:

bim-coordination-skills/
├── .claude/
│   └── skills/
│       ├── clash-parser/
│       │   └── SKILL.md
│       ├── issue-tracker/
│       │   └── SKILL.md
│       ├── model-audit/
│       │   ├── SKILL.md
│       │   └── rules.yaml
│       ├── coordination-matrix/
│       │   └── SKILL.md
│       ├── rfi-drafter/
│       │   └── SKILL.md
│       ├── lod-checker/
│       │   └── SKILL.md
│       └── bep-generator/
│           └── SKILL.md
├── templates/
│   ├── rfi-template.md
│   ├── issue-template.md
│   └── audit-report-template.md
└── config/
    ├── naming-conventions.yaml
    ├── lod-matrix.yaml
    └── discipline-mapping.yaml

Step 2: Configure project-specific overrides. Each project can override the default configuration files (naming conventions, LOD requirements, discipline mappings) without modifying the shared skills. Keep overrides in the project’s own coordination/config/ folder, and reference them in the skill definitions using relative paths.

Step 3: Version your skills. Use Git tags to version your skill library. When a skill is updated (e.g., adding support for a new clash report format), tag the release so that projects using older versions are not affected until they explicitly update.

Step 4: Document skill usage. Each skill’s SKILL.md file should include:

A one-line description of what the skill does
Required input files and formats
Output format and location
Configuration options
Example invocation command

Step 5: Onboard new team members. When a new coordinator joins the team, they clone the skill library, copy the configuration files for their project, and start using the skills immediately. The learning curve is minimal because the skills handle the complexity internally.

Step 6: Collect feedback and iterate. After each coordination cycle, ask coordinators what worked and what did not. Common requests include support for additional clash report formats, new audit rules, or different output formats. Because skills are just text files (markdown with instructions), anyone on the team can propose changes through a pull request.

Putting It All Together

The skills described in this guide are not theoretical. They address real pain points that BIM coordinators deal with on every project. Here is a realistic weekly coordination workflow using these skills:

Monday: Discipline leads export updated models. Run the model audit skill on each export to catch quality issues before clash detection.
Tuesday: Run clash detection in Navisworks or Solibri. Export reports to the coordination/clash-reports/ folder. Run the clash report parser to generate prioritized summaries.
Wednesday morning: Run the issue tracker skill to convert critical and major clashes into assigned issues. Run the RFI drafter for clashes needing design input. Run the coordination matrix skill to update trending data.
Wednesday afternoon: Coordination meeting. Review the prioritized clash summary, discuss hot zones from the coordination matrix, and assign action items. The meeting runs faster because everyone is looking at pre-sorted, pre-categorized data.
Thursday/Friday: Discipline teams resolve assigned issues. Updated models feed into the next week’s cycle.

Over time, the coordination matrix shows whether clashes are trending down (the team is getting better at proactive coordination) or staying flat (there may be a systemic issue in the workflow). The LOD checker and model audit skills prevent low-quality models from polluting the clash reports. The RFI drafter ensures that design-level conflicts get formal attention instead of languishing in a spreadsheet.

The goal is not to remove the coordinator from the process. The goal is to remove the repetitive data processing that keeps the coordinator from doing what they are actually good at: understanding spatial relationships, negotiating design trade-offs, and keeping the project moving toward a coordinated model.

Start with the skill that addresses your biggest bottleneck. For most teams, that is the clash report parser. Once you see how much time it saves, the rest of the skill library builds itself.