matlab-define-toolbox-api

Name: matlab-define-toolbox-api
Author: matlab

815stars105forks

How to install matlab-define-toolbox-api?

matlab/matlab-agentic-toolkit/matlab-define-toolbox-api

$npx -y skills add matlab/matlab-agentic-toolkit --skill matlab-define-toolbox-api

Installs into the current project.

Summary

Scan a folder, triage files into include/exclude, identify the public API, and produce a toolboxSpecification.m Interface Spec — all in one pass. Use when turning loose code into a toolbox.

Files · 1

View on GitHub

SKILL.md

1	# matlab-define-toolbox-api — Toolbox Scope & Spec Generator
2
3	You take a folder of code, figure out what belongs in the toolbox, identify the public API, and produce the Interface Spec — the contract defining what the toolbox exposes. One skill, one artifact.
4
5	## When to Use
6
7	- User wants to turn code into a toolbox
8	- User points at a folder and says "make this a toolbox" or "package this"
9	- User has a mix of scripts, functions, tests, data, and scratch files
10	- Starting the files-to-package pipeline from scratch
11
12	## When NOT to Use
13
14	- Adding files to an existing spec — edit `buildUtilities/toolboxSpecification.m` directly
15	- Analyzing dependencies — use `matlab-analyze-dependencies` after the spec is approved
16	- Building the .mltbx package — use `matlab-build-toolbox`
17	- Documenting the toolbox — use `matlab-document-toolbox`
18
19	## Key Functions
20
21	\| Function \| Purpose \|
22	\|----------\|---------\|
23	\| `dir` \| Recursive file listing for inventory \|
24	\| `which` \| Resolve function locations on path \|
25	\| `exist` \| Check whether a name resolves to a file, folder, or built-in \|
26	\| `matlab.codetools.requiredFilesAndProducts` \| Trace caller/callee relationships for Support classification \|
27
28	## Inputs
29
30	\| Input \| Required \| Description \|
31	\|-------\|----------\|-------------\|
32	\| path \| No \| Folder or list of files to analyze. If not provided, prompt the user. \|
33	\| purpose \| No \| What the toolbox does and who uses it. If not provided, prompt the user. \|
34
35	## Workflow
36
37	### Step 1 — Gather Inputs
38
39	If path is not provided:
40	> What folder or files would you like to package as a toolbox?
41
42	If purpose is not provided:
43	> In a sentence or two, what does this toolbox do? Who will use it?
44
45	Do not proceed until both are provided.
46
47	### Step 2 — Inventory the Folder
48
49	Scan the path recursively. Classify every file:
50
51	\| Category \| Detection Rule \|
52	\|----------\|---------------\|
53	\| Function \| `.m` file with `function` keyword on first non-comment line \|
54	\| Class \| `.m` file with `classdef` keyword \|
55	\| Script \| `.m` file with no `function`/`classdef` keyword \|
56	\| Live Script \| `.mlx` file \|
57	\| Test \| In `tests/`/`test/` folder, or name matches `Test.m`, `_test.m`, `test_*.m` \|
58	\| Data \| `.mat`, `.csv`, `.xlsx`, `.json`, `.xml` (non-config) \|
59	\| Config/Meta \| `buildfile.m`, `projectStartup.m`, `Contents.m`, `.prj`, `resources/` \|
60	\| Scratch/Temp \| In `scratch/`, `tmp/`, or names like `untitled.m`, `Copy_of_` \|
61	\| Other \| READMEs, images, licenses, etc. \|
62
63	### Step 3 — Classify Relevance
64
65	Using the purpose as guide, classify each file:
66
67	- Include — directly serves the toolbox's stated purpose
68	- Support — needed by included files (helper/utility called internally)
69	- Exclude — not relevant (tests, scratch, unrelated code)
70	- Uncertain — needs user input
71
72	Heuristics:
73
74	\| Signal \| Disposition \|
75	\|--------\|-------------\|
76	\| Function name aligns with purpose keywords \| Include \|
77	\| H1 text mentions concepts from purpose \| Include \|
78	\| Called by an included file \| Support \|
79	\| In `private/` or `+internal` folder \| Support \|
80	\| Test file for an included function \| Exclude \|
81	\| Script with no connection to purpose \| Exclude \|
82	\| Data file referenced by included code \| Include \|
83	\| Scratch/temp naming pattern \| Exclude \|
84
85	### Step 4 — Identify Public API
86
87	From the Include set, determine visibility:
88
89	\| Signal \| Classification \|
90	\|--------\|---------------\|
91	\| Has H1 help text \| Likely public \|
92	\| Has `arguments` block or input validation \| Likely public \|
93	\| Descriptive action-oriented name \| Likely public \|
94	\| Classdef with public methods \| Public \|
95	\| Called by others but not standalone \| Internal \|
96	\| In `private/` or generic utility name \| Internal \|
97	\| Script \| Example/entry point \|
98
99	### Step 5 — Present Report & Get Confirmation
100
101	Display a combined scope + API report:
102
103	```
104	## Toolbox Scope & API — [Name]
105
106	Purpose: [user's stated purpose]
107	Source: [path]
108	Total files: N
109
110	### Public API (N functions)
111	\| Function \| Signature \| H1 \| Category \|
112	\|----------\|-----------\|-----\|----------\|
113
114	### Internal Support (N files)
115	\| File \| Type \| Reason \|
116	\|------\|------\|--------\|
117
118	### Excluded (N files)
119	\| File \| Reason \|
120	\|------\|--------\|
121
122	### Uncertain — Need Your Input
123	\| File \| Why Uncertain \|
124	\|------\|--------------\|
125	```
126
127	Then ask:
128	> Please review:
129	> 1. Should any excluded files be included?
130	> 2. Should any included files be removed?
131	> 3. For uncertain files — include or exclude?
132	> 4. Is the public API surface correct?
133	> 5. What categories should functions be grouped into? (e.g., "Analysis", "I/O", "Visualization")
134
135	Incorporate feedback before proceeding.
136
137	### Step 6 — Generate Interface Spec
138
139	Produce `t

People who liked this also viewed

6 picks

Type

matlab-define-toolbox-api

815stars105forks

View on GitHub

How to install matlab-define-toolbox-api?

matlab/matlab-agentic-toolkit/matlab-define-toolbox-api

$npx -y skills add matlab/matlab-agentic-toolkit --skill matlab-define-toolbox-api

Installs into the current project.

Summary

Scan a folder, triage files into include/exclude, identify the public API, and produce a toolboxSpecification.m Interface Spec — all in one pass. Use when turning loose code into a toolbox.

Files · 1

View on GitHub

SKILL.md

1	# matlab-define-toolbox-api — Toolbox Scope & Spec Generator
2
3	You take a folder of code, figure out what belongs in the toolbox, identify the public API, and produce the Interface Spec — the contract defining what the toolbox exposes. One skill, one artifact.
4
5	## When to Use
6
7	- User wants to turn code into a toolbox
8	- User points at a folder and says "make this a toolbox" or "package this"
9	- User has a mix of scripts, functions, tests, data, and scratch files
10	- Starting the files-to-package pipeline from scratch
11
12	## When NOT to Use
13
14	- Adding files to an existing spec — edit `buildUtilities/toolboxSpecification.m` directly
15	- Analyzing dependencies — use `matlab-analyze-dependencies` after the spec is approved
16	- Building the .mltbx package — use `matlab-build-toolbox`
17	- Documenting the toolbox — use `matlab-document-toolbox`
18
19	## Key Functions
20
21	\| Function \| Purpose \|
22	\|----------\|---------\|
23	\| `dir` \| Recursive file listing for inventory \|
24	\| `which` \| Resolve function locations on path \|
25	\| `exist` \| Check whether a name resolves to a file, folder, or built-in \|
26	\| `matlab.codetools.requiredFilesAndProducts` \| Trace caller/callee relationships for Support classification \|
27
28	## Inputs
29
30	\| Input \| Required \| Description \|
31	\|-------\|----------\|-------------\|
32	\| path \| No \| Folder or list of files to analyze. If not provided, prompt the user. \|
33	\| purpose \| No \| What the toolbox does and who uses it. If not provided, prompt the user. \|
34
35	## Workflow
36
37	### Step 1 — Gather Inputs
38
39	If path is not provided:
40	> What folder or files would you like to package as a toolbox?
41
42	If purpose is not provided:
43	> In a sentence or two, what does this toolbox do? Who will use it?
44
45	Do not proceed until both are provided.
46
47	### Step 2 — Inventory the Folder
48
49	Scan the path recursively. Classify every file:
50
51	\| Category \| Detection Rule \|
52	\|----------\|---------------\|
53	\| Function \| `.m` file with `function` keyword on first non-comment line \|
54	\| Class \| `.m` file with `classdef` keyword \|
55	\| Script \| `.m` file with no `function`/`classdef` keyword \|
56	\| Live Script \| `.mlx` file \|
57	\| Test \| In `tests/`/`test/` folder, or name matches `Test.m`, `_test.m`, `test_*.m` \|
58	\| Data \| `.mat`, `.csv`, `.xlsx`, `.json`, `.xml` (non-config) \|
59	\| Config/Meta \| `buildfile.m`, `projectStartup.m`, `Contents.m`, `.prj`, `resources/` \|
60	\| Scratch/Temp \| In `scratch/`, `tmp/`, or names like `untitled.m`, `Copy_of_` \|
61	\| Other \| READMEs, images, licenses, etc. \|
62
63	### Step 3 — Classify Relevance
64
65	Using the purpose as guide, classify each file:
66
67	- Include — directly serves the toolbox's stated purpose
68	- Support — needed by included files (helper/utility called internally)
69	- Exclude — not relevant (tests, scratch, unrelated code)
70	- Uncertain — needs user input
71
72	Heuristics:
73
74	\| Signal \| Disposition \|
75	\|--------\|-------------\|
76	\| Function name aligns with purpose keywords \| Include \|
77	\| H1 text mentions concepts from purpose \| Include \|
78	\| Called by an included file \| Support \|
79	\| In `private/` or `+internal` folder \| Support \|
80	\| Test file for an included function \| Exclude \|
81	\| Script with no connection to purpose \| Exclude \|
82	\| Data file referenced by included code \| Include \|
83	\| Scratch/temp naming pattern \| Exclude \|
84
85	### Step 4 — Identify Public API
86
87	From the Include set, determine visibility:
88
89	\| Signal \| Classification \|
90	\|--------\|---------------\|
91	\| Has H1 help text \| Likely public \|
92	\| Has `arguments` block or input validation \| Likely public \|
93	\| Descriptive action-oriented name \| Likely public \|
94	\| Classdef with public methods \| Public \|
95	\| Called by others but not standalone \| Internal \|
96	\| In `private/` or generic utility name \| Internal \|
97	\| Script \| Example/entry point \|
98
99	### Step 5 — Present Report & Get Confirmation
100
101	Display a combined scope + API report:
102
103	```
104	## Toolbox Scope & API — [Name]
105
106	Purpose: [user's stated purpose]
107	Source: [path]
108	Total files: N
109
110	### Public API (N functions)
111	\| Function \| Signature \| H1 \| Category \|
112	\|----------\|-----------\|-----\|----------\|
113
114	### Internal Support (N files)
115	\| File \| Type \| Reason \|
116	\|------\|------\|--------\|
117
118	### Excluded (N files)
119	\| File \| Reason \|
120	\|------\|--------\|
121
122	### Uncertain — Need Your Input
123	\| File \| Why Uncertain \|
124	\|------\|--------------\|
125	```
126
127	Then ask:
128	> Please review:
129	> 1. Should any excluded files be included?
130	> 2. Should any included files be removed?
131	> 3. For uncertain files — include or exclude?
132	> 4. Is the public API surface correct?
133	> 5. What categories should functions be grouped into? (e.g., "Analysis", "I/O", "Visualization")
134
135	Incorporate feedback before proceeding.
136
137	### Step 6 — Generate Interface Spec
138
139	Produce `t

People who liked this also viewed

6 picks

Type