matlab-create-buildfile
starsforks
How to install matlab-create-buildfile?
matlab/matlab-agentic-toolkit/matlab-create-buildfile
$npx -y skills add matlab/matlab-agentic-toolkit --skill matlab-create-buildfileGenerate a MATLAB buildfile.m with tasks for static analysis, testing, coverage reporting, and packaging. Use after matlab-create-project when the project structure is in place and you need repeatable build automation.
SKILL.md
| 1 | # matlab-create-buildfile — Build Plan Generator |
| 2 | |
| 3 | You generate a `buildfile.m` that defines the repeatable build/test/package pipeline using MATLAB's `matlab.buildtool` framework. |
| 4 | |
| 5 | ## When to Use |
| 6 | |
| 7 | - After `matlab-create-project` has set up the project structure |
| 8 | - User says "set up the build" or "create a buildfile" |
| 9 | - Project has code and tests but no build automation |
| 10 | |
| 11 | ## When NOT to Use |
| 12 | |
| 13 | - A `buildfile.m` already exists and works — use `matlab-build-toolbox` to execute it |
| 14 | - User wants to run the build, not create it — use `matlab-build-toolbox` |
| 15 | - No MATLAB project exists yet — use `matlab-create-project` first |
| 16 | |
| 17 | ## Inputs |
| 18 | |
| 19 | - **project_root**: Path to the project (default: current directory) |
| 20 | - **coverage_threshold** (optional): Line-coverage percentage to warn below (default: 80) |
| 21 | - **warning_threshold** (optional): Max warnings before check fails (default: 0 = strict) |
| 22 | |
| 23 | ## Workflow |
| 24 | |
| 25 | ### Step 1 — Assess What Exists |
| 26 | |
| 27 | Scan the project for: |
| 28 | - Source folder — one of (in priority order): |
| 29 | 1. `toolbox/` — the standard toolbox-design-guidelines layout (everything that ships) |
| 30 | 2. `+packagename/` — namespace-package layout (from matlab-create-project) |
| 31 | 3. `source/` or `src/` — generic source folder |
| 32 | - `tests/` — test files to run |
| 33 | - MEX source files — C/C++/Fortran files (`.c`, `.cpp`, `.cxx`, `.F`, `.f90`) in folders like `mex/`, `src/mex/`, `c_src/`, or at the project root. Presence indicates the project needs a `MexTask`. |
| 34 | - `toolboxPackaging.prj` — packaging configuration (produced by Toolbox Packaging Tool) |
| 35 | - Existing `buildfile.m` — update rather than replace |
| 36 | - `buildUtilities/toolboxSpecification.m` — interface spec (for context on what the toolbox exposes) |
| 37 | |
| 38 | Record the detected structure — the generated buildfile must reference actual paths. |
| 39 | |
| 40 | ### Step 2 — Generate `buildfile.m` |
| 41 | |
| 42 | Use built-in task types (`CodeIssuesTask`, `CleanTask`, `TestTask`, `MexTask`) where they exist, and custom function-based tasks only where built-in tasks lack needed behavior (coverage reporting, packaging). |
| 43 | |
| 44 | **Task strategy:** |
| 45 | - **`clean`** — built-in `CleanTask` |
| 46 | - **`check`** — built-in `CodeIssuesTask` (SARIF output, threshold enforcement) |
| 47 | - **`mex`** — built-in `MexTask` (only if MEX source files detected in Step 1). Use `MexTask.forEachFile` when multiple MEX sources exist. Output folder is `toolbox/` (or source folder) so MEX files ship with the toolbox. |
| 48 | - **`test`** — built-in `TestTask` with `.addCodeCoverage()`. Produces JUnit XML test results AND a `.mat` coverage file for programmatic inspection by the coverage task. The built-in task supports incremental builds — it skips when source/tests are unchanged. |
| 49 | - **`coverage`** — custom function-based task that loads the `.mat` coverage results from the test task, logs per-file coverage, and warns if below the threshold. It does NOT fail the build — coverage is advisory, not a gate. |
| 50 | - **`package`** — custom function-based task (no built-in equivalent for toolbox packaging). |
| 51 | |
| 52 | **Include comments in the generated buildfile** that explain design choices — particularly why a task is custom vs. built-in, what tradeoffs that creates, and how the user could switch approaches. |
| 53 | |
| 54 | Use `scripts/buildfile-template.m` as the base template. Apply these adaptation rules: |
| 55 | - Replace `"toolbox"` with the actual source folder detected in Step 1 |
| 56 | - Replace `"tests"` if tests live elsewhere |
| 57 | - Replace `0.80` with the user's coverage threshold (as a decimal) |
| 58 | - Replace `0` in `WarningThreshold` with the user's warning threshold |
| 59 | - If MEX source files were detected, add a `MexTask` with appropriate source paths and output folder. Set `plan("test").Dependencies` to include `"mex"` so tests run after MEX compilation. |
| 60 | - If no MEX source files exist, omit the `mex` task entirely (don't generate dead code). |
| 61 | - If no `toolboxPackaging.prj` exists, use the programmatic variant from `references/buildfile-variants.md` |
| 62 | - Set `plan("package").Outputs` to match the actual output path |
| 63 | |
| 64 | ### Step 3 — Present the Plan |
| 65 | |
| 66 | ``` |
| 67 | ## Build Plan — [Toolbox Name] |
| 68 | |
| 69 | | Task | Type | Description | Dependencies | Fail condition | |
| 70 | |------|------|-------------|--------------|----------------| |
| 71 | | clean | CleanTask | Remove derived artifacts | — | — | |
| 72 | | check | CodeIssuesTask | Static analysis (SARIF output) | — | Any error; any warning (strict) | |
| 73 | | mex | MexTask | Compile MEX files (if detected) | — | MEX compilation fails | |
| 74 | | test | TestTask | Run tests + produce coverage | check, mex (if present) | Any test failure | |
| 75 | | coverage | Custom | Report coverage, warn if below threshold | test | — (advisory only) | |
| 76 | | package | Custom | Build .mltbx from toolboxPackaging.prj | coverage | Package file not pro |
People who liked this also viewed
6 picksType
- hyperframes-cliUse the HyperFrames CLI development loop: init, add, catalog, capture, lint, check, snapshot, compare, grade-compare, preview, play, present, beats, keyframes, single or batch render, publish, cloud, SkillsJul 2026
- request-refactor-planSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- analyze-projectRigor Analyze / Rigor Audit read-only skill for deep learning research repositories. Use when the user wants to read and understand a repository, inspect model structure and training or inference entrSkillsMay 2026
- explore-codeRigor Improve implementation leaf skill for auditable candidate implementation in deep learning research repositories. Use when the researcher explicitly authorizes exploratory work on an isolated braSkillsMay 2026
- ubiquitous-languageSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- scaffold-exercisesSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
