Classifying Review Findings
- 80 installs
- 129 repo stars
- Updated August 4, 2026
- bitwarden/ai-plugins
Classifying Review Findings is a Claude skill that categorizes code review findings into five severity levels with emoji labels for PR comments.
About
This skill categorizes code review findings into severity levels for PR comments. It maps each finding to one of five categories (CRITICAL, IMPORTANT, DEBT, SUGGESTED, QUESTION) with an emoji and criteria, requires three verification checks before classifying, and rejects non-findings like praise, style preferences, and naming nitpicks. A developer uses it to consistently label and prioritize review findings when commenting on a PR.
- Five severity categories with emoji, label, and criteria
- Verification gate before any finding is classified
- Measurable criteria for SUGGESTED improvements (complexity reduction of 3+)
Classifying Review Findings by the numbers
- 80 all-time installs (skills.sh)
- Ranked #487 of 1,352 Code Review & Quality skills by installs in the Skillselion catalog
- Data as of Aug 5, 2026 (Skillselion catalog sync)
classifying-review-findings capabilities & compatibility
- Capabilities
- code review · finding classification
- Use cases
- code review
What classifying-review-findings says it does
CRITICAL | Will break, crash, expose data, or violate requirements
If you can't measure the improvement, don't suggest it.
npx skills add https://github.com/bitwarden/ai-plugins --skill classifying-review-findingsAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 80 |
|---|---|
| repo stars | ★ 129 |
| Last updated | August 4, 2026 |
| Repository | bitwarden/ai-plugins ↗ |
What it does
Classify code review findings into severity levels with emoji labels for PR comments.
Who is it for?
Consistently labeling and prioritizing code review findings when commenting on a PR.
Skip if: Generating or verifying the findings themselves beyond the classification gate.
When should I use this skill?
You are categorizing code review findings into severity levels or deciding which emoji and label to use for PR comments.
What you get
Each valid finding is classified into one of five severity levels with a consistent emoji and label.
- Severity-classified code review findings
By the numbers
- 5 severity categories
- 3 verification checks before classifying
- Complexity-reduction threshold of 3+
Files
Classifying Review Findings
Severity Categories
| Emoji | Category | Criteria |
|---|---|---|
| ❌ | CRITICAL | Will break, crash, expose data, or violate requirements |
| ⚠️ | IMPORTANT | Missing error handling, unhandled edge cases, could cause bugs |
| ♻️ | DEBT | Duplicates patterns, violates conventions, needs rework within 6 months |
| 🎨 | SUGGESTED | Measurably improves security, reduces complexity by 3+, eliminates bug classes |
| ❓ | QUESTION | Requires human knowledge - unclear requirements, intent, or system conflicts |
ALWAYS use hybrid emoji + text format for each finding (if multiple severities apply, use the most severe: ❌ > ⚠️ > ♻️ > 🎨 > ❓):
Before Classifying
Verify ALL three:
1. Can you trace the execution path showing incorrect behavior? 2. Is this handled elsewhere (error boundaries, middleware, validators)? 3. Are you certain about framework behavior and language semantics?
If any answer is "no" or "unsure" → DO NOT classify as a finding.
Not Valid Findings (Reject)
- Praise ("great implementation")
- Vague suggestions ("could be simpler")
- Style preferences without enforced standard
- Naming nitpicks unless actively misleading
- PR metadata issues (title, description, test plan) - handled by summary skill, not classified here
- Renovate/Dependabot minor/patch updates to existing dependencies with passing CI — these are routine Stage 5 monitoring, not reviewable findings
Suggested Improvements (🎨) Criteria
Only suggest improvements that provide measurable value:
1. Security gain - Eliminates entire vulnerability class (SQL injection, XSS, etc.) 2. Complexity reduction - Reduces cyclomatic complexity by 3+, eliminates nesting level 3. Bug prevention - Makes entire category of bugs impossible (type safety, null safety) 4. Performance gain - Reduces O(n²) to O(n), eliminates N+1 queries (provide evidence)
Provide concrete metrics:
- ❌ "This could be simpler"
- ✅ "This has cyclomatic complexity of 12; extracting validation logic would reduce to 6"
If you can't measure the improvement, don't suggest it.
Related skills
Improve Codebase ArchitectureSafely deepen clusters of shallow modules into cohesive, testable units while respecting their external dependencies.566k196k
Caveman ReviewGet ultra-compressed, one-line code review comments that cut noise while keeping every actionable fix.270k94.7kCodebase DesignShared vocabulary for designing deep modules: improve a module's interface, find deepening opportunities, decide where a seam goes, make code more testable.266k196kCavecrewDelegate coding tasks to specialized subagents that return compressed output, keeping the main context window usable for much longer sessions.220k94.7kCode ReviewReviews a branch or PR diff on two axes at once: conformance to coding standards plus a code-smell baseline, and whether it actually implements the original spec.201k196k
Requesting Code ReviewDispatch a consistent, high-signal code reviewer subagent that catches plan deviations and quality issues before merging or continuing development.183k264kFAQ
What are the severity categories?
CRITICAL, IMPORTANT, DEBT, SUGGESTED, and QUESTION, each with an emoji and criteria.
When should a SUGGESTED improvement be raised?
Only when it provides measurable value, such as reducing cyclomatic complexity by 3 or more or eliminating a vulnerability class.