Check Authoring

Create custom Model Advisor checks that use modern DetailStyle callbacks and ResultDetail reporting. This skill prevents common authoring mistakes: using deprecated StyleOne/StyleTwo patterns, incorrect registration, missing result formatting, and wrong callback contexts.

When to Use

• Creating a new Model Advisor check (standard, edit-time, or config-parameter)
• Adding an edit-time canvas warning for a naming or style rule
• Validating configuration parameters programmatically with auto-fix
• Enforcing a modeling convention with auto-fix actions
• Checking System Composer architecture models (components, ports, connectors, interfaces, stereotypes)

When NOT to Use

• Running or debugging existing checks — use Model Advisor UI
• Writing Simulink Test test cases
• Querying model structure without creating a check — use model_query_params
• Modifying Model Advisor configuration or preferences

Workflow

1. Determine check pattern — Choose the check type based on user intent (see Step 1 below)
2. Determine API pattern — Identify which model elements the check inspects (see Step 2 below)
3. Read reference files — Load the selected pattern and API reference files from references/
4. Present plan to user — State chosen pattern, API(s), check ID, and file names. If the pattern choice is obvious from the prompt, proceed without waiting.
5. Write check definition — Generate the .m file(s) following the Code Generation section below
6. Write registration — Create or append to sl_customization.m
7. Validate — Run check_matlab_code on each generated .m file
8. Report — Show output file locations, placement instructions, and test command

This skill covers check authoring only. To run checks on a model, use the checking-model-compliance skill.

Step 1: Choose the Check Pattern

FormatTemplate is an add-on, not standalone.

Step 2: Choose the API Pattern(s) for Check Logic

All check types can also use references/api-framework.md — consult for input parameters, auto-fix actions, exclusion filtering, and result formatting.

• Config parameter checks use get_param(system, paramName) — refer to the config parameter pattern and framework API.
• System Composer checks must use 'None' callback context (architecture models do not compile).
• A single check can combine multiple API patterns (e.g., blocks + signals).

Conventions

• Always: Use 'DetailStyle' callback style — legacy styles cannot use ResultDetail reporting
• Always: Include sl_customization.m registration — checks are invisible without it
• Always: Use ModelAdvisor.ResultDetail for reporting — only API that populates results pane correctly
• Always: Use ModelAdvisor.Check(id) constructor — never use ModelAdvisor.Registration
• Never: Use 'StyleOne'/'StyleTwo'/'StyleThree' — deprecated and incompatible with ResultDetail
• Never: Generate checks without test instructions — untestable checks waste user time
• Ask First: Choose edit-time vs. standard when ambiguous — wrong choice requires a full rewrite
• Ask First: Choose package name for edit-time classes — affects namespace, hard to rename later

Code Generation

Naming

• Check ID: reverse-domain style, e.g. com.company.checkarea.checkname
• Check definition function: define<CheckName>.m
• Edit-time class: PascalCase, e.g. SignalLabels.m, placed in +PackageName/

Files to Generate

• Always: check definition file (.m)
• Always: sl_customization.m — create new or append to existing (only one per folder)
• Edit-time checks: both registration function and class file in +PackageName/
• Standard checks with auto-fix: include ModelAdvisor.Action setup and action callback

Verification

After generating all files:

1. Run check_matlab_code on each .m file — zero warnings required
2. Report file locations, placement instructions (must be on MATLAB path), and test command: Advisor.Manager.refresh_customizations

Test model creation and functional testing are out of scope for this skill (handled separately). Static analysis via check_matlab_code is the default verification step.

Review Gate

After generating check code, verify:

• [ ] Callback uses 'DetailStyle' (not 'StyleOne'/'StyleTwo'/'StyleThree')
• [ ] Context is correct: 'None' for structural checks, 'PostCompile' for compiled properties
• [ ] Pass case sets ViolationType = 'Passed' with a status message
• [ ] Violations use correct setData type: 'SID' for blocks, 'Signal' for lines
• [ ] sl_customization.m registers the check with correct function handle
• [ ] For edit-time: finishedTraversal is implemented, execution is lightweight
• [ ] For System Composer: uses 'None' context, reports component SID (not port/connector)
• [ ] No checkcode warnings in generated files

----

Copyright 2026 The MathWorks, Inc.

----