# Cpptest Fix All Violations

> Use when: fixing static analysis violations in C or C++ code reported by Parasoft C/C++test

- Skill: `parasoft/cpptest-fix-all-violations` (Agent Skill)
- Install (CLI): `npx skillmds@latest add parasoft/cpptest-fix-all-violations`
- Raw SKILL.md: https://api.skillmd.com/api/skills/parasoft/cpptest-fix-all-violations/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: parasoft (https://skillmd.com/u/parasoft)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/parasoft/cpptest-fix-all-violations

---


# 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:

```bash
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:
```bash
./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:
1. **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.
2. **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.
3. 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.