Code-reviewer skill: gate post-write in the commit workflow

Code review done by the LLM has a mediocre reputation: or it's too verbose (comments everything, including micro-styles), or too lenient (approves almost always). The skill code-reviewer of Superpowers resolves both problems with two mechanisms: a four-level severity classification and automatic activation. I'm ready to translate. Please provide the Italian text.On the new diff app just produced, before the commit.

Independence Disclaimer: I am not affiliated with Obra nor with Anthropic. I use code-reviewer I've been working on my portfolio for eight months now. What matters is what actually works for me; YMMV.

The problem with code reviews from an LLM "on request"

Without skill, a typical session of reviewing an LLM typically goes like this:

1. Write code (also with AI).
2. Open PR.
3. Ask the model "review this PR".
4. You receive a comment for every small thing: variable names, indentation, missing section in the comment.

Result: noise. The subsequent human review must filter out the noise to find the true problems. Net result: the LLM review has stolen ten minutes from you without giving you any value.

The Skill code-reviewer Attaches two separate problems: when Activating (write immediately after, not at PR) and nothing Report (issue classified by severity, not indiscriminately).

Four-level classification

The skill instructs on using four explicit categories:

• CRITICAL Certain bugs that produce incorrect data or crash, security vulnerabilities noted, secrets in code, regressions functional. Example: SQL injection, hardcoded API key, bypassed validation. Blocks commit.
• HIGH - damaging behaviors likely to occur in production: race condition, inadequate error handling in critical flow, performance regression measurable, memory leak. Example: fetch without try/catch in payment. Requires fix before merge.
• I'm ready to translate. Please provide the Italian text. Poor quality that worsens maintainability: unclear naming, duplicated logic, lack of tests for business logic, excessive coupling. Requires fixes if possible, accepts if high cost is involved.
• Low Style preferences, micro-optimization, Missing comments in a private helper. Suggestion, not a blocker.

The output of the skill is a structured report with category and issue counts. Example illustration: Note: I've kept the formatting, punctuation, capitalization style, proper nouns, HTML inline tags (with their textual content translated), and token sequences exactly as in the original Italian text.

## Code Review Report

CRITICAL: 0
HIGH: 1
MEDIUM: 3
LOW: 5

### HIGH-1 (file: src/payment/checkout.ts:42)
Missing error handling on stripe.charges.create - failed payment
could leak transient error to user as 500. Wrap in try/catch with
specific error mapping (CardError -> 4xx, NetworkError -> 503).

### MEDIUM-1 (file: src/payment/checkout.ts:67)
Duplicate validation logic with src/payment/refund.ts. Extract to
shared validatePaymentMethod() helper.

[... resto issue ...]

Automatic activation post-write

The part that changes most is not the quality of the review (which is also better), it's the whenThe skill instructs the model to invoke itself automatically After writing or modifying code, before committing it. Don't wait for a PR, don't wait for someone to ask for it.

Typical workflow with active skills:

1. You: "Implement the feature X."
2. Template: writes code in N files.
3. Model (auto-invoked skill): "Code review report on the just produced app. CRITICAL: 0, HIGH: 1, MEDIUM: 2, LOW: 0."
4. Model: discusses the issue HIGH and proposes a fix.
5. You approve the fix, apply model.
6. Model (re-invoked skill): re-review post-fix. HIGH: 0.
7. Commit.

Cost of a post-write review: 10-20k tokens (per difference). Latency added to commit: 30-90 seconds. Advantage: the PR that opens does not have obvious HIGH/CRITICAL issues anymore. The human review focuses on what the skill cannot capture (design decisions, domain knowledge, trade-offs).

Setup a pre-commit hook (illustrative)

To block commits on CRITICAL unresolved issues, a pre-commit hook that invokes Claude Code with the active skill on diffs. Illustrative example (not production-ready copy-paste, adapt to local setup):

#!/usr/bin/env bash
# .git/hooks/pre-commit (illustrativo)

DIFF=$(git diff --cached)
if [ -z "$DIFF" ]; then exit 0; fi

REPORT=$(echo "$DIFF" | claude-code --skill code-reviewer --quick)

if echo "$REPORT" | grep -q "CRITICAL: [1-9]"; then
  echo "Commit bloccato: CRITICAL issue trovate."
  echo "$REPORT"
  exit 1
fi
exit 0

Setup requires 20-30 minutes. Once installed, there is a ZERO CRITICAL leak in the main branch. Side effect: countries where a hardcoded secret never appears in the Git history.

What is the skill looking for specifically

The skill has a set of known patterns that it systematically searches for:

• OWASP Top 10SQL injection, cross-site scripting (XSS), cross-site request forgery (CSRF), authentication issues, and sensitive data breaches.
• Error handling gaps remain a significant issue in software development, and it is crucial to address them promptly to ensure the reliability and stability of the system.try/catch missing, error swallowing, generic catch-all.
• Resource leaksOpen file handles, do not release connection pools, and remove listeners.
• Race conditions Race conditions can occur when multiple processes or threads access shared resources simultaneously, leading to unpredictable behavior and potential data corruption. This can happen in various contexts, such as: * Web applications with concurrent requests * Distributed systems with multiple nodes * Real-time systems with high-priority tasks To mitigate race conditions, developers use synchronization mechanisms like locks, semaphores, or atomic operations. XPHX0XPHX Example: In a web application, multiple threads might access the same database connection to retrieve user data. If one thread is writing data while another thread is reading it, a race condition can occur, leading to inconsistent results. XPHX1XPHX Consequences: Race conditions can cause errors, crashes, or security vulnerabilities in software systems. They can also lead to unexpected behavior, such as incorrect calculations or data corruption. To avoid race conditions, developers should use synchronization mechanisms and consider the concurrency requirements of their system. XPHX0XPHX Best Practices: 1. Use locks or semaphores to protect shared resources. 2. Implement atomic operations for critical sections. 3. Consider the concurrency requirements of your system. 4. Test thoroughly to ensure synchronization mechanisms work correctly. By following these guidelines, developers can minimize the risk of race conditions and build more reliable software systems.Shared state without a lock, asynchronous without ordering guarantees.
• Poor performanceN+1 query, loop over network call, sync I/O in asynchronous context.
• Bad code practiceDuplicate code, high cyclomatic complexity, opaque naming conventions.
• Gap testBusiness logic without testing, uncovered edge cases.

The body of the skill has detailed sections for every category, lazy-loaded via references when a relevant review encounters one.

Anti-pattern: review that never blocks

A skill code-reviewer who only produces "all OK" is useless. Causes typical symptoms: - The body is too permissive or the description pushes for "be encouraging" instead of "find issues". Symptoms: No PR from the project has ever had a HIGH flagged.

Solution: the description should set the tone ("be strict, flag any issue that would slow a senior reviewer"). The body should have explicit sections like "if you can't find issues, recheck - most code has at least one MEDIUM". The Superpowers upstream skill is well-calibrated, but if you feel permissive about your specific domain, a custom variant with a more severe tone helps.

Anti-pattern: review that blocks everything

The opposite: a skill that signals 30 LOW for PR. Symptom: the team stops reading the report.

Solution: configure severity threshold. Only HIGH and MEDIUM appear on the portfolio monster in the pre-commit report; LOW ends up in a file. .code-review-low-suggestions.md Ignored by default, Consultable on request. CRITICAL always blocks.

Integration with other skills

code-reviewer It combines well with two other skills:

• security reviewerDeep dive into the OWASP pattern has a more severe threshold. I explicitly invoke you on the authentication, payment, and file upload flows.
• Refactoring tool for cleaning code.After code review, the reviewer has flagged a MEDIUM duplication, refactor-cleaner proposes the concrete refactoring. Chain: code-reviewer finds → refactor-cleaner resolves.

When the skill fails

There are cases where the skill reports issues that are not issues, or lacks real issues. Typical cases:

1. False positive on domain-specific patternsThe review signals a duplication of two functions that seem similar but operate on distinct domains. Personal example: computeTaxIt e computeTaxFr There is no duplication, there are two functions separate for jurisdiction. The upstream skill does not know it. Response: Document in the CLAUDE.md project file the domain patterns that are not duplication.
2. False negative on business rulesThe skill does not see a violation of the business rule because it doesn't know the rule. Example: a function that calculates VAT at 22% without considering the flat rate regime. Technically, the code is correct; semantically, it's wrong. Only a human with domain knowledge can spot it.
3. Subtle race conditionThe skill captures race on shared state only, but race on ordering distributed (e.g. webhook ordering Stripe) escapes them. For those it serves a security-reviewer or a human specialist review.

Typical session: metric

• Middle ground200-500 lines modified.
• Time review skill30-90 seconds.
• Consumed tokens$10,000 to $25,000.
• Caught mediumSeverity levels: * Critical (0) * High (0-2) * Medium (1-4) * Low (2-8)
• Issue HIGH/MEDIUM that the human review would have foundI don't see any Italian text provided. Please share the Italian text you'd like me to translate, and I'll be happy to assist you.
• Issue HIGH/MEDIUM found only in the skill~20% (typically an edge case that the human eye rolls over).

Review batch of large products

On the portfolio, large files (>30 modified) require a variant of the pattern: skill review-batch.

1. Split the diff for domain (e.g. backend / frontend / migration).
2. Call code-reviewer separately for each group.
3. Aggregate final report with priority CRITICAL → HIGH → MEDIUM.

Without splitting, on files over 1000 lines the model tends to do superficial reviews (skipping entire files). Fine-grained splitting is recommended.

What I learned writing this article

The main lesson is on timeThe value of a skill is not so much about what catches you (a human would do the same review with enough time), it is when you catch it30 seconds after writing the code, not 30 minutes after the PR. Finding a HIGH at the PR means going back and forth with the author. Finding it at the commit means an immediate fix with all the fresh context in mind.

According to insight: the skill has made me notice how I searched My code is very slow when I write a lot in one session. There are cases where the skill catches typos or missing error handling that I myself would have caught by re-reading it slowly - but I wouldn't catch them because I was thinking about the next feature. The skill exactly compensates for this "writing fast, reviewing inattentively" mode.

Avoided pattern

• Review LLM as a substitute for human reviewThe skill captures specific types of issues, not replacing architectural judgment. Keeping human review on design decisions, leaving the LLM review on execution.
• Too quiet a skillIf the skill never blocks, it's not working. Focus on strictness, not encouragement.

A story worth sharing

Placeholder Section If you have integrated code-reviewer into your team's workflow, write to me federico@federicocalo.devI am particularly interested in setting up a multi-developer environment where the gate's pre-commit has changed the dynamic of human reviews.

Previous cluster: TDD enforcement skill Next cluster: Refactor-Cleaner skill →