Performs confidence-based code review filtering issues at 80+ threshold for bugs, quality issues, conventions against plans or requirements. Use after major features, before merging, or per task in workflows.
From popkit-opsnpx claudepluginhub jrc1883/popkit-ai --plugin popkit-opsThis skill uses the workspace's default tool permissions.
checklists/review-checklist.mdstandards/review-output.mdDesigns and optimizes AI agent action spaces, tool definitions, observation formats, error recovery, and context for higher task completion rates.
Implements structured self-debugging workflow for AI agent failures: capture errors, diagnose patterns like loops or context overflow, apply contained recoveries, and generate introspection reports.
Compares coding agents like Claude Code and Aider on custom YAML-defined codebase tasks using git worktrees, measuring pass rate, cost, time, and consistency.
Review code for bugs, quality issues, and project conventions with confidence-based filtering. Only reports HIGH confidence issues to reduce noise.
Core principle: Review early, review often. Filter out false positives.
Mandatory:
Optional but valuable:
Each identified issue receives a confidence score (0-100):
| Score | Meaning | Action |
|---|---|---|
| 0 | Not a real problem | Ignore |
| 25 | Possibly valid | Ignore |
| 50 | Moderately confident | Note for reference |
| 75 | Highly confident | Report |
| 100 | Absolutely certain | Report as critical |
Threshold: 80+ - Only issues scoring 80 or higher are reported.
## Code Review: [Feature/PR Name]
### Summary
[1-2 sentences on overall quality]
### Critical Issues (Must Fix)
_Issues with confidence 90+_
#### Issue 1: [Title]
- **File**: `path/to/file.ts:line`
- **Confidence**: 95/100
- **Category**: Bug/Correctness
- **Description**: What's wrong
- **Fix**: How to fix it
### Important Issues (Should Fix)
_Issues with confidence 80-89_
#### Issue 2: [Title]
- **File**: `path/to/file.ts:line`
- **Confidence**: 82/100
- **Category**: Conventions
- **Description**: What's wrong
- **Fix**: How to fix it
### Assessment
**Ready to merge?** Yes / No / With fixes
**Reasoning**: [1-2 sentences explaining the assessment]
### Quality Score: [X/10]
1. Get git SHAs:
BASE_SHA=$(git rev-parse HEAD~1) # or origin/main
HEAD_SHA=$(git rev-parse HEAD)
2. Dispatch code-reviewer subagent:
3. Act on feedback:
Launch 3 code-reviewer agents in parallel with different focuses:
Consolidate findings and filter by confidence threshold.
Never:
If reviewer wrong:
"Ask what you want to do" - After presenting issues, ask the user how to proceed rather than making assumptions.
This section covers how to respond to review feedback, not how to give it.
Feedback Received → Read ALL → Verify → Evaluate → Implement → Respond
Step 1: Read ALL Comments Before Implementing ANY
Items may be related. Partial understanding = wrong implementation.
Step 2: Verify Against Actual Code
Don't assume the reviewer is right. Check:
For each suggestion:
- Does this code path actually exist?
- Does the suggested fix compile/work?
- Will it break existing functionality?
- Is the edge case real or hypothetical?
Step 3: Evaluate Technical Soundness
Push back on technically questionable suggestions:
| Reviewer Says | Your Response |
|---|---|
| "This could fail if..." (hypothetical) | "Is this edge case actually reachable? Show me the path." |
| "Use pattern X instead" | "Does X fit our architecture? What's the trade-off?" |
| "This is inefficient" | "Is this a hot path? Premature optimization?" |
| "Add validation for Y" | "Is Y possible given our type system?" |
Disagree with technical reasoning, not emotion. If you're right, show evidence.
Step 4: Implement Strategically
Order matters:
One commit per logical change. Makes it easier for re-review.
Step 5: Respond to Each Comment
| Situation | Response |
|---|---|
| Fixed the issue | "Fixed in [commit]" or just resolve the comment |
| Disagree | Technical reasoning why, ask for their perspective |
| Need clarification | Ask specific question, don't guess |
| Won't fix | Explain why (tech debt ticket? out of scope?) |
Performative Agreement:
BAD: "Great point! You're absolutely right! I'll fix that immediately!"
GOOD: "Fixed" or "Good catch" or just the fix itself
Actions demonstrate engagement better than words.
Blind Implementation:
BAD: Immediately implementing every suggestion without verification
GOOD: Verify suggestion makes sense for YOUR codebase, then implement
Defensive Reactions:
BAD: "Well actually, I wrote it this way because..."
GOOD: "Here's why I chose this approach: [technical reason]. Does that change your recommendation?"
It happens. Handle professionally:
Don't:
Stop if you're:
pop-test-driven-development)pop-systematic-debugging