reference.md
# Review Check Reference
## MCP Tools
### get_all_review_issues (preferred)
Retrieves all review issue types for a file in a single call.
**Parameters:**
| Parameter | Type | Required | Description |
|-----------|------|----------|-------------|
| `repositoryName` | string | Yes | The repository name, e.g. `owner/repo-name`. Case-insensitive; the server normalises the value. |
| `branchName` | string | Yes | Current branch (from `git branch --show-current`) |
| `filePath` | string | Yes | Relative directory path with forward slashes and trailing `/`. Empty string for root files. |
| `fileName` | string | Yes | Filename with extension |
| `analysisName` | string | No | The analysis project name for mono-repo disambiguation. Case-insensitive. Leave empty for single-project repositories. **Qualimetry Enterprise only.** |
| `pullRequest` | string | No | The pull-request number/id. When supplied, only issues flagged `IsPullRequestIssue` (raised on the pull request's new code) are returned. Resolve it with **standard git only** — `git ls-remote origin "refs/pull/*/head" "refs/merge-requests/*/head" "refs/pull-requests/*/from"` and take the ref whose SHA equals the branch's remote head (GitHub / GitLab / Bitbucket Server). Leave empty to return all issues for the file. |
**Returns:** JSON array of `CodeReviewIssue` objects with `ReviewType` populated.
### Individual Review Tools (fallback)
If `get_all_review_issues` is unavailable, call each tool individually with the same parameters (each also accepts the optional `pullRequest`):
| Tool | Review Type | Description |
|------|-------------|-------------|
| `get_coding_standards_review_issues` | CodingStandards | Language-specific coding standard violations |
| `get_design_best_practice_review_issues` | DesignBestPractices | Design pattern and best practice issues |
| `get_general_principles_review_issues` | GeneralPrinciples | General coding principle violations |
| `get_secure_principles_review_issues` | SecurePrinciples | Secure coding principle violations |
| `get_policies_review_issues` | Policies | Organisation policy violations |
### get_standards_compliant_example
Retrieves a compliant code example showing how to resolve the issues found. This tool must be enabled by an organisation administrator in the AI Settings page. If it has not been enabled, the tool returns a message stating so.
**Parameters:** Same parameters as above (`repositoryName`, `branchName`, `filePath`, `fileName`, and optional `analysisName`).
**Returns:** A string containing the compliant code example, or a message indicating the feature is not enabled.
---
## Response Schema: CodeReviewIssue
```json
{
"CreatedDateTime": "2026-03-10T14:30:00Z",
"MajorCategory": "string",
"MinorCategory": "string",
"Explanation": "string",
"SuggestedRemedy": "string",
"IsPullRequestIssue": true,
"Severity": "High | Medium | Low",
"ReviewType": "string"
}
```
| Field | Description |
|-------|-------------|
| `CreatedDateTime` | UTC timestamp when the issue was created |
| `MajorCategory` | Top-level classification (e.g., Security, Maintainability, Performance) |
| `MinorCategory` | Specific rule or subcategory |
| `Explanation` | Detailed description of the violation |
| `SuggestedRemedy` | Suggested fix or improvement |
| `IsPullRequestIssue` | `true` if found on a line altered in the most recent pull request review |
| `Severity` | `High`, `Medium`, or `Low` |
| `ReviewType` | Review category: `CodingStandards`, `DesignBestPractices`, `GeneralPrinciples`, `SecurePrinciples`, or `Policies`. Only populated by `get_all_review_issues`. |
---
## File Path Splitting Rules
The `filePath` and `fileName` parameters must follow these conventions:
1. Paths are **relative to the repository root**, not absolute
2. Use **forward slashes** (`/`), even on Windows
3. `filePath` is the **directory portion only**, with a **trailing slash**
4. `fileName` is just the **filename with extension**
5. For files at the repository root, `filePath` is an **empty string**
### Examples
| Full Relative Path | `filePath` | `fileName` |
|-------------------|------------|------------|
| `src/Services/MyService.cs` | `src/Services/` | `MyService.cs` |
| `Program.cs` | `` (empty) | `Program.cs` |
| `tests/unit/TestHelper.java` | `tests/unit/` | `TestHelper.java` |
| `src/main/java/com/example/App.java` | `src/main/java/com/example/` | `App.java` |
| `Controllers/Api/UserController.cs` | `Controllers/Api/` | `UserController.cs` |
---
## Presentation Format
Present issues to the user using this structure:
```
## Review Issues for `<fileName>`
### Coding Standards (N issues)
**[High]** MajorCategory > MinorCategory
Explanation text here.
**Remedy:** Suggested remedy text.
**[Medium]** MajorCategory > MinorCategory
...
### Design Best Practices (N issues)
...
### General Principles (N issues)
...
### Secure Principles (N issues)
...
### Policies (N issues)
...
## Compliant Code Example
<compliant code example here>
```
- Group by **ReviewType** in the order shown above
- Within each group, order by **severity**: High first, then Medium, then Low
- Only show groups that have issues
- Always call `get_standards_compliant_example` if any issues were found. If the tool returns a message that the feature is not enabled, present the issues without the example and relay the message to the user.
---
## Review Types
| Review Type | What It Checks |
|-------------|----------------|
| **CodingStandards** | Violations of language-specific coding standards (naming, formatting, structure) |
| **DesignBestPractices** | Design pattern issues, architectural anti-patterns, industry best practices |
| **GeneralPrinciples** | General coding principles (DRY, SOLID, clean code, readability) |
| **SecurePrinciples** | Security vulnerabilities and secure coding practice violations (OWASP, input validation) |
| **Policies** | Organisation-specific policy violations (custom rules, compliance requirements) |
---
## Error Handling
| Scenario | Action |
|----------|--------|
| No review found for the file | Inform the user: "No Qualimetry code review found for this file on this branch. The file may not have been reviewed yet." |
| MCP tool unavailable | Inform the user that the Qualimetry MCP server may not be configured |
| Git commands fail | Inform the user that git is required and must be initialised in the project |
| `get_all_review_issues` unavailable | Fall back to calling the five individual review tools |
| Compliant example unavailable | Present the issues without the example; note that no compliant example is available |
| Compliant example not enabled | The tool returns a message that the feature must be enabled by an organisation administrator. Relay this message to the user. |
SKILL.md
---
name: review-check
description: >
Checks for all types of code review issues found by the Qualimetry HITL code
reviewer on a source file, including coding standards violations, design and
best practice issues, general coding principle violations, secure coding
principle violations, and policy violations. Retrieves a compliant code
example showing how to resolve the issues. Invoked as the review-check skill,
optionally with a file path argument, to check a previously reviewed file.
license: Apache-2.0
compatibility: Requires the Qualimetry MCP server and git to be configured.
allowed-tools: get_all_review_issues get_coding_standards_review_issues get_design_best_practice_review_issues get_general_principles_review_issues get_secure_principles_review_issues get_policies_review_issues get_standards_compliant_example
metadata:
author: qualimetry
version: "1.1"
homepage: https://qualimetry.com
---
# Review Issues Check
When working with a source file that may have been previously reviewed by Qualimetry, follow this workflow to retrieve and present any review issues found.
## Step 1: Determine the Target File
Identify the file to check:
- If invoked with an argument (e.g. `review-check src/MyService.cs`), use that file path.
- Otherwise, use the file currently being discussed or edited in the conversation.
## Step 2: Gather Repository Information
Determine the `repositoryName` and `branchName`:
**`repositoryName`** — the repository name in `owner/repo-name` format (e.g., `organisation/my-project`). The server is case-insensitive and handles `.git` suffixes automatically.
**`analysisName`** *(optional, Qualimetry Enterprise only)* — if the repository is a mono-repo with multiple analysis projects, provide the analysis project name to disambiguate. Case-insensitive. Leave empty for single-project repositories. If omitted and multiple projects are found, the server returns an error listing the available analysis names.
**`branchName`** — run this shell command:
```bash
git branch --show-current
```
This returns the branch name (e.g., `main`, `develop`, `feature/login-page`).
**`pullRequest`** *(optional)* — to limit the results to the issues raised on a pull request's new code, supply the PR number. Resolve it for the current branch using **standard git only** — no GitHub/Azure/Bitbucket CLI required. Every major host advertises the PR as a ref whose head equals the source-branch tip, so match the branch's remote head SHA against those refs:
```bash
BRANCH=$(git branch --show-current)
SHA=$(git ls-remote origin "refs/heads/$BRANCH" | cut -f1)
git ls-remote origin "refs/pull/*/head" "refs/merge-requests/*/head" "refs/pull-requests/*/from" \
| awk -v s="$SHA" '$1==s{print $2; exit}' | grep -oE '[0-9]+' | head -1
```
This covers GitHub (`refs/pull/<n>/head`), GitLab (`refs/merge-requests/<n>/head`) and Bitbucket Server (`refs/pull-requests/<n>/from`). If it prints nothing — the branch is not pushed, or the host does not expose PR refs over git (e.g. Bitbucket Cloud, Azure DevOps) — omit `pullRequest` and the tools return all review issues for the file.
## Step 3: Split the File Path
Split the file's path relative to the repository root into two parts:
- **`filePath`**: The directory portion, using forward slashes (`/`), with a trailing slash. Example: `src/main/java/com/example/`
- **`fileName`**: Just the filename with extension. Example: `Main.java`
Rules:
- Convert backslashes to forward slashes.
- The path must be relative to the repository root, not an absolute path.
- If the file is at the repository root, `filePath` should be an empty string.
Examples:
| Full relative path | `filePath` | `fileName` |
|-------------------|------------|------------|
| `src/Services/MyService.cs` | `src/Services/` | `MyService.cs` |
| `Program.cs` | `` | `Program.cs` |
| `tests/unit/TestHelper.java` | `tests/unit/` | `TestHelper.java` |
## Step 4: Retrieve Review Issues
Call the Qualimetry MCP tool `get_all_review_issues` with these parameters:
- `repositoryName` - from Step 2
- `branchName` - from Step 2
- `filePath` - from Step 3
- `fileName` - from Step 3
- `pullRequest` (optional) - from Step 2, to return only the pull-request issues for the file
This single call returns all review issue types (coding standards, design best practices, general principles, secure principles, and policy violations).
**Fallback:** If `get_all_review_issues` is not available, call each tool individually and merge the results:
1. `get_coding_standards_review_issues`
2. `get_design_best_practice_review_issues`
3. `get_general_principles_review_issues`
4. `get_secure_principles_review_issues`
5. `get_policies_review_issues`
All tools take the same four parameters, plus the optional `pullRequest`.
## Step 5: Present the Issues
If issues were found, present them to the user:
1. **Group by review type** (e.g., Coding Standards, Design Best Practices, General Principles, Secure Principles, Policies).
2. **Within each group, order by severity** (High first, then Medium, then Low).
3. **For each issue, show:**
- Severity (High / Medium / Low)
- Major Category and Minor Category
- Explanation of the issue
- Suggested Remedy
## Step 6: Retrieve Compliant Code Example
If issues were found, also call `get_standards_compliant_example` with the same four parameters (`repositoryName`, `branchName`, `filePath`, `fileName`).
This tool requires an organisation administrator to enable it in the AI Settings page. If the tool returns a message indicating the feature is not enabled, present the review issues without the example and relay the message to the user.
Present the compliant code example as a reference showing how the issues could be resolved. Note that this example should be carefully reviewed - it is a suggestion, not necessarily the final solution.
## Step 7: Handle No Results
- If no review was found for the file, inform the user: "No Qualimetry code review found for this file on this branch. The file may not have been reviewed yet."
- If a Qualimetry MCP tool is not available, inform the user that the Qualimetry MCP server may not be configured.
## Important
- Always use `git branch --show-current` to get the branch name. Do not assume `main` or `master`.
- To check only a pull request's findings, resolve its number with standard git (`git ls-remote origin` against the host's PR refs — see Step 2) and pass it as `pullRequest`.
- File paths must use forward slashes, even on Windows.
- The `filePath` parameter must include a trailing slash if non-empty.
## Related: Rules-Based Analysis Issues (Qualimetry Enterprise)
On Qualimetry Enterprise, additional tools are available for retrieving live
rules-based analysis issues (bugs, vulnerabilities, code smells) for a
repository branch. These are distinct from the HITL code review issues
retrieved by this skill:
- `get_rules_based_analysis_issues_summary` -- total counts by type and severity
- `get_rules_based_analysis_issues` -- paginated issues with filtering
See the `analysis-issues` skill for the full workflow.
For full MCP tool schemas, response formats, file path splitting rules, and presentation templates, see [reference.md](./reference.md).