simulink-explain-missing-coverage
Use this skill when the user asks to summarize, or asks why Simulink Coverage objectives are missing, unsatisfied, or uncovered on a coverage result they already have — why specific decision, condition, MCDC, relational-boundary, or saturation/overflow outcomes weren't exercised, whether uncovered l…
Install / Use
npx skills add matlab/simulink-agentic-toolkit --skill simulink-explain-missing-coverageInstalls into whichever agent you are using.
SKILL.md
Installable skill definition
Quality Score
Category
MarketingSupported Platforms
Our assessment of simulink-explain-missing-coverage
simulink-explain-missing-coverage scores 91/100 on our quality scale, 185th of 629 Marketing skills we index (top 30%).
Its SKILL.md is 12 KB long, well organised into 14 sections with 2 code examples: a thorough specification that gives an agent plenty to work with.
With 1,148 GitHub stars, it is one of the more widely adopted skills in the catalogue.
Maintenance, license and trust
- The repository was last updated 16 days ago, so simulink-explain-missing-coverage is actively maintained.
- No license is declared. By default that means all rights are reserved: you can read it, but reusing or redistributing it is not clearly permitted. Ask the author before building on it commercially.
- Its trust signals score 88/100, with 1 caution from licensing, adoption, age or documentation. These come from repository metadata, not a code audit — read the skill file before letting an agent act on it.
simulink-explain-missing-coverage compared with similar skills
All 4 of these similar skills score higher than simulink-explain-missing-coverage; compare them before choosing.
| Skill | Score | Stars | Updated | Format |
|---|---|---|---|---|
| simulink-explain-missing-coverage (this skill)by matlab | 91 | 1.1k | 16d ago | SKILL.md |
| algorithmic-artby anthropics | 100 | 177.9k | 11d ago | SKILL.md |
| pptxby anthropics | 100 | 177.9k | 11d ago | SKILL.md |
| designby nextlevelbuilder | 100 | 130.2k | 12d ago | SKILL.md |
| ui-ux-pro-maxby nextlevelbuilder | 100 | 130.2k | 12d ago | SKILL.md |
Frequently asked questions
- How do I install simulink-explain-missing-coverage?
- Run
npx skills add matlab/simulink-agentic-toolkit --skill simulink-explain-missing-coverage. The install tabs above show the steps for each supported agent. - Which AI agents does simulink-explain-missing-coverage work with?
- It is written for Universal, as a SKILL.md file. Other agents that read the same format can often use it too.
- Is simulink-explain-missing-coverage safe to use?
- It declares no license and scores 88/100 on trust signals. Skills are instructions an agent will follow, so read the file before installing it and do not approve commands you do not understand.
- Is simulink-explain-missing-coverage still maintained?
- The repository was last updated 16 days ago, so simulink-explain-missing-coverage is actively maintained.
Skill content
View source on GitHubname: simulink-explain-missing-coverage description: "Use this skill when the user asks to summarize, or asks why Simulink Coverage objectives are missing, unsatisfied, or uncovered on a coverage result they already have — why specific decision, condition, MCDC, relational-boundary, or saturation/overflow outcomes weren't exercised, whether uncovered logic is dead code, or how to close the gap (a test, a coverage filter, or a design change). It reads an existing cvdata, .cvt file, sim-with-coverage output, or Simulink Test result; it never runs cvsim to collect coverage." license: https://www.mathworks.com/content/dam/mathworks/license/pmrl/license.md metadata: author: MathWorks version: "0.1" toolbox_dependencies: - Simulink Coverage - Simulink Design Verifier - Simulink Check
Explaining Missing Simulink Coverage
Explain why coverage objectives are missing on a coverage result the user already
has, and what to do about each one — across all objective types (decision,
condition, MCDC, relational boundary, saturation/overflow, lookup-table execution).
Works from an existing cvdata / cvdatagroup, a .cvt file, a
Simulink.SimulationOutput with coverage on, or a Simulink Test result set.
It keeps two questions separate:
- Is this outcome reachable? — for decision/condition/MCDC objectives, answered by formal proof (SLDV dead-logic detection) joined to the coverage result deterministically. A provably-dead outcome is a fact.
- If reachable, why wasn't it tested — and if dead, was that intended? — answered by the agent, reasoning over an input trace (Model Slicer) plus model structure. This is judgment, always presented as a recommendation.
Requires: MATLAB R2023a+, Simulink Coverage, Simulink Design Verifier (dead-logic detection), Simulink Check / Model Slicer (input tracing). The skill never collects coverage — it reads a result that already exists. When SLDV or the Model Slicer is unavailable, the affected step degrades honestly (see Guardrails), never fabricating evidence.
When to Use
- User asks why an objective — of any metric — or a specific true/false outcome is missing, unsatisfied, or uncovered.
- User asks whether uncovered logic is dead code (unreachable) or just untested.
- User asks how to close a coverage gap on a result they already collected — what test to add, what to filter, or what to change.
- User needs audit-ready triage: provably-dead vs. still-to-test, each traced to its inputs.
- User points at an existing coverage artifact and asks to explain it.
When NOT to Use
- Collecting coverage / simulating to measure coverage → this skill reads a result, it does not collect one; tell the user to collect coverage first, then return here.
- Authoring or generating tests →
testing-simulink-models. This skill recommends a scenario in words; it does not build a harness or generate vectors. - Design-error detection / fixing runtime defects (divide-by-zero, overflow) →
resolve-design-errors. - Model compliance against a standard (MISRA, MAB, JMAAB) →
checking-model-compliance. - Requirement verification → not this skill (it only queries existing links, read-only).
Coverage Sources
All four sources resolve to the one object the analysis consumes — a cvdata /
cvdatagroup. resolveCoverageData normalizes them and makes no decisions; when a
source carries more than one unit, the agent asks which to explain.
| Source | Holds | Resolves via |
|---|---|---|
| cvsim result | cvdata / cvdatagroup | pass through |
| .cvt file | path | cvload (cell of cvdata) |
| sim w/ coverage | SimulationOutput | embedded cvdata var, else cvresults(model) (per-run + cumulative) |
| Simulink Test | ResultSet | getCoverageResults (cvdata object array) |
Rules the agent applies: multiple units → always ask which to explain (never merge or
pick silently); cvresults per-run vs. cumulative → cumulative by default, mention the
single-run view exists.
Prerequisites
All script functions live in the skill's scripts/ directory. Call them with
evaluate_matlab_code and project_path set to that folder. Never addpath,
restoredefaultpath, or savepath — altering the session path breaks the coverage tooling.
Use these functions; do not hand-roll resolution, extraction, the SLDV run, the join, or the trace. The Step-2 join in particular matches SLDV verdicts to outcomes on an exact key — the agent must never do that matching itself.
| Function | Inputs → Output | Role |
|---|---|---|
| resolveCoverageData(source) | source → {cvdata,model,kind,label}[] | Normalize sources to a list of units |
| getCoverageSummary(cvd) | one cvdata → covSummary | Rollups + outcome detail + filter/reduced info |
| detectDeadLogicObjectives(model, metrics) | model + metrics → [dead, status] | SLDV dead-logic (decision/condition/MCDC only) |
| markSldvDeadLogic(covSummary, dead) | covSummary + dead → covSummary | Deterministic join — stamp dead, record unmatched/contradictions |
| traceObjectiveInputs(model, blockPaths, maxDepth) | model + paths → [traces, status] | Slicer: controllable inputs + dependency chain |
The scripts return MATLAB structs. Their exact output contracts — field names, nesting,
what an absent field means — are documented in references/script-outputs.md; consume
the returns by that reference rather than probing fieldnames and guessing paths. Deeper
method detail lives in references (load on demand): SLDV recipe + join semantics in
references/dead-logic-analysis.md; classification + scenario composition in
references/explaining-and-resolving.md; filter authoring in
references/coverage-filter-api.md (load after filter approval, Step 3); read-only
requirement traceability in references/requirements-tracing.md (load when prioritizing
by requirement linkage, Step 3).
Workflow
Three steps. Step 1 is cheap and always safe; Steps 2–3 run the expensive engines and are gated — do not run them for a plain "summarize" request.
1. Summarize coverage → resolveCoverageData + getCoverageSummary
2. Locate missing objectives → collect uncovered outcomes; if any decision/condition/MCDC
are uncovered, detectDeadLogicObjectives + markSldvDeadLogic
3. Explain and resolve → traceObjectiveInputs on the owning blocks; agent explains
Step 1 — Summarize coverage
cands = resolveCoverageData(source). The source's model must be loaded first — if it isn't open or on the path,load_systemit (notaddpath). Ifnumel(cands) > 1, ask which unit(s) to explain. For asimyielding per-run and cumulative, default to cumulative and say so.covSummary = getCoverageSummary(cands(k).cvdata).- Render a summary: total satisfied / total, then a worst-first table of systems by
unsatisfied count (
kind == 'system'nodes — the model root and each subsystem/chart, not subsystems only; omit fully-covered ones). Name the enabled metrics.
Gate. Stop here unless the user asked why coverage is missing or how to improve it.
Step 2 — Locate missing objectives
- Collect the uncovered Tier-2 outcomes (
covered == false). If none, STOP — report full coverage on the enabled metrics. - Run SLDV only if at least one uncovered outcome is decision / condition / MCDC (the metrics SLDV dead-logic covers). Otherwise skip it and go to Step 3.
- If running it:
[dead, status] = detectDeadLogicObjectives(model, metrics); % dead-eligible metrics present covSummary = markSldvDeadLogic(covSummary, dead); % exact-key join; do NOT match by hand - Present the outcomes in their reachability states (detail in
references/dead-logic-analysis.md):- Provably dead — SLDV
ranand the join stampeddead == true(fact). - Reachable, stated cautiously — decision/condition/MCDC, SLDV
ran, not stamped dead: "SLDV found no dead logic here, so it needs a test." Not a completeness proof. - Deadness not established — SLDV
skipped_no_license/error, or a non-SLDV-analyzable metric (relational / saturation / lookup-table). State the reason.
- Provably dead — SLDV
Step 3 — Explain and resolve
Trace the owning blocks of the uncovered outcomes in one batch, then reason over the
evidence (full method in references/explaining-and-resolving.md):
[traces, status] = traceObjectiveInputs(model, blockPaths);
- Judge intent from the traced evidence — the controllable inputs and what each block in
the chain computes. A control pinned by a
Constant/configuration, or a defensive guard the trace shows can't be reached in this context (a range clamp, a divide-by-zero guard) → likely intentional (recommend a coverage filter, Justify mode —references/explaining-and-resolving.md,references/coverage-filter-api.md). A dead branch tracing to controllable inputs → likely unintentional (recommend a design review). When the trace leaves intent unclear, usemodel_read/model_overviewfor more context. - Compose a test scenario for testable outcomes: invert the required condition from the
chain (Switch
y = (u2 >= 5) ? …, false uncovered → driveu2 < 5), stated in the controllable inputs. Group outcomes sharing inputs — one test often closes several. - When a trace is
method == "unavailable", fall back tomodel_read/model_overviewon that block; never fabricate inputs or a chain. - When prioritizing which outcomes to test first — or whenever the user asks what to
address first — check requirement linkage (read-only,
references/requirements-tracing.md) if Requirements Toolbox is available: a linked + uncovered outcome is "untested but required" (cite the requirement ID) and outranks an unlinked one; an unlinked outcome is lower priority (a hint the logic may be unrequired — surface it, do not conclude it). If Requirements Toolbox is unavailable, say so and prioritize without it.
Writing a .cvf filter or editing the model is Ask First (Guardrails).
Guardrails
Always
- State the resolved unit (model, label, per-run vs. cumulative) and enabled metrics in the summary header.
- Report covSummary counts verbatim; the two coverage tiers agree by construction — do not recompute them.
- Separate fact from judgment in every finding ("SLDV proved this unreachable" vs. "this appears intentional because the control is a constant").
- Signal honestly when an engine did not run:
status == "skipped_no_license"/"error"and per-blockmethod == "unavailable"mean not performed — say so. - Group testable outcomes by shared inputs and note when one test closes several.
Ask First
- Which unit to explain, whenever the source resolves to more than one.
- Writing a coverage filter (
.cvf) — present the rule and rationale; write only on explicit approval, using the engineer's rationale (never fabricated). - Editing the model — present the change; apply only on explicit approval, never silently to the original.
Never
- Never declare an outcome "dead code, safe to filter" as fact. SLDV proves unreachability; whether dead logic is intentional and filterable is the engineer's audit call. Present evidence + a recommendation.
- Never index-match SLDV verdicts to outcomes by hand —
markSldvDeadLogicowns the join. - Never call a completed-SLDV "no dead logic" result a completeness proof — a timeout
(
status == -1) can hide deadness. - Never modify the MATLAB path (
addpath/restoredefaultpath/savepath).
Common Mistakes
| Mistake | Fix | |---|---| | Running SLDV / Slicer for a "summarize" request | Step 1 only; gate on wanting the why | | Running SLDV when no de
Truncated for display — read the full file on GitHub.
Related Skills
algorithmic-art
177.9kCreating algorithmic art using p5.js with seeded randomness and interactive parameter exploration. Use this when users request creating art using code, generative art, algorithmic art, flow fields, or particle systems.
pptx
177.9kUse this skill any time a .pptx or .potx file is involved in any way — as input, output, or both. This includes: creating slide decks, pitch decks, or presentations; reading, parsing, or extracting text from any .pptx or .potx file (even if the extracted content will be used elsewhere, like in an em…
design
130.2kComprehensive design skill: brand identity, design tokens, UI styling, logo generation (55 styles, Gemini, Atlas Cloud, or MuAPI AI), corporate identity program (50 deliverables, CIP mockups), HTML presentations (Chart.js), banner design (22 styles, social/ads/web/print), icon design (15 styles, SVG…
ui-ux-pro-max
130.2kUI/UX design intelligence for web, mobile, and desktop. This skill should be used when designing, building, reviewing, or fixing interfaces, including pages, components, design systems, accessibility, interaction, responsive layout, typography, color, charts, and stack-specific UI implementation.
Languages
Trust signals
From repository metadata: license, adoption, age and documentation. Not a code audit — see the Safety scan above for what the skill file itself contains.
