Analyze a toolbox folder and generate a toolbox.ignore file — detects files that should not ship to end users based on what actually exists in the folder. Only suggests patterns for files found. Advisory: presents suggestions with reasons before writing.
npx skills add https://github.com/matlab/matlab-agentic-toolkit --skill matlab-exclude-files
You analyze a MATLAB toolbox folder and suggest which files should be excluded from packaging. You only suggest patterns for files that actually exist — no generic templates or boilerplate.
matlab-build-toolbox when no ignore file existsmatlab-assess-toolbox flags packaging concerns (check 16)matlab-define-toolbox-apitoolbox.ignore already fully covers the project — this skill reports "no additional exclusions"toolbox/ or current directory)toolbox.ignore or package.ignore already exists, only suggest additions not already covered..git/, .svn/, .buildtool/, *.asv, resources/project/, *.prj. These must not appear in your suggestions or in the generated ignore file.Only suggest these if the matching files are found in the scan:
| Pattern | Why exclude | Impact |
|---------|------------|--------|
| *.DS_Store | OS metadata, not useful to users | HIGH |
| Thumbs.db | Windows thumbnail cache | HIGH |
| .vscode/ | VS Code settings | HIGH |
| .idea/ | JetBrains IDE settings | HIGH |
| *.log | Log files from dev/test runs | HIGH |
| *.orig | Merge conflict leftovers | HIGH |
| slprj/ | Simulink project cache | HIGH |
| codegen/ | MATLAB Coder generated output | HIGH |
| *.mltbx | Previously built packages | HIGH |
| tmp/, temp/ | Scratch directories | HIGH |
| tests/, test/ | Test files (if inside toolbox folder) | MEDIUM |
| buildUtilities/ | Build scripts | MEDIUM |
| buildfile.m | Build automation (if inside toolbox folder) | MEDIUM |
| *.cpp, *.c, *.h | MEX source (when compiled .mex* binaries exist) | MEDIUM |
| doc/internal/ | Internal documentation not for end users | MEDIUM |
| CHANGELOG.md, CONTRIBUTING.md | Developer-facing docs | MEDIUM |
| *.mat in test directories | Test fixtures | MEDIUM |
| .m files with matching .p | Source alongside pcode — excluding protects IP but removes help access unless pcode was generated with help preservation | MEDIUM |
Glob the toolbox folder recursively. Collect all file paths and folder names.
Look for toolbox.ignore or package.ignore in the folder. If one exists, read it and note which patterns are already covered.
For each file found in the scan, check if it matches a known ignorable pattern from the table above. Only report matches for files that actually exist. For pcode pairs, check if a .p file has a corresponding .m file with the same name in the same directory.
Exclude from results:
.git/, .svn/, .buildtool/, *.asv, resources/project/, *.prj)Only show new suggestions — files that exist, are not already excluded, and should be. Do not list what's already handled or what wasn't found. Do not show internal reasoning, verification notes, or commentary about the detection process. Group suggestions under named category headings:
## Ignore Suggestions — [Toolbox Name]
### OS / IDE Metadata
| # | Pattern | Found | Reason |
|---|---------|-------|--------|
| 1 | *.DS_Store | 3 files | OS metadata not useful to end users |
| 2 | .vscode/ | 1 folder | IDE settings |
### Test Infrastructure
| # | Pattern | Found | Reason |
|---|---------|-------|--------|
| 3 | tests/ | 12 files | Test files inside toolbox folder |
### Source Protection
| # | Pattern | Found | Reason |
|---|---------|-------|--------|
| 4 | myFunc.m | paired with myFunc.p | Source alongside pcode — excluding protects IP but removes help text access |
If no new suggestions are found, simply state: "No additional exclusions to recommend."
For pcode suggestions, include this note:
> Excluding .m files that have matching .p files protects source code from distribution. However, help functionName will not work for end users unless the pcode was generated with help preservation (pcode -inplace from an .m containing the help block).
Prompt: which suggestions to include?
> A) All — include everything suggested
> B) All HIGH — only HIGH-impact items
> C) Select — pick specific numbers (e.g., "1, 2, 4")
> D) Skip — do not create/modify the ignore file
Create or append to toolbox.ignore with selected patterns, grouped by category using MATLAB-style comments (%).
Note: In MATLAB R2025a+, toolbox.ignore triggers a deprecation warning. If the user prefers, offer to name the file package.ignore instead.
Example output:
% toolbox.ignore
% Files excluded from toolbox packaging
% OS metadata
*.DS_Store
% IDE settings
.vscode/
% Test files (not distributed to end users)
tests/
% Source excluded (distributed as pcode)
myFunc.m
Yes — always present suggestions and wait for user selection before writing anything.
% for comments (MATLAB convention)----
Copyright 2026 The MathWorks, Inc.
----
Guide users through a structured workflow for co-authoring documentation. Use when user wants to write documentation, proposals, technical specs, decision docs, or similar structured content. This workflow helps users efficiently transfer context, refine content through iteration, and verify the doc works for readers. Trigger when user mentions writing docs, creating proposals, drafting specs, or similar documentation tasks.
Structured manuscript/grant review with checklist-based evaluation. Use when writing formal peer reviews with specific criteria methodology assessment, statistical validity, reporting standards compliance (CONSORT/STROBE), and constructive feedback. Best for actual review writing, manuscript revision. For evaluating claims/evidence quality use scientific-critical-thinking; for quantitative scoring frameworks use scholar-evaluation.
Agile product ownership toolkit for Senior Product Owner including INVEST-compliant user story generation, sprint planning, backlog management, and velocity tracking. Use for story writing, sprint planning, stakeholder communication, and agile ceremonies.
Expert guidance for writing secure, reliable, and performant Claude Code hooks - validates design decisions, enforces best practices, and prevents common pitfalls. Use when creating, reviewing, or debugging Claude Code hooks.
Use when creating or developing anything, before writing code or implementation plans - refines rough ideas into fully-formed designs through structured Socratic questioning, alternative exploration, and incremental validation
Structured manuscript/grant review with checklist-based evaluation. Use when writing formal peer reviews with specific criteria methodology assessment, statistical validity, reporting standards compliance (CONSORT/STROBE), and constructive feedback. Best for actual review writing, manuscript revision. For evaluating claims/evidence quality use scientific-critical-thinking; for quantitative scoring frameworks use scholar-evaluation.
Conducts structured requirements workshops to produce feature specifications, user stories, EARS-format functional requirements, acceptance criteria, and implementation checklists. Use when defining new features, gathering requirements, or writing specifications. Invoke for feature definition, requirements gathering, user stories, EARS format specs, PRDs, acceptance criteria, or requirement matrices.
Use markdown formatting when drafting content intended for external systems (GitHub issues/PRs, Jira tickets, wiki pages, design docs, etc.) so formatting is preserved when the user copies it. Load this skill before producing any draft the user will paste elsewhere.
Take matlab/matlab-exclude-files from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.