parasoft C/C++test Fix All Violations Skill
This skill analyzes and fixes Parasoft C/C++test static analysis violations. Code changes can be optionally committed to the repository.
When to Use This Skill
Use this skill when:
- User wants to fix or repair static analysis violations in C or C++ code
Assets
This skill uses the following external resources and tools:
| Type | Name | Description | Failure Handling |
|---|---|---|---|
| Script | cpptest-analyze.sh |
Builds the project and runs Parasoft C/C++test analysis. This is the only way to run the analysis; using other commands or tools may lead to incorrect results. | Report error and exit |
| MCP Tool | get_violations_from_report_file |
Fetches violations from a Parasoft C/C++test report file. | Report error and exit |
| MCP Tool | get_rule_documentation |
Fetches rule documentation from Parasoft C/C++test. | Report warning and proceed |
Workflow
Overview of the workflow:
- Read configuration parameters
- Run analysis and collect violations
- Select rule to fix
- For selected rule:
- Get rule documentation
- Fix and verify violations
- Commit fixes (if applicable)
- Repeat workflow until all violations are fixed
Be sure to follow the workflow steps in order. Steps should be executed sequentially, without user intervention, until the final output is generated.
Step 1: Read Configuration Parameters
Read the following environment variables to configure the workflow:
echo $CPPTEST_COMMIT_FIXES
echo $CPPTEST_ITERATION_LIMIT
echo $CPPTEST_RULES_LIMIT
| Variable | Valid Values | Default | Description |
|---|---|---|---|
CPPTEST_COMMIT_FIXES |
true, 1 |
(not set) | If set to true or 1, commit fixes after each rule. Any other value is ignored. |
CPPTEST_ITERATION_LIMIT |
positive integer | 3 |
Maximum number of fix-and-verify attempts per rule before declaring it unfixable. If the value is not a positive integer, use the default of 3. |
CPPTEST_RULES_LIMIT |
positive integer | 20 |
Maximum number of rules to process before stopping the workflow. If the value is not a positive integer, use the default of 20. |
Store these values as commit_fixes (boolean), iteration_limit (integer), and rules_limit (integer) for use in later steps. The user's explicit request to commit (if any) also sets commit_fixes to true. The user's explicit request for an iteration limit (if any) overrides iteration_limit. The user's explicit request for a rules limit (if any) overrides rules_limit.
Step 2: Run Analysis and Collect Violations
Execute the following script in the root of the project:
./cpptest-analyze.sh
This is the only way of building the project and running the analysis - do not use any other commands or tools.
Use get_violations_from_report_file MCP tool to collect violations from reports/report.xml file generated by the analysis. Do not analyze the report file manually or use any other tools to get the violations, as this may lead to incorrect results and inefficient workflow.
If there are no violations reported, finish the workflow immediately.
Step 3: Prioritize Violations and Select Rule to Fix
From the collected violations, select one rule with the highest severity. Severity 1 is the highest, severity 5 is the lowest (1 > 2 > 3 > 4 > 5).
Step 4: Get Rule Documentation
Always use get_rule_documentation MCP tool to fetch documentation for the selected rule. This documentation may include the rule description, rationale, examples of compliant and non-compliant code, and guidance on how to fix violations of this rule.
Step 5: Fix and Verify Violations of the Selected Rule
Attempt to fix all violations of the selected rule in a loop. Each attempt consists of:
- Apply fixes — analyze the violation messages, code, and rule documentation, then make the smallest changes possible to resolve the violations. Do not fix violations of other rules.
- Verify — re-run the analysis and re-collect violations (Step 2). If the violations for the selected rule are gone, the rule is fixed — exit the loop.
- If violations remain, analyze the output and try again.
Repeat until the violations for the selected rule are fixed, or the number of attempts reaches iteration_limit (from Step 1). If the limit is reached, declare the rule unfixable and skip it.
Step 6: Commit All Fixes for the Selected Rule (Conditional)
This step should only be performed if the violations were fixed and verified AND if commit_fixes (from Step 1) is true. If commit_fixes is false, skip this step and report to the output that the commit was skipped for the current rule.
IMPORTANT: Commit after fixing each rule. Do not accumulate fixes from multiple rules into a single commit!
Commit changes to the repository using git commit command. Be sure to follow the commit message guidelines below to ensure consistency and clarity in the commit history. Do not use any other committer e-mail, name, or commit message format, as this may lead to confusion and inefficient workflow:
- Always use 'autofix@demo' as committer e-mail.
- Always use 'Autofix' as committer name.
- Use verbose commit message - list all changes explicitly.
- The first line of the commit message must be exactly "Autofix RULE-IDENTIFIER" (e.g., "Autofix MISRA-123"), followed by a blank line.
- Separate distinct logical paragraphs with a single blank line. Do not insert blank lines between individual sentences or wrapped lines within the same paragraph.
Step 7: Repeat for Next Rule
Repeat steps 3-6 until all violations are fixed or skipped (as defined in Step 5), or until the number of processed rules reaches rules_limit (from Step 1). If the limit is reached, stop the workflow and report that the rules limit was reached.