solidworks-automation-skill: A Python Toolkit That Gates CAD Claims Behind a Capabilities File

What Problem the Capability File Solves

Most CAD automation repositories present a feature list and leave you to discover which parts work on your machine. This project inverts that. The README states that the executable scope is defined by capabilities.yaml at the repository root, described as the single source of truth, and that unverified capabilities are not packaged as finished unattended deliverables. That is an unusual editorial decision for an automation toolkit, and it is the reason the project is worth a closer look at all. The audience is mechanical design engineers and automation developers who already script SolidWorks through COM and want a layer that does not silently produce wrong geometry. The README is explicit about the reliability baseline: SolidWorks 2024, SolidWorks 2026 SP01.1, and AutoCAD 2024 on real hardware. SolidWorks 2025 and any capability not covered by regression testing remain compatibility targets rather than verified ones. Threaded holes carry a verified label, with the README describing a rebuild that reads back the real thread and a review result of pass/100. A CNC-oriented fillet and chamfer subskill is marked stable. Engineering drawings, sheet metal, weldments, Simulation, Routing, complex surfaces, and mold work sit behind pilot gates. The value proposition is not that it does everything. It is that the project tells you which parts it does.

Three Entry Points Over One Python Core

The README describes a Skill package, an MCP server, and a CAD Studio desktop application as peer entry points that share the same capabilities and scripts. The Skill route targets clients that support skill import, installed either through npx github:wzyn20051216/solidworks-automation-skill or claude skill add with the repository URL. The MCP route targets Codex, Claude Code, Cursor, Windsurf, and other MCP clients, with Smithery named as the recommended installer. The desktop route is a Windows installer or portable ZIP from GitHub Releases, aimed at users who want a graphical interface for managing projects, conversations, tasks, previews, and delivery. Choosing one does not lock out the others, but they are not interchangeable in operation. The MCP server exposes SolidWorks COM automation as local tools covering basic modeling, assembly, mates, appearances, export, review, and a rotation motor. The desktop app adds a signed auto-update path that checks GitHub Releases silently at startup and asks the user to confirm download and install. A C# Add-in host is also documented, with a net48/x64 strong-named assembly covering application events, a three-command CommandGroup, TaskPane, and a full PropertyManagerPage handler. The README notes that production deployment of that host must use 64-bit RegAsm with /codebase /tlb, and that the in-process callback, application events, CommandGroup, TaskPane, PropertyManagerPage, and JSON diagnostics were regression-tested on SW2026 SP1.1.

Diagnostics Before Modeling: cad_doctor and cad_studio doctor

The first command you run is not a modeling command. The README gives python scripts/cad_doctor.py and python scripts/cad_studio.py doctor as the local environment checks, and states that the remediations field in the diagnostic output lists missing items, their scope of impact, official download addresses, and copyable install commands. This matters because the toolkit has a fallback path. Missing SolidWorks or AutoCAD only blocks the corresponding native formats. Open formats including STEP, IGES, BREP, STL, OBJ, GLB, DXF, SVG, PDF, and PNG remain available, handled by an OCCT/OCP isolated process for 3D and a separate 2D backend. So a machine with no CAD install can still produce geometry files, subject to capability gating that blocks complex features. When filing an issue, the README specifies python scripts/cad_studio.py export-diagnostics --output .\cad-studio-diagnostics.zip, and states the archive contains only version, stage, error codes, and timing, with no prompts, model content, API keys, or full private paths. That is a concrete privacy boundary rather than a vague assurance. The same remediation advice appears in the desktop app under Settings and Help, which suggests the diagnostic logic is shared rather than duplicated per entry point.

The CLI Surface and What It Reveals About Scope

Queue jobs can be driven without the desktop app. The README lists python scripts/cad_studio.py status, run --enable-mock, retry <job-id>, and cancel <job-id> for job control. Beyond that, the command list maps the toolkit's actual surface area: write-open-format for open-format export from a .cadstudio.json part file, preview-dxf for headless DXF preview into a scene JSON, check-dfm against a supplier profile JSON, check-routing, fea-preflight, prepare-fea, run-fea with a timeout, run-fea-convergence with a per-case timeout, review-advanced-geometry, create-ocp-loft, and create-ocp-surface. Two things stand out. First, the FEA commands exist alongside a README statement that Simulation and FEA sit in a controlled pilot gate, so the commands being present does not mean they are production-ready. Second, the OCP loft and surface commands point at the OCCT path rather than SolidWorks, which is consistent with the no-CAD fallback design. The DFM check takes a profile file, meaning manufacturability rules come from your supplier configuration rather than a built-in rule set, which puts the burden of encoding shop constraints on you. The mock flag on run is useful for exercising the queue without CAD present, and the README does not claim mock mode validates geometry.

Where the Verified Boundary Actually Sits

The README's case table is the most useful part of the documentation because it separates evidence from ambition. The M6x1 threaded hole case is marked verified, with a rebuild that reads back the real thread and produces SLDPRT, STEP, and a four-view drawing. The CNC fillet and chamfer subskill is marked stable, and the README describes six advanced paths completing SLDPRT, STEP, reopen, and FeatureData readback on SW2026 SP1.1, plus C0.2 and C0.4 chamfers on a fixed oblique edge of an open-source corner bracket with topology preserved after processing. It also states plainly that hold lines remain blocked. That kind of negative statement is rare and useful. The NIST test part drawing case is pilot, with five views, ten required dimensions, an A-A section, and a claim of 70 passing orientation tests and a PDF text boundary with zero overlaps. The README immediately qualifies it: automated checks catch missing output and obvious collisions, but frames, dimension chains, hole tables, and manufacturing semantics still require final visual review by an engineer. It also notes the test part comes from NIST public domain material rather than being the project's own benchmark. The mini fan motion assembly example is pilot with manual review required. Nothing in the material supports the idea that drawings can ship unattended.

The AutoCAD Side Is the Weakest Link

The topics list includes autocad, dwg, and dxf, so it is worth being precise about what the README claims. Headless DXF preview and structural review are described as usable. Native AutoCAD DWG drawing remains gated by the stability of the local ActiveX proxy, and the README points to the capability list for details. That is a meaningful constraint for anyone whose workflow is DWG-centric rather than SolidWorks-centric. The verified hardware baseline includes AutoCAD 2024, but the gating language suggests the failure mode is environmental rather than a missing feature. If your pipeline depends on producing native DWG files, the DXF path is the part the documentation stands behind, and the DWG path is the part it does not. The same caution applies to exported assemblies: the README says basic assembly export through native Pack and Go passed continuous regression on SW2026 SP01.1, but when complex references are missing, the toolkit falls back to a pilot staging package with a hash manifest instead of a clean export. That hash manifest is a reasonable integrity mechanism, and it is also a signal that the output is not what a downstream consumer expects from Pack and Go.

Alternatives and the Maintenance Question

The obvious alternative is writing your own Python COM automation with pywin32 against the SolidWorks API, which is what most teams do. The difference in approach is not the API surface, since this project calls the same COM interfaces. It is the routing layer and the gates. The README describes a multi-language backend router that picks between Python, C# PIA and Add-in, native C++, SWBasic, OCCT, and external solvers per atomic operation, and distinguishes Automation-equivalent semantics from exact native interfaces. A hand-rolled script has no such distinction, so a fillet that looks right in the API call may not match the native feature. On the other side, a hand-rolled script has no capability file to update, no pilot gates to argue with, and no desktop app to install. For a single engineer automating one repeatable task on one machine, that trade may not be worth it. For a team that needs the same automation to behave predictably across several workstations and SolidWorks versions, the gating is the point. Maintenance cost is where the MIT licence and the version baseline interact. MIT permits commercial use and modification, and the README does not impose additional terms, but running this against SolidWorks 2025 or 2027 is outside the verified set, so upgrade cost is really regression cost: someone has to confirm each capability still holds on the new build. The project pushes that work onto capabilities.yaml rather than hiding it, and the release cadence visible in the metadata (v0.3.4 in late August 2026, with a push in early September) suggests active but not frozen development. I have not installed or run any of this, so the diagnostics output, the DFM rule behaviour, and the actual reliability of the pilot features are things you would need to confirm on your own hardware.

Editorial conclusion

Adopt it if you are automating SolidWorks 2024 or 2026 SP01.1 on Windows and you want a scriptable layer that separates verified capabilities from experimental ones, particularly for threaded holes, fillet and chamfer work, and open-format export without a CAD install. Do not adopt it if you need unattended production drawings, complex sheet metal, weldments, or Simulation and Routing today, since the README places those in pilot or compatibility targets. Before committing, run python scripts/cad_doctor.py on the target machine and read capabilities.yaml to confirm your specific operation is listed as verified for your SolidWorks build rather than assumed from the feature list.

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. wzyn20051216/solidworks-automation-skill on GitHub