justify-findings

name	justify-findings
description	Adds Polyspace justification annotations to C/C++ source code. Use when the user asks to "justify this finding", "add a Polyspace annotation", "mark as false positive", "suppress finding", or wants to add justification comments to Polyspace findings.
license	MathWorks BSD-3-Clause
metadata	{"version":"1.0"}

How to Justify Polyspace Findings

Use Polyspace annotation comments to justify findings that are false positives, intentional behavior, or prevented by external constraints (hardware, protocol, caller validation).

This skill uses source code comments only. Do not offer alternative methods (XML files, external config files, etc.). The annotation is always a comment inserted directly in the source code, either on the finding line or as a block around the finding lines.

Annotation syntax

Line mode (default)

Insert at the end of the finding line:

code_on_finding_line; /* polyspace FAMILY:ACRONYM [Status] "justification text" */

Block mode

Insert around the finding lines:

/* polyspace-begin FAMILY:ACRONYM [Status] "justification text" */
code_on_finding_lines;
/* polyspace-end FAMILY:ACRONYM */

FAMILY:ACRONYM format

Both FAMILY and ACRONYM must match the exact values from the analysis results. Examples:

• Defect:INT_ZERO_DIV — Bug Finder defect
• MISRA-C3:8.4 — MISRA C 2012 rule (family MISRA-C3)
• MISRA-C-2023:8.4 — MISRA C 2023 rule (family MISRA-C-2023)
• CERT-C:DCL00-C — CERT C rule
• CWE:119 — CWE weakness

Do not guess family names — for example, MISRA C 2012 uses family MISRA-C3 and MISRA C 2023 uses family MISRA-C-2023.

Status values

• Justified (default)
• Not a defect
• No action planned

Severity (optional)

Append severity after the status with a colon:

/* polyspace FAMILY:ACRONYM [Justified:High] "justification text" */

Values: High, Medium, Low.

Justification text guidelines

A good justification explains why the deviation is acceptable. Include:

• The reason for the deviation (e.g., hardware access, portability, performance, adopted code that cannot be modified, code quality, project convention)
• Specific details — reference the relevant function, variable, constraint, or platform

Keep it concise (under 20 words), no trailing period. Examples:

• "Hardware register read requires cast to uint32_t"
• "Vendor-supplied HAL library cannot be modified"
• "Inline assembly required for cycle-critical ISR"
• "int is 32-bit on all target platforms for this project"
• "Helper macro reduces repetition across 12 call sites"
• "Denominator checked non-zero by caller validate_input()"

User confirmation

Always ask the user for confirmation before inserting the annotation. Present:

1. The finding (family, acronym, message, location)
2. Your proposed justification text
3. The exact annotation you plan to insert

Wait for explicit approval before editing the file.

Pre-approved justification catalog

If the project has a justification catalog JSON file:

If the Polyspace MCP Server is available, use the query_justification_catalog tool with the findings and catalog_file_path arguments to get pre-approved justification texts.

Otherwise, invoke the query-justification-catalog skill, or if skills are not available, read query-justification-catalog/SKILL.md in this skill's parent folder for the catalog JSON schema and how to query it directly.

If no catalog file is provided and the project has IDE markers (.vscode/, .project, .vs/), the user may have a justification catalog configured in the IDE extension settings — ask them.

Next analysis

On the next Polyspace analysis run, the annotation is recognized and the finding is marked as justified.

---

Copyright 2026 The MathWorks, Inc.

---