text to cad - Moses Yebei

The Problem

Generating usable CAD geometry from natural language usually means either hand-coding parametric models or fighting brittle OpenSCAD-style scripts. Teams that need STEP, STL, URDF, and DXF outputs from a single prompt end up maintaining several disconnected toolchains. This repo packages those workflows as agent skills, so an LLM can produce and preview real CAD artifacts from a project directory.

What This Does

This is a portfolio of four self-contained projects, not one codebase: skills/ (448 files) holds the agent skill definitions, plugins/ (441 files) contains the CAD viewer and related tooling, viewer/ (373 files) is a browser-based preview workbench, and packages/ (229 files) holds the core libraries. The main skill is skills/cad/SKILL.md, which generates and edits CAD models with STEP as the primary output, plus STL, 3MF, and GLB exports. Companion skills cover DXF drawings, URDF/SRDF robot descriptions, and off-the-shelf part sourcing.

The stack is mixed: JavaScript/TypeScript for the viewer and cadjs package, Python for cadpy and the skill scripts. The packages/cadjs/src/common/cadScene.js file is the most-connected module, with 105 functions called from 39 other files.

How It Is Wired

Execution starts at main in packages/implicitjs/scripts/export.mjs, which reaches 343 functions. The traced path from entry to process exit is main -> exportImplicitCadFile, which writes to the filesystem via fs.mkdir. That is the shortest route; framework callbacks (like the viewer's HTTP handlers) are not visible as source edges.

The internal call graph shows 3,878 resolved edges. The highest-blast-radius functions are clamp (68 call sites), abs (67), and normalizeString (60). The tests/python/support/paths.py module is a hub with 23 dependents, meaning any change there ripples widely. Four modules sit in circular dependencies.

File responsibilities concentrate in cadScene.js for scene normalization, sdfEvaluator.js for implicit geometry evaluation, and displaySettings.js for theme/color normalization. The viewer's CadWorkspace component imports 22 modules, making it the heaviest client-side dependency.

How To Use It

Setup is per-project. The Python packages use pyproject.toml (install with pip or uv), the JS packages use package.json (npm), and the docs site uses Next.js. Clone with:

git clone https://github.com/moses-y/text-to-cad

Install the CAD skill's Python dependencies from plugins/cad/skills/cad-viewer/requirements.txt. For the viewer, run the dev server from viewer/ using its package scripts. The README documents the skill workflows but does not give a single install command for the whole repo.

Real-World Use

A robotics team prompts an agent to design a motor mount. The agent uses the CAD skill to generate a STEP file, the DXF skill for a mounting plate profile, and the URDF skill to produce robot description files. The viewer renders all three locally in the browser before any fabrication order is placed.

Code Health & Issues

Static analysis found 539 findings (62 high, 477 medium). The high-severity issues are oversized files — viewer/src/server/catalog/cadDirectoryScanner.mjs and packages/cadjs/src/common/cadScene.js exceed 1,400 lines each — and deep nesting in three workbench components.

The SDLC audit found four high-severity issues:

High - next@16.2.6 carries CVE-2026-64642 and eight more advisories; upgrade and commit the lockfile.
High - packages/cadpy/pyproject.toml has no lockfile; the shipped artifact can differ from the tested one.
High - CI has no test command despite 193 test files; the green check proves nothing.
High - release.yml pushes directly to the default branch with --force-with-lease.

Medium issues: no least-privilege token permissions, no Dependabot, no dependency scan in CI.

The Bottom Line

The skill-based approach is practical and the benchmark suite (10 documented cases with GIFs) shows real capability. The main risk is operational: unlocked dependencies, untested CI, and direct pushes to a deploying branch. Use it if you want a working CAD-generation workflow; fix the CI and lockfile gaps before trusting it in production.

What the analyser found

Deployment readiness

6/7

Container image
CI pipeline
Lockfile committed
Test suite
README
License
No committed secrets

Composition

1,663 files

JavaScript678
Python416
Markdown146
Shell53
JSON37
YAML32

ReactNext.jsExpress

Architecture

Top-level areas of the codebase, sized by module count. Arrows show how many imports cross from one area into another.

graph TD g0["viewer 337 modules"] g1["skills 296 modules"] g2["plugins 284 modules"] g3["packages 213 modules"] g4["tests 45 modules"] g5["docs 24 modules"] g5 -->|1| g3

Dependencies

3 of 22 declared dependencies are a major version behind. Resolved 22 of 22 against the registry.

Package	Declared	Latest	Behind
`@types/node`	^20	26.2.0	6 major
`typescript`	^5	7.0.2	2 major
`eslint`	^9	10.8.1	1 major

What would stop me shipping this

Ranked by severity × confidence × production reach. Reach is the honest discriminator across a collection that is mostly other people's code: the same finding matters more in something that ships.

high4

medium3

low1

Upgrade the pinned dependency carrying a published advisoryhigh9 occurrences

next@16.2.6 CVE-2026-64642 (high) +8 more

The pinned version is the one that installs, so a published advisory against it describes this deployment rather than a hypothetical one, and the advisory is also a public description of how to exploit it.

Fix: Upgrade to the fixed version named in the advisory, then commit the lockfile.

Commit a lockfile beside the manifesthigh

packages/cadpy/pyproject.toml

manifest with no lockfile in scope

An unlocked range means the artifact you tested and the artifact you ship can contain different transitive code, so a malicious patch release reaches production with no diff.

Fix: Run the package manager once and commit the generated lockfile.

Make CI invoke the test suite it hashigh193 occurrences

.github/workflows

193 test files, no test command in the 4 workflows read

A green check that never executed an assertion is worse than no check, because reviewers trust it.

Fix: Add a test step to the existing workflow rather than a new workflow.

Open a pull request instead of pushing to the default branchhigh

.github/workflows/release.yml

git push --force-with-lease origin "$branch"

Automated commits land on the branch that deploys, with no test having run against the result.

Fix: Push to a bot branch and open a pull request, or restrict the push to a tag ref.

Declare least-privilege permissions for GITHUB_TOKENmedium

.github/workflows/test.yml

1 workflow(s) declare no permissions

With no declaration the token inherits the repository default, so any injected step can push commits or mint releases from inside your own CI.

Fix: Add permissions: contents: read at the top of the workflow and widen per job only where needed.

Enable Dependabot or Renovatemedium

48 manifest(s), no update bot configured

Without a bot a published advisory sits unpatched until someone audits by hand, which across 1,322 repositories means never.

Fix: Commit .github/dependabot.yml covering the repo ecosystems plus github-actions.

Gate pull requests on a dependency vulnerability scanmedium

.github/workflows

no dependency scan in CI

This is the one gate that would catch a known-vulnerable package before it reaches a build, and no repository in the sample had it.

Fix: Add dependency-review-action on pull_request, or osv-scanner on push and a schedule.

Set timeout-minutes on the workflow jobslow4 occurrences

.github/workflows/deploy-docs.yml

4 workflow(s) declare no job timeout

A wedged step runs to the six-hour platform default, which on a two-hourly schedule means three runs overlap behind it.

Fix: Add timeout-minutes with a realistic bound to each job.

Checked deterministically against the repository tree and a bounded set of its files: committed credentials, unpinned actions and base images, missing lockfiles and update bots, workflows that discard failures, published advisories against the declared dependencies, runtime configuration, licensing and notebook reproducibility. No language model is involved in this section.