/lab-hardware-cad

name: lab-hardware-cad
description: Design custom laboratory hardware as parametric build123d models and export fabrication-ready STEP, STL, and DXF files - microfluidic chips and molds, optomechanical mounts and breadboard adapters, cuvette and microplate holders, tube racks, animal-behavior rigs, and 3D-printed instrument fixtures. Use when a research task needs a physical part that must mate with standardized labware, an optical table, a cage system, or a printer, CNC, or laser process.
license: MIT
compatibility: Python 3.10-3.14 with build123d 0.11.1 and matplotlib for snapshots. Geometry commands require build123d; the standards lookup and the interface check run on the standard library alone. No network access needed.
allowed-tools: Read Write Edit Bash Glob Grep
metadata:
  version: "1.3"
  skill-author: K-Dense Inc.
  last-reviewed: "2026-08-15"
  build123d-version: "0.11.1"

Lab Hardware CAD

Design physical research hardware as **parametric Python source**, export STEP as the authoritative artifact, and verify the result both numerically and visually before anything is fabricated.

The hard part of lab hardware is almost never the geometry. It is that the part must mate with equipment whose dimensions are fixed by a published standard or a vendor drawing. A holder that is 0.5 mm too wide does not fit the plate reader; a channel with the wrong aspect ratio collapses during bonding; a mount whose bolt pattern is 25.4 mm instead of 25.0 mm will not reach the optical table. This skill exists to keep those numbers correct and checked.

When to use

Use for any request to design, model, or fabricate a physical part for a lab: chip, mold, mount, adapter, holder, rack, bracket, enclosure, jig, fixture, arena, or maze. Also use to inspect or modify an existing STEP file.

Do **not** use for finite-element analysis, computational fluid dynamics, molecular structure, or scientific plotting. Those are different skills.

Setup

uv venv --python 3.12 .venv-labcad
uv pip install --python .venv-labcad/bin/python "build123d==0.11.1" "matplotlib>=3.8"

build123d 0.11.1 requires Python >=3.10,<3.15 and pulls in the OpenCascade kernel through `cadquery-ocp-novtk`. The wheel is large; install once per project and reuse it.

All bundled scripts take `--help`. `check.py standards` runs without build123d installed.

**Model files are executed, not parsed.** `gen.py`, `check.py`, and `snapshot.py` import a `*_model.py` and call its `build()`, which runs arbitrary Python in the current environment. That is inherent to parametric CAD — the source is the design. Only run model files authored in this session or supplied by the user from a trusted location. If a model came from the internet, a shared drive, or an untrusted colleague, read it before running it and say that you did.

Required workflow

Follow these steps in order. Steps 5 and 6 are not optional, and step 6 is not waived by step 5 passing.

1. Route to a device family

Read the request, classify it, and load **exactly one** family reference. Do not load all four — they are long, and mixing conventions between families is a common source of error.

| If the part is | Load | | --- | --- | | A chip, mold, channel network, flow cell, gasket, or anything with fluid ports | `references/microfluidics.md` | | A mount, post, breadboard adapter, cage-system part, filter or sample holder in a beam path | `references/optomechanics.md` | | An adapter, insert, rack, or holder for plates, cuvettes, tubes, slides, or dishes | `references/labware-adapters.md` | | An arena, maze, head-fixation part, spout, tether, or extrusion-mounted enclosure for animal work | `references/behavior-rigs.md` |

If the part genuinely spans two families — a microfluidic chip that bolts to an optical table — load the family that owns the **critical interface**, then read only the interface section of the second. State in your response which family you routed to.

2. Establish the interface dimensions before any geometry

Every part has at least one mating interface. Before writing code, write down for each interface:

• the **source** of the dimension: a published standard, a vendor drawing, or a user measurement;
• the **nominal value and tolerance**;
• the **clearance or interference** you intend, and why.

Look the number up in `assets/standards.json` or the family reference. **Never write an interface dimension from memory.** If the number is not in the standards file or the reference, ask the user for the vendor drawing or the measurement rather than guessing. A guessed interface dimension is the single most expensive failure mode in this skill.

A feature that must *receive* a standardised component is sized against that component's **maximum material condition** — nominal plus its plus-tolerance — and only then given clearance. Sized from nominal instead, it fits only the smaller half of conforming parts.

python scripts/check.py standards --list
python scripts/check.py standards --show slas-microplate-footprint

The bundled standard IDs (exact strings; do not guess variants): `slas-microplate-footprint`, `slas-microplate-height`, `slas-microplate-flange`, `slas-well-positions-96`, `slas-well-positions-384`, `slas-well-positions-1536`, `cuvette-standard-10mm`, `optical-breadboard-metric`, `optical-breadboard-imperial`, `cage-system-30mm`, `sm1-lens-tube-thread`.

If the part mates with nothing in this list, that is common and fine: declare no interfaces, and name every interface dimension with its source (user spec, vendor drawing, measurement) as **unchecked** in the report. Never declare against an unrelated standard to fill the gap — a fabricated declaration is worse than an honest "nobody checked this".

3. Choose the process before choosing the geometry

Read `references/fabrication-limits.md`. Process determines minimum wall, minimum feature, achievable tolerance, and whether the part survives autoclaving or cont