check-authoring

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

Determine check pattern — Choose the check type based on user intent (see Step 1 below)
Determine API pattern — Identify which model elements the check inspects (see Step 2 below)
Read reference files — Load the selected pattern and API reference files from references/
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.
Write check definition — Generate the .m file(s) following the Code Generation section below
Write registration — Create or append to sl_customization.m
Validate — Run check_matlab_code on each generated .m file
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

If the user mentions...	Use Pattern	Reference
On-demand check, batch check, or nothing specific	Standard check (Default)	`references/pattern-standard.md` — full template with DetailStyle callback and ResultDetail reporting
"edit-time", "live", "real-time", "canvas warning"	Edit-time check	`references/pattern-edittime.md` — EdittimeCheck class with blockDiscovered/finishedTraversal
Config parameters, solver settings, diagnostics, model settings	Config parameter check	`references/pattern-config-param.md` — get_param/set_param with auto-fix action
"custom table", "formatted report", "custom columns"	+ FormatTemplate	`references/pattern-format-template.md` — combine with standard or edit-time pattern for custom tables

FormatTemplate is an add-on, not standalone.

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

If the check inspects...	Reference
Blocks (properties, types, names, positions, masks)	`references/api-blocks.md` — find_system patterns and block property access
Signals (line names, labels, propagation, connections)	`references/api-signals.md` — line handle queries and signal tracing
Stateflow (charts, states, transitions, junctions, data)	`references/api-stateflow.md` — Stateflow.find and chart traversal
Data types, workspace, variables (resolution, data dictionary)	`references/api-data-resolution.md` — workspace variable resolution and storage class
MATLAB code analysis (checkcode, codeIssues, mtree)	`references/api-code-analysis.md` — static analysis of .m files
System Composer (components, ports, connectors, interfaces)	`references/api-system-composer.md` — architecture model queries

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:

Run check_matlab_code on each .m file — zero warnings required
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