Skip to main content
ClaudeWave
Skill996 repo starsupdated 9d ago

matlab-generate-code

>

Install in Claude Code
Copy
git clone --depth 1 https://github.com/matlab/matlab-agentic-toolkit /tmp/matlab-generate-code && cp -r /tmp/matlab-generate-code/skills-catalog/code-generation/matlab-generate-code ~/.claude/skills/matlab-generate-code
Then start a new Claude Code session; the skill loads automatically.

SKILL.md

# Generate Code with MATLAB Coder

Umbrella skill for the MATLAB Coder workflow: generate code, verify it, refine the config, and accelerate with profiled MEX.

## When to Use

- Generating C/C++ or CUDA code from MATLAB functions (MEX, lib, dll, exe)
- Writing new MATLAB code that must be compatible with code generation
- Reviewing existing MATLAB code for codegen readiness or fixing codegen errors
- Configuring codegen settings for specific targets (embedded, speed, readability, safety)
- Verifying generated code matches MATLAB output (coder.runTest, matlabtest.coder.TestCase)
- Profiling and accelerating generated MEX functions
- Using coder.* directives (coder.varsize, coder.const, coder.extrinsic, coder.ceval, etc.)

## When NOT to Use

- Simulink Coder / Embedded Coder Simulink-model workflows
- Generating code for target languages that are not C, C++, or CUDA
- Fixed-Point Designer conversion workflows
- Hand-written MEX C files (not generated by MATLAB Coder)
- General MATLAB programming unrelated to code generation

### Route to a more specific skill

- **Generating code from an AI model** (PyTorch `.pt2` / LiteRT `.tflite` via `loadPyTorchExportedProgram` / `loadLiteRTModel`) → use **matlab-deploy-ai-model**. Return here for the underlying `coder.*` directives, config tuning, and screener/verification.
- **Deploying to physical embedded hardware** (on-target PIL, ERT hardware configs, board selection — STM32 / Raspberry Pi / ARM Cortex) → use **matlab-deploy-embedded-code**. This skill covers host-side codegen, SIL, and config tuning up to hardware targeting.
- **Speeding up interpreted MATLAB by rewriting the M-code** (vectorization, preallocation, caching) → use **matlab-optimize-performance**. This skill's acceleration path assumes you want to compile to MEX/C, not restructure the algorithm.
- **General MATLAB test authoring** (parameterized tests, fixtures, mocking, coverage, CI/CD, App Designer) → use **matlab-write-test**. This skill covers only codegen-equivalence tests (`coder.runTest`, `matlabtest.coder.TestCase`).
- **Modernizing deprecated APIs for currency/maintainability** when code generation is not the goal → use **matlab-modernize-code**. This skill rewrites source only to satisfy codegen constraints, with explicit authorization.

## Routing — load the matching reference file on demand

Pick the workflow that matches the user's intent and read the corresponding `references/*.md`. Each reference file is a deep, self-contained guide; load only what you need rather than carrying all four in context.

| User intent | Load |
|---|---|
| Writing new codegen-compatible MATLAB; reviewing MATLAB for codegen readiness; fixing codegen errors; `%#codegen`; language constraints; type/size rules | `references/write-codegen-ready.md` |
| Understanding a specific `coder.*` directive (coder.varsize, coder.const, coder.inline, coder.unroll, coder.extrinsic, etc.) | `references/write-coder-directives.md` |
| Using MATLAB classes in codegen; class limitations; `coder.classSignature`; handle vs value class restrictions | `references/write-class-limitations.md` |
| Generate C/C++/CUDA code (MEX, lib, dll, exe), specify input types, fix `coder.screener` issues | `references/generate-code.md` |
| Verify generated code matches MATLAB; write `coder.runTest` / `matlabtest.coder.TestCase` tests; SIL setup | `references/verify-code.md` |
| Tune a working config for a deployment goal (embedded / speed / readability / size / safety); SIMD values (SIMDAcceleration, InstructionSetExtensions), OpenMP, OptimizeReductions | `references/refine-config.md` |
| Profile generated MEX, measure `coder.timeit` / `coder.perfCompare`, find hotspots | `references/accelerate-mex.md` |
| Look up a config property's name, availability, or non-obvious behavior | `references/config-properties.md` |

**Disambiguation — "write" vs. "generate" vs. "generate for a class":**
- "Write codegen-ready code" = authoring/reviewing the MATLAB source so it *can* be compiled (`write-codegen-ready.md`)
- "Generate code" = running `codegen` to produce C/C++ from an already-valid function (`generate-code.md`)
- "Generate code for a class" / "generate C++ class" = the user's source is a `classdef` file → load `generate-code.md` (Step 0 handles class entry points via `coder.ClassSignature`). Do NOT default to wrapping the class in a function.
- If both apply (user wants to write a function AND generate code from it), load `write-codegen-ready.md` first, then `generate-code.md`

For requests that span workflows (e.g., "generate MEX, verify it, then speed it up"), load the references in order rather than all at once.

## Out of scope

- **Simulink** Coder / Embedded Coder workflows (these are skill candidates of their own).
- **Non-C, C++, or CUDA target languages** — this skill covers C/C++ and CUDA code generation only
- **Fixed-point conversion** (use Fixed-Point Designer).
- **Hand-written MEX files** — the acceleration guidance assumes MATLAB Coder-generated MEX.
- **`CodeExecutionProfiling` / SIL profiling** with Embedded Coder — out of scope for the acceleration reference.

## Cross-cutting rules

These apply across every workflow. Apply them whether or not you've loaded a per-workflow reference yet.

### Class entry point — use `coder.ClassSignature`, not a wrapper function

When the user's target is a MATLAB class (classdef file) and they want to generate C++ code from it, use `coder.ClassSignature` for direct class code generation. Do NOT create a wrapper entry-point function. This produces a proper C++ class with methods — which is what users mean when they say "generate C++ class."

Load `references/generate-code.md` → Step 0 and `references/write-class-limitations.md` → "Direct class code generation" for the full workflow. The prerequisite `enableCodegenForEntryPointClasses` must run once per session.

Only fall back to a wrapper function if the user's MATLAB version lacks `coder.ClassSignature` (pre-R2026a) or the clas
matlab-train-networkSkill

>

matlab-driving-data-importerSkill

Import recorded driving sensor data (GPS, camera, lidar, actor tracks, lanes) into scenariobuilder.* objects (GPSData, CameraData, LidarData, ActorTrackData, Trajectory, laneData) and run preprocessing — synchronize, offset correction, crop, normalizeTimestamps, convertTimestamps. Also: compute actor tracks from lidar when no annotations exist, attach camera/lidar mounting + intrinsics, export to MAT/workspace/timetable/script. Use for raw driving dataset files (KITTI, nuScenes, Waymo, Pandaset, ROS/ROS2 bags, .mat, .csv, .mp4) or driving/vehicle/sensor logs that need wrapping. drivingLogAnalyzer (DLA) is OPT-IN ONLY — invoke only on explicit user request ('DLA', 'open in DLA', 'inspect/explore/analyze the recording') or reported sensor problem (sync drift, timestamp mismatch, overlay misalignment). NEVER auto-launch DLA after wrapping (Rule 0). For 'build scenario / export to RoadRunner / drivingScenario / OpenSCENARIO / Unreal / simulate', hand off to matlab-scenario-builder.

matlab-scenario-builderSkill

Generate driving scenes, scenarios, road surfaces, and 3D content from already-wrapped scenariobuilder.* sensor data (GPS, camera, lidar, actor tracks) using Scenario Builder for Automated Driving Toolbox. Use to BUILD, EXPORT, or AUGMENT a virtual scenario/scene/map: ego or actor trajectories, trajectory smoothing, OpenCRG road-surface extraction, 3D asset generation, static-object placement, point-cloud georeferencing + elevation, lane-based ego localization, sensor-fusion tracking, scenario-event extraction (cut-ins, hard brakes, near-misses, ADAS disengagements), or export to RoadRunner, drivingScenario, OpenDRIVE, OpenCRG, OpenSCENARIO, or Unreal Engine. Also: log-to-scenario, scenario harvesting, accident/near-miss reconstruction, SOTIF (ISO 21448) and ISO 26262 scenario coverage, USGS-aerial-lidar scene augmentation, traffic-sign placement from camera+lidar logs. NOT for raw-data import or multi-sensor sync/crop/offset/timestamp normalization — route those to matlab-driving-data-importer.

roadrunner-asset-mappingSkill

>

roadrunner-convert-lanelet2-to-rrhdSkill

>

roadrunner-import-sceneSkill

>

roadrunner-rrhd-authoringSkill

>

matlab-build-simbiology-modelSkill

Build, modify, and diagram SimBiology models — API reference, helper functions, and layout patterns. Use when constructing or editing models programmatically or visually.