Skip to content
Design
Skill

/design-automation

Rule-based design systems, constraint satisfaction, space planning algorithms, automated layout generation, drawing automation, code compliance checking, and computational workflows for AEC design automation

BOOST
From plugin
computational-design-skills
22318 skills
Install
$ npx -y skills add Abhinavbwj/Claude-skills-for-Computational-Designers --skill design-automation --agent claude-code

How it fires

How this skill gets triggered: by you, by Claude, or both.

  • Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
  • You can call itInvoke it directly when you want it.
  • Slash command/design-automation

Context preview

The summary Claude sees to decide when to auto-load this skill.

Rule-based design systems, constraint satisfaction, space planning algorithms, automated layout generation, drawing automation, code compliance checking, and computational workflows for AEC design automation

SKILL.md

design-automation.SKILL.md
title: Design Automation
description: Rule-based design systems, constraint satisfaction, space planning algorithms, automated layout generation, drawing automation, code compliance checking, and computational workflows for AEC design automation
version: 1.0.0
tags: [automation, rule-based, constraint-satisfaction, space-planning, layout, compliance, workflow, code-generation]
auto_activate: true
user_invocable: true
invocation: /design-automation

Design Automation for AEC

Design automation is the disciplined application of computational logic to replace, accelerate, or augment repetitive and rule-governed design tasks across architecture, engineering, and construction. This skill covers the full spectrum from simple parametric rules through constraint-satisfaction engines to fully generative layout systems, drawing automation pipelines, and automated code-compliance verification.

---

1. Design Automation Spectrum

1.1 Levels of Automation in AEC

Design automation exists on a continuum. Understanding where a task falls on this spectrum determines the appropriate technology and the degree of human oversight required.

| Level | Label | Description | Example | |-------|-------|-------------|---------| | 0 | Manual | Designer makes every decision, draws every line | Hand-drafted floor plans | | 1 | Parametric | Geometry driven by explicit parameters; designer controls inputs | Grasshopper slider controlling facade panel width | | 2 | Rule-Based | IF-THEN logic encodes design knowledge; system applies rules automatically | Auto-sizing exit widths based on occupant load | | 3 | Constraint-Based | System searches solution space satisfying stated constraints | CSP solver placing rooms to satisfy adjacency + area constraints | | 4 | Generative | System produces many candidate designs autonomously; human selects | GA-based floor plan generator producing 500 layout options | | 5 | AI-Assisted | Machine-learned models propose designs or predict performance | GAN generating floor plan from adjacency graph | | 6 | Autonomous | Fully closed-loop: sense conditions, generate design, validate, output | Automated site grading from survey to construction docs (emerging) |

1.2 What Can vs. Should Be Automated

**High automation potential:**

  • Code compliance checking (deterministic rules)
  • Structural member sizing (engineering formulas)
  • Parking layout optimization (geometric + count)
  • Sheet creation and annotation (repetitive)
  • Clash detection (spatial intersection)
  • Area and quantity takeoffs (data extraction)

**Medium automation potential:**

  • Space planning and room layout (heuristic + constraint)
  • Facade design (performance + aesthetic rules)
  • MEP routing (complex constraints, many valid solutions)
  • Site grading (optimization with soft constraints)

**Low automation potential (human judgment critical):**

  • Architectural concept design (cultural, contextual)
  • Urban massing and placemaking (experiential quality)
  • Material palette selection (aesthetic, tactile)
  • Client presentation and persuasion (social)

1.3 Human-in-the-Loop Design Automation

The most effective AEC automation systems keep designers in the loop at critical decision points:

1. **Define** — Human sets objectives, constraints, preferences 2. **Generate** — System produces candidate solutions 3. **Evaluate** — System scores and ranks; human reviews 4. **Select** — Human chooses preferred direction 5. **Refine** — System develops selected option further 6. **Validate** — Automated compliance checking; human sign-off

This cycle can repeat at multiple scales: master plan level, building level, floor level, room level.

1.4 The Role of Design Rules and Heuristics

Design rules encode domain expertise in computable form:

  • **Hard rules**: Must be satisfied (building code, structural limits). Violation = invalid design.
  • **Soft rules**: Should be satisfied (rules of thumb, best practices). Violation = penalty score.
  • **Heuristics**: Rules of thumb that usually produce good results but are not guaranteed optimal. Examples:
  • Office floor plate depth should not exceed 15m from core to window
  • Residential corridor length should not exceed 30m without a window
  • Parking bay angle of 90 degrees maximizes density; 60 degrees improves maneuverability
  • Structure grid spacing of 7.5-9.0m suits most office programs

---

2. Rule-Based Design Systems

2.1 Production Rules (IF-THEN)

The simplest and most widely used automation pattern in AEC:

IF occupant_load > 500
THEN required_exits >= 3
     AND exit_width_total >= occupant_load * 5.0mm

IF room_type == "bathroom" AND floor_area < 4.0
THEN min_dimension >= 1.5m
     AND door_swing == "outward"

IF building_height > 23m
THEN fire_resistance_rating >= 120min
     AND sprinkler_system == required

Production rules are stored in a rule base and executed by a rule engine that: 1. Matches rules against current facts (pattern matching) 2. Resolves conflicts when multiple rules fire (conflict resolution) 3. Executes the winning rule's action (assertion or modification) 4. Repeats until no more rules fire (quiescence)

2.2 Decision Trees

Hierarchical rule structures where each node tests a condition and branches lead to sub-decisions:

Building Classification Decision Tree:
├── Occupancy > 300?
│   ├── YES → Assembly (A)
│   │   ├── Fixed seating? → A-1
│   │   ├── No fixed seating? → A-2
│   │   └── Worship? → A-3
│   └── NO → Business (B)
│       ├── Office? → B
│       └── Educational? → E
│           ├── Students > 12 yrs? → E
│           └── Students ≤ 12 yrs? → E (daycare)

Decision trees are valuable because they are transparent, auditable, and can be validated against code text.

2.3 Rule Engines

Production rule engines for AEC applications:

  • **Forward chaining**: Start from known facts, derive conclusions. Used for compliance checking. "Given this building, what rules are violated?"
  • **Backward chaining**:
Read more
Ships withcomputational-design-skills

Claude skills for Computational Designers

Get the whole plugin