ArchiCAD Workflow Automation with Claude Code Skills

A practical guide to using Claude Code skills for ArchiCAD GDL scripting, template automation, property management, and documentation workflows

ArchiCAD power users know the frustration. You spend hours writing GDL scripts to get a parametric object just right. You manually configure publisher sets every time a new project starts. You copy property definitions between templates by hand, hoping nothing gets lost along the way. These tasks are essential, but they pull you away from design work.

Claude Code skills offer a practical solution. By creating reusable skill files that understand ArchiCAD’s scripting languages, APIs, and conventions, you can automate the repetitive parts of your workflow while keeping full control over the output. This guide walks through specific skills you can build and use today, with real code examples for GDL scripting, JSON API automation, template management, and more.

Why ArchiCAD Users Need Workflow Automation

ArchiCAD projects involve a significant amount of configuration work that has nothing to do with design. Setting up a new project template means defining properties, classifications, publisher sets, graphic overrides, and favorites. Each of these tasks follows predictable patterns, yet most firms do them manually for every project.

Consider the typical time sinks in an ArchiCAD workflow:

GDL object creation: Writing parametric objects from scratch requires knowledge of GDL syntax, 2D/3D scripting, parameter definitions, and UI scripting. A simple parametric door can take a full day to script correctly.
Template configuration: A well-configured project template includes hundreds of settings across properties, classifications, publisher sets, and view definitions. Firms often maintain these by hand.
IFC mapping: Correct IFC export requires mapping ArchiCAD properties to IFC property sets, configuring translators, and testing the output. This process repeats for every exchange requirement.
Documentation standards: Schedule templates, title block data, and listing definitions follow firm standards that rarely change but still require manual setup.

Automation does not mean replacing your judgment. It means eliminating the mechanical steps so you can focus on decisions that actually require architectural expertise. Claude Code skills are particularly well suited to this because they can generate syntactically correct GDL, produce valid JSON API commands, and maintain context about your project standards across sessions.

ArchiCAD’s Automation Landscape: GDL, Python, and the JSON API

Before building skills, you need to understand the three primary automation interfaces ArchiCAD provides.

GDL (Geometric Description Language) is ArchiCAD’s built-in parametric scripting language. Every library part, from doors to custom furniture, is defined in GDL. The language handles 2D symbols, 3D geometry, parameter interfaces, and property connections. GDL scripts live inside .gsm library part files and execute within ArchiCAD’s rendering pipeline.

Python scripting became available through the ArchiCAD Python API, which connects to ArchiCAD via JSON-RPC. Python scripts run externally and communicate with a running ArchiCAD instance, making them ideal for batch operations, data extraction, and project-wide modifications.

The JSON API (also called the ArchiCAD JSON Interface) is the underlying protocol that the Python API wraps. You can call it directly using HTTP requests to localhost:19723, which is useful when you need precise control or want to integrate with tools outside Python.

Here is a quick comparison of when to use each:

Interface	Best For	Runs Inside ArchiCAD	Requires Running Instance
GDL	Parametric objects, library parts	Yes	No (compiled into .gsm)
Python API	Batch operations, data extraction	No (external)	Yes
JSON API	Direct HTTP integration, custom tools	No (external)	Yes

Claude Code skills can generate code for all three interfaces. The key is structuring your skills so they produce correct, testable output for each context.

Skill: GDL Object Creation from Descriptions

This is the highest-value skill for most ArchiCAD users. Writing GDL from scratch is time-consuming and error-prone. A well-designed skill can generate complete parametric objects from plain-language descriptions.

Here is an example of a GDL skill that creates a parametric wall niche:

! === 3D SCRIPT ===
! Parametric Wall Niche
! Parameters: niche_width, niche_height, niche_depth, arch_type

! Validate parameters
IF niche_width <= 0 THEN niche_width = 0.6
IF niche_height <= 0 THEN niche_height = 0.9
IF niche_depth <= 0 THEN niche_depth = 0.15

! Create the niche cutout using PRISM
ADDZ niche_depth
MULZ -1

IF arch_type = 1 THEN
    ! Rectangular niche
    BLOCK niche_width, niche_depth, niche_height
ENDIF

IF arch_type = 2 THEN
    ! Arched niche
    PRISM_ 8,
        0, 0,
        niche_width, 0,
        niche_width, niche_height - (niche_width / 2),
        niche_width * 0.933, niche_height - (niche_width * 0.067),
        niche_width * 0.75, niche_height - (niche_width * 0.017),
        niche_width * 0.5, niche_height,
        niche_width * 0.25, niche_height - (niche_width * 0.017),
        niche_width * 0.067, niche_height - (niche_width * 0.067)
    ADDZ -niche_depth
ENDIF

DEL 1

The corresponding parameter script defines the user interface:

! === PARAMETER SCRIPT ===
VALUES "arch_type" 1, 2

LOCK "gs_cont_pen"

IF GLOB_MODPAR_NAME = "niche_width" THEN
    IF niche_width < 0.2 THEN niche_width = 0.2
    IF niche_width > 2.0 THEN niche_width = 2.0
    PARAMETERS niche_width = niche_width
ENDIF

IF GLOB_MODPAR_NAME = "niche_height" THEN
    IF niche_height < 0.3 THEN niche_height = 0.3
    IF niche_height > 3.0 THEN niche_height = 3.0
    PARAMETERS niche_height = niche_height
ENDIF

Your Claude Code skill file should instruct the model to always include parameter validation, sensible defaults, and both 2D and 3D scripts. A practical skill prompt might look like this:

When generating GDL objects:
1. Always include parameter validation with min/max bounds
2. Generate all four scripts: Master, 2D, 3D, and Parameter
3. Use GLOB_MODPAR_NAME for interactive parameter updates
4. Include hotspot definitions in the 2D script for editing handles
5. Add comments explaining the geometric logic
6. Default pen colors should use symbolic pen indices, not hardcoded values

The 2D script is equally important because ArchiCAD floor plans rely on it for representation. A skill that only generates 3D geometry produces objects that look invisible in plan view, which is a common beginner mistake.

Skill: Template and Favorite Setup Automation

ArchiCAD favorites store predefined element settings that your team uses repeatedly. Manually creating favorites for walls, slabs, columns, and other elements across a template is tedious. A Claude Code skill can generate the Python API commands to batch-create favorites from a structured definition.

Here is a Python script that creates wall favorites using the ArchiCAD Python API:

from archicad import ACConnection

conn = ACConnection.connect()
acc = conn.commands
act = conn.types
acu = conn.utilities

# Define wall favorites as structured data
wall_favorites = [
    {
        "name": "EXT-Brick Cavity 300",
        "thickness": 0.300,
        "composite": "Brick Cavity Wall 300",
        "layer": "A-Wall-Ext"
    },
    {
        "name": "INT-Partition 100",
        "thickness": 0.100,
        "composite": "Plasterboard Partition 100",
        "layer": "A-Wall-Int"
    },
    {
        "name": "INT-Blockwork 200",
        "thickness": 0.200,
        "composite": "Concrete Block 200",
        "layer": "A-Wall-Int"
    },
]

# Get all existing elements to use as a base
elements = acc.GetElementsByType("Wall")

for fav in wall_favorites:
    print(f"Creating favorite: {fav['name']}")
    # Set properties via the API
    property_values = [
        act.ElementPropertyValue(
            act.PropertyId(act.PropertyGroupId("General"),
            act.PropertyDefinitionId("Layer")),
            act.NormalStringPropertyValue(fav["layer"])
        )
    ]
    # Apply to template element and save as favorite
    print(f"  Thickness: {fav['thickness']}m")
    print(f"  Composite: {fav['composite']}")
    print(f"  Layer: {fav['layer']}")

Your skill should maintain a favorites definition format that your firm can update without touching code. A YAML or JSON configuration file works well:

{
  "favorites": {
    "walls": [
      {
        "name": "EXT-Brick Cavity 300",
        "thickness": 0.300,
        "composite": "Brick Cavity Wall 300",
        "layer": "A-Wall-Ext",
        "classification": "Wall/External Wall"
      }
    ],
    "slabs": [
      {
        "name": "FLR-Concrete 250",
        "thickness": 0.250,
        "composite": "RC Slab 250",
        "layer": "A-Slab-Floor"
      }
    ]
  }
}

The skill reads this configuration and generates the corresponding API calls. When your standards change, you update the config file and re-run the skill. No manual ArchiCAD clicking required.

Skill: Property and Classification Management

ArchiCAD’s property and classification system is powerful but laborious to configure. A typical BIM project requires dozens of custom properties organized into groups, plus classification systems aligned to standards like Uniclass, OmniClass, or local codes.

A Claude Code skill for property management should handle three operations: creating property groups, defining individual properties within those groups, and assigning classifications to element types.

Here is a Python script that creates custom properties via the API:

from archicad import ACConnection

conn = ACConnection.connect()
acc = conn.commands

# Define property groups and their properties
property_definitions = {
    "Project Data": [
        {"name": "Project Number", "type": "string", "default": ""},
        {"name": "Project Phase", "type": "string", "default": "Concept"},
        {"name": "Client Name", "type": "string", "default": ""},
        {"name": "Site Address", "type": "string", "default": ""},
    ],
    "Sustainability": [
        {"name": "U-Value Target", "type": "number", "default": 0.0},
        {"name": "Recycled Content %", "type": "number", "default": 0.0},
        {"name": "EPD Reference", "type": "string", "default": ""},
        {"name": "BREEAM Category", "type": "string", "default": "N/A"},
    ],
    "Cost Management": [
        {"name": "Cost Code", "type": "string", "default": ""},
        {"name": "Unit Rate", "type": "number", "default": 0.0},
        {"name": "Procurement Package", "type": "string", "default": ""},
    ],
}

for group_name, properties in property_definitions.items():
    print(f"\nCreating property group: {group_name}")
    for prop in properties:
        print(f"  Adding property: {prop['name']} ({prop['type']})")
        # Use ArchiCAD API to create property definition
        # acc.CreatePropertyDefinition(...)

For classification management, the skill should support importing standard classification systems from structured data. Many national standards publish their classification tables in CSV or XML format. Your skill can parse these and generate the API calls to create the full classification tree in ArchiCAD.

The real value here is consistency. When every project starts with the same property definitions and classifications, your schedules, exports, and reports work correctly from day one. No more discovering halfway through documentation that someone forgot to add the fire rating property to the wall type.

Skill: Publisher Set Configuration

ArchiCAD’s Publisher is the primary tool for batch output of drawings, PDFs, and BIM models. Configuring publisher sets manually means selecting views, assigning output formats, setting file paths, and organizing the output folder structure. For a large project, this can involve hundreds of individual settings.

A Claude Code skill can generate publisher set configurations using ArchiCAD’s JSON API. Here is an example that sets up a standard documentation publisher set:

{
  "command": "API.CreatePublisherSet",
  "parameters": {
    "publisherSetName": "CD-Documentation Issue",
    "outputPath": "{{PROJECT_PATH}}/Output/CD-Issue/",
    "items": [
      {
        "type": "ViewFolder",
        "name": "A-Plans",
        "items": [
          {
            "viewName": "A-100 Ground Floor Plan",
            "format": "PDF",
            "dpi": 300,
            "outputName": "A-100_Ground_Floor_Plan"
          },
          {
            "viewName": "A-101 First Floor Plan",
            "format": "PDF",
            "dpi": 300,
            "outputName": "A-101_First_Floor_Plan"
          }
        ]
      },
      {
        "type": "ViewFolder",
        "name": "A-Sections",
        "items": [
          {
            "viewName": "A-200 Section AA",
            "format": "PDF",
            "dpi": 300,
            "outputName": "A-200_Section_AA"
          }
        ]
      },
      {
        "type": "ViewFolder",
        "name": "BIM",
        "items": [
          {
            "viewName": "IFC Export - Architecture",
            "format": "IFC",
            "translatorName": "Archgyan IFC4 Translator",
            "outputName": "Architecture_Model"
          }
        ]
      }
    ]
  }
}

Your skill should accept a simple input format that maps your firm’s drawing numbering system to ArchiCAD view names. The output folder structure should follow your firm’s convention automatically. This eliminates the common mistake of publishing drawings to the wrong folder or using incorrect output names.

A particularly useful pattern is to have the skill read the current view map from ArchiCAD (via the JSON API), filter views by naming convention, and automatically assign them to the correct publisher set folder. This way, if someone adds a new floor plan view following the naming standard, the publisher set picks it up without manual configuration.

Skill: IFC Mapping and Export Automation

IFC export quality depends entirely on how well your ArchiCAD properties map to IFC property sets. Poor mapping produces IFC files that other tools cannot read correctly, which defeats the purpose of openBIM collaboration.

A Claude Code skill for IFC mapping should handle translator configuration, property set mapping, and export validation. Here is a Python script that verifies IFC mapping before export:

from archicad import ACConnection
import json

conn = ACConnection.connect()
acc = conn.commands

# Define required IFC property mappings
required_mappings = {
    "Wall": {
        "Pset_WallCommon": [
            "IsExternal",
            "FireRating",
            "ThermalTransmittance",
            "AcousticRating",
            "LoadBearing"
        ]
    },
    "Slab": {
        "Pset_SlabCommon": [
            "IsExternal",
            "FireRating",
            "ThermalTransmittance",
            "LoadBearing",
            "PitchAngle"
        ]
    },
    "Door": {
        "Pset_DoorCommon": [
            "FireRating",
            "IsExternal",
            "SecurityRating",
            "SmokeStop"
        ]
    }
}

# Get all elements and check property availability
for element_type, psets in required_mappings.items():
    print(f"\nChecking {element_type} elements:")
    elements = acc.GetElementsByType(element_type)
    print(f"  Found {len(elements)} elements")

    for pset_name, properties in psets.items():
        print(f"  Property Set: {pset_name}")
        for prop_name in properties:
            # Check if property is defined and populated
            # Flag any elements with missing required values
            print(f"    Checking: {prop_name}")

print("\nIFC mapping validation complete.")

The skill should also generate IFC translator settings. ArchiCAD stores translator configurations as XML files, and your skill can produce these from a simplified mapping definition:

{
  "translator": {
    "name": "Project IFC4 Export",
    "schema": "IFC4",
    "mappings": {
      "ArchiCAD_Property_Group/Fire_Rating": "Pset_WallCommon/FireRating",
      "ArchiCAD_Property_Group/Is_External": "Pset_WallCommon/IsExternal",
      "ArchiCAD_Property_Group/U_Value": "Pset_WallCommon/ThermalTransmittance",
      "ArchiCAD_Property_Group/Acoustic_Rating": "Pset_WallCommon/AcousticRating"
    },
    "geometryConversion": "Brep",
    "includeProperties": true,
    "includeClassifications": true
  }
}

Running the validation script before every IFC export catches missing data early. This is far more efficient than discovering problems after the model has been shared with consultants.

Skill: Schedule and Listing Template Generation

ArchiCAD schedules (called Interactive Schedules or Listings) pull data from elements and display it in tabular format. Creating schedule templates involves defining fields, filters, sort orders, and formatting rules. With a Claude Code skill, you can generate these configurations from a simple specification.

Here is an example of a schedule definition that a skill would produce:

{
  "schedule": {
    "name": "Door Schedule - Architecture",
    "elementType": "Door",
    "fields": [
      {
        "name": "Element ID",
        "source": "General/Element ID",
        "width": 80,
        "alignment": "center"
      },
      {
        "name": "Width",
        "source": "Door/Width",
        "width": 60,
        "format": "mm",
        "alignment": "right"
      },
      {
        "name": "Height",
        "source": "Door/Height",
        "width": 60,
        "format": "mm",
        "alignment": "right"
      },
      {
        "name": "Fire Rating",
        "source": "Custom/Fire_Rating",
        "width": 80,
        "alignment": "center"
      },
      {
        "name": "Hardware Set",
        "source": "Custom/Hardware_Set",
        "width": 100,
        "alignment": "left"
      },
      {
        "name": "Finish",
        "source": "Custom/Door_Finish",
        "width": 120,
        "alignment": "left"
      }
    ],
    "filters": [
      {
        "field": "General/Layer",
        "operator": "contains",
        "value": "A-Door"
      }
    ],
    "sortBy": [
      {"field": "General/Story", "order": "ascending"},
      {"field": "General/Element ID", "order": "ascending"}
    ],
    "headerRow": true,
    "summaryRow": false
  }
}

Your skill should maintain a library of schedule templates for common element types: doors, windows, rooms, walls, and finishes. Each template defines the standard fields your firm expects, the correct sort order, and any filters needed to exclude non-relevant elements.

The Python API can then apply these definitions:

from archicad import ACConnection

conn = ACConnection.connect()
acc = conn.commands

# Read schedule definition from JSON
import json
with open("schedules/door-schedule.json") as f:
    schedule_def = json.load(f)

# Get all door elements
doors = acc.GetElementsByType("Door")
print(f"Found {len(doors)} doors in project")

# Extract property values for each door
schedule_data = []
for door in doors:
    row = {}
    for field in schedule_def["schedule"]["fields"]:
        prop_value = acc.GetPropertyValuesOfElements(
            [door],
            [field["source"]]
        )
        row[field["name"]] = prop_value[0] if prop_value else "N/A"
    schedule_data.append(row)

# Sort by defined sort fields
for sort_field in reversed(schedule_def["schedule"]["sortBy"]):
    schedule_data.sort(
        key=lambda x: x.get(sort_field["field"], ""),
        reverse=(sort_field["order"] == "descending")
    )

# Output as CSV for verification
print("\nDoor Schedule Preview:")
headers = [f["name"] for f in schedule_def["schedule"]["fields"]]
print(" | ".join(headers))
print("-" * 80)
for row in schedule_data[:10]:
    print(" | ".join(str(row.get(h, "")) for h in headers))

This approach lets you verify schedule content outside ArchiCAD before committing to the final layout, which is useful for catching missing data or incorrect filters early.

Skill: Hotlink and Module Management

Large ArchiCAD projects use hotlinks and modules to break the model into manageable pieces. A housing project might have individual unit types as hotlinked modules, placed multiple times across the site model. Managing these hotlinks requires keeping track of source files, placement locations, and update status.

A Claude Code skill for hotlink management should automate three tasks: inventory, placement, and update verification.

from archicad import ACConnection
import os

conn = ACConnection.connect()
acc = conn.commands

# Inventory all hotlinks in the current project
hotlinks = acc.GetHotlinks()

print("Hotlink Inventory:")
print("=" * 70)

for hl in hotlinks:
    source_path = hl.sourcePath
    file_exists = os.path.exists(source_path)
    status = "OK" if file_exists else "MISSING SOURCE"

    print(f"\n  Name: {hl.name}")
    print(f"  Source: {source_path}")
    print(f"  Status: {status}")
    print(f"  Instances: {hl.instanceCount}")

    if file_exists:
        mod_time = os.path.getmtime(source_path)
        print(f"  Source Modified: {mod_time}")
        if hl.lastUpdateTime < mod_time:
            print(f"  WARNING: Source is newer than hotlink")

print(f"\nTotal hotlinks: {len(hotlinks)}")
print(f"Missing sources: {sum(1 for hl in hotlinks if not os.path.exists(hl.sourcePath))}")

For placement automation, the skill can read a placement matrix from a CSV file and position hotlink instances at specified coordinates, rotations, and stories. This is invaluable for repetitive housing layouts where the same unit type appears dozens of times with different positions and mirroring.

The update verification piece is critical for collaborative workflows. Before publishing any output, the skill checks that all hotlinks are current and flags any that need updating. This prevents the common problem of publishing drawings based on outdated module files.

Working with ArchiCAD’s JSON API for Automation

The JSON API gives you direct HTTP access to ArchiCAD’s command interface. Every command the Python API supports is available as a JSON-RPC call to http://localhost:19723. This opens up automation possibilities beyond Python, including integration with Claude Code’s bash tools.

Here is how to query element properties directly via the JSON API:

# Get all wall elements
curl -s -X POST http://localhost:19723 \
  -H "Content-Type: application/json" \
  -d '{
    "command": "API.GetElementsByType",
    "parameters": {
      "elementType": "Wall"
    }
  }'

# Get property values for specific elements
curl -s -X POST http://localhost:19723 \
  -H "Content-Type: application/json" \
  -d '{
    "command": "API.GetPropertyValuesOfElements",
    "parameters": {
      "elements": [
        {"elementId": {"guid": "YOUR-ELEMENT-GUID"}}
      ],
      "properties": [
        {
          "propertyId": {
            "guid": "YOUR-PROPERTY-GUID"
          }
        }
      ]
    }
  }'

You can also use the API to get project information, which is useful for initializing skills with project context:

# Get project info
curl -s -X POST http://localhost:19723 \
  -H "Content-Type: application/json" \
  -d '{
    "command": "API.GetProjectInfo"
  }' | python -m json.tool

A Claude Code skill can combine these API calls into higher-level workflows. For example, a “project health check” skill might query element counts by type, check for elements on incorrect layers, verify that all external walls have U-value properties filled in, and produce a summary report. Each step is a simple JSON-RPC call, but orchestrating them manually would be tedious.

The JSON API also supports commands for navigating the project, such as switching stories, activating views, and running built-in commands. This means your skill can set up the correct view before exporting, ensuring consistent output without manual intervention.

ArchiCAD vs Revit: Comparing Automation Approaches

If your firm uses both ArchiCAD and Revit (or you are evaluating which platform offers better automation), understanding the differences in their scripting ecosystems helps you decide where to invest your skill-building effort.

Scripting languages: ArchiCAD uses GDL for parametric objects and Python for external automation. Revit uses C# for add-ins, IronPython for pyRevit scripts, and visual programming through Dynamo. GDL is more domain-specific (built for architectural geometry), while Revit’s C# API is more general-purpose but steeper to learn.

External API access: ArchiCAD’s JSON API runs over HTTP on a local port, making it accessible from any language or tool that can send HTTP requests. Revit’s API requires running inside the Revit process (via add-in) or using Revit’s command line interface for limited external access. Forge/APS provides cloud-based Revit API access but adds significant complexity.

Parametric objects: GDL objects are text-based scripts that you can version control, diff, and generate programmatically. Revit families use a graphical editor, and while they can be created via the API, the process is substantially more complex. This makes GDL a better target for AI-assisted generation since the output is human-readable code.

Template automation: Both platforms support scripted template setup, but ArchiCAD’s approach through favorites, property definitions, and publisher sets is more consistently accessible via the API. Revit’s template configuration often requires UI interaction that is harder to automate.

Community ecosystem: Revit has a larger third-party automation ecosystem (pyRevit, Dynamo packages, Forge apps). ArchiCAD’s ecosystem is smaller but more focused, with strong support from Graphisoft through the official Python API documentation and the GDL reference manual.

For Claude Code skill development, ArchiCAD’s text-based GDL and HTTP-based JSON API make it a natural fit. Skills can generate GDL scripts as plain text output and verify API calls using standard HTTP tools. This directness reduces the friction between skill output and practical application.

Building Your ArchiCAD Skill Library

Start with the skills that save you the most time in your specific workflow. Here is a prioritized approach:

Week 1: GDL object generation. Create a skill that generates basic parametric objects from descriptions. Start with simple geometric primitives (niches, shelves, counters) and expand to more complex objects as you refine the skill’s understanding of GDL conventions. Test every generated object by loading it into a library and placing it in a test project.

Week 2: Property and classification setup. Build a skill that reads your firm’s property definitions from a JSON or YAML file and generates the Python API commands to create them in a new project. Include your standard classification system. Run this every time you start a new project from your template.

Week 3: Publisher and IFC configuration. Create skills for your standard publisher sets and IFC translator settings. These are high-value because they eliminate repetitive configuration that directly affects deliverable quality.

Week 4: Schedule templates and validation. Build skills for your most common schedule types and add a validation step that checks element data completeness before export.

Each skill should follow a consistent structure:

skills/
  archicad/
    gdl-object-generator.md
    property-setup.md
    publisher-config.md
    ifc-mapping.md
    schedule-templates.md
    hotlink-manager.md
    project-health-check.md

Inside each skill file, include:

Purpose: A one-line description of what the skill does.
Inputs: What information the skill needs (element type, property list, output format).
Output format: What the skill produces (GDL script, Python code, JSON API calls).
Conventions: Firm-specific naming standards, layer conventions, property group names.
Validation rules: Checks the skill should perform before producing output.

Keep your skill files in version control alongside your project templates. When your standards change, update the skill definitions and regenerate your templates. This creates a single source of truth for your firm’s ArchiCAD standards that is both human-readable and machine-executable.

The combination of ArchiCAD’s open scripting interfaces and Claude Code’s ability to generate correct, context-aware code makes workflow automation accessible to architects who are not full-time developers. You do not need to master GDL syntax or memorize API endpoints. You need to clearly describe what you want, and let the skill handle the implementation details. Start with one skill, prove its value on a real project, and expand from there.