autodesk-fusion-script-generator

Files (37)

• marketplace.json · .agents/plugins/
• marketplace.json · .claude-plugin/
• plugin.json · .claude-plugin/
• plugin.json · .codex-plugin/
• .gitignore
• LICENSE
• README.md
• SKILL.md
• llm_fusion_runner.manifest · addins/llm_fusion_runner/
• llm_fusion_runner.py · addins/llm_fusion_runner/
• openai.yaml · agents/
• chain_bolt_press_jig.manifest · examples/chain_bolt_press_jig/
• chain_bolt_press_jig.py · examples/chain_bolt_press_jig/
• gpu_air_guide.manifest · examples/gpu_air_guide/
• gpu_air_guide.py · examples/gpu_air_guide/
• iec_c14_cradle.manifest · examples/iec_c14_cradle/
• iec_c14_cradle.py · examples/iec_c14_cradle/
• speaker_stand_flange.manifest · examples/speaker_stand_flange/
• speaker_stand_flange.py · examples/speaker_stand_flange/
• plugin.json
• fusion_advanced_geometry.md · references/
• fusion_api_patterns.md · references/
• fusion_api_research.md · references/
• fusion_interfaces_and_fit.md · references/
• fusion_printability.md · references/
• printable_handoff.md · references/
• runner_setup.md · references/
• build_plugin_package.py · scripts/
• configure_fusion_runner.py · scripts/
• fusion_api_lookup.py · scripts/
• fusion_runtime_bridge.py · scripts/
• preflight_fusion_script.py · scripts/
• validate_stl_exports.py · scripts/
• test_plugin_package.py · tests/
• test_runner_lifecycle.py · tests/
• test_runner_setup.py · tests/
• test_stl_exports.py · tests/

SKILL.md (first lines)

# Autodesk Fusion AI Script Generator

Generate parametric Autodesk Fusion 360 Python scripts from a natural-language description of a part. Save the files and, when the opt-in LLM Fusion Runner is active in an open Fusion session, run an autonomous edit-test-diagnose loop. The skill does not launch Fusion.

## Plugin packaging maintenance

For installation or packaging changes, use root `plugin.json` as the metadata
source. Run `scripts/build_plugin_package.py --write`, then `--check` and the
package tests; do not edit its generated manifests or catalogues independently.
See [README.md](README.md) for direct GitHub and standalone installation. Packaging
work does not require connecting to Fusion. Preserve local changes and publish
only when the user authorizes a commit/push.

## Startup connection check

At the start of every job, resolve this skill's repository path and run the read-only `scripts/configure_fusion_runner.py`, then `scripts/fusion_runtime_bridge.py status` once a scripts root is configured. Do this before relying on the autonomous loop. If the runner is missing, stopped, stale, or loaded from the wrong location/source revision, follow [references/runner_setup.md](references/runner_setup.md) and guide the user to add `addins/llm_fusion_runner/` from this repository in Fusion. Recheck until both `active` and `identity_matches` are true; continue independent design work while setup is pending. Do not launch Fusion or claim runtime validation while the connection is unavailable.

## Slicer boundary

Own CAD geometry, printable-body names, geometry validation, neutral per-body mesh exports, and suggested physical orientation. Stop there.

When the user also wants a slicer-ready project:

- Export one neutral 3MF or STL per printable body.
- Write a slicer-neutral `printable_manifest.json` using `references/printable_handoff.md`.
- Do not assign AMS slots, Bambu filament presets, Bambu plate coordinates, custom layer G-code, or call Bambu Studio from the Fusion script.
- Hand the neutral exports to `$bambu-studio-project-builder`, which owns Bambu packaging and validation.

## Output location

First, check the optional local preference file in the platform configuration directory: `%APPDATA%\autodesk-fusion-script-generator\config.json` on Windows, `~/Library/Application Support/autodesk-fusion-script-generator/config.json` on macOS, and `$XDG_CONFIG_HOME/autodesk-fusion-script-generator/config.json` (or `~/.config/...`) on Linux. When it contains a non-empty `scripts_root` string, use that directory unless the user gives a different destination. If the file is missing, invalid, or has no `scripts_root`, ask the user for their Fusion scripts directory. If they want code only, return the script and manifest without writing either file.

After a user explicitly approves saving their preference, create or update the local, untracked file:

```json
{
  "scripts_root": "<fusion-scripts-directory>"
}
```

On first use, read this preference before asking for a directory. If it is missing and a workspace was supplied, inspect that workspace for an existing Fusion Scripts directory (matching script folders and manifests are useful evidence), then propose it. With explicit approval to remember the location, use `scripts/configure_fusion_runner.py --scripts-root "<directory>" --write` to preserve unrelated settings and save the preference. The helper's default mode is read-only. Read JSON as `utf-8-sig` so Windows-created files with a BOM work.

Never create, overwrite, or change this preference file without that approval. Treat it as local configuration: do not add it to Git, quote its contents in public output, or assume its value applies to another machine.

Each script must live in its own subfolder, and the subfolder name, Python file name, and manifest file name must match:

```
<fusion-scripts-directory>/<script_name>/<script_name>.py
<fusion-scripts-directory>/<script_name>/<script_name>.manifest
```

Use a descriptive, short snake_case script name without a `.py` extension for the folder (e.g. `ptfe_bracket`, `pi_camera_mount`, `desk_cable_clip`). Keep names practical for Fusion's script loader; prefer about 30 characters or fewer when possible. Create a `.manifest` JSON file with the same base name:

```json
{
  "autodeskProduct": "Fusion360",
  "type": "script",
  "id": "<script_name>",
  "supportedOS": "windows|mac"
}
```

Set `id` to the script name. Include the four fields above; the bundled preflight validator requires them.

By default, keep the script folder clean: only `<script_name>.py` and `<script_name>.manifest`. Do not put README files, generated STLs, images, or helper files in the Fusion script folder unless the user explicitly needs them there or the script itself must generate them at runtime. Extra files can make Fusion's manual "Add" flow more confusing while debugging imports.

If a script folder or matching file already exists, ask the user whether to overwrite or pick a new name before changing it.

## Workflow

### 1. Interview the user

Don't dive into code. First, build a mental model of the part. Ask the questions that actually matter for *this* part - not a rote checklist. Skip questions that are obvious from context, and group related ones so it doesn't feel like an interrogation.

Things worth understanding before writing code:

- **What is it for?** The use case often answers half the dimensional questions for free (e.g. "PTFE tube guide" tells you the hole size).
- **Overall shape and orientation.** A rough verbal description, or an ASCII sketch from the side / top. Ask the user to describe what it looks like from each relevant view if it's non-trivial.
- **Critical dimensions.** Lengths, thicknesses, diameters. Ask for the *constraints* (table is 18 mm thick) rather than the final numbers - you can derive the rest.
- **Mating parts.** Anything it has to fit, slide over, screw into, clip onto. Get the mating dimensions, plus a clearance preference if relevant.
- **Mating envelopes.** For connectors and nested parts, identify which member enters which bore and which physical part occupies every radial and axial region. Do not infer plug/socket behavior from male/female labels. Verify a mated pair of official drawings or STEP models; standardized contacts do not guarantee interchangeable housing geometry.
- **Reference artifacts.** When an existing STL, STEP, sketch, or failed print defines an interface, inspect it read-only and record exact hole centres, diameters, plate bounds, thicknesses, and keyed profiles before redesigning. Keep a dimension ledger with the source of every value; do not repurpose a number from an unrelated measurement or numbered list item.
- **Seating datums and installation path.** Identify the actual surface that seats against the print, then measure every axial stop, shoulder, strain relief, latch, and cover from that datum. Describe how the real part enters, translates, rotates, and becomes captive; a valid final cavity can still be impossible to assemble.
- **Part size versus required clearance.** Clarify whether a stated diameter or width is the mating part's maximum size or the desired printed opening. Add printer/material clearance only after that distinction is explicit.
- **Holes and features.** Count, diameter, position, what passes through them, whether they're through-holes or blind, whether they need countersinks.
- **Fixing method.** Screws? Glue? Press-fit? Magnets? This drives whether you need screw holes / pilot holes / pockets.
- **3D-printing considerations.** Wall thickness (default to ~3-5 mm for FDM structural parts), fillets on stress concentrators, material, intended orientation, internal support access, adhesion, and whether branding will be paint-filled or printed as a separate multicolour body.

If the user says something ambiguous, draw an ASCII diagram of your interpretation and ask them to confirm before you code. **Cheap to ask, expensive to redesign.**

### 2. Plan before writing

Once you have the picture, briefly summarise back the part to the user - dimensions, features, hole positions - and get a thumbs-up. Then mentally decompose the geometry into Fusion operations:

- What's the base profile? On which plane? Extruded along which axis?
- Are there secondary features (holes, slots, pockets) and which face/plane do they live on?
- What gets filleted/chamfered for strength or print quality?
- Can each feature keep one obvious job? Prefer a few readable ribs, collars, or bosses over merging adjustment hardware into a more elaborate load-bearing form without a clear need.
- Which dimensions are measured, recovered from reference geometry, standards-based, inferred from imagery, or deliberately chosen as print clearance? Do not treat an unscaled photograph as a dimensional drawing.
- What is the complete assembly sequence, and does every intermediate position clear fixed stops, lips, and cable strain reliefs?
- Which bodies or sleeves begin as isolated first-layer islands in the intended print orientation, and do they need a brim or removable breakaway tabs?
- In each candidate orientation, where does an internal bore abruptly contract as layers rise? Those contractions create annular ceilings; prefer an orientation that leaves precision cavities open and support-free even when its footprint is smaller.
- Which uncertain fits should be calibrated with small, physically labeled gauges before generating the final build?
- Which generated entities are final printable solids, separate assembly parts, or hidden construction bodies? Decide the exact printable-part count before coding the final message.

For compact electronics enclosures, read the enclosure clearance and thermal-claims section in [references/fusion_api_research.md](references/fusion_api_research.md). It covers fan pad envelopes, hardware head clearance, local cable covers, mounting axes after size changes, and the distinction between CAD validation and thermal testing.

### 3. Write the script

Use the patterns in `references/fusion_api_patterns.md` - there are several Fusion 360 API gotchas (sketch coordinate transforms, profile selection, hole direction, unit conventions) that will silently break a naive script. Read that file before writing code; don't try to remember the API from scratch.

For any unfamiliar Fusion API class or method, verify the signature against the installed Autodesk stubs before writing code:

```
python "<skill-directory>/scripts/fusion_api_lookup.py" ClassName.methodName
```

Read `references/fusion_advanced_geometry.md` before using temporary BRep geometry, base features, non-trivial booleans, or sketch text. Read `references/fusion_api_research.md` when using fitted splines or threads, or when a Fusion runtime error needs diagnosis. Cross-check official Autodesk documentation for semantics and retirement notices, while using the local installed stubs for the exact Python signature. A method remaining in the stubs can be backward-compatible but retired; use Autodesk's current replacement in new scripts.

From matcluck/autodesk-fusion-modelling, MIT.

More from matcluck/autodesk-fusion-modelling