Best 3D, CAD and shader skills for AI agents

An agent doing 3D work is doing it blind. That is the whole problem, and almost everything else about picking skills for this domain follows from it. A Three.js scene with the camera sitting inside the cube renders a black rectangle and throws no error. OpenSCAD writes a mesh with self-intersections and still exits zero. A Gaussian splat trains to a loss curve that looks fine and produces a cloud of floaters. A clash report comes back empty because the geometry silently failed to load, and empty is exactly what success looks like. In every other domain the agent can run the thing and read the output. Here the output is a picture, and nobody is looking at it.

Stale knowledge makes it worse. Three.js has shipped ES modules only since r147, so an agent reaching for a script tag from memory writes code that cannot resolve three at all. What surprised me is that the skills which actually help are not the ones with the widest API coverage. They are the ones that hand the agent a check it can run without eyes — and even two skills wrapping the same command-line modeller put their weight in completely different places. One renders the part from six angles and orders the agent to open the PNGs. The other says the exit code will not tell you the mesh is broken, so read what the compiler printed.

Top picks

Start a Three.js scene with threejs-scene-setup

threejs-scene-setup states the version it was checked against — patterns target r165+, verified against r184 — and its siblings carry the identical line. That house style does more for you than a thousand words of API prose, because Three.js breaks its own conventions on a schedule and an undated skill silently rots. It teaches setAnimationLoop rather than a hand-rolled requestAnimationFrame, caps setPixelRatio around 2 so retina screens don't tank the frame rate, and — the part that matters — enumerates what a black canvas means: camera at the origin, or a lit material with no light in the scene. That is the blind agent's debugger. It stops deliberately at scene setup and hands models and lighting to siblings, which is a virtue, not a gap. If you're in React instead, r3f-fundamentals covers the same ground declaratively and is worth it for the frameloop table alone; threejs-fundamentals is a competent alternative but ships under AGPL-3.0, which is a decision, not a detail.

Write GLSL with shader-dev

shader-dev is a routing table over 36 technique files, and the routing table is where the value sits. It knows that shader code copied from ShaderToy will not compile in a browser and lists the exact port: #version 300 es first, fragCoord becomes gl_FragCoord.xy, mainImage gets wrapped in a real main(). It names the GLSL reserved words that break a shader when used as variable names — sample, filter, input, output among them — and it explains that a let referenced above its own declaration throws a ReferenceError, which reaches the user as a blank white page rather than as anything resembling a stack trace. Then it does the thing I most want from a shader skill: it sets a hard performance budget. Ray-march loops at or under 128 steps, inner lighting loops at or under 32, FBM at or under 6 octaves, and no more than 1000 total nested iterations per pixel, past which the browser freezes. An agent writing shaders will exceed all four of those cheerfully. The caveat is structural: the technique files live beside the skill, so the routing table is what you're installing, and it's only as good as the files it points at.

Print parts with use-openscad, and read its stderr rule twice

use-openscad is built around a single hard-won fact: OpenSCAD prints mesh problems to stderr and still exits zero. The exit code is reliable enough for parse errors and useless for geometry warnings, so the skill instructs the agent to capture stderr after every mesh export and grep it for manifold, self-intersect, degenerate and warning before declaring success, and to run with --hardwarnings when the result is going into CI. It also corrects two things an agent gets wrong from general knowledge — that --render is needed for STL export (it isn't; it only affects PNG), and that libraries should be pulled in with include, which copy-pastes top-level geometry and scrambles error line numbers, rather than use. It even locates the binary per platform, including the detail that Windows wants the openscad.com wrapper. The rival is openscad, which puts its weight somewhere else entirely: it renders front, back, left, right, top and isometric previews and requires the agent to open every PNG and look for inverted normals and failed booleans before delivering. Both know how to produce a preview image; only one makes looking at it mandatory, and only one warns you that the compiler's silence means nothing. They catch different failure classes. Install the one that matches your agent — visual review if it can read images, stderr discipline if it can't — and if you can afford both, run them in that order.

Do real mechanical CAD with cad

cad is the most opinionated document I read here and it earns it. STEP is the primary artifact, build123d Python is the source of truth, and the generated file is never edited directly. It ships defaults so you don't get an agent inventing them: millimetres, XY base plane, positive Z extrusion, 2.0-3.0 mm walls on small plastic enclosures, and M3/M4/M5 clearance holes at 3.4/4.5/5.5 mm. Snapshot review is mandatory and explicitly cannot be skipped just because the deterministic checks passed. Best of all, it forbids a specific agent reflex: never use git diff or file-size churn to decide whether a CAD artifact changed, because a byte-identical export and a geometrically identical part are different questions. The surrounding family is a genuine pipeline rather than a padded one — gcode orchestrates real slicer CLIs and never touches a printer, and bambu-labs puts the physical machine behind --execute --confirm-start-print — though several of those siblings are written in Codex's voice, which reads oddly in another harness without changing what they do. The real caveat is that this family leans on bundled scripts, so a partial install leaves you with instructions and no tools.

Debug a splat run with 3dgs-training-debugger

3dgs-training-debugger is unusually front-loaded: the tables you need in the middle of a run are in the document itself rather than in a file it tells you to go fetch. It gives a reference trajectory for a healthy run — loss, PSNR, Gaussian count and VRAM at each stage — so the agent has something to compare against instead of guessing. Its artifact table maps what you see to what went wrong: stretched Gaussian streaks mean scale isn't being clamped, ghosting means the clone offset or a scale gradient sign is wrong, holes mean pruning was too aggressive or the structure-from-motion points were sparse there. The timing rule is sharper still — an artifact present from iteration zero is an initialisation problem, one that appears right after the first densification cycle is a clone/split bug. It carries a VRAM formula that costs out a Gaussian at 59 floats, or 236 bytes, which is enough to predict an out-of-memory crash before you hit it. Depth still lives on disk: the full convergence trajectories, the per-GPU VRAM tables and the numbered artifact patterns are all references, so install the skill directory, not just the instructions.

Detect BIM clashes with clash-detection-analysis

Of the three tools with "clash" in the name, clash-detection-analysis is the one that opens the model. It loads IFC through ifcopenshell with world coordinates on, caches geometry per element, and for hard clashes filters candidate pairs by bounding box before doing anything expensive. Its clash sets are the reason to install it: structure against MEP at 0.05 m, electrical against plumbing at 0.15 m for water safety, door swing clearance at 0.90 m — real numbers an agent will not produce on its own. Know one thing before you trust the output. The "hard clash" test builds a k-d tree over one element's vertices and asks how close the other element's vertices come, calling it an intersection under 0.001 m. Vertices, not surfaces. A thin pipe passing clean through the middle of a coarsely tessellated slab has no vertex near any other vertex, and will be reported as clear. Treat it as a fast screen, not a certificate — and note that the soft-clearance pass skips the bounding-box filter entirely, so it slows down badly on a real model. Its sibling bim-clash-detection is weaker for a different reason: it never reads a model at all, taking a table of axis-aligned bounding boxes, which flags every diagonal duct run in the building.

What the name doesn't tell you

Read the description before the title. react-three-fiber is not an R3F tutorial — it is the 3D renderer for the json-render project, teaching a JSON element format and a Zod material schema across 19 built-in components. Excellent if you are building JSON-driven scenes, useless as a way to learn R3F. In construction, "clash" in the title tells you nothing about whether the thing parses a building model. And a skill carved out of one application tends to keep that application's assumptions in its examples, so scan the body before letting an agent follow it into a codebase with different conventions.

Licensing is the other silent filter. There is enough permissive MIT and Apache-2.0 material covering this ground that an AGPL-3.0 dependency should be a deliberate choice rather than something you discover later.

The bug that shows up after an hour of progress

web3d-integration-patterns is worth naming for a failure the other picks can't see: two animation libraries writing to the same property, or a tween that outlives the component that created it. Neither breaks anything immediately. Both surface only after an agent has been productive for a while and the scene starts behaving strangely under interaction. Its rule of one library per property, and its insistence on killing timelines in the cleanup function, are exactly what a fast-moving agent gets wrong. Check its examples against your installed versions before letting anything copy them.

Routers, and when they earn their tokens

Single-publisher families like to ship a router that dispatches to their own siblings. Some are genuine. threejs-builder routes on paradigm — imperative Three.js, R3F, or WebGPU, detected from the project — and loads exactly one reference, which is a real saving because those three paradigms share almost no code. 3d-cad is a provider matrix rather than a tutorial, and it is honest about where the gaps are, including the rule that slicers fail silently on non-manifold meshes so you should check with a mesh library first; just note that it presupposes the cli-hub harness, without which the tables are lists of names.

Others are overhead. postfx-router exists to route between three post-processing skills, which is a table of contents you pay context for, and it points at particle and shader skills outside its own set. It also still carries a section describing the author's own project, complete with cosmic glow on digits — a reliable sign that a skill was carved out of an application rather than written for general use. The test is simple: count the destinations and check whether they overlap. A router into three siblings you could have read directly is not decomposition. The same question applies inside a family worth having: 3dgs-engineering-guide sits beside the training debugger with strict anti-fabrication rules, but its substance is loaded from disk and one of its routing targets isn't in the set at all.

Pick for the loop, not the coverage

What makes these picks work is not how much of each API they document. It is that each one gives the agent a way to find out it was wrong without a human looking at a picture: a black-canvas checklist, a stderr grep, a compile-error list and an iteration budget, a mandatory snapshot, a healthy-loss trajectory, a clearance table with real numbers in it. Choose by the job first — web scene, shader, printable part, mechanical assembly, splat run, coordinated building model — and then, within that job, take the one that closes the loop. Somebody still has to look at the picture eventually. Everything before that shouldn't need them.