From codacy-skills
Enriches pull request code reviews with Codacy data — quality issues, security findings, coverage, and duplication. Use whenever the user asks to review a PR, check what a pull request introduced, verify PR coverage, look at PR quality, or find new issues in a PR. Also use when another code-review skill is active (e.g. CodeRabbit) to layer Codacy data on top. Trigger this skill for any pull request review workflow, even if the user just says "review PR 42" or "what's wrong with this PR".
How this skill is triggered — by the user, by Claude, or both
Slash command
/codacy-skills:codacy-code-reviewThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
> **Glossary:** See [glossary.md](../../references/glossary.md) for shared definitions of Codacy concepts (issues, findings, severity, coverage, tools, patterns, etc.).
Glossary: See glossary.md for shared definitions of Codacy concepts (issues, findings, severity, coverage, tools, patterns, etc.).
This skill enriches code reviews with Codacy data. It works alongside any existing code review process (a code-review skill, CodeRabbit, manual review, etc.) — it adds Codacy-specific data on top.
codacy-analysis) — for fast local analysis. See codacy-analysis-cli for setup.codacy) — for coverage data, quality gate status, and ignoring issues. See codacy-cloud-cli for setup.Both CLIs share credentials at ~/.codacy/credentials, so a single login covers both.
This skill uses two complementary analysis sources:
| Source | What it provides | Speed |
|---|---|---|
| Analysis CLI (local) | Issues and security findings on PR changes | Instant — no push or remote analysis needed |
| Cloud CLI (remote) | Coverage delta, quality gate, duplication, issue management (ignore/unignore) | Requires the PR to be pushed and analyzed by Codacy |
Prefer local analysis for issue detection — it runs immediately on the current working tree with --pr and doesn't require waiting for remote analysis. Use the Cloud CLI to supplement with coverage data and quality gate status, and to manage issues (ignore/unignore).
The Analysis CLI may not support every tool that Codacy Cloud runs. If the project uses tools not available locally (check with codacy-analysis analyze --inspect --output-format json), flag that some findings may only appear in the Cloud results.
codacy-analysis analyze --pr compares the current branch against the PR's target branch, catching issues even before pushing.codacy pull-request <provider> <org> <repo> <prNumber> --reanalyze-and-wait to trigger reanalysis and block until it completes (polls every 10 seconds, up to 20 minutes). For fire-and-forget, use --reanalyze instead and re-check manually.codacy pull-request <prNumber> work without explicit parameters.When reviewing a pull request, follow these steps. Always complete all steps — do not skip.
Code Review Progress:
- [ ] Step 1: Gather PR context (title, description, linked ticket)
- [ ] Step 2: Run local analysis on PR changes
- [ ] Step 3: Fetch Cloud PR data (coverage, quality gate)
- [ ] Step 4: Check introduced issues
- [ ] Step 5: Check coverage
- [ ] Step 6: Verify alignment with ticket and PR description
- [ ] Step 7: Propose test plan and check coverage gaps
- [ ] Step 8: Summarize and suggest improvements
Fetch the pull request metadata from the source provider (GitHub, GitLab, Bitbucket):
If there is a linked ticket, fetch its content as well.
Run the Analysis CLI to get immediate results on the changed files — no need to wait for remote analysis:
# If the PR already exists (compares against the PR's target branch)
codacy-analysis analyze --pr --output-format json
# If the PR hasn't been created yet (compares against the merge base of the current branch)
codacy-analysis analyze --diff --output-format json
Use --pr when the pull request exists, --diff when you're reviewing changes on a branch before the PR is opened. Both run all locally available tools on the changed files only.
If the project hasn't been initialized for local analysis yet:
codacy-analysis init
codacy-analysis analyze --pr --install-dependencies --output-format json
Parse the local results for issues — these are available immediately and cover the bulk of the review. Note any tools listed in capability.unavailable that might provide additional findings only through Codacy Cloud.
Coverage, quality gate status, and duplication metrics are only available from Codacy Cloud:
codacy pull-request <provider> <org> <repo> <prNumber>
This returns: up-to-standards status, coverage delta, complexity delta, duplication delta, and changed files.
For the annotated diff with inline coverage annotations:
codacy pull-request <provider> <org> <repo> <prNumber> --diff
If the remote analysis is stale or missing, trigger a reanalysis and wait for completion:
codacy pull-request <provider> <org> <repo> <prNumber> --reanalyze-and-wait
This blocks until reanalysis finishes (up to 20 minutes) and reports the delta. While waiting, continue the review using local results from Step 2. For fire-and-forget reanalysis, use --reanalyze instead.
Combine findings from both local analysis (Step 2) and Cloud data (Step 3):
If issues look like false positives, suggest ignoring them via the Cloud CLI:
# Ignore a specific issue in this PR
codacy pull-request <provider> <org> <repo> <prNumber> --ignore-issue <issueId> --ignore-reason FalsePositive
# Ignore all issues Codacy identified as potential false positives in one go
codacy pull-request <provider> <org> <repo> <prNumber> --ignore-all-false-positives
# Unignore if needed
codacy pull-request <provider> <org> <repo> <prNumber> --unignore-issue <issueId>
If the same false positive pattern keeps appearing across PRs, suggest disabling the pattern via configure-codacy instead.
Coverage data comes from the Cloud CLI (Step 3). Review:
--diff output to see which specific lines lack coverage (✘ markers)Flag files with new uncovered lines as needing tests.
With the ticket/issue: Check that the code changes address the stated requirements. Note any functionality described in the ticket that is not present in the changes. Note any changes that go beyond the scope of the ticket.
With the PR description: Verify the description accurately reflects what was changed. Note discrepancies.
If the ticket or PR description is missing, incomplete, or inaccurate, note specific improvements to suggest.
Based on the changed code and coverage data:
Present a structured review summary:
## Codacy Review Summary
### Quality gate
[Pass / Fail — from Codacy PR analysis]
### Issues introduced
[List issues by severity, or "None"]
### Coverage
[Delta, uncovered lines in new code]
### Alignment
- Ticket: [aligned / gaps noted]
- PR description: [accurate / suggestions]
### Test plan
[Proposed scenarios and whether tests exist]
### Suggested improvements
- PR description: [if applicable]
- Ticket/issue: [if applicable]
If a code review skill (e.g. code-review skill, CodeRabbit) has already performed a review, add a Codacy data section to that review rather than replacing it. Follow steps 2–7 above and append the Codacy findings.
npx claudepluginhub codacy/codacy-skills --plugin codacy-skillsProvides CDSS development patterns for drug interaction checking, dose validation, clinical scoring (NEWS2, qSOFA), and alert classification integrated into EMR workflows.